The SDLC Was Built for Human-Speed Code

The software development lifecycle most teams ran yesterday was designed when writing code was the slow and expensive part of building software.

That assumption is visible throughout it. Sprints are measured in weeks because implementation took weeks. Estimation exists to predict how long an engineer needs to produce a few thousand lines, a prediction that has never been reliable and gets made anyway. Code review runs after implementation because typing was where defects entered.

Agents have removed most of the cost of producing code. The work that remains expensive is deciding what to build, verifying that what comes back matches the intent, and getting it into production without breaking anything. Buying agent licenses (Claude, Cursor, Codex, Copilot) addresses none of that. A license purchase is a tool rollout. Reorganizing the lifecycle around the activities that are now expensive is an operating model change. I can usually tell which one a team did about six weeks in, when every engineer has agent access and the working method has not moved.

Everything below comes from running this inside my own teams and watching others attempt it. Nobody has run a controlled study on any of it, me included.

What actually changes⌗

The unit of engineering work moves from a written implementation to a specification, a review, and a proof. What an engineer produces becomes the intent behind the code plus the evidence that the code satisfies it.

Repo context becomes an engineering artifact with an owner and a maintenance cost. Files like AGENTS.md, the conventions doc, and the architecture notes determine whether agents produce competent work. Context behaves like a dependency. It goes stale as the system changes, and every agent that reads stale context inherits the error.

Lines of code never measured engineering skill. The metric survived because producing code took effort, and effort correlated loosely enough with contribution that nobody had to defend it. Agents sever that link, and output volume stops being a signal at all once an agent produces a week of implementation in an afternoon. Judgment about which code should exist, and taste about how the system fits together, become the scarce inputs.

Process⌗

The working shape becomes brainstorm, plan, agent execution, and human gates.

Review moves ahead of implementation. When producing code was expensive, reviewing the finished diff was the only practical option. Now the plan is the cheap place to catch a mistake and the diff is the expensive one, so the plan is where reviewer attention belongs.

Every agent-authored change should arrive with its evidence: which tests ran, which checks passed, what was verified and what was not. If you accept a pull request that says an agent wrote it and nothing else, you have moved the entire burden of verification onto your reviewer.

CI checks context freshness alongside code correctness. A failed build is the cheapest place to catch an architecture document that still describes a service you deleted two months ago. Every time I have relied on somebody remembering instead, the context went stale inside a quarter.

People⌗

Engineers become editors-in-chief. They specify the work, curate what comes back, and verify it. They type considerably less.

Editing well is harder than writing, and good editors are rarer than good writers. Your engineers may read the change as a demotion, so it is worth saying plainly that it raises the difficulty of the work while lowering the visible activity.

Seniority needs redefining along the same line. A promotion system that rewards output volume breaks visibly once an agent can generate a staff engineer’s annual line count in a day. Judgment becomes the basis for seniority, and authorship of the context that every agent depends on becomes a form of standing that the org chart should recognize.

Taste is the hardest of these qualities to hire for, and the one I have never found a way to teach quickly. An agent will hand you five implementations that all pass the tests, and someone has to decide which one the codebase should live with for the next three years. That decision shows up in naming, in where a boundary sits, and in what gets left out entirely. Writing the wrong abstraction used to be slow enough that somebody noticed before it spread very far. Agents removed that delay, so taste now sets how maintainable the result ends up.

Reviewing AI-authored work without rubber-stamping is a trained skill. Human code fails in human ways, with errors clustered where the work was hard, and reviewers learn over time to look there first. Agent code fails uniformly and reads fluently at the point of failure. Every reviewer I have worked with needed to be taught this explicitly before they caught it reliably.

Team composition⌗

Our teams are getting smaller, in the range of three to five engineers, with agents carrying the long tail of implementation. Large teams were worth their coordination cost when implementation was the constraint. Once agents absorb the implementation, a large team keeps paying that overhead without the throughput that used to justify it. A team that small only works when the coordination those extra people used to do happens automatically.

My teams use the forward deployed engineer model for client work, and it fits these conditions well. Embedded engineer-architects own an outcome end to end instead of a queue of tickets. A few senior engineers with agents now cover ground that needed a full delivery team. The scarce skill was always working out what the client actually needs, and agents cannot do that.

Tooling⌗

Standardize on one agent stack across the organization. I once counted nine personal setups running in parallel, each with different models, skills, and tools. The workflows were impossible to support or secure, and nobody could answer a simple question about how the teams actually worked.

Guardrails need to be deterministic. Hooks and policies execute on every run; prompt instructions do not. Anything with real consequences belongs in code that runs whether or not the agent cooperates: a secret leaving the repository or a migration running unreviewed. An agent on one of my teams merged straight to main, pushed to the remote, and ran a Prisma migration that wiped the database (local though). AGENTS.md had a rule against all three.

Context files, playbooks, plans, and evals live in the repo under version control. They get written, reviewed, versioned, and deprecated like any other artifact. Prompts kept in chat history cannot be reviewed, improved, or handed to another engineer, and a team that keeps them there cannot explain why its agents behave the way they do.

Measurement⌗

Wire telemetry and capture a baseline before the first team onboards. Without numbers from before the agents arrived, you cannot tell which teams adopted the tooling, which workflows they use, or what changed when they started. I see this skipped more than any other step, and adding the measurement later leaves nothing to compare against.

Retire lines of code and commit counts. Agents generate both in volume at no cost.

Measure outcomes and ratios. Change failure rate, split between human-authored and agent-authored changes. Rework rate. Survival of AI-written code, meaning how much of it remains three months later, since code that gets deleted did not deliver value. Pair every speed metric with a quality counterweight: cycle time alongside change failure rate, throughput alongside rework. Speed improves under the same pressure that raises failure rates, so the two numbers carry meaning only when read together.

Pitfalls⌗

Pilot purgatory. Tools are installed and licenses assigned, and the working method does not change. The pilot meets every criterion the pilot defined, which is a low bar given who set it, while nothing ships differently. A rollout scoped as a tool adoption has no mechanism for changing how decisions get made.

The review bottleneck. I run into this one most often, and teams plan for it least. Agents multiply the volume of changes while human review capacity stays fixed. Without adding review capacity or moving review upstream, the queue relocates onto your most senior engineers. Mine are getting burnt out on ever-larger PR reviews. Past a certain size, some would just LGTM.

Stale context. An agent working from outdated context does not slow down. It produces wrong output at full speed, and that output reads exactly as it does when the agent is correct. This is the one that has cost me the most time to catch. It usually shows up when a downstream dependency changes its API contract and the context files still describe the old one. That failure predates agents entirely, and agents only changed how fast it spreads before anyone notices.

Measuring activity instead of outcomes. Teams optimize for whatever is measured. A metric that counts agent invocations will produce agent invocations. You will clear the target in week two, and you will have learned nothing.

Where to start⌗

I would give the first phase thirty days and keep the scope narrow: two or three teams, one sanctioned stack (my current favorite is Claude Opus 4.8 for the plan, GPT-5.5 in Codex for execution, then back to Opus for review), telemetry wired before anyone starts, and a baseline captured while the pre-agent numbers still exist. Standardize context and guardrails, then run one complete loop end to end on a real change rather than a demo, shipped with its evidence attached. Publish the before and after honestly, including whatever got worse. I would rather read your real thirty-day numbers than another transformation story with no baseline behind it.

Written the way it argues for. The outline came from my notes since the 2026 new year break, when agentic engineering took over how my teams work. An agent did the typing and fixed my grammar. I edited the hell out of the draft.