The Problem

A new tool has been introduced.

What used to take developers weeks now takes minutes.

But the office still seems hectic. Things don’t feel like they’re getting done faster.

Management mandates the use of the new technology. The developers must be sandbagging.

Productivity continues to stagnate. Morale drops. Layoffs start.

This story doesn’t come from 2026. This isn’t AI.

It’s the 1970s. It’s the compiler.

Coding Isn’t the Problem

Many under the spell of AI psychosis have announced on their X (previously known as Twitter, which we’re still saying years later because no one remembers it’s called X now) accounts that Coding is solved.

The issue isn’t that they are incorrect. The issue is that coding has been solved for a long time.

Since the early 1980’s, the predominant cost of software was in requirements, not coding.

(Well, actually, the predominant cost of software is, was, and will continue to be maintenance, but after that, the cost came from requirements.)

The requirements problem is deciding what the software should do. And it takes absolutely the bulk of the time before any feature gets out the door. Has for nearly fifty years.

If This Is True, Why Don’t We Know It?

Why isn’t it more widely understood that requirements have been the problem for a generation?

Because when bros are shouting from their X (previously known as Twitter) accounts that “coding is solved,” they are not, by and large, shouting with excitement at the triumph of technology over toil.

They’re shouting with malicious glee that finally those fucking programmers have got whats coming to them.

Unfortunately, just like every other time the tech industry has tried to fire all its programmers, the finance bros who don’t understand why a software engineer makes as much, if not more than, them (but refuses to wear a suit, and doesn’t seem to be plotting to backstab anyone, what gives with these goodie-two-shoes software people?) have fundamentally misunderstood the problem of software.

For a generation, management types have screamed at the developers, “Why isn’t it done yet? It should be easy!” and developers have screamed back, “What is it? What do you want us to build?” only to hear in response, “IT’S OBVIOUS!”

But it’s not. It has never been obvious; it will never be obvious.

Requirements are a Wicked Problem. To figure out what the software should do, it just takes a lot of answering questions. Engineers ask them, document the answers, and when they get far enough, start making guesses with actually constructing prototypes because they know half the answers are wrong. They just don’t know which half.

Management types hate answering questions.

This is primarily for two reasons.

Questions Make Me Feel Dumb

When I get a question and don’t know the answer, I see it as an interesting thing to figure out so we can build the software; managers, however, feel offended that the developer would have the audacity to embarrass them.

Most developers feel confused and wrong all the time because their job is to specify something so well that even a computer can do it. And that’s a hard job, because most of the world isn’t specified that well. Yet.

Managers don’t like feeling confused and wrong. That’s why they left engineering and became managers. And they don’t like engineers making them feel confused and wrong when those engineers ask good questions.

Many folks higher up in organizations have a zero-sum view of the world. And, paradoxically, even though we know the most emotionally intelligent managers are the best, managers often seem to lack more and more emotional intelligence as they rise up the ranks.

Thus, they feel embarrassed by your question - which isn’t a very emotionally intelligent thing to do. And they think that this is because you, the engineer, intentionally attacked them.

Oh boy, do they fucking hate you for that.

Managers spend most of their day wanting to lay off most of their employees if they could, because all those employees do is embarrass the manager (probably on purpose, those assholes!). So these types of people are the ones you often see on X (previously known as Twitter) licking their chops at the upcoming layoffs.

I Make Deals Out Of Ambiguity

The other major reason managers hate questions is that when they get to the requirements meeting with the developers and hear how the developers can’t tolerate ambiguity in the spec and need hard answers one way or another, they’re stuck between a rock and a hard place.

You see, they just got out of a meeting in which ambiguity was the intentional outcome. Finance needed X, client services needed Y, sales needed Z. A shrewd manager knows how to play with words to convince them that they all actually want the same thing, and don’t you worry, that thing is coming.

Managers use ambiguity as a negotiation tactic.

But you can’t build things that are ambiguous. That’s like, the whole problem.

So managers will often scream at developers, saying it’s obvious what the software should do. The issue is, they may be saying this because they don’t want to admit they don’t know what the software should do, or because they just got out of a meeting where everyone pretended to agree that what the software should do is obvious.

AI Doesn’t Solve This

We’re repeatedly seeing the same problem, and what’s been fun about this round of “I’ll get those developers, and their mangy dog too!” is that the bro types have been beaten over the head with the problem again and again with the problem but just come back a week later saying that AI Solves This.

We had prompts, but they produced slop.

So we introduced agents, but we still refused to actually spend any time instructing those agents on what to do, so they eventually produced slop.

Then we introduced loops, and we still refused to spend any time giving instructions, so they produced slop too.

You probably have received any number of PRDs from various people pretending they’re product experts now, but the PRDs themselves are AI slop, so you can’t use them as actual specs because they don’t actually answer any questions.

Could you use AI to write a good PRD? Of course you can. Does anyone have the patience? No, because they don’t like feeling dumb and they don’t like removing their strategic ambiguity.

Try it. Try actually generating specs with AI. Good specs. Do a “grill-me” skill, or long-form interviews. Generate PRD after PRD. Rigorous enough to have AI create the code. You can do it. It’s totally possible.

It will just take you the same time it took before. All the while, your boss will be breathing down your neck, screaming at you, and pushing your name up the layoff list for “not using AI enough,” even though you spent all day in Claude Code.