Greenfield is solved. Point a good model at an empty folder and it will build you something that runs, and it'll do it while you make coffee. The model-weight monsters are genuinely, spookily good at a blank page — Fable 5 will happily architect you a working app from a sentence. Model-weight-first development, where you lean on the raw capability of the weights, is great right up until the moment it isn't.
The moment it isn't is the gap everyone is stuck in. POC to production. The valley where 95% of enterprise pilots go to die.
And the thing missing in that valley has a name I keep coming back to: good steer. The difference between a model that's generally good and a model that's specifically good in your context. Turns out good steer also has a proper engineering name, borrowed from a different discipline entirely. It's backpressure. Once you see the whole POC-to-prod problem as a backpressure problem, it stops being mystical and starts being an engineering task — a hard one, but a nameable one.
What backpressure actually is
Backpressure is a term stolen from fluid dynamics — the resistance that opposes flow through a pipe. Jay Phelps has the canonical software write-up: in software it's the resistance opposing the flow of data. A producer generates faster than a consumer can handle, and something has to give.
His I Love Lucy image is the one that sticks: Lucy at the conveyor belt, wrapping chocolates, the belt going faster than her hands. She tries stashing them (buffering) and eating them (dropping), and neither works, because the real fix was never on her end. The real fix is to slow the belt — to control the producer.
That's the whole taxonomy, and it matters, so hold it:
- Control the producer — the consumer sets the pace. The only option with no nasty tradeoff.
- Buffer — pile the excess up to deal with later. Fine until it's unbounded, at which point it's how you fall over.
- Drop — throw some away.
Control is best. Buffering unbounded is death. Remember that second one — it's the whole back half of this post.
The model is the producer, and it's a firehose
Here's the mapping nobody says out loud. In AI-assisted engineering, the model is the producer. A firehose of plausible code, generated at a volume no human consumer can keep pace with. Generally good. Confidently wrong in exactly the ways your specific environment cares about. Left unchecked it overwhelms you — not because it's bad, but because it's fast and context-blind.
Backpressure is everything your environment pushes back to shape that flow. And Phelps' punchline maps perfectly: controlling the producer is the best strategy, and controlling the producer is exactly what good steer is. You're not cleaning up after the model. You're resisting its output in the right places until the flow comes out shaped like your context instead of like the internet's average.
This is also why the cheaper models matter more than the leaderboard suggests. A dumb, cheap model with heavy backpressure will out-ship an expensive genius with none — because the backpressure, not the weights, is what makes the output specifically right. Good steer turns a generally-good cheap monster into a specifically-good one. That's leverage you can afford at scale.
The backpressure you already have
Start where it's easy, because you're already doing some of this.
Prompt, then spec. Both are backpressure. A prompt resists the flow a little; a spec resists it a lot — it constrains the model toward one specific outcome instead of the thousand plausible ones. Every constraint you add is a hand on the belt.
Then TDD, and a test harness around the core loop. This is the good stuff. You wrap the generative function in tests, and every failure feeds back into the loop as steer. The agent runs, the bar goes red, the red bar pushes back, the agent corrects. Moss wrote the seminal version of this and Geoff Huntley boosted it: the successful agent setups are the ones that build structure around the agent to give it automated feedback on correctness, which lets it run longer-horizon tasks and earns your trust to hand it harder ones. Huntley's line is the one to tattoo on the wall — if you aren't capturing your backpressure, you're failing as a software engineer.
All true. All real. And all of it is local. This is the backpressure of one engineer's harness, resisting the flow inside one repo, one loop, one head. For a side project that's the whole game. For an enterprise it's barely the warm-up — because the producer you're trying to control is about to get pointed at a much bigger, much meaner consumer.
There be dragons
Let me not hand-wave the difficulty, because that's where every breathless AI-productivity take falls apart.
The number of ways a change can die on its way into production at a real enterprise, at speed and at scale, is enormous. Regulatory. Legal. Risk. Compliance. Cyber. The genuinely dumb CI/CD decision someone made five years ago that everything now depends on. Upstream and downstream change impact — and most harnesses are repo-myopic, they literally cannot see past the four walls of the repo they're running in, so they have no idea what they just broke three services over. The uniquely weird thing your org does at its router that exists nowhere in any training set. The org-wide architectural law about how you are and aren't allowed to secure an API.
Point a firehose at that and you do not get production software. You get a gorgeous POC that dies at the first dragon, and then a slightly different gorgeous POC that dies at the second one.
POC hell is an unbounded buffer
Now go back and collect that thing I told you to hold.
Buffering is fine until it's unbounded, and an unbounded buffer is how systems fall over. POC hell is an unbounded buffer. It's the exact failure mode. You've got a producer running flat out — a firehose of demos, prototypes, "look what I made in an afternoon" — and no backpressure strong enough to drain any of it safely to production. So it accumulates. The buffer grows. You generate faster than you ship, forever, and you mistake the volume of the buffer for progress.
The fix is not a bigger producer. It is never a bigger producer. A smarter model just fills the buffer faster. The fix is backpressure at the scale the producer actually operates — which, in an enterprise, is the whole org.
Org-scale backpressure: the harness-harness
The individual loop gives you local backpressure. The enterprise needs backpressure that carries the organisation's accumulated constraints back into the generative loop — at the moment of invocation, and again at the gate. That's a bigger structure than a test file. It's the harness your harness runs inside. I've built pieces of it, so this isn't theory:
Skynet is a code-intelligence layer over the entire estate — thousands of repos as one graph. It lets a coding agent compute upstream and downstream impact across all your repos, not just the one it's sitting in. That's a direct answer to the repo-myopia dragon: the flow gets resisted by the reality of what a change actually breaks elsewhere, before it ships, not after the incident.
Governor lets the vertical teams — cyber, cloud, data, legal-risk-compliance — assert their requirements as code, at invocation, and have them hard-asserted on CI. The org's policy pushes back on the generative function at the exact moment work happens, and again at the gate it has to pass. Not a meeting. Not a wiki nobody reads. Backpressure, expressed as policy, applied to the producer.
Add the rest — test harnesses, cyber checks on CI, the whole apparatus — and you've got the thing almost nobody is building: the org-level megastructure inside which an individual's harness runs. The harness-harness. In nearly every enterprise I've talked to, this layer simply doesn't exist. Which is precisely why they're stuck in POC hell. They bought the firehose. They never built the backpressure.
Capture it, or drown in it
Huntley's right that an engineer who doesn't capture their backpressure is failing. Scale it up: an organisation that doesn't capture its backpressure is going to buffer demos until it drowns in them, wondering the whole time why all that measured productivity never once reached a customer.
The model was never the bottleneck. It's a firehose and it's getting wetter every month. The bottleneck is, and always was, the backpressure — the good steer that turns raw generative capability into something specifically, safely, production-ready right here, in your weird, regulated, dragon-infested context.
Build the megastructure that supplies it. Or keep buffering, and call the puddle a strategy.
Receipts: the streams definition and the control/buffer/drop taxonomy are from Jay Phelps, "Backpressure explained". Backpressure-for-agents is Moss/Banay, boosted by Geoffrey Huntley. The "95% of pilots fail" figure is the MIT NANDA study, late 2025.