AI didn’t touch what engineers actually know. It ended their power to be the only ones who could say what was possible.
When I started out as an information architect, one of my first projects was a massive enterprise product. By the time my boss assigned it to me, the tech specs had been written and the features defined. My job was to turn them into wireframes.
I spent three weeks burning the midnight oil trying to get every detail right, reviewing with my boss, making sure I’d translated the documentation into a solid user experience.
Then came the night we presented it.
I got through wireframe number three, of about a hundred and twenty, before the engineering PM interrupted. “No, not in scope.” I brushed it off as one thing I’d probably gotten too exuberant about and kept going. It came again. And again. And again.
Piece by piece, the work was disassembled as not feasible, not in this timeline, not the way I’d built it. Nothing could be done. Not the client, not my boss, not the person running the meeting, none of them could save it, because none of them got to decide what launched. Engineering did.
When engineering said a thing couldn’t be built, the thing didn’t get built.
I was green enough to be crushed and green enough to assume they were right. Back then, they usually were. The engineers really did know what could ship and what couldn’t, and the rest of us really didn’t. That’s why the process worked.
Notice that I came into that project with the specs already written, the features already chosen, before the person designing the actual experience was in the room. That’s how far upstream the power sat.
Every system has a constraint, one link that governs the whole chain. Eliyahu Goldratt built a management philosophy on the idea that a factory, a company, any process bends around its weakest point, and everyone ends up organized around whoever that is.
In building software, the “can we build it, and how long will it take” question, what Marty Cagan calls “feasibility,” always belonged to engineering. For most of the history of the field, feasibility was the binding constraint. One group held a quiet, near-absolute say over everyone else on the product team, the power to decide what was real.
The business could want it. The client could pay for it. The designer could make it beautiful. It still died if the people who had to build it said no.
That power didn’t come from strategy. Back then, engineers were rarely even invited to the early meetings. It came from the one fact that they were the only ones who could turn an idea into a shipped product.
It was earned. The reason engineering’s word carried was that building software actually is hard, years of learning systems, languages, edge cases, the accumulated scar tissue of things that broke at 3 a.m. When an engineer said a thing was hard, they’d usually paid for that knowledge the hard way. The authority was real, but what changed is that it stopped being the only thing standing between an idea and a working version of that idea.
When you’re the only one who can make the thing exist, you don’t have to win the argument about whether to build it. You just say how long it’ll take, or whether it can be done at all, and no one can tell you you’re wrong.
That is what AI is quietly dismantling. By that, I mean the monopoly held by engineering.
The room nobody could see into
The reason this hierarchy held on so long was because engineering was the one room in the building nobody else could see into.
A stakeholder could look at a design and have an opinion about the color of a button. Anyone could stand at a whiteboard and sketch how a user moves from one screen to the next and be roughly right about it.
The work was legible. You could point at it and argue with it. Code was not.
You’d raise an idea in a meeting and watch it come back wrapped in words you couldn’t argue with. It’s a race condition. It’ll break the schema. That’s tightly coupled to the auth layer. The architecture won’t support it. Each one might be completely true. You had no way to know, and that was the point. The conversation was over, because who were you to push back?
Code happened behind a door, in a language most of the people relying on it couldn’t read, and that illegibility was the whole source of the power. In 1959, John French and Bertram Raven mapped out the bases of social power, the reasons one person defers to another, and one of them was what they called expert power, or the influence you hold simply because you know something the other person doesn’t and can’t easily check.
They filed it under informal power. It needs no title, no seat on the org chart.
The CTO didn’t have authority over strategy or the customer or the budget. What the CTO had was the only answer nobody else could check.
George Akerlof won a Nobel Prize partly for a 1970 paper about used cars that showed what happens to a market when one side knows more than the other. When the seller knows which cars are lemons and the buyer can’t tell, the seller holds all the leverage, and the whole market bends around that imbalance.
Software teams ran on the same asymmetry. The people who could code got to say what was a lemon and what wasn’t, and the rest of us had to take their word for it.
Edgar Allan Poe’s “The Purloined Letter” is an even older version of this. In the story, a stolen letter everyone is frantic to recover has been hidden in the most obvious place imaginable, out on a desk, in plain sight, and it stays hidden precisely because everyone assumes something that valuable must be locked away somewhere hard to reach.
The power of the letter wasn’t in the actual letter, of course. It was in everyone’s belief that getting to it was harder than it actually was.
Psycho-analyst Jacques Lacan built a whole seminar on that story, arguing the letter’s actual contents never even matter, what matters is the hold it has over whoever’s chasing it. I’ll let you decide how much that sounds like a room full of adults deferring to a Jira ticket.
The code worked the same way the letter did. What can’t be checked doesn’t get checked, and for thirty years a guess got to stand in for the truth.
We have been here before
This isn’t the first time a craft got its doors kicked open.
There was a moment in the late 1980s when desktop publishing arrived and, suddenly, anyone with a Macintosh and a laser printer could do something that used to require a print shop, a paste-up artist, and a union card.
“Desktop Publishing” even became a buzzword that swept through every office, and panic followed. The publishing industry worried that if everyone can set type now, what happens to the people who spent years learning to set type well?
In the early days of the internet, we heard similar stories from clients. You’d be in a meeting and they’d ask why the design work cost so much. They’d say, “My nephew knows Photoshop, so he can make my logo.”
The tool got easier to access and easier to use, and for a minute it looked like the profession behind it was finished.
Obviously, it wasn’t.
The reason it wasn’t is the most important thing to understand about the moment we’re in now. Rebecca Kelly, writing about the democratization of design, said that the tools became available to everyone, but design literacy, the sense of why one choice is right and another is a disaster, didn’t spread with them.
Anyone could open the software. Almost no one could open the software and be good.
The profession didn’t die, but the value stopped being can you operate the tool and became do you know what to make it do.
The people who thrived were the ones who stopped guarding access to the tool, which was gone anyway, and started selling the judgment the tool couldn’t provide.
Hold onto that idea, because engineering is about to live through the exact same thing.
What broke it
Here is what changed.
In February 2025, Andrej Karpathy, a founding member of OpenAI, posted something half-joking to describe a way he’d started working. He called it “vibe coding.” You describe what you want to an AI, you accept what it gives back, you barely look at the code, and somehow a working thing appears.
He meant it loosely, a throwaway line about a throwaway weekend project.
The line did not stay throwaway. Nine months later, Collins Dictionary named “vibe coding” its word of the year.
A joke became a dictionary entry in less time than it takes most companies to ship a feature, which tells you it named something real.
It is real. By 2024, Kyle Daigle and GitHub’s research team surveyed two thousand developers at enterprises across the U.S., Brazil, India, and Germany, and found more than 97% of them already using AI coding tools at work. Adoption wasn’t a trend anymore. It was the water.
While the survey is full of numbers about professional developers working faster, the part that matters is that the door came off the hinges for everyone else.
Now a founder can go home on a Friday, open Claude (or Cursor, Figma Make, etc.), and by Monday have a rough version of the three-week feature limping along well enough to make a point. The designer who was told for years that her idea was too hard to build just builds it, perhaps with poor code, and ships it.
There’s a scene in the first Iron Man that keeps coming to mind. Obadiah Stane, told by his engineers that the thing simply can’t be done, the technology doesn’t exist, explodes. “Tony Stark was able to build this in a cave! With a box of scraps!” His engineer, quietly, honestly says, “Well, I’m sorry. I’m not Tony Stark.”
We’re living in that moment right now.
The impossible thing just got built, and “it can’t be done” now has to reckon with the fact that someone, somewhere, with far less experience than you, already did it.
It doesn’t mean the cave version is good. That first Iron Man suit was, at best, a prototype. Anyone who’s watched a slick demo fall apart the second a real user touches it knows the gap between “it works on stage” and “it works.” The entire comedy of Silicon Valley demonstrates that epically.
The demo doesn’t have to be well-coded to show it’s possible. It just has to work once, in a room full of people who were told it couldn’t.
The confident claim that used to end the conversation now has to survive a live counterexample.
The part where the code is bad
Before anyone frames this as the machines making engineers obsolete, let’s be clear that a lot of that weekend code is bad.
By “bad,” I mean that it works right up until it doesn’t, in ways only someone who actually knows what they’re doing can see coming.
GitClear analyzed more than 200 million lines of code and found that as AI tools took over, code duplication jumped eightfold, refactoring fell off a cliff, and short-term churn, code rewritten or thrown out within two weeks, kept climbing.
All of that is the signature of technical debt, stuff that runs today and becomes someone’s nightmare in six months. Developers feel it.
In Stack Overflow’s 2025 survey, even as adoption climbed toward 80%, trust in the accuracy of AI output fell to 29%, and the single most common complaint was code that is “almost right, but not quite.”
Somewhere in a real product I’ve worked on, an AI decided, with total confidence, that everyone in the United States changes their clocks at the same moment. Arizona does not change its clocks. Arizona has not changed its clocks since the Johnson administration, and somewhere a chatbot is still surprised about it.
The bug it produced quietly handed certain users double points and a duplicate notification if they did the right thing at the wrong hour, which no one noticed until the numbers looked strange. That’s where things get problematic.
It’s easy to say that AI writes code that fails. Failure is loud and easy to catch. The problem is that it writes code that works, mostly, and buries the mistake somewhere no one notices until it’s already live.
The fact that anyone can now generate working-ish code is precisely why judgment, real engineering judgment, the kind that knows what’s a lemon, matters more than it ever did. The floor’s just gotten lower and the ceiling higher. What has collapsed is the space in between, the place where guessing went unchallenged.
To be fair, it’s not all garbage. GitHub’s own controlled research found AI assistance improved readability and reliability on well-scoped tasks, and Google has reported real velocity gains.
The truth is, and where the DORA research lands, is that AI improves the small stuff, a cleaner function, a faster first draft, while quietly straining the big stuff, the stability and coherence of the system as a whole. It can write you a paragraph. It can’t yet write you a whole cohesive book.
A machine can hand you paragraphs all day. A human still has to organize them into a book that holds together.
The reckoning
For most of history, the people who could read the text held power over the people who couldn’t. Scripture stayed in Latin, the priest told you what God wanted, and you believed him because you had no way to check.
Code worked the same way. It sat behind a language the rest of the room couldn’t read, and whoever could read it didn’t just answer questions. They got to pronounce what was possible, and be believed. That’s a kind of power most jobs never touch.
Anyone can build something. Far rarer is the authority to declare what can’t be built, and have the whole room take it as fact.
The thing about pronouncements is that they’re often just confident guesses. Amos Tversky and Daniel Kahneman, in the work that helped win a Nobel Prize, showed how badly a number, any number, anchors the people who hear it. Say three weeks and three weeks becomes the gravity the whole conversation falls toward, whether or not three weeks was ever true.
Bringing it back to our world, Lucas Gren and Richard Berntsson Svensson ran a series of experiments on exactly this. Ask a developer how long a job will take, pad the description with requirements that don’t actually apply, and the number climbs to match, even though the real work never changed.
Confident expertise is wrong all the time, even at the top. William Goldman, who won two Oscars writing movies, exposed the truth about Hollywood when he said, “Nobody knows anything. Not one person in the entire motion picture field knows for a certainty what’s going to work.”
Every studio but one passed on Raiders of the Lost Ark. The people paid to know didn’t, and couldn’t.
Engineering’s verdicts carried the same certainty and the same odds, and the only people who could tell a real limit from a convenient one were the ones handing down the verdict.
Shakespeare wrote the two versions of this power, and I’ve worked with both. One is Iago in Othello, whose entire weapon is that no one ever checks him. Everyone calls him “honest Iago,” and the honesty is precisely what makes the manipulation work. Othello never tests Iago’s honesty. He treats it as settled, and reasons out from there, which is exactly why the lies land.
More on the second one later.
That’s the CTO whose “it can’t be done” is load-bearing specifically because it’s unauditable. Not necessarily a liar, but a person whose one channel of truth nobody else can reach, and who knows it.
The higher the stakes, the sharper the leverage, and the stakes are never higher than for a founder who can’t read the code. Paul Graham, who has funded more startups than almost anyone, named the problem in “The 18 Mistakes That Kill Startups,” Business guys, he wrote, “can’t tell which are the good programmers.”
A non-technical founder can’t fully evaluate the work, the timeline, or the “no.”
Fundraising depends on shipping, shipping depends on the CTO’s yes, and when the CTO says a feature is six months out, the founder has no independent way to know whether that’s true, roughly true, or a negotiation dressed as a fact.
I’ve watched founders spend years effectively hostage to the one person who could turn their company into a product, not because that person was a villain, but because no one else could see into the box well enough to push back.
Unfortunately, I’ve dealt with that. The one who hears that a designer prototyped the “impossible” feature over the weekend and gets defensive, who reaches for a new reason it still can’t really be done, who treats being checked as an insult rather than an invitation. I’ve left companies over exactly that.
Watch what happens to any group when the thing that protected them stops protecting them. They protect themselves instead. The defensiveness is what people do when a monopoly they built a career on quietly expires without any warning.
The impulse is entirely understandable. I just don’t think it’s survivable.
The good ones already knew
Remember I said Shakespeare wrote two versions of this power. Iago was the first. Prospero is the second.
In The Tempest, Prospero, at the height of his powers and the most knowledgeable figure on the island, the one who can do what no one else even understands, chooses to give it up. He says, “I’ll break my staff… and, deeper than did ever plummet sound, I’ll drown my book.”
The staff was his authority. The book was his knowledge, the source of all of it. He drowns the book on purpose, not because it’s taken from him, but as an act of trust toward the people he’d been holding under his power.
That’s the good CTO. Same expertise as Iago, opposite instinct.
The ones I’ve admired most never hoarded the “can it be done” answer as leverage, but rather they opened up the conversation. They pulled the designer and the strategist into the room and told you honestly what was cheap and what was expensive and why.
Remember that wall of words, it’ll break the schema, the architecture won’t support it? A good engineer says the exact same sentence, then adds the part the gatekeeper always left off, which is here’s what that actually means, and here’s what we could do instead.
They treated their knowledge as something to spread rather than something to charge rent on. For them, none of this is a threat, because they were never relying on keeping things opaque.
They were relying on being collaborative, and being collaborative is exactly the thing that’s worth the most right now.
That instinct turns out to be quite effective. When Google spent two years studying what actually made its teams succeed, expecting to find the answer in talent or seniority, what it found instead was psychological safety. The teams that performed best were the ones where people felt safe to speak up, admit they were wrong, and ask the question everyone else was afraid to ask.
The idea, first defined by Amy Edmondson, describes exactly the environment a collaborative engineer builds and a hoarding one prevents. A team sitting in silence, deferring to the one person who can’t be questioned, is the precise opposite of the thing that makes teams work.
I’ve been fortunate to experience that version up close, multiple times.
A CTO who, instead of guarding the codebase, opened it, set up a shared way for everyone to see what was being built and why, and reframed his own job from gatekeeper to the person who makes it easier for everyone else to build well.
A team that handed designers direct access to the code and treated it as an experiment worth running rather than a border to defend.
In one company, I watched a skeptical CTO stop worrying we were going to embarrass ourselves with AI and realize he no longer had to personally build every small thing, that he could hand off the making and spend his own scarce time on the judgment only he had. You could see the relief.
This is happening everywhere now. I’ve talked to teams at big, established companies where product managers have started generating working code directly, and the whole organization is scrambling to figure out what that means, sometimes in a build-first-think-later panic that is its own kind of mess.
Carrie Webster describes a “rework tax” spreading across the field, engineering teams losing whole days to cleaning up AI-generated work that shipped without review, and incidents per pull request climbing as velocity does.
Nobody’s handling it gracefully, but nobody gets to opt out of the question, either.
There’s a reframing of teams that we need to embrace. When my team started building this way, prototyping real interactive products in days instead of describing them in wireframes, I assumed the win was speed. It wasn’t. We didn’t go faster. We went deeper.
The time we used to spend translating an idea across three disciplines and waiting for the veto, we now spend on the idea itself. Is this the right thing to build, for the right person, for the right reason. The work moved up the stack, from typing to thinking. From can we build it to should we.
The engineers who thrive won’t be the ones who defended the old ground. They’ll be the ones who kept moving to where the value went.
Think about Nintendo, a company that started in 1889 making paper playing cards by hand and is now, most of a century and a half later, one of the most important names in interactive entertainment. It survived that long by refusing to confuse the card with the craft.
When Sony and Microsoft turned game consoles into a horsepower arms race, more processing power, more teraflops, more of a number that mostly meant a bigger number, Nintendo didn’t try to win it. Its CEO, Satoru Iwata, said, “We are not competing against Sony or Microsoft. We are battling the indifference of people who have no interest in video games.” It made the Wii, put a controller in your grandmother’s hand, and changed what the competition was even about.
Raw power for its own sake was always a trap. It was true for game consoles and it’s true for engineering now. The value was knowing what to build, and being honest about what it costs.
Nobody’s coming to save the people who built a career on being the bottleneck. But everyone else, the ones who just wanted to make good things, with good people, without asking permission first, finally get to.
References and further reading
On why the monopoly held (power, information, and the hidden object)
- Eliyahu Goldratt, The Goal (1984) and the Theory of Constraints, every system is governed by its single binding constraint, and the whole organization ends up structured around it.
- Marty Cagan, “The Four Big Risks,” the framework that assigns feasibility, the “can we build it” question, to engineering.
- John R. P. French and Bertram Raven, “The Bases of Social Power” (1959), the origin of “expert power,” influence that comes from knowing something others can’t check, and which needs no formal authority.
- George Akerlof, “The Market for ‘Lemons’: Quality Uncertainty and the Market Mechanism,” Quarterly Journal of Economics (1970), how information asymmetry hands power to whoever knows more.
- Edgar Allan Poe, “The Purloined Letter” (1844), the thing hidden in plain sight, and the power that lives in everyone’s belief that it must be hard to find.
On the historical rhyme (a craft’s doors getting kicked open before)
- Rebecca Kelly, “Democratizing Design” (Academy for Design Innovation Management, 2019), the tools spread to everyone, the judgment behind them did not, and the profession survived by moving up.
- CBC Archives, “Desktop publishing” (1988), a period snapshot of the last time a specialized craft suddenly landed on every desk.
On what broke the monopoly (the rise of build-it-yourself)
- Andrej Karpathy, the tweet coining “vibe coding” (February 2025).
- Collins Dictionary, “vibe coding” named Word of the Year 2025, nine months from tweet to lexicon.
- GitHub, “Survey: The AI wave grows” (2024), 97%+ of developers using AI coding tools.
On the honest counter (the code is often bad)
- GitClear, “AI Copilot Code Quality” research (2025), duplication up eightfold, refactoring down, churn rising, the signature of technical debt.
- Stack Overflow, 2025 Developer Survey, adoption up, trust down to 29%, top complaint: “almost right, but not quite.”
- DORA, 2024 Accelerate State of DevOps Report, the honest synthesis: AI helps the small stuff and strains the system-level stuff.
On the confident ‘no’ as leverage
- Amos Tversky and Daniel Kahneman, “Judgment under Uncertainty: Heuristics and Biases,” Science (1974), the anchoring effect: any number distorts every judgment that follows it.
- Lucas Gren and Richard Berntsson Svensson, “Is it Possible to Disregard Obsolete Requirements?” (Requirements Engineering Journal, 2021), padding a task with irrelevant requirements systematically inflates the guess.
- William Goldman, Adventures in the Screen Trade (1983), “Nobody knows anything”, confident expert prediction, examined honestly.
On collaboration as the thing that actually works
- Google, re:Work, Project Aristotle, a two-year study of 180 teams that found psychological safety was the strongest predictor of team performance.
- Amy Edmondson, the Harvard professor who defined “psychological safety,” the shared belief that it’s safe to speak up, admit error, and ask the hard question.
- Carrie Webster, Smashing Magazine, on the “rework tax”, engineering teams cleaning up AI-generated work shipped without review as non-engineers build directly.
- Satoru Iwata, Nintendo’s CEO, on refusing to fight Sony and Microsoft on raw power, “battling the indifference of people who have no interest in video games.”
AI took away engineering’s right to say no was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.