Where AI coding tools help in an IEC 62304 process, and where they cost you time

Since AI coding assistants became usable, we have used them on regulated medical software. Chat assistants, IDE copilots, terminal coding agents, an AI design tool. The projects ranged from a hospital laboratory device and its documentation to a therapeutic embedded device with legacy code and platform work for imaging manufacturers. The stacks were embedded, desktop, web and cloud.

AI coding tools in a regulated IEC 62304 workflow

What follows is our experience on our own projects. It is not a study.

I have submitted a talk on this topic to DMEA 2027 in Munich. If it is accepted, I will go through the whole lifecycle there in detail in April.

One rule first

Nothing a tool produced went into a project without an engineer reading it.

Where it saved real time

Fit-gap analysis on legacy code. On the therapeutic device from my last post, we had to compare several hundred pages of documentation already submitted to the FDA with a 20,000 line legacy codebase. With a coding agent reading both sides and an engineer validating every finding, it took one day. Over 90 percent of the gaps it flagged were confirmed on review. Two senior engineers doing it by hand would have needed about two weeks.

Traceability work. Building a traceability matrix, finding requirements that no test covers, locating every place in the documentation that a code change will touch. The tools are fast at this, and the result is easy to check, because a link either exists or it does not.

Test skeletons from acceptance criteria. Given a requirement and its acceptance criteria, the tools write a test skeleton that is correct more than 90 percent of the time. The engineer still decides what the test should prove, but the typing is gone.

UX iteration with the client. We used an AI design tool to produce screen variants during client workshops. The back and forth that used to take several rounds of mockups happened in one session. Communication time on that project was about half of what we would have expected.

Where it did not

Checking the answer is the daily problem. These models are trained to give a plausible answer. "I do not know" scores badly in training and evaluation, a confident guess scores well. On medical software a confident wrong answer about a timing constraint or a risk control is worse than no answer.

They agree too easily. Give a model a flawed premise and it builds on it. If the requirement is wrong, you get well structured code for the wrong requirement. A critique step before planning helps: ask the tool to find what is wrong with the plan before it writes anything.

The engineering effort moves, it does not disappear. Writing gets faster. Reading, checking and iterating take longer. Across our projects, total development time did not drop noticeably. Where the planning was thin, the rework made it longer.

What changed instead

Scepticism about AI tools in regulated teams is understandable, and if the only measure is how fast production code gets written, the numbers above support it.

The tools took over the long, repetitive work around the code: tracing requirements to tests, checking documents against the implementation, writing test skeletons, carrying the same change through several documents. Our most experienced developers used to lose days to that work. With most of it handled by a tool and checked by an engineer, they spend that time on feature development and on refining the architecture. The result is that we deliver products of higher quality, which matters more to our clients than the speed of typing.

Data protection decided how far we could go

Before any client code goes near a tool, read the terms of service. Where is the data processed, how long is it kept, who can see it, and is it used to train the model. We only use business tiers that have a contractual no training clause and a GDPR data processing agreement. The client's NDA has to allow the tool provider as a subprocessor. If it does not, the tool is not used on that project, however useful it would be.

Patient data never goes into a cloud tool, not even an anonymised sample for a quick test.

The alternative is an on premise model. Nothing leaves the building, which removes the transfer question, and access control and logging still apply. The cost is a weaker model and a GPU bill that is now yours. For some clients that trade is worth it.

Where it fits in the IEC 62304 lifecycle

Walking the standard from planning to maintenance, this is roughly where we landed:

Planning and requirements: useful for finding gaps and contradictions in a requirements set. Not useful for deciding what the requirements should be.
Architecture and detailed design: useful as a reviewer of a design an engineer wrote. Weak as the author, because it does not know your hardware constraints or your risk file.
Implementation and unit verification: the most visible speed up, and the most review load.
Integration and system testing: test skeletons and test data, strong. Judging whether a test proves the requirement, still a human job.
Maintenance and problem resolution: impact analysis on legacy code is where the time saving was largest.

Who should be in charge

If you introduce these tools into a regulated team, put a software architect in charge, not a product manager. You need someone who knows the code, knows where the tool is reliable and where it is not, and plans the architecture with the tool instead of letting the tool plan it.

What is still open

The regulatory side has not settled. ISO 13485 requires manufacturers to validate software used in the quality system and in production, and the FDA's computer software assurance guidance describes a risk based way to do it. Neither says how to validate an AI assistant whose output changes from one run to the next, or how to record what a tool produced and who checked it. For now each manufacturer has to write that into its own procedures. The EU AI Act is clearer here: a coding assistant used inside the company is not a high risk AI system, but since February 2025 the company has had to take measures to build the AI literacy of the people who use it, a duty the Digital Omnibus of July 2026 softened without removing.

There is also a longer term risk I think about. The tools now do much of the work junior developers used to learn on, and US payroll data already shows fewer young people being hired into the occupations most exposed to AI, software development among them. In ten years, the people who would have learned to validate the output may not exist.

Next for us: more cases, a documented validation of the tools we use, and publishing the lifecycle map in full. If you are working out the same questions in your team, I would like to compare notes: tamas.fodor@silurus-software.com.