Article — "AI Removes Engineering's Feasibility Veto — and Redraws Cross-Functional Power": Article — "AI Removes Engineering's Feasibility Veto — and Redraws Cross-Functional Power": Two people who watched the same barrier fall came to opposite conclusions about what to celebrate.
Dan Maccarone, writing about the moment AI dissolved engineering's monopoly, treats it as a liberation: the room nobody could see into is finally lit, and the veto that killed his work is gone. Andrew Baker, a bank CIO, calls it the part of the AI transition almost nobody is planning for.
Both are right. That's the problem. What Maccarone celebrates as freedom is exactly what Baker is warning about, and they diverge because they're describing two different barriers that used to be welded into one.
Start with the scene Maccarone opens on, because it's the whole argument in miniature.
He's a young information architect, three weeks into wireframing a massive enterprise product. The presentation begins. "I got through wireframe number three, of about a hundred and twenty, before the engineering PM interrupted. 'No, not in scope.'"
Then it happened again. And again. Piece by piece, the work was disassembled — not feasible, not this timeline, not the way he'd built it.
The client, the boss, the person running the meeting — none of them could save it. Only engineering got to decide what was real.
The instinct is to read that as gatekeeping. It wasn't. It was a reality check, and the cheapest one the product team had.
Notice how far upstream the power sat. Maccarone came into the project after the tech specs were written and the features chosen — before the person designing the actual experience was even in the room. The constraint wasn't a stage in the process. It was the thing the whole process bent around.
That's Goldratt's binding constraint: every system has one link that governs the whole chain, and everyone organizes around it. In software, that link was feasibility — Marty Cagan's "can we build it, and how long will it take" — and it belonged to engineering, full stop.
But the interesting question is why. And the answer is not competence, or not only competence.
The power came from illegibility. A stakeholder could argue about a button's color. Anyone could sketch a user flow at a whiteboard and be roughly right. The work was legible; you could point at it and push back.
Code was not. It came back wrapped in words you couldn't argue with — it's a race condition, it'll break the schema, that's coupled to the auth layer. Each might be completely true. You had no way to check, and that was the point.
Maccarone reaches for exactly the right frame: Akerlof's market for lemons. When the seller knows which cars are lemons and the buyer can't tell, the seller holds all the leverage, and the market bends around the imbalance.
Software teams ran on that asymmetry. The people who could read the code got to say what was a lemon. Everyone else took their word for it.
So the veto wasn't just a bottleneck. It was a filter — a crude, imperfect, sometimes self-serving filter, but a functioning one. When an engineer said no, they'd usually paid for that knowledge the hard way, at 3 a.m. when something broke. The scars were part of the assessment.
Now watch the barrier fall.
Patrick Morgan set out to organize his team's prototypes at Sublime Security and ended up building something else entirely: an agent-native design tool, with design principles that guide how the agent prototypes, plus a system to port over production frontend. A designer, holding what used to be engineering's leverage.
John Bai, who was reportedly the first NYC design hire at Cursor, uses agents to streamline his Figma work, at a company where — tellingly — no two designers have the same tools or process. The terminal, which reportedly (per a separate account) always exposed the language of the machine rather than the possibilities of the tool, is being handed back to designers through agents that translate intention into action.
This is real. The asymmetry Maccarone described is genuinely dissolving. Designers can now make the thing exist, which means engineering can no longer end the argument by being the only ones who can end it.
And here's where the celebration gets dangerous, because Baker names the split that Maccarone's essay quietly steps over.
"AI demolished the barrier to production and did not touch the barrier to judgement."
AI demolished the barrier to production and did not touch the barrier to judgement — and most organizations have no mechanism for telling the two apart.
Those two things were bundled together for so long that we started treating them as a single capability. The ability to produce a thing and the ability to assess whether the thing is any good arrived, historically, in the same person. Now they've come apart, and most organizations have no mechanism for telling them apart.
Baker's scene is the mirror image of Maccarone's, and just as sharp.
Take a mature mobile banking app: ten-plus years old, thousands of screens, per Baker roughly 1,200 APIs, security controls added after specific incidents, dependencies nobody has audited since 2019. Someone proposes migrating the whole thing to a new stack with agents. A proof of concept gets built.
It demos beautifully — as these things always do, because the demo path is the one thing an agent will absolutely nail. And then someone in the room says: "I liked the output."
Baker's response is the entire point of this piece. The relevant question is not whether they liked it. The relevant question is whether they are qualified to know whether it is good.
"I liked the output" is not an engineering assessment. It's a reaction to a happy path.
Put those two scenes side by side. Maccarone's engineering PM began rejecting his wireframes with "not in scope" — and however much that stung, the filter was doing work. Baker's steering committee waves through a migration of 1,200 APIs on the strength of a demo, because the person who used to say "not feasible" no longer has the only key to the room.
That's the migration nobody's tracking. The veto isn't vanishing. It's being reassigned — to whoever can look at a working demo and tell whether it survives contact with reality.
And that job is harder than the old one, not easier. Saying "no, not feasible" required knowing what could be built. Saying "yes, this is actually good" requires knowing what breaks at hour four, on the path the demo carefully avoided.
So the real question for design orgs isn't the triumphant one Maccarone's title implies — did we take away engineering's right to say no. It's the uncomfortable one underneath it: if we inherit the power to ship, do we also inherit the duty to catch the lemon?
Because the veto was load-bearing. It filtered out things that looked fine and weren't. Remove the person who held it and don't replace the judgment they carried, and you haven't removed a constraint — you've removed a reality check, and kept all the velocity that used to be safe only because that check existed.
There's a version of this transition where designers become genuine governors of AI output: people who can read a build well enough to know when the happy path is hiding a schema that won't scale, an auth coupling that will break, a dependency nobody audited. That version is a real upgrade. Judgment migrates to the people closest to the user and the intent.
There's another version where "I liked the output" becomes the whole review, and the org confuses its new speed with new competence. That version ships lemons faster than any org in history ever has, and calls it progress.
The barrier that fell was production. The barrier that didn't is the one that matters now.
Whoever ends up holding the veto — and design has a real shot at it — needs to be able to tell a good build from a demo that just nails the happy path. Gaining the power without gaining that discipline isn't liberation.
It's just a faster way to disassemble the wrong hundred and twenty wireframes — except now, no one in the room can tell.