Agentic software developmentWhen AI produces more code than humans can review.

01 / Assuring outcomes

The shift: From inspecting code to assuring outcomes

In conventional software development, human code review is an important part of quality assurance.

Agentic development changes how that work is shared.

A coding agent can, for example:

• Analyse and implement a requirement.
• Examine existing functionality for potential impacts.
• Create unit, integration and regression tests.
• Run tests and fix errors independently.
• Submit its changes as a pull request.

A second agent, working as independently as possible, can then review the code, tests and requirements, identify defects and request corrections.

For suitable tasks, this review–rework cycle can be largely automated.

One distinction is essential:

Passing an AI review is not proof that software is correct.

Agentic reviews therefore need to be supported by independently verifiable evidence: automated tests, static analysis, security checks and, where necessary, simulations or hardware tests.

The aim is not to remove human responsibility. It is to make better use of scarce human expertise.

02 / Four risk classes

Four risk classes instead of a blanket review requirement

Not every software change needs the same level of scrutiny.

Correcting a typo in a user interface has a different risk profile from changing the emergency shutdown of an industrial machine.

I therefore recommend four risk classes as a starting point:

This is a proposed internal governance framework, not a statutory risk classification.

The key point: Potential harm determines the risk class, not the number of changed lines of code.

Practical example: A cloud application

A manufacturer is developing a customer portal for spare-parts orders.

An agent is asked to add a sorting option to an existing overview.

If presentation and sorting logic are isolated, the change could be classified as R1.

Appropriate checks would include:

• Tests for different sorting criteria and empty result lists.
• Checks that existing filters still work.
• Automated regression tests.
• Independent agentic review.

If the same agent changes tenant isolation or access control, however, a higher risk class is required—even if only a few lines are affected.

Practical example: Embedded software

An agent is asked to change timeout handling in a control module.

In the worst case, an error could cause physical damage.

Unit tests and AI code review are not enough here. Depending on the system, additional methods are needed, such as hardware-in-the-loop testing, timing analysis, fault simulation and safety approvals.

The development automation can be largely identical in both cases. The evidence and approvals required are different.

03 / The workflow

A practical workflow: Develop, verify, correct, approve

For most mid-sized businesses, a straightforward workflow is enough to get started:

1Define requirements and assess risk

A triage agent analyses the task, identifies affected components, proposes acceptance criteria and recommends a risk class.

Where impacts are unclear or critical, a person makes the decision.

2Implement

The coding agent develops the change, including the necessary tests.

3Verify automatically

A CI pipeline runs appropriate checks:

• Build, linting, type checking and tests
• Static security analysis and secret scanning
• Dependency and licence checks
• Project-specific architecture and quality rules

4Review independently

A separate review agent specifically looks for functional defects, security issues, regressions, unnecessary complexity and missing test cases.

5Rework automatically

Confirmed findings are returned to the coding agent.

After each correction, the affected tests and reviews are run again. Two unsuccessful review–rework rounds, for example, are a sensible point to escalate—not a reason to keep looping indefinitely.

6Approve according to risk

Low-risk changes can be approved automatically after sufficient validation. Critical changes go to the responsible person with a concise overview of the evidence and unresolved risks.

7Learn from the results

Defects discovered later, human corrections and actual release problems feed back into improvements to the verification process.

This workflow does not necessarily require seven different agents. Two agent roles—a coding agent and an independent reviewer—supported by CI and simple triage are often a better starting point.

04 / Four templates

Four templates you can use straight away

The greatest benefit comes from clear assignments, verifiable quality criteria and enforced technical boundaries, rather than particularly long prompts.

05 / Less complexity

An underestimated problem: AI often produces too much

Coding agents sometimes tend to go beyond what a task requires.

Typical examples include:

Documentation inflation: Small changes lead to extensive Markdown files, additional architecture overviews or complete change histories.

Overengineering: A simple function is split into multiple new classes, interfaces and abstraction layers.

Test inflation: Numerous tests check the same property while important edge cases are missing.

Scope creep: The agent refactors neighbouring components that were not part of the assignment.

Review theatre: Agents produce long review reports with many cosmetic observations but little additional assurance.

The remedy is to explicitly optimise for Minimum Sufficient Engineering.

Every additional file, abstraction, dependency or piece of documentation should have a clear benefit.

A concrete example: In a Git repository, the normal change history belongs in Git and pull requests—not as a newly generated history in every edited source file.

Architectural decisions, on the other hand, should be documented when they help future developers understand non-obvious relationships or deliberately accepted trade-offs.

This saves more than tokens. It reduces long-term maintenance costs.

06 / Measuring trust

How trustworthy is an AI review, really?

An agent can judge a change to be correct and still miss a defect.

That is why I find claims such as “99% confidence” problematic when they come solely from a model’s self-assessment.

A better approach is to measure the entire verification process empirically.

For example: A company randomly samples 300 automatically accepted changes from a comparable, low-risk class of tasks. Qualified people review them additionally. No significant missed defects are found.

Under the assumptions below, this gives a one-sided 95% upper confidence bound of approximately 0.994%, or 1% when rounded. This concerns the proportion of automatically accepted changes that still contain at least one significant defect—not the number of defects per line of code.

When is this calculation justified?

• The sample represents the task class in question; observations are independent and come from a process with a stable defect probability. Many variants of the same patch cannot simply be counted as independent cases.
• The sample size and defect criteria are fixed in advance. Reviewers do not keep sampling until a favourable result happens to appear.
• The additional review reliably detects the defects in question. The calculation assumes complete detection: with unknown missed defects, it only bounds the detection rate, not reliably the true defect proportion.

“95% confidence” describes the reliability of the procedure: over repeated equivalent samples, at least 95% of the upper bounds calculated this way would cover the true proportion. It does not mean a “95% probability that this particular bound is correct”, nor does it guarantee individual changes. New task classes or changes to the verification process require a fresh assessment.

Methodological sources: Hanley & Lippman-Hand: the rule of three and its derivation (PDF); NIST: exact binomial confidence bounds. The calculation above explicitly uses a one-sided bound; the upper endpoint of a two-sided, equal-tailed 95% interval would be higher, at approximately 1.22%.

My recommendation: Increase autonomy gradually based on demonstrated process quality—and reduce it again if quality deteriorates.

For safety-critical functions, general sampling metrics like these are not sufficient on their own. Specific verification evidence appropriate to the risk is required.

07 / Security & compliance

Security, data protection and compliance: Build them in from the start

Using coding agents in production development means controlling not only the code they generate, but also the agents themselves.

An agent that can execute shell commands, read repositories or call external services needs clearly limited permissions.

I therefore recommend five practical guardrails:

1. Isolated execution: By default, agents work in isolated development environments with the fewest permissions possible.
2. Controlled data access: Confidential source code, credentials and personal information must be processed only through approved systems. Providers, contracts, data flows and storage conditions must be assessed in advance.
3. Independent checks: Wherever possible, security rules are enforced by CI, access policies and specialised tools, rather than prompts alone.
4. Traceable changes: Pull requests, test results, dependencies and relevant approval decisions remain traceable.
5. Product-specific requirements: Embedded controllers, cloud services and software products may have different security, evidence and regulatory obligations.

Useful technical frameworks include the NIST Secure Software Development Framework and OWASP’s guidance on the security of agentic AI systems.

Depending on the use case, relevant legal requirements may include the GDPR, the Cyber Resilience Act, national implementation of NIS2, contractual and licensing terms, and sector- or product-specific rules.

It is essential to check what actually applies in each case. Using a coding agent does not automatically make every AI-specific product obligation applicable to the software being developed.

An agentic review replaces neither a required conformity assessment nor human approval mandated by law or applicable standards.

08 / The four-week pilot

Getting started in a mid-sized business: A pilot, not a major project

A company does not need its own AI agent platform or ten specialised agents to get started.

I would begin with an existing repository and a manageable pilot.

Week 1Measure the baseline

How much human time does the team spend on implementation, review and rework? Which defects are typically discovered late? Which changes carry particular risks?

At the same time, define risk classes, access boundaries and the existing CI checks.

Week 2Introduce a coding agent and independent review

Suitable tasks are implemented by agents and passed through the automated review–rework loop.

For now, people continue to check the results.

Week 3Measure quality and address weaknesses

The team assesses missed defects, false review findings, test quality and actual time savings.

Wherever possible, address the most important weaknesses through verification mechanisms that remain effective over time.

Week 4Trial controlled autonomy

Individual trivial tasks with sufficient safeguards can be considered for automatic approval.

Broader approval permissions are granted only after sufficient validation of the relevant task class. Four weeks is a useful starting point for the pilot, but it does not prove that R1 auto-merge is already safe enough.

Which metrics matter?

Token costs and generated lines of code are not enough for a sound economic assessment.

In particular, I would measure:

• Human working hours per successfully accepted change
• Time from assignment to production deployment
• Defects and security findings discovered afterwards
• Effort spent on rework and operational disruptions
• Direct AI, infrastructure and verification costs

These metrics should be assessed by task class. Otherwise, a shift towards easier tasks could be mistaken for a productivity improvement.

The goal is not “as many automated pull requests as possible”.

It is: More economically valuable, sustainably maintainable software per human working hour—within accepted risk limits.

09 / Conclusion

Conclusion: The bottleneck shifts from writing to verifying

Agentic software development changes the role of developers.

Their key contribution increasingly lies in defining precise goals, setting appropriate architectural boundaries, independently verifying outcomes and deliberately managing risks.

This applies equally to a mid-sized mechanical engineering company with embedded software and to a manufacturer developing its own ERP extensions or cloud services.

The optimal level of automation will vary. The underlying approach can remain the same.

My guiding principle: As much autonomy as makes economic sense—as much independent verification and human oversight as the risk demands.

Companies that apply this approach consistently can benefit from the productivity of agentic development while keeping quality assurance and responsibility firmly within the development process.