How to be in control when agents are writing the code

A change to our software starts with human intent: something we learned standing next to a surgeon, or a step towards safer surgery through better interpretation of fluorescence. An agent that knows our code, our risks and where the product is going turns that intent into a specification and shows it to us as a picture: what the change reaches, what has to move in the architecture, how the risk profile shifts. We negotiate the specification with it until we agree. Then the agent builds the implementation against what we settled on, and brings it back in the same form: easy, fast and safe to digest.

By the time the implementation reaches us, the impact analysis has been redone against the real code. It names the requirements and documents the change touches, and any requirement or test plan the build changed along the way. A diagram built from the code itself shows which parts of the system the change actually reaches. Around 2,500 automated tests have run, and the quality system has listed the reviews this change triggers, with the exact reason for each one written beside it. Then one of us sits down with a page that was prepared to be understood in ten minutes, and decides.

That last step is the one we designed everything else around.

Quality was always more than writing the code

Somebody has to prepare. Trace the change to the requirements it touches, work out what else it could affect, check the tests exist, find the clause of the standard that applies, and write it all down so the record matches the work. And somebody has to decide: is this risk acceptable, does this change go in, is this release fit to leave the building.

The second part is where the responsibility lives. The first job is where the hours went, and where the human errors crept in: a dependency missed or misread, a decision made on documentation that had gone stale. The people qualified to decide spent most of their week preparing, and the preparation was done to the depth the calendar allowed rather than the depth the risk deserved. We have built and run several quality systems before, and it was true in ours too.

Agents change the cost of the preparations, but do not take part in taking responsibility. An agent can trace, cross-check, summarise and draft on every change, not just the ones somebody had time for. We have built deterministic code native tracing to avoid stochastic variance in the outcome. The agents cannot take responsibility for a patient. So we designed our process around one question: where does people's time bring most value?

What we can afford now

Things that used to cost a day of a senior engineer's time per change, and so happened only on the big changes, now happen on all of them.

• An impact assessment on every change. Several agents read the same change with different briefs and between them name the requirements, use cases and controlled documents it modifies.
• An architecture check against the real code. At build time we harvest the call structure of the software, so the impact analysis can be checked against what the change reaches rather than what the author remembered.
• The ISO standards trace directly to our processes. Our register holds ISO 13485, IEC 62304 and ISO 14971 and other relevant standards clause by clause. A review asks which obligation applies to the change.
• Traceability that maintains itself. Every requirement carries its category, its criticality and how it is verified, and the tests are harvested from the code at every build, so the link from a requirement to its tests comes from the code.

Where the people focus

Risk decides. The quality system looks at the rows of the impact analysis and proposes what the change should trigger of quality procedures. Touch a safety or a critical requirement and a risk assessment is owed. Touch a security requirement and a security review is owed. Reach across several use cases and an architecture review is triggered. Every proposal cites the rows that caused it; the comment at the top of that code reads “never a vibe”. It proposes and never decides.

Then a person decides after having reviewed the material prepared by the agents. A person chose what to build and agreed the specification before the first line of code existed. At the point of decision it is the second time a person looks, which is what puts us in full control.

An agent cannot approve a change. The system enforces that; it is not a policy or a convention. A person approves, and if the code changes after that, the approval no longer counts and the merge stays blocked until a person looks again. None of this is a prompt an agent could reason its way around. And promoting a release to production is a manual act, done by a named person, every time.

The merge gate is the last thing asked of a change before it lands, and it is IEC 62304, clause 8.2.1, built into the tooling: a controlled item changes only in response to an approved change request.5 That is the moment responsibility is taken, and it is a person who takes it.

Agents prepare the data for the fastest and best review. Humans are always in control.

Why the agents don't sign

Agents in the loop bring their own pitfalls, and one of them has been measured. A paper published in June 2026 followed 400 reviewers through 11,429 reviews of agent-written code over seven months. The longer they were exposed, the more they approved and the less they said: approvals rose from 30% to 37% and inline comments fell by 22%.1 The authors' reading is habituation under workload. We don't think we're immune, so we treat it as a risk and mitigate it.

The human decision is kept small, pointed and informed. That is how we avoid review fatigue and auto-approve behaviour. The agents prepare a change page and put it in front of the reviewer: what changed, what it touches, which reviews it owes and why, and what the tests say. It doesn't ask the person to redo the analysis or read low-value reports. If the reviewer disagrees with the change proposal, it is the same conversation as at the specification: a dialogue with the agent and another round of work, until the change is shown to be good and safe. Some of the review steps suggested by the system can be waived by a human, but a waiver needs a written argument. The waivers are kept, so we can trace how our procedures are used and which of them earn their place.

A quality system can be perfectly tamper-evident and still be fiction: thirty plausible procedures, approved because they read correctly, describing a company that does not exist. That is the failure we design against.

The standards were written for this

ISO 13485, IEC 62304 and ISO 14971 do not say who writes the code or the documents. They say what has to be true: changes are controlled, requirements are traced, risks are assessed and the evidence is kept. An article from the regulatory consultancy Innolitics put it plainly this April: “Compliance is not a property of the code itself; it is a property of the evidence and provenance surrounding the code.”2

The regulators are moving the same way. Since 2 February 2026 the FDA's quality regulation incorporates ISO 13485 by reference, so one system can serve Europe and the United States.3 The FDA's guidance on the software a manufacturer uses inside its own quality system asks for a risk-based approach: more assurance where the software can affect safety or quality, less where it can't.4 That is how we treat the agents themselves. The closer an agent's output sits to a patient, the more of it a person reads.

A company with three people

We are three people building a medical device. We merge many changes every working day, and each one goes through the gate above. We follow ISO 13485, IEC 62304 and ISO 14971 because they describe the right way to build this, and because a notified body will ask. We believe we are building better software than we have ever built before, with fewer people, and the record of every change is what we would show to prove it.

Our internal tooling, our quality management system itself and our medical device software go through the same gates. This way we get to test and identify friction as much as possible.