IEC 62304 already has a name for software whose development you cannot account for. It calls it SOUP, software of unknown provenance, and code an agent wrote with no record of how it was made comes uncomfortably close to the definition.
The standard's definition of SOUP covers software that is already developed and generally available but was not built for your device, and software developed earlier for which adequate records of the development process are not available. SOUP is allowed, with extra risk analysis. Your own device software system is not, and the standard says so. Code an agent wrote for your device is your code. It needs the same development records as code your engineers wrote by hand, and agents write code faster than those records get made.
What the FDA's AI guidance covers, and what it leaves out
Device teams looking for FDA direction on AI find two documents. Final guidance on predetermined change control plans (PCCPs) for AI-enabled device software functions, issued in December 2024, lets a manufacturer describe planned model changes in advance. Draft guidance on lifecycle management and marketing submissions for AI-enabled device software functions, issued in January 2025, sets out what a submission for such a device should contain.
Both are about AI inside the device. Neither addresses the agent that writes the device's code. That question lands in the quality system, which is the place most device teams have not looked.
If the device itself contains AI and you sell in the EU, the EU AI Act adds its own quality system expectations. See The EU AI Act for software teams.
Where an AI coding agent sits in the quality system
Since 2 February 2026, the FDA's Quality Management System Regulation has incorporated ISO 13485:2016 by reference. ISO 13485 expects manufacturers to validate computer software used in the quality management system, with effort in proportion to risk. The FDA's final guidance on computer software assurance, issued in September 2025, describes a risk-based approach for production and quality system software, and it does not cover software in the device itself.
Whether a coding agent counts as quality system software is not settled. The defensible position does not depend on settling it. Do not try to validate the agent. Verify what it produces, through the design controls you already run, and keep the proof. That shifts the burden from the tool to the record: every agent change has to show the review and testing its software safety class calls for.
The records that make agent code defensible
IEC 62304 expects traceability from software requirements to the code and tests that verify them, configuration management of each software item, and a problem resolution process. Agent work adds one question to each of those: who or what produced this?
- Provenance per software item. Which requirement it implements, and whether a person or an agent wrote it.
- Verification per change. The review and tests it passed, who reviewed it, and whether it came back for rework.
- Records that hold up as records. 21 CFR Part 11 sets expectations for electronic records and signatures that FDA rules require you to keep, including secure audit trails. If your design history evidence lives in your ticketing and version control systems, plan for that before an investigator asks.
The test is simple. Pick any software item in safety class C and ask whether you can show, from the record, who wrote it, against which requirement, and who verified it. If the honest answer for agent code is "the engineer remembers," that item is closer to SOUP than to your software.
Passing the class C test
Run that test against a record instead of anyone's memory. Bloomfilter rebuilds the history of each software item from your tickets, version control, CI, and agent sessions: the work item it traces to, whether an agent wrote it, who reviewed it, and whether a review or test was skipped along the way. That is provenance per software item, ready for design history and audits. It does not validate your device. More on Bloomfilter for regulated software.