Cloudflare just wrapped a week of posts about what they call the agent development lifecycle: the SDLC rebuilt for a world where agents write the code. their welcome post glosses it as “SDLC but with humans taken out of the loop,” but the serious claim under the cheek is simpler: implementation is no longer the bottleneck, so the lifecycle has to change. i’ve been waiting for a big engineering org to say that plainly. because the argument the rest of us keep having, trust ai code or don’t, is older than the ADLC and a lot dumber.
that argument has two camps.
camp one is the software factory. point agents at the backlog, merge whatever comes out, ship at the speed the tokens stream. in this world you’re not needed at all; review is a bottleneck to delete. and the throughput is real: Cloudflare ran a pipeline of subagents that drove Astro’s open GitHub issues from 200+ down to about 30. but that pipeline had structure behind it. the merge-whatever-comes-out version gets its bill later: across 623 million code changes, GitClear watched duplicated code climb 81% while refactoring collapsed from 21% of changes to under 4%. the factory ships, and the codebase rots underneath it.
camp two says the model’s output can’t be trusted, and that if you’re shipping ai-written code you’re not a real developer. they keep every workflow manual and use ai like a fancy autocomplete. they have receipts too: METR ran a trial where experienced open-source developers were 19% slower with ai while believing they’d been 20% faster (METR themselves say tools have improved since). and the mood is spreading: nearly half of developers in the 2025 Stack Overflow survey actively distrust the accuracy of ai output.
both camps are answering the same question: do you trust the model? that’s not a question engineers ask about power tools. you don’t trust or distrust a table saw. you build a shop around it, a fence, a riving knife, a rule about where your hands go, and then the saw cuts all day. the question worth asking is: do you trust your system?
flowchart TD
Q{"the argument everyone is having:<br/>do you trust the model?"}
F["camp one: the software factory<br/>merge whatever the agents produce"]
S["camp two: the holdouts<br/>ai as fancy autocomplete"]
Fo["duplicated code up 81%,<br/>refactoring 21% to under 4%"]
So["19% slower in the METR trial,<br/>while feeling 20% faster"]
B{"the question worth asking:<br/>do you trust your system?"}
M["the middle path<br/>human plan gate, human promotion,<br/>model runs everything between"]
Q --> F --> Fo
Q --> S --> So
Fo --> B
So --> B
B --> M
classDef ask fill:#f1f5f9,stroke:#475569,color:#111827
classDef camp fill:#fee2e2,stroke:#dc2626,color:#111827
classDef cost fill:#fef3c7,stroke:#d97706,color:#111827
classDef good fill:#dcfce7,stroke:#16a34a,color:#111827
class Q,B ask
class F,S camp
class Fo,So cost
class M goodso let me lay out the middle path. it’s inspired by Cloudflare’s ADLC, and it’s built from what i’ve personally watched work.
where i’m coming from
quick credentials, because i’m about to ask you to believe something uncomfortable. i’m an engineer. i work every day with engineers who ship a lot of code. between us we run software that’s in production right now, software on its way to production, and a third kind i’ve started calling throwaway software… things you build in an afternoon because now you just can.
and across all of it, here’s the uncomfortable part: i’m producing good production code without reading most of the code.
not because i’m careless. because i moved my time to the two places where it changes the outcome. i spend it up front, researching the problem and reviewing the model’s plan before anything runs. and i spend it at the end, judging what the model produced: the outcome, the architecture, the proof that it works. the lines in between, the model writes, checks, and re-checks with more patience than my tired eyes ever had. only when something smells do i drop into the diff. then i promote the work forward.
that’s the whole thesis. you don’t need to read every line of code. you need a system that makes not-reading safe.
get the repo ready first
none of this works on a repo an agent can’t navigate. your agents are permanently new hires: sharp, tireless, and on day one forever. they read files, not Slack history. so before you hand one a ticket, the repo has to carry:
- a context file. CLAUDE.md, AGENTS.md, whichever your tools read; the agents.md format is in 60k+ open-source repos. architecture in one screen, the commands, the rules that always apply. Anthropic’s advice holds: keep it small, push depth into linked docs.
- real documentation and a real README. living truth, not archaeology. a stale doc now misleads every agent on every task that touches it, so keeping docs true is production work.
- an engineering standards doc. what a commit is, what a PR must contain, test expectations, security rules. written once, consumed twice: by the agent while building and by the reviewers while judging. Cloudflare runs their standards exactly this way, and their ai reviewer has flagged around 230,000 violations against those standards.
- skills for your repeatable workflows. the deploy ritual, the migration checklist, the release procedure. the second time you do a process by hand, package it.
- and the unglamorous parts that make autonomy possible: a dev environment the agent can run end to end, the connectors to every tool it needs, and CI that actually gates merges.
let the model run the whole loop
the biggest lever for me wasn’t a better model. it was handing the model the entire workflow instead of just the typing. don’t ask for code; ask for the finished job. and don’t be shy about scale… i’ll hand the model ten tickets at once and let it run long, because it can, as long as every ticket carries three things: a clear task, a definition of done, and verification criteria. autonomy scales with how well the work is defined, not with how small it is.
one thing stays mine no matter what: the definition of done. Kent Beck’s warning from his own experiments is that the genie would rather make the tests pass than fix the code, and he’s watched agents delete failing tests outright. the model writes plenty of tests. the acceptance criteria are human property.
here’s the loop, end to end:
flowchart TD
Plan["you: research, review the plan, approve"]
Build["model: code, tests, self-review,<br/>verify in dev env"]
PR["PR: tests green, video attached"]
Review["Greptile review"]
Merge["you: five-minute check, merge"]
Staging["staging: human QA"]
Promote["you: weekly test, changelog, promote"]
Prod["production"]
Plan --> Build --> PR --> Review
Review -- "findings" --> Build
Review -- "clean" --> Merge --> Staging --> Promote --> Prod
classDef human fill:#dcfce7,stroke:#16a34a,color:#111827
classDef machine fill:#e0f2fe,stroke:#0284c7,color:#111827
classDef ship fill:#fef3c7,stroke:#d97706,color:#111827
class Plan,Merge,Promote human
class Build,PR,Review machine
class Staging,Prod shipthree points stay human: the plan, the merge, and the weekly promotion. the model runs everything between them.
walking it: the model writes the code and its tests. then it reviews its own work, a real internal code review pass, because a second look catches what the first missed even when both looks are the model’s. then it verifies the work where the work runs: spins up the dev environment, exercises the feature, records it. this part stopped being aspirational a while ago; Cursor’s cloud agents attach video artifacts straight to the PR, and Claude Code and Codex drive a real browser. then it opens the PR with every test passing and the evidence in the PR body: the plan it implemented, what changed, proof it works.
then a review that isn’t the author. Greptile or whichever ai reviewer you run, configured with your standards, re-reviewing on every push. its findings go back to the model, not to you. if that loop hasn’t converged after a couple of rounds, a human steps in.
and only then, me. my check takes about five minutes: is Greptile clean, is the video convincing, are the tests green, and a skim of the file list for anything bloated or unnecessary trying to ride along. outcomes and architecture, not line-by-line. the one place i’d still read the diff line by line: auth, money, migrations, because Veracode’s benchmark still finds LLMs introduce security flaws in 45% of tasks. if it all holds, i merge.
if that reads like i’m barely working, look at the first box again. the plan gate is where the engineering happens. i research how the thing should be built, i make the model write the plan, and i don’t approve until i could defend that plan myself. review effort didn’t leave my week; it moved from diffs to plans and proofs. which is where it had to go, because reviewers were drowning anyway: teams with heavy ai adoption merge 98% more PRs while review time balloons 91%.
how the team ships
one person running this loop is nice. a team shipping on it is the point, so the mechanics matter.
preview deployments are optional and disposable. spin one up when someone needs to show work in progress (per-PR previews make this nearly free), share the URL, trash it when the conversation is over.
every PR merges to staging. staging is where the week’s merged work accumulates, running like production, and it’s where human QA walks the flows that matter.
production ships weekly, by a person. at the end of the week someone reviews everything sitting in staging, tests it, updates the changelog, and promotes. the train has one bypass: a production incident doesn’t wait for friday. a hotfix runs the same loop at speed, ships alone, and backfills the changelog. the changelog itself is not optional: a changeset per user-facing change keeps it honest, and tagged GitHub releases make the shipping history public to the whole company. in DORA’s terms weekly sits right at the high-performer line, and their decade of data says speed and stability rise together… so treat weekly as the training cadence, and raise it as the system earns trust.
flowchart LR
Merged["merged PR"]
Preview["preview deploy<br/>optional, disposable"]
Staging["staging<br/>the week's work accumulates<br/>human QA walks the flows"]
Weekly{"friday: a person reviews,<br/>tests, updates the changelog"}
Prod["production"]
Incident["production incident"]
Hotfix["hotfix: same loop, at speed<br/>ships alone, backfills the changelog"]
Merged --> Staging --> Weekly --> Prod
Merged -.-> Preview
Incident --> Hotfix --> Prod
classDef flow fill:#e0f2fe,stroke:#0284c7,color:#111827
classDef human fill:#dcfce7,stroke:#16a34a,color:#111827
classDef bypass fill:#fee2e2,stroke:#dc2626,color:#111827
classDef opt fill:#f1f5f9,stroke:#94a3b8,color:#111827
class Merged,Staging,Prod flow
class Weekly human
class Incident,Hotfix bypass
class Preview optunderneath all of it, the discipline that keeps the whole thing auditable: conventional commits, PRs that are one reviewable idea, a branch structure everyone shares, versioning and tags that mean something. agents inherit your hygiene.
hold both ends
Cloudflare is right that the lifecycle has to be rebuilt around agents. my version of the rebuild keeps the two ends firmly human: the start, where you decide what to build and approve the plan, and the shipping side, where you judge the outcome and promote it. i hold those with both hands, i let the model run everything in between, and i ship better code than i did back when i read every line.
the camps can keep arguing about the model. models change quarterly anyway; any opinion about “the model” dies with the next release. the system compounds. write yours down, hand it to your team and your agents both, and let the middle scale.