- Coding agents reshape the whole software lifecycle, not just the keyboard: requirements, design, testing, review, documentation and operations all shift. The SDLC phases stay; the division of labor between human and agent is what changes.
- When generation gets cheap and fast, human review and verification become the constraint. The center of gravity moves from writing code to reviewing and specifying it, which makes tests the executable contract and diff size a governance parameter.
- The human role skews toward orchestrator, reviewer and architect, and governance of generated code (provenance, licensing, scanning, tiered review gates) is what keeps velocity from turning into risk. Treat this as an evolution of the SDLC, not a bolt-on.
It is not just code generation
The reflex when a coding agent lands in an organization is to file it under "faster typing." The demos encourage this: a prompt goes in, a working feature comes out, and the natural conclusion is that the model has automated the part where an engineer's fingers hit the keyboard. That framing is not wrong so much as small. Writing code was never the expensive part of delivering software. Deciding what to build, agreeing on how it should behave, verifying that it does, and keeping it running were always the costly steps, and those are exactly the steps agents now reach into.
Watch what actually happens when a team adopts agents seriously. Requirements get drafted and stress-tested in conversation before a ticket exists. Design options are sketched, compared, and discarded in minutes. Tests are generated alongside the code they cover. Pull request descriptions, changelogs, and runbooks write themselves from the diff. On-call engineers paste a stack trace and get a candidate root cause before they have finished reading the alert. The keyboard step is the most visible change and the least important one.
This is why "AI coding tool" undersells what is happening. The unit of disruption is not the function you no longer type; it is the lifecycle whose economics have shifted underneath you. Every phase that used to be gated by how fast a human could produce an artifact is now gated by something else, usually by how fast a human can check one. An organization that upgrades only its code generation, and leaves requirements, review, testing and operations running on their old assumptions, will feel the friction move rather than disappear. The rest of this piece traces where it moves, phase by phase, and what to do about it.
The phases stay, the work moves
Nothing about the classical lifecycle becomes obsolete. You still gather requirements, design, implement, test, review, release and operate. What changes is who does the first draft and who is responsible for the judgment. The pattern is consistent across phases: the agent produces a fast, plausible draft, and the human moves upstream into steering it and downstream into verifying it. The work does not vanish; it relocates to the two ends of each phase, where it is harder to automate and more consequential to get wrong.
| Phase | What the agent now drafts | Where the human stays essential |
|---|---|---|
| Requirements | User stories, edge cases, acceptance criteria from a rough brief | Deciding what is actually worth building and resolving conflicting intent |
| Design | Options, trade-off sketches, interface stubs, migration plans | Choosing the architecture the org will live with and own |
| Implementation | The bulk of the code, across files, at branch scale | Specifying the task precisely and setting constraints |
| Testing | Unit, property and integration tests; fixtures; eval cases | Deciding what "correct" means and where coverage must be deep |
| Review | Diff summaries, self-review notes, suggested fixes | Accountable approval of what ships and why |
| Docs & ops | Changelogs, runbooks, root-cause hypotheses from telemetry | Confirming the explanation and authorizing the response |
Read the right-hand column and a theme emerges. What stays human is specification and judgment: saying precisely what is wanted at the front of a phase, and taking accountable responsibility for the result at the back. Those are not the parts an agent is weakest at by accident; they are the parts that carry organizational risk and cannot be delegated without delegating the liability with them. The middle, the production of the artifact, is where leverage concentrates, and it is also where the least of the durable value ever lived.
Review becomes the bottleneck
Every production system has a constraint, and improving anything other than the constraint just moves inventory around. For most of software's history the constraint was generation: a feature took as long as it took a competent engineer to write and integrate it, and everything downstream waited on that. Coding agents collapse the cost of generation by an order of magnitude for a large class of tasks. The constraint does not disappear when you do that; it relocates. It lands on the next slowest step that a human still has to perform with real attention, and that step is review.
The arithmetic is unforgiving. An engineer can review perhaps two or three substantial diffs a day with the depth that catches a subtle logic error or a quietly wrong assumption. A single developer running agents in parallel can generate many more than that. When generation capacity exceeds review capacity, one of two things happens. Either the team throttles generation back to what it can actually inspect, or review degrades into rubber-stamping, and rubber-stamping is precisely how a plausible-looking defect reaches production. There is no third option where unreviewed generated code is safe at volume.
This is why the discipline that pays off most is pushing effort upstream, into the specification. A precise, testable description of the desired behavior is what makes the resulting diff reviewable quickly, because the reviewer checks the output against a stated contract rather than reverse-engineering the intent. That is the argument for spec-driven development, sharpened: the spec is no longer just documentation, it is the thing that keeps review from becoming the wall the whole pipeline breaks against.
Testing carries more weight
If a rising share of your code is drafted by a system that is confident, fast, and occasionally wrong in ways that read as correct, then the mechanism that decides whether you can trust it has to get stronger. That mechanism is testing. In an AI-native lifecycle, tests stop being a quality metric you report on and become the executable contract that makes delegation safe. A strong suite converts the agent's loop from "generate and hope" into "generate and converge," because the agent's own verification step actually verifies something before a human ever sees the diff.
The kinds of tests that matter shift accordingly. Example-based unit tests still pull their weight, but two styles earn a larger role when the author is a machine. Property-based tests assert invariants that must hold across a generated range of inputs, which catches the plausible-but-wrong edge cases an agent is prone to. And eval-style checks, borrowed from how we assess models themselves, gate behavior rather than implementation, which matters when the implementation is regenerated freely.
- Property-based tests. State an invariant ("the output is always sorted," "encode then decode returns the input") and let the framework hunt for counterexamples the agent did not consider.
- Eval-style behavioral gates. Score outcomes against expected behavior in CI, so a regression blocks the merge regardless of who or what authored the change. See the evals deep-dive.
- Coverage as a leverage metric. Where the suite is strong, you can safely delegate more; where it is thin, delegation is a gamble. Coverage now tells you how much you can hand off.
This raises the stakes on the tests themselves. Agents will happily write tests too, and a test that asserts the current behavior is not the same as a test that asserts the correct behavior. Human judgment concentrates here: deciding what "correct" means, guarding against tests that merely mirror the implementation, and wiring the whole thing into AI-native CI/CD so verification runs automatically on every generated change.
New roles and skills
When the artifact is cheap and the verification is dear, the job description follows the value. The engineer moves away from being the person who produces the code and toward being the person who directs its production and stands behind its correctness. Three roles, long present but now dominant, describe where the day goes: the orchestrator who decomposes work into agent-sized tasks and runs the loop, the reviewer who verifies machine output that fails differently from human output, and the architect who owns the decisions an agent should never make alone.
HUMAN AGENT
----- -----
specify --------- task+spec ----> gather
(intent, criteria) plan
^ edit
| run tests
steer <-------- questions ------- (self-verify)
| |
| diff + summary
v |
review <--------- output ------------- +
|
accept / send back with feedback --> (loop)
|
own the merge (accountable)
The skills that make someone effective in this loop are not the ones that made them fast at typing. Prompting matters, but it is the easy half and it commoditizes quickly. The durable, scarce skills are spec-writing, the ability to state precisely and testably what a change must and must not do, and verification, the ability to read a confident machine-generated diff and find the place where it is subtly beside the point. Machine-authored code fails in a distinct register: syntactically clean, superficially reasonable, and occasionally solving a slightly different problem than the one you posed.
Organizations that train only "users" of these tools, and not reviewers and specifiers, get the leverage without the safety. The competency to develop deliberately is reviewing agent diffs and writing the specs that make them reviewable. Senior time spent there is not overhead; under the new constraint it is the highest-leverage work in the building.
Governing generated code
Once agents contribute a material share of the codebase, questions arrive that never had to be asked when every line had a human author with a name attached. Who wrote this, and under what supervision? Is this snippet echoing something licensed? Did a plausible-but-unvetted dependency get pulled in because it looked right? Governance of generated code is the discipline that keeps the velocity from quietly converting into risk, and its cost is low if you build the records in from the start and miserable if you reconstruct them after an incident.
Four controls carry most of the weight. Provenance: mark agent-assisted commits mechanically, for instance with a commit trailer, so attribution is queryable from history rather than remembered. This is what lets you compute escaped-defect rates for assisted versus unassisted changes and answer honestly when a customer or regulator asks how much of the product is machine-written. Licensing: generated code can reproduce licensed fragments, so license and dependency checks matter more, not less. Security scanning: static analysis and secret detection do not care who authored a line, which is exactly why they are the right backstop when volume makes manual spotting unreliable. Review gates: tier scrutiny by risk rather than applying it uniformly.
None of this is novel engineering. It is classical control, applied deliberately because an agent amplifies whatever process it is dropped into. The broader framework, including policy templates by risk tier, sits in Governing AI Code.
The architect view
The mistake I see most often is treating agents as a feature to bolt onto the existing SDLC, the way an IDE plugin gets installed and forgotten. That produces exactly the friction described throughout this piece: generation accelerates, everything downstream jams, and the organization concludes the tools are overrated when the truth is that it upgraded one station on the line and left the rest at their old capacity. This is an evolution of the lifecycle, not an accessory to it, and it wants to be redesigned as one.
Redesign means investing where the constraint actually is. The tooling improves on its own schedule and needs little help from you; the scarce capabilities are verification and specification, so that is where the money and the process design go. Build the paved road: approved tools and models, sandboxed execution, permission presets per environment, shared agent configuration per repository, commit-trailer conventions, and strong automated verification wired into CI. Adopting an agent should mean joining a configured lane, not improvising one, and the lane is what makes velocity safe at scale.
Two principles keep the redesign honest. First, size agent usage to review capacity, not generation capacity, and treat reviewer attention as the budgeted scarce resource it now is. Second, measure rather than believe: perceived speedup and real speedup can diverge sharply, so instrument cycle time, escaped defects, and review load on real work and let the numbers argue. The organizations that compound with these tools are not the ones with the best models; they are the ones that took specification seriously, kept review honest under volume, and redesigned the process on purpose. Theory here; working systems in the Lab, including the Sprint Simulator.