The agentic SDLC, and the stage everyone skips

The classic SDLC exists because writing code was the expensive, error-prone middle of the process; every stage around it was built to protect the organization from that middle. Agents collapse the middle. Implementation gets fast and cheap, and the surrounding stages stop fitting.

The ADLC is the redesign. Intake comes straight from the tracker (FactoryKit picks tasks up from a Linear label). Implementation is an agent in a sandbox. And the interesting design question moves downstream: if code is written 10x faster but reviewed at human speed, you have not removed the bottleneck. You have moved it to review and made it worse.

The industry is loud about throughput and quiet about regression risk. DORA’s research has said for years that elite delivery pairs speed with stability; the pairing is the point. Throughput without a stability mechanism is faster defect delivery.

We came to this conviction at Bug0, where we build automated QA, and the lesson transferred directly to agents: test suites pass while software breaks. An agent’s claim that a change works is an assertion. A recording of the change working is evidence.

• Checks as contract. Every change runs the repo’s own lint, build, and tests, with a fix budget (FactoryKit allows 3 attempts) before a human sees anything.
• Self-review. The agent re-reads its own diff against the task before packaging.
• Behavioral QA. UI changes get exercised in a real browser, and the session is recorded.
• Evidence on the PR. The recording and check results ship with the pull request, so review starts from proof rather than trust.

Under that design the human checkpoint gets cheaper instead of more loaded: reviewers watch the feature work, then read the diff with intent.

You can build this in-house. Uber’s internal pipeline is a good public reference for what that takes. Or install one: FactoryKit ships this ADLC as a working software factory on your own infrastructure, set up and run in by forward-deployed engineers.