Intent Is the New Constraint: Where Engineering Craft Moved in 2026

There's an idea from a 1984 business novel that explains more about software in 2026 than most things written about software in 2026. The novel is The Goal, by Eliyahu Goldratt, and the idea is the Theory of Constraints. It says that any system – a factory, a team, a pipeline – has, at any given moment, exactly one dominant bottleneck. And it draws an unforgiving conclusion from that: improving anything other than the bottleneck is wasted effort. Speed up a step that isn't the constraint and the system doesn't get faster. You just produce a bigger pile of work waiting in front of the step that still is.

Hold that idea, because it's the cleanest way to understand what AI did to software development. For years, the constraint in building software was writing the code. AI didn't remove that constraint. It moved it. And where it moved tells you where the real work now lives.

The chain, and where the slow link used to be

Picture software delivery as a simple chain. Intent becomes code, code becomes a check, the check becomes a release. An idea in someone's head turns into working instructions, those instructions get verified, and the verified result ships to users.

For most of the history of the field, the slow link kept moving. Early on, the constraint was infrastructure – just getting servers provisioned and environments stood up absorbed enormous effort. Then, as that got easier, the constraint became implementation: the sheer labor of translating an idea into correct, working code. That's the link that defined what "engineering" meant for a generation. Being a great engineer largely meant being good at that translation – holding the problem in your head and turning it into code that worked.

That's the link AI is dissolving. As one widely-shared 2026 essay on the site berme.io put it, applying Goldratt directly, the work of turning intent into code is becoming fast and cheap. Coding agents – AI systems that write and modify code on instruction – are thinning out the middle of the chain. The translation step that used to take days takes hours, or less.

By Goldratt's logic, when you relieve the constraint, it doesn't vanish. It relocates. And in software it relocated in two directions at once.

Downstream: the pipeline jammed

In one direction, the bottleneck slid downstream, to the check-and-release end. If you generate far more code far faster, all of it still has to be reviewed, integrated, tested, and deployed – and those steps didn't get an AI speedup of the same magnitude. So the code piles up against them. CircleCI's 2026 analysis of software delivery, summarized by the firm Thoughtworks, names this directly: integration, rather than code generation, is now the rate-limiting step. The jam moved from writing to shipping.

That's real, and it's where a lot of the industry's attention has gone. But it's the less interesting half of the story. The more important relocation happened in the other direction – upstream – and far fewer people are looking there.

Upstream: agents do exactly what you said

Here's the property of coding agents that nobody quite prepared for. They do exactly what the intent says. Precisely, literally, faithfully. And that turns out to be a problem.

A senior human engineer, handed a vague or slightly contradictory spec, doesn't just execute it. They notice the gap. They fill in the obvious missing piece, flag the contradiction, wander over to ask "wait, did you mean X or Y?" before building the wrong thing. That quiet absorption of ambiguity is most of what experience buys you, and it's invisible precisely because good engineers do it automatically.

Agents don't do that. They take whatever shape the intent has – sharp or vague, complete or full of holes – and execute against it faithfully. They don't resolve the ambiguity; they build it. If the intent is unclear, you don't get a clarifying question. You get a confident, fast, thorough implementation of something subtly wrong.

This is the part that quietly turned problem definition into the constraint. As the Linear CEO's argument is paraphrased in that same berme.io piece, the craft of software is shifting upstream – away from writing code and toward forming clear intent, assembling the right context, and articulating the constraints that make the work meaningful. The activity that used to feel secondary, the part you did quickly so you could "get to the real work" of coding – figuring out what actually matters, naming the tradeoffs, defining what "done" means – is now the limiting factor for the whole system. Not because it's nice to do it well. Because the agent will faithfully and rapidly build the wrong thing if you don't.

This is a product-strategy problem in disguise

Look closely at what "forming clear intent" actually is, stripped of the engineering vocabulary. Knowing which problem is worth solving. Knowing who it's for. Knowing the constraints the solution has to respect, and what would make the result genuinely good rather than merely functional. That's not a coding skill that happened to get more important. That's product strategy. And it just became the binding constraint of software delivery.

This reframes where a team's scarce attention should go, and the reframing runs against the prevailing instinct. The instinct, when execution gets cheap, is to chase more execution – more agents, more code, more velocity, more output. Goldratt would call that the classic mistake: pouring effort into a step that is no longer the constraint, and getting a bigger pile of work waiting at the step that is. If implementation is cheap and intent is the bottleneck, then the leverage is upstream, in the work most organizations still file under overhead. The problem definition. The context-gathering. The ruthless clarity about what's actually worth building.

There's a strand of 2026 management thinking – sometimes flying the "#NoProjects" banner – that lands in the same place from a different door: govern the work around learning and the true constraint, rather than around adherence to a plan written before anyone understood the problem. Different vocabulary, identical physics. When the cost of building something drops toward zero, the value of knowing what to build climbs toward everything.

What to invest in when building gets cheap

So the practical move is almost the opposite of the reflex. Don't put your best people on going faster. Put them on the front of the line – on intent. Treat problem definition, context, and constraint articulation as first-class engineering work, with the seniority and the time that implies, because that is now precisely what they are. The leverage isn't in the typing anymore. It's in being clear about what's worth typing.

The craft didn't leave engineering when the agents arrived. It moved to the front of the line – to the place where it was always quietly doing the most important work, and where, now, it's the only thing the whole system is actually waiting on.