AI Inside the Engineering Process: What Is Worth Automating, and What Still Needs an Engineer

Four of the vendors whose tools we support in India have put AI in four different places. Arm set out a platform strategy that spans one computing continuum, from the edge to the physical world to the cloud. SEGGER gave an AI coding agent direct control of J-Link and J-Trace. Perforce put AI-assisted remediation behind the Helix QAC and Klocwork analysis engines. Siemens EDA drew a line inside Xpedition between the work that belongs to AI and the work that belongs to algorithmic automation, and argued on its Industry Forward podcast that chip complexity has outgrown siloed design. We have covered each of those on its own, and each of those pieces stands by itself.

One more announcement sits alongside those four, and it is not an AI story at all: STMicroelectronics put J-Link into continuous validation for StellarStudio. It belongs in this piece because it is a story about what “validated” has to mean once tools start acting on their own.

This piece is the one behind them. None of the four is about a product called AI. Every one of them is about AI arriving inside a step of the engineering process that already existed: the debug loop, the static analysis backlog, design entry, inference on the part. That is a different thing from an assistant bolted on top, and it changes the question an engineering lead in Bengaluru or Pune should be asking. The question is not which vendor’s assistant is best. It is which parts of your process are now economically worth automating, and which still need an engineer in the loop because the cost of being wrong is a recall.

GSAS has worked the tooling side of exactly those steps since 2010: debug and trace, static analysis, unit test and coverage, compiler validation, PCB and IC design flows. What follows is our position, written from that standing.

The shape of what actually shipped

Look at the four as a set and one structural fact stands out. In every case the AI sits on top of a deterministic instrument that already existed, and it drives that instrument rather than replacing it.

SEGGER and Embedder. Per SEGGER’s announcement, the agent “flashes the build, sets breakpoints, inspects registers and memory, and monitors live output over RTT.” The intelligence is Embedder’s. The observation is J-Link’s, and it is the same observation a human engineer has been relying on for years. As we wrote in our coverage of the integration, the loop only works if the probe can read target RAM while the core runs, so what happens next depends on how your RTT is set up, not on the agent.

Perforce. AI-assisted remediation for Helix QAC and Klocwork is, in Perforce’s words, “Powered by QAC and Klocwork’s inter-procedural dataflow analysis”, and “Every fix requires explicit developer approval before it is applied.” The finding still comes from the qualified analysis engine. The language model writes a proposed correction for that specific finding, and Perforce states that “Automated re-analysis runs after each proposed fix is generated.” We set out the mechanics in AI-assisted code remediation for safety-critical C and C++.

Siemens EDA. Siemens is precise that “Not every problem requires AI, and not every productivity gain comes from a generative experience.” In Xpedition, AI goes where “engineers benefit from natural-language interaction, data interpretation, or assistance early in the design process”, while routing execution and rule-aware updates are handled by “algorithmic automation” that follows the constraint set. We covered that split in AI and intelligent automation in PCB design, and the broader argument about verification crossing the chip-to-board boundary in our summary of the Industry Forward episode.

Arm. The agentic platform announcement is about silicon, but the part a Cortex-M team can act on is the toolchain it already owns: Helium, CMSIS-NN, Ethos-U and Vela, reachable from the Keil MDK seat on the bench. That was the point of our read of the announcement. Here AI is not driving the tool at all. It is the workload, and the instruments that matter are the compiler, the trace probe and the linker map.

Four vendors, four steps, one pattern. The deterministic instrument is the thing that makes the AI usable, because it is the thing that tells you whether the AI was right.

The question is not which assistant is best

Once you see the pattern, the buying question changes. An assistant that cannot flash your part, cannot read your analysis engine’s dataflow and cannot see your constraint set is a chat window. An assistant wired to those things inherits whatever your instruments can observe, and no more.

So the useful decision is about the process, and it can be made with three tests that our field engineers apply on real projects.

Is the loop closed by something deterministic? A proposed static analysis fix is re-analysed by the engine that raised the finding. An agent’s firmware change is flashed and observed over RTT on real silicon. A routed bus is checked against the same rules that constrained it. In each of those cases a wrong answer from the AI is caught by the step after it, at the cost of one more turn of the loop. Where there is no such step, the AI’s output is an opinion, and an opinion has to be reviewed by a person who understands the consequence.

What does a wrong answer cost? If the answer is “a rebuild”, automate it. If the answer is “a respin”, automate the mechanical part and put an engineer on the decision. If the answer is “a field failure in a product that carries a safety claim”, the engineer stays, and the AI’s role is to make that engineer faster, not to stand in for them.

Is the work high-volume and mechanical? The first-run baseline that a mature codebase produces when a coding standard is applied for the first time is exactly this shape: thousands of findings, most of them with a small set of valid corrections. So is bring-up debugging, where the loop is flash, run, break, read, adjust. So is fan-out and escape routing. These are the steps where automation earns its keep, and they are also, not by coincidence, the steps the vendors chose first.

Apply the three tests to a typical embedded programme in India and the picture is clearer than the marketing suggests.

• First-run static analysis backlog. Worth automating now. The engine decides what is wrong, the AI proposes the fix, re-analysis closes the loop, and a developer approves. The value is in the research time between finding and fix, which is where MISRA and ISO 26262 programmes lose their schedule.
• Bring-up and intermittent-fault debugging. Worth automating, with a condition: the bench has to be instrumented first. An agent reading an empty RTT log makes the same mistake a new engineer makes on day one, and RTT control block placement, buffer mode and low-power behaviour decide whether the log is complete. Those are the things our engineers fix before an automated loop is pointed at a board.
• Test harness, stub and driver generation. Already automated, and without a language model. TESSY performs interface analysis on function signatures and generates drivers and stubs, and the Classification Tree Editor generates test vectors from partitions an engineer defines. Where AI can add something here is in drafting, and the drafting is not the evidence.
• Repetitive layout execution. Worth automating, algorithmically, which is what Siemens is doing. The router that respects the constraint set and re-applies it after every edit is the productivity gain. A generative model improvising on a DDR5 breakout is not.
• Pre-layout signal integrity decisions. Human, with a simulator. The topology, driver, package and termination choices that cause a respin are made in HyperLynx LineSim before a trace exists, with a waveform in front of an engineer. This is the step where being wrong costs a prototype spin, and it is the step least suited to a tool that cannot show its reasoning against physics.
• Test-case design against safety requirements. Human. Systematic, traceable test design is what an assessor reads, and the traceability from requirement to test to result is the deliverable. Tools carry it. People own it.
• The tool qualification argument. Human, by definition. More on that below, because it is the part that decides whether any of the above is admissible on a safety programme.

Where the human stays, and why it is not caution

There is a version of this argument that reads as timidity: keep people around because AI cannot be trusted. That is not our position, and it is not what the standards say either.

Under ISO 26262, the tool confidence level is not a property of a product. It belongs to a use case, inside a specific development process, and it is determined by the tool user. Two things drive it: whether a malfunction of the tool could introduce or fail to detect an error in the item, and how confident you are that such a malfunction would be prevented or detected downstream. The most valuable sentence in the mechanism is the one that sells nothing: a tool whose errors cannot reach the product, or would reliably be caught, needs no qualification measures at all. Our ISO 26262 page sets the mechanism out in full, and the IEC 61508 page covers the parallel T1, T2 and T3 classification for industrial programmes.

Read that against the four launches and the design principle falls out on its own. An AI assistant in the toolchain is a tool. If you place it where the step after it is a qualified analysis engine re-running, a coverage-measured test suite executing on the target, or a probe reading real memory on real silicon, then your downstream detection confidence is high and the confidence argument is tractable. If you place it where nothing deterministic follows, you have created a tool with high impact and low detection, and you now own the qualification of a non-deterministic component. Perforce’s own framing of the same point is that “Human-in-the-loop oversight is built-in”, and that code reviews remain a key and often mandatory part of safety-critical and security-critical development practice. We agree, and we would put it more strongly: the human in the loop is not a hedge against the AI, it is the detection measure that keeps the AI’s tool confidence level where you want it.

That is why the recall framing matters. It is not that a model might be wrong more often than an engineer. It is that on a safety programme the question “who confirmed this, and is that recorded” has to have an answer at every step, and a model cannot be that answer. An engineer can. The place to spend automation is on the volume between those confirmations.

The same logic applies where the AI is the product rather than the tool. Once a trained model is making decisions in the field, a deterministic verification argument is under real pressure, and that is the case the emerging AI-and-functional-safety guidance is concerned with. We covered the Perforce material on that shift in AI, Rust and the new functional safety standards, and we will not summarise standards we cannot quote.

What we tell teams in India

Four things, in the order we would do them.

Instrument before you automate. An agent inherits what the bench can observe. If your firmware does not print over RTT with the buffer mode chosen deliberately and the control block where the probe will find it, fix that first. If your static analysis runs once before a release rather than on every commit, wire it into CI first. If your unit tests do not measure structural coverage, add it first. Every one of those is worth doing whether or not an AI ever touches the project, and every one of them is the precondition for automation that can be trusted.

Treat “does the code leave the building” as the first filter. Many programmes in India, in defence, aerospace, space and increasingly in automotive work carried out under contractual source controls from European and Japanese principals, cannot send source to a cloud service at all. Perforce’s statement that “Support for private, air-gapped environments means no data leaves your network” is the property that makes remediation usable on those programmes, and its MCP delivery means the host supplies its own already-approved model. Ask the same question of every AI feature before you ask about accuracy.

Buy the instrument, not the assistant. The assistants will change. J-Link’s device coverage, a TUV-certified analysis engine’s dataflow, a constraint-driven router and a validated compiler are the durable assets, and the AI features arriving now are arriving on top of them. A team that standardises on the instruments is in a position to use whichever assistant its security function approves this year and next.

Keep the record. Every automated step on a safety programme needs a human approval that can be shown to an assessor later. Perforce builds the approval step in. For a debug agent, decide before the first run who owns the RTT channel and how the bench build differs from the production build. For automated layout, the constraint set is the record. Design the approval into the process now, because it is far harder to add after the fact.

Debug, analysis, test and design tools, supported in India

GSAS Micro Systems is Arm’s engineering partner in India for development tools. It is the authorized Perforce engineering partner in India. It is also an authorized engineering partner for SEGGER, Razorcat, Solid Sands and Siemens EDA. The instruments in this piece are the ones our field engineers work on every week: Keil MDK and ULINKpro for build and trace on Cortex-M, J-Link PRO and J-Trace PRO for the debug loop, Helix QAC and Klocwork for the analysis that decides what is wrong, TESSY for the coverage evidence, SuperTest for the compiler beneath all of it, and HyperLynx and Xpedition Standard on the board side.

We do that work on benches in Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR. If you want a view of which steps in your own process are ready to automate, and which of your instruments need setting up before an AI is pointed at them, ask an engineer a question or request a quote.

Sources: SEGGER, Embedder and SEGGER partnership announcement, 10 September 2026, Perforce, AI-Assisted Code Remediation, Siemens, Accelerate PCB design productivity with AI and intelligent automation, 18 May 2026, Arm Newsroom, The agentic era needs a computing platform everywhere, 8 September 2026