May an agent write code in a regulated project?
Yes — under the same conditions as a human. What matters is not who wrote the line but whether it is specified, reviewed, tested and released. Anyone who closes that chain can use agents. Anyone who opens it for agents has a problem with humans too.
This text is the short answer of principle. What the chain actually looks like in a production project — role separation, a second review over the fix diff, and the findings a green pipeline would not have delivered — is in the field report How we develop with AI agents.
Which five guardrails do we set?
1. No commit without a Definition of Ready. Agents work exclusively on issues that have passed a Definition of Ready. Requirement, acceptance criteria and scope are fixed before the first commit. This is the single most effective measure — a vaguely worded ticket produces nonsense faster with an agent than with a human, because nobody asks a clarifying question along the way.
2. Nothing bypasses the pipeline. Every agent-generated change goes through build, unit, integration and E2E tests plus static analysis — the same gates as hand-written code. There is no fast lane, no exception for “just a small thing”.
3. A separate review agent before the human review. Implementation and review sit with different agents. The review agent sees the change without the chain of reasoning that led to it — the same reason humans review their own code badly.
4. Tool access instead of pasted context. Via MCP the agents are connected to repository, issue tracker, documentation and test environments. Context an agent can fetch itself is not copied into the prompt — that removes the “stale information in the prompt” failure mode.
5. Humans keep architecture, security and release. Architectural decisions, security-relevant changes and final sign-off stay with people. Not out of principle, but because at those three points the consequences of a mistake are not caught by a test run.
What does this additionally mean in a regulated setting?
In environments with an obligation of evidence — medical technology, public administration — the question of traceability is added: every change has to be traceable back to a requirement. The ticket-driven workflow delivers that anyway; what matters is that the agent has no route to commit around it.
Then there is the question that comes before the technology: where may the code be processed? We settle that in writing before the project starts — cloud API, dedicated hosting or full self-hosting, including training-data exclusion and retention periods. Details under AI engineering.
What do we get out of it?
Higher throughput at consistent code quality and substantially higher test coverage. The point that matters to us: the freed-up capacity goes into test depth, not into more features. A small team thereby delivers at the speed of a larger one without giving up traceability — and traceability is exactly what acceptance procedures ask about.