A coding agent can inspect a repository, modify several files, generate tests, run them, fix failures, and report that the task is complete.
Everything can pass. And the change can still be wrong.
Consider this task:
Add cancellation support to the order API, preserve backward compatibility, and add tests.
An agent finds the endpoint, implements cancellation, updates the contract, and generates passing tests. Then review discovers that cancellation belongs in another service. Some of the business logic already exists there.
The implementation works. The tests work. The architectural decision is wrong. This is an important distinction as AI coding moves from autocomplete toward increasingly autonomous coding agents:
A coding assistant accelerates execution. An engineering process determines what should be executed, under which constraints, and what evidence demonstrates that the result is ready.
Implementation Correctness Is Not System Correctness
Coding agents are becoming good at bounded implementation work:
- exploring repositories
- implementing defined features
- generating tests
- debugging failures
- refactoring code
- performing repetitive migrations
- updating documentation
But consider another requirement:
Prevent suspicious users from completing checkout.
What qualifies as suspicious?
Does another service own that decision? Should checkout be blocked or require additional verification? What happens to an existing order?
An agent can infer answers and implement them consistently. It can even generate tests validating those assumptions.
But passing tests only establish that the implementation satisfies what the tests assert. If the implementation and tests originate from the same incorrect assumption, they can agree perfectly while the feature remains wrong.
That gives us an important distinction:
Implementation correctness is not system correctness.
Software engineering has to address both.
Faster Coding Moves the Bottleneck
There is another consequence of coding agents that deserves more attention:
Generation capacity ≠ delivery capacity
Imagine that AI allows developers to implement changes much faster. More pull requests arrive. But architectural reviews still require senior engineers. Integration still takes time. Product ambiguity still requires decisions. Security checks and deployment controls still exist. Implementation capacity increased. Delivery capacity did not necessarily increase with it. The bottleneck simply moved.
It might move to:
- review
- testing
- integration
- architecture
- product decisions
- deployment
This is why measuring AI adoption by generated lines of code or agent tasks completed tells us relatively little about engineering throughput.
A better question is:
Is validated, deployable work moving through the system faster?
AI Also Makes Wrong Decisions Cheaper to Execute
Suppose an agent incorrectly assumes authorization belongs in an API controller instead of an existing policy layer. It implements the rule there. It generates tests around that implementation. It updates documentation. A later task discovers the new pattern and follows it. The agent has been consistent. Unfortunately, it has consistently propagated the wrong architectural decision.
AI reduces the cost of executing a decision. It does not automatically improve the quality of that decision. That means faster generation increases the value of identifying bad assumptions before they spread.
What an AI Development Workflow Needs
A useful AI software development process needs mechanisms around code generation.
One practical model is:
Intent → Context → Execution → Evidence → Feedback
Intent
Define enough of the desired outcome that an incorrect implementation can be recognized. The goal is not producing larger specifications. It is exposing unresolved assumptions before implementation makes them expensive.
Context
Provide the information necessary for the delegated decision. For an API change, that might include:
- service ownership
- API compatibility requirements
- domain rules
- architectural constraints
- security requirements
- existing components that should be reused
More context is not automatically better. Relevant context is.
Execution
Define what the agent can change autonomously.
For example:
Modify the order service and its tests. Preserve the public API. Do not modify the payment service or database schema. If either is required, stop and escalate.
That is more operational than telling an agent to "follow the architecture."
Evidence
Do not use:
The agent says it finished.
as the completion criterion.
Depending on the change, evidence could include builds, tests, contract validation, security checks, architecture rules, reviewed diffs, or deployment checks. The key is that validation should not depend entirely on the same assumptions used to generate the implementation.
Feedback
The workflow should not end when the pull request merges.
Production errors, performance signals, incidents, user behavior, and support feedback can reveal assumptions that pre-production validation missed.
Those signals should influence future engineering decisions.
Human Oversight Should Follow Risk
The answer is not to require human approval after every agent action. That simply moves the bottleneck to humans.
A more useful model separates work into three categories:
| Work | Default control |
|---|---|
| Bounded implementation and mechanical changes | Agent autonomy |
| Builds, linting, contracts, security scans and other deterministic checks | Automated validation |
| Ambiguous requirements, architecture trade-offs and consequential decisions | Human judgment |
The exact boundary depends on the system.
A useful rule is:
Increase autonomy when the task is bounded, constraints are explicit, failures are detectable, and the consequences of an incorrect action are acceptable.
As ambiguity, blast radius, irreversibility, or business consequences increase, so should oversight.
From AI Coding to Agentic Software Development
Teams can evolve gradually.
Stage 1 — Assistance: developers use AI for coding, debugging, tests, and exploration.
Stage 2 — Delegation: agents execute bounded tasks with explicit constraints and validation.
Stage 3 — Workflow integration: AI participates across requirements, implementation, validation, review, and documentation.
Stage 4 — Process orchestration: work moves through defined stages with constraints, evidence requirements, automated gates, and escalation paths.
Not every team needs Stage 4. The goal is not maximum autonomy. It is reducing the mismatch between how quickly software can be generated and how reliably the organization can validate and deliver it.
Measure Delivery, Not AI Activity
Questions such as "How much code did AI write?" or "How many tasks did our agents complete?" measure AI activity. They do not necessarily measure engineering performance.
A better objective is:
Increase the rate at which correct, validated, maintainable software reaches production.
AI coding can substantially change implementation economics. But the more capable coding agents become, the more important the surrounding engineering system becomes: intent, context, boundaries, evidence, and feedback.
The interesting question is therefore no longer whether coding agents can produce software. They can.
The question is:
Has your engineering process evolved enough to absorb the speed at which they can produce it?
Top comments (0)