knowing what’s right and being able to prove it

Agents make code cheap to produce. The scarce resource becomes knowing what’s right and being able to prove it, so human effort moves to each end of the pipeline: specification up front, verification and accountability at the back. The middle gets automated.

If I were inventing the SDLC from scratch with AI in mind, this is where I’d end up:

Ideation and scoping. Humans decide what to build and why, and assign a relative risk scope.
Specification. Humans write the spec in detail. Acceptance criteria, user experience and workflows, invariants, permission model, failure modes. Agents assist here but the spec and design are human-owned artifacts.
Verification. This is largely automated, with a human approval stage. Tests are written from the spec, isolated from product code. Adversarial agents build attack cases. A hardening checklist is defined based on feature risk. The spec may be updated where flaws are found.
Implementation. Agents write the feature, including its telemetry and audit logging, against the spec and frozen tests. Humans are only involved here for problems and escalations.
Refactor. A fresh agent session reviews for duplication, inconsistent abstractions, and human legibility, then refactors against the frozen tests. This is part of the definition of done, not a deferred cleanup. Resolving this will be a mix of automation and human involvement for architecture-level decision making.
Risk-tiered review. This is an accountability gate. Nontrivial features get another round of adversarial review, including auth probing, API-level composition attacks, fuzzing. Humans review the change, its intent, and the implemented outcome, at a depth tailored to the risk scope, and give a go/no go for release.
Release with feature flags, cheap rollback paths, and automatic gating on the checklist from the verification stage. Canary or gradual rollouts are a good option.
Observability. Telemetry and feedback to trigger alerts, potential rollbacks. Humans own incident response, using AI assistance, with the audit trail and readable code making RCAs possible. Incidents should feed back to the risk analysis for future work.
Maintenance. Ongoing security analysis and high-level review of the codebase, its conventions and architecture rules. Incidents and near-misses become permanent tests, checklist items, or conventions. Periodic metric-triggered or human-initiated cleanup also belongs here.

Why?

In traditional Agile, we spend most of the human time in the middle: writing, reviewing, and debugging code. Here, humans concentrate on specification up front and verification and accountability at the back, and the middle is automated. Humans decide what is right (stages 1 to 3), decide whether it’s acceptable to ship (6), and own what happens afterward (8 and 9). Agents do the production work in between. We keep Agile’s small teams, short iterations, incremental delivery, and retros.

Tests are isolated and specified early, because authors share blind spots with their own tests. We build the tests first, ensure their correctness and completeness, and then keep them separate from the human and agent code authors. The test suite only changes if a flaw is found in the spec, with human approval; code flaws can’t be papered over by a test change.

Security is checked at the API level, because agents rather than UIs are increasingly the client. UIs can’t implicitly handle the security work anymore (not that they ever really should have been trusted to do so.) Agents and bad actors alike will use those APIs in unplanned ways, so it’s essential to keep them secure both individually and in combination.

Lighter pre-merge review is acceptable because detection and rollback are cheap, and increasingly, because agent-written code is generally competent. Line-by-line code review should be a rarity; review depth should reflect the track record of the agent, model, or workflow that produced the change; incidents lower trust, clean releases raise it. This lets us adjust to the correct amount of verification effort; scrutiny goes where the evidence says it’s needed.

What human roles exist?

A single engineering “team” might consist of a combination of

Product owner. Similar to today’s PM / PO, with more explicit responsibility for risk assessment.
Specification engineer / feature owner. Writes the detailed spec. This is the new center of the industry, a blend of engineer, business analyst, and domain expert.
UX. Usability and design is just as important as ever; this should be a key role on any team. UX will work closely with the feature owner to ensure both the UI and the API are well-designed and follow the necessary standards.
Verification engineer. The evolution of QA/SDET. They approve the generated tests against the spec, and design and maintain the adversarial agent setups.
Security engineer. Closely paired with verification, but focuses on external threats, prompt injection through untrusted content, over-broad agent credentials, and agents doing unexpected things on a user’s behalf.
Release authority. Senior reviewer, not the spec writer, with accountability for release quality.
Reliability / incident lead. The evolution of SRE; owns observability, anomaly detection, and incident response.

Underlying all of them would be the platform and agent workflow engineers, who build the actual agent harnesses and tooling. Small orgs would outsource this, using pre-built agents and externally-hosted models, but someone would still need to be responsible for configuring and evaluating them.

Other specialist roles (design systems, database managers, accessibility or compliance experts, the team’s management chain and architecture governance) would continue to exist.

(The pipeline to seniority remains an open question, but I suspect junior engineers will start on small, low-risk-tier features, graduate to larger or more complex features, and eventually grow up into owning release authority as seniors. There is plenty of engineering work for even junior engineers to do, it’s just that little of that work will involve “writing code”. Instead it’ll be writing the spec, or evaluating the completeness of a test suite, or building the adversarial test cases.)

How do we measure productivity?

This may be a premature question until the roles settle out…. But some changes are obvious. Velocity and story points measure activity, which means little when typing is cheap. Outcome measures (escaped defects, incident rate, spec-to-verified-in-production time) replace them.