The Human-Gated SDLC

Almost everyone I talk to has already adopted AI in their engineering org. The DORA 2025 data backs that up: roughly 90% of professionals now use AI in their work. The question on the table has quietly changed. It's no longer “can AI write code?” It obviously can. It's the messier one nobody hands you a playbook for: how do we adopt this at team scale without drowning in slop and losing our engineering judgment?

Here's the tension that should be keeping engineering leaders up at night. Adoption is near-universal, but trust is falling. In Stack Overflow's 2025 survey, trust in AI accuracy dropped from 40% to 29% year over year, and only 3.1% of developers say they “highly trust” the output. Favorability is sliding too. We have built an entire operating model on a tool the people using it increasingly don't trust.

That's not a capability problem. It's a trust-and-accountability problem. And capability is not the thing that fixes it.

The two answers I don't believe in

When teams hit this wall, they tend to fall toward one of two poles.

The first is vibe coding: let the model run, ship what looks right, find out in production. It feels fast. The METR randomized trial is the splash of cold water here: experienced developers working in familiar codebases were measured 19% slowerwith AI, while believing they were about 20% faster. (Caveat worth stating plainly: that's early-2025 tooling, experts, large familiar repos. I won't over-read it. But the gap between felt speed and measured speed is the whole point.) Vibe coding optimizes for the feeling.

The second is full autonomy: the cleanest articulation is Geoffrey Huntley's “Ralph” , where the human is “on the loop, not in it.” Gates are automated: tests, lints, the model fixing the model. It's a real position, held by serious people, and it has its place. But as a general operating model for an org that has to stand behind what it ships, it removes the humans from exactly the decisions that carry accountability.

Both poles share a hidden assumption: that the human is overhead. Either skip the review, or automate it away. I think that's backwards.

The third path: a human-gated SDLC (software development life cycle)

The conversation right now is mostly happening under the banner of spec-driven development, intent as the source of truth, pitched explicitly against vibe coding. I think SDD is directionally right, and it's the best on-ramp we have. But its center of gravity is the spec: GitHub Spec Kit, AWS Kiro, Tessl, Thoughtworks, all good work, all crowded, all arguing about how much of the truth lives in the markdown.

I want to move the argument one step over. The spec is necessary. It isn't where the leverage is. The leverage is in where the humans stay in the loop. Call it the human-gated SDLC: AI does the synthesis (drafting, expanding, translating intent into options) and humans hold a small number of deliberate gates at the points where judgment actually matters. Not review everywhere (that's the “verification tax” DORA describes: “I spend more time babysitting the AI”). Not review nowhere (that's Ralph). Review where the decision is irreversible or expensive to get wrong.

This isn't a framework I sketched on a whiteboard. It's the pipeline we run.

The pipeline, and its three gates

beebucket's Feature Lifecycle is a nine-phase pipeline that takes an idea to production. AI skills do the synthesis work between phases. And there are exactly three deliberate human gates, chosen, not defaulted:

Three gates. Everything between them, AI accelerates. The discipline is in keeping the gates few, deliberate, and exactly where judgment compounds.

Why this beats buying more tools

The most useful finding in DORA 2025 is that AI is an amplifier. It magnifies the strengths of healthy organizations and the dysfunctions of struggling ones in equal measure. It correlates with both higher throughput andhigher instability. AI doesn't hand you a process; it scales whatever process you already have, including the absence of one.

That's why “which copilot did you buy?” is the wrong question, and “where are your gates?” is the right one. Tools are roughly fungible now. The gate placement (the part that's actually yours) is what determines whether AI amplifies your craft or your chaos.

For teams in regulated and public-sector contexts, this lands even harder: when you have to be able to say who decided what and why, deliberate human gates aren't friction, they're the audit trail. I'll keep that as a backdrop here rather than the headline, but it's not a coincidence that the human-gated model and accountability-heavy environments fit each other so well.

Where I'm genuinely unsure

I won't pretend the gate placement is settled. Even SDD's most pragmatic voices (Birgitta Böckeler at Thoughtworks) openly wrestle with it: “I'd rather review code than all these markdown files.”Where human review should sit is the live question. I have a strong opinion shaped by running this pipeline for real, not a proof. Which three gates, in which order, for which kind of org: that's exactly the conversation I want to be having with other engineering leaders.

If this is your problem

If you've adopted AI across your team and you're feeling the slop, the verification tax, the quiet erosion of trust. You don't need more tools and you don't need to ban the ones you have. You need to decide, deliberately, where your humans stay in the loop.