A coding agent can turn a detailed plan into code, tests, configuration, and infrastructure before the next planning meeting. That can reduce the time and effort needed for implementation. It does not settle whether the team chose the right problem, has permission to use the data, understands the operational consequences, or can release the change safely.
That gap can make a familiar delivery failure happen sooner.
The risk is easy to miss because the first result looks convincing. The pull request is large. The test suite is green. The service starts. People can demo it. By then, a team may have invested enough in one approach that changing direction feels costly or politically difficult.
This English-language version develops ideas from my Russian Habr article. It approaches the same question through learning and decision points, with less attention to the speed of the first implementation.
The code was fast. The decision arrived late.
Consider two integration projects.
In the first, a team read the documentation for a compliance-checking API and spent a sprint building a convenient adapter. Other teams immediately wanted to use it. The next sprint uncovered the decisive constraint: the API had been built for an internal audit workflow and exposed raw data. Its use could not be extended to the new scenario.
In the second, an engineer used AI to prepare an integration with a product that was new to the team. The service appeared within a sprint. Legal, security, data access, and ownership questions took two more sprints to resolve.
These are not stories about poor engineering. The teams had working code and useful documentation. They discovered the expensive unknown after implementation had created momentum around one solution.
Coding agents raise the stakes. A weak assumption now spreads quickly through interfaces, fixtures, infrastructure, monitoring, and tests. Rewriting the code may be cheap. Reworking the decision can still involve system owners, permissions, evidence, release coordination, and accountability.
Writing code and shipping code are different measurements
The evidence on AI-assisted development is mixed for a good reason: researchers measure different work in different environments.
Controlled studies have found meaningful speedups on contained programming tasks. A 2025 Google field experiment reported faster completion of a complex internal task. METR’s randomized study found the opposite result in a different setting: experienced maintainers working in mature open-source projects took 19% longer on pre-defined tasks when early-2025 AI tools were available.
Neither result settles the question for every team. Together, these findings suggest factors worth examining: task type, system maturity, repository knowledge, verification burden, and the way work moves through the organisation.
A useful reason to distinguish code activity from delivery comes from an NBER working paper on writing code versus shipping code. In the paper’s dataset, autonomous coding agents were associated with a 240% increase in commits; the estimated increase was 80% for projects and 30% for releases. The authors interpret that attenuation as evidence that AI and human work remain strong complements in the production chain.
A faster implementation therefore leaves an empirical question for each organisation: where does the work wait next? Review may be the constraint. It may be CI capacity, an integration environment, a product decision, a security check, an API owner, or a release window. Teams can answer that question by examining their own flow data.
DORA’s 2025 report reaches a compatible conclusion. AI amplifies the strengths and weaknesses already present in an organisation. The report also argues that tool investment alone will not fix weaknesses in the delivery system.
Two jobs for a specification
Specifications are useful to agents. An agent needs examples, boundaries, interface contracts, expected failure modes, and a way to check the result. A vague request forces it to invent too much of the surrounding system.
In practice, teams use “specification” for at least two distinct kinds of work.
One kind is discovery work. The team is still learning what a customer needs, whether an integration is available, which data can be used, or which architecture will survive production. The specification should make the next learning step concrete. It should name the scenario, the scope of the experiment, the assumption under test, and the evidence that will change the team’s decision.
Another is execution work. The team already understands the problem class and can define a bounded solution space. A data schema, a configuration grammar, API contracts, approved examples, and a test harness give the agent rules it can follow repeatedly.
These labels are only practical shorthand; real work often contains elements of both. They can help teams avoid a costly mistake: treating an uncertain product or organisational question as if it were already a routine implementation task.
SDD alone does not determine how a team makes decisions. A waterfall pattern can emerge when new evidence no longer changes an early design. A team can also create risk by postponing every decision in the name of flexibility. Useful delivery work keeps the important decisions explicit, revisable, and owned.
What bounded automation looks like
Some agentic tasks can operate within broad, well-defined boundaries.
Take a recurring event or payment-stream connection. The runtime configuration defines the source, validation rules, transformations, and operational limits. The team keeps a grammar for that configuration, examples of working connections, and a test framework that checks the expected behaviour. An agent can prepare a new configuration and its tests. An engineer handles exceptions and accepts the change through the normal pipeline.
That workflow can be efficient because the important rules already exist in a form the system can check.
OpenAPI supports machine-readable API contracts. JSON Schema validates declared data structure and constraints. A CI pipeline can reject a configuration that violates a known invariant. Each of those checks covers a limited projection of reality. It cannot establish product value, legal permission, security in every context, performance under load, or a sound operational decision.
The boundary matters. Teams can expand automation with more confidence as more of the relevant work becomes explicit, executable, maintained, and reviewed by someone who owns the exceptions.
Reversibility is an engineering capability
A large diff does not define a large change. A ten-line edit in billing can affect a critical customer path. A migration across hundreds of files can be routine when the rules are stable and the checks are reliable.
The useful measure is the amount of risk a competent person must understand before approving the next step.
DORA recommends working in small batches. Smaller changes move more easily through delivery, and teams recover from failures more easily. The principle applies to agentic development without modification. Agents can prepare a broad implementation; teams still decide how much uncertainty and blast radius they want to carry into one release.
Before assigning a substantial task to an agent, I would want the team to answer these questions:
- Which user or system scenario are we testing?
- What is outside this iteration?
- Which assumption must hold before we invest further?
- Which external owners need to confirm data, API access, permissions, or constraints?
- Which invariants must survive the change?
- Which test, metric, log, or demonstration will provide a useful signal?
- How will the change be enabled, observed, and reversed?
- Who decides whether to continue, revise the approach, or stop?
Think of this as a decision canvas. It gives a team a place to surface the unknowns that later become expensive.
Measure the path, not the activity around the tool
AI usage, accepted suggestions, generated lines, and pull requests are useful adoption signals. None can establish that an engineering system delivers more useful change.
I would use three layers of measurement.
Use: who works with the tool regularly, on which kinds of task, and at which stage of delivery.
Flow: lead time to production, throughput, time waiting for review, time in CI, review iterations, and merge-to-production time.
Stability: rollbacks, hotfixes, deployment rework, escaped defects, and time to recover from a failed deployment.
DORA’s delivery metrics combine throughput and instability. They work best at the level of an application or service, where the operating context and risk are visible. They are poor instruments for ranking individual engineers.
A team has evidence of progress when it learns earlier, keeps risk visible, and moves changes through production without adding instability. More agent-generated code may be part of that story. It is never the whole story.
The fast waterfall test
SDD gives agents the context they need. In a mature, repeatable workflow, it can turn accumulated engineering knowledge into work that more people can initiate and the system can verify.
A fast waterfall can begin when code accumulates around an assumption before the team has tested it.
The harder part is turning a plausible implementation into a decision the team can justify. That still requires a good question, a useful signal, and somebody who owns the release.