The software development lifecycle is not a row of boxes in Jira. It is the work between deciding to change a system and learning whether that change helped.
Requirements, design, implementation, testing, release and operation still happen when an agent writes the code. What changes is their shape. Activities that used to occupy separate phases can now occur inside one short conversation, while the hand-offs and waiting between them shrink.
Boris Tane makes the stronger case: agents collapse the traditional sequence into intent, building and observation. I think he has identified the right movement, but “dead” hides the difficult part. Removing a phase from a diagram does not remove its responsibility. It moves that responsibility somewhere else.
Phases Are Collapsing; Obligations Are Not
Consider a small feature built with an agent. We describe an outcome, the agent inspects the repository, proposes an approach, changes code, writes tests and runs them. We try the result, notice that the behaviour is slightly wrong, revise the requirement and repeat.
Requirements and implementation happened together. So did design and testing. This is much closer to product discovery than a ticket moving through columns.
It can also go wrong much faster. An ambiguous phrase now becomes code before the next meeting. A weak architectural assumption spreads through several files before a reviewer sees the plan. A passing test suite may simply encode the same misunderstanding as the implementation.
The obligations remain:
- decide what outcome is worth pursuing;
- make constraints and failure modes explicit;
- choose an architecture that can carry the change;
- gather evidence that the implementation behaves as intended;
- release without taking an unreasonable risk;
- observe the effect and learn from it.
Those are not ceremonies. They are the irreducible work. Sprint planning, a separate QA queue or a pull-request template are implementations of that work, and some of them can disappear. The responsibilities cannot.
The New Loop
A compact version is:
Intent → Build + Verify → Release → Observe → Learn → Next intentThe arrows matter as much as the boxes. A team gains little from generating code in minutes if a decision waits a week, review waits three days, release happens monthly and production feedback never reaches the next plan.
Adolfo Builes puts this well: optimise the whole process, not an individual’s coding speed. His loop runs from idea through planning, building, review, QA and production to learning. The opportunity is to reduce waiting, ambiguity and rework across it.
This also explains why raw code output is a misleading productivity measure. More output can create more work in every downstream activity. If review capacity, deployment safety and operational ownership stay fixed, an agent can make the organisation slower by filling its queues faster.
The 2025 DORA report describes AI as an amplifier of an organisation’s existing strengths and weaknesses. That is a more useful mental model than a universal multiplier. A team with clear ownership and fast feedback gets a tighter loop. A team with ambiguous priorities and fragile delivery gets ambiguity and fragility at higher throughput.
Intent Becomes an Engineering Artefact
When implementation is expensive, a slightly vague ticket can survive because a developer spends days resolving uncertainty while coding. When an agent can produce a plausible version quickly, vagueness becomes visible sooner. That is good, provided we treat the first version as a question rather than an answer.
The input needs enough precision to constrain the output:
- the user or system outcome;
- examples of expected behaviour;
- invariants that must remain true;
- relevant architecture and local conventions;
- unacceptable side effects;
- the evidence required before release.
This is not a return to hundred-page specifications. The intent can be a short document, a failing acceptance test or an executable example. It should be proportional to the cost of being wrong.
Discovery remains part of the loop. A prototype can expose a bad assumption more effectively than another planning meeting. The mistake is allowing the prototype to acquire production authority merely because it exists and the tests it wrote for itself are green.
Verification Moves Into the Loop
Traditional code review assumes that production is slow enough for a human to inspect each change. Agent output puts pressure on that assumption, but “give up review” is the wrong general conclusion.
Review has several jobs: detect defects, spread knowledge, check design, maintain conventions and establish accountability. Some of those jobs can move to automated checks or independent agent review. Others still require a person who understands the system and answers for the outcome.
The practical change is from one large gate near the end to many smaller gates throughout the loop:
- acceptance tests derived from the intent;
- type, lint and static-analysis checks during implementation;
- an independent review pass against the specification;
- security review for changes to sensitive boundaries;
- integration and end-to-end tests before release;
- staged deployment, telemetry and rollback afterwards.
This is the argument from the security chapter applied to the entire lifecycle: implementation should not define its own standard of correctness.
For an unusually demanding example, Datadog describes agents working on Redis- and Kafka-like systems against layered verification harnesses. The team used explicit invariants, deterministic simulation, TLA+ specifications, bounded verification and production-like telemetry. Datadog says the harness became the primary source of correctness, with humans still defining it, setting targets and approving architectural changes.
That does not mean every web application needs TLA+. It shows the direction of travel: as generation becomes cheaper, durable verification assets become more valuable. A useful invariant keeps checking future changes; a heroic read of one diff does not.
Observability Is Feedback, Not Absolution
Tane argues that monitoring is the surviving stage and becomes the primary safety mechanism. I would phrase it more cautiously. Observability is the feedback channel that closes the loop. It is not permission to skip the controls before release.
A dashboard cannot undo corrupted data. An alert cannot make a dangerous migration reversible. If the service lacks a useful rollback, ownership or response capacity, more telemetry gives us a well-instrumented incident.
Good operational feedback answers questions tied to the original intent:
- Did the expected users adopt the change?
- Did error rate, latency or cost move outside an agreed range?
- Are authorisation failures or suspicious access patterns increasing?
- Can we connect the change to the observed effect?
- When should the release pause or roll back automatically?
The agent can help investigate and sometimes remediate. The policy for doing so must be explicit. An autonomous system allowed to deploy a fix is also a system allowed to change production, which brings us straight back to runtime boundaries, scoped authority and auditability.
From Coder to Orchestrator, With Caveats
Nicholas Zakas predicts a move from coder, through conductor, to orchestrator of multiple agents. He expects development tools to emphasise tasks and agent status rather than text editing.
I find that shift plausible. When an agent handles implementation, more of our work involves decomposing a problem, distributing context, designing feedback loops and deciding which outputs deserve attention. Syntax recall matters less than the ability to check the agent’s choices.
I am less convinced that understanding code becomes optional. We still need enough technical depth to recognise a broken abstraction, question a security boundary and debug the harness itself. Orchestration without engineering judgement is project management performed at machine speed.
Builes offers the necessary brake: do not generate more code than experienced engineers can review, validate and maintain. Review need not mean reading every line, but somebody must understand the system well enough to challenge the evidence. Otherwise the bottleneck has not disappeared. We have hidden it in future maintenance and incidents.
Where the Old Lifecycle Still Fits
A tight agent loop suits reversible, well-observed changes with cheap feedback. It is less convincing when feedback arrives months later, failure can harm people, or several organisations must agree before anything moves.
Medical devices, financial controls, safety-critical infrastructure and regulated changes retain explicit stages for good reasons. Large programmes still need coordination across teams. Hardware and physical operations do not become instantaneous because the software arrived early. Even a small product may benefit from a deliberate design review when a decision will be expensive to reverse.
The right question is not “Have we abolished the SDLC?” It is “Where does each responsibility live now, and what evidence shows that it happened?”
For teams using agents, I would start by mapping the real loop. Measure waiting as well as implementation. Delete a hand-off when continuous collaboration or automation can replace it. Keep a gate when it protects an expensive boundary. Strengthen the feedback path from production to the next decision.
The last chapter in Part I steps outside the repository and asks where else this pattern applies: Beyond Coding.