“The customer can’t write a production-ready spec” — the customer doesn’t have to. The model writes the spec itself.

Seventeen people wrote me this week to say AI in a customer’s hands is useless because the customer can’t formulate a production-ready spec. They missed one thing: the customer doesn’t have to. The model formalizes the spec itself.

"The customer can't write a production-ready spec" — the customer doesn't have to. The model writes the spec itself.

Seventeen people wrote me this week to say the same thing: AI in a customer's hands won't produce results, because the customer is incapable of formulating a production-ready task specification. Seventeen adults among my active subscribers couldn't reason their way to the one thing that collapses their entire argument in a single move.

The thesis you missed

The customer doesn't need to know how to write a spec. Any modern model — Claude, in practice — formalizes the spec itself. From whatever incoherent, contradictory human-language mess the customer hands it. Through a conversation in a chat. The model structures what was said, finds the holes and contradictions, asks follow-up questions exactly where a live analyst would — except immediately, not after two scheduling calls. It produces a systematic result. No complaints. No weeks of waiting.

Your entire defense rests on one assumption: between the customer's fuzzy want and a production-ready spec, there must stand a person with years of experience. A gatekeeper. A translator from human to technical. That gatekeeper was just removed.

Why this hits the most expensive thing you own

The skill of "gathering requirements correctly" is what engineers and team leads use to justify their indispensability more than the code itself. The code is already written by the model. What remained was the last line of defense: "sure, but the customer still can't explain what they need without us." That line sustains an entire intermediary economy — weeks spent "clarifying requirements," alignment calls, sign-off documents, estimates of "400+ hours" before a single line is written.

And that entire line of defense falls to one fact. The customer doesn't need to know anything. They just say what they want, in plain human language — and the model handles the formalization.

What it looks like in practice

Let me break down the mechanics, because that's exactly what those seventeen people failed to see.

First move — an ordinary conversation. The customer dumps their contradictory mess into the chat the way they know how: "I want it to work, to not crash, and for clients to stop complaining." The model doesn't shrug and send back "please clarify requirements." It structures what was said, finds the gaps and contradictions, and asks follow-up questions precisely where a live analyst would — except immediately, not after two scheduled calls.

Second move — the one that should stop you in your tracks. The customer can paste, into their very first message, a previous spec — yours, mine, anyone's — that was polished by a human over months. And say: do it to this standard. That's it. The quality bar you spent years refining is now loaded into context with a single paste and becomes the template the machine uses to produce the next spec.

Don't believe it — test it yourself. Right now, open the latest GPT or Opus at high effort. Opus, not some cut-rate consumer chatbot, not a discount model — this matters, a weak model genuinely won't carry it. Throw in a purely non-technical prompt:

"Formulate, in technical language, a task specification for what a developer must account for in an integration between Bitrix and an ERP system, so that nothing crashes. Use all best practices."

You will be staggered by how much it anticipates. Mine produced a 27-page document. Your self-satisfied team lead with a thousand years of experience wouldn't have covered half of it — and certainly not in a minute.

"But who tests it" — same method, same prompt

The next argument is always: the result still needs to be tested. Yes, it does. The same way — with a prompt.

"Now develop a tool that checks whether everything in the task was implemented in accordance with the spec."

The model that just wrote the spec assembles the verification tool for it — itself.

And if you want to push harder, the prompt gets sharper:

"Emulate every failure mode in practice and show me exactly how the system survives each one."

Boundary scenarios, failures, degradation paths — the things an "experienced engineer thinks through" — run explicitly, in front of the customer, on demand.

Real rocket science, writing prompts like that. Incredibly hard. Years, years of labor and pattern-matching needed. No non-technical person could manage without you. And your customers are all uniformly clueless, right? You can absolutely sleep soundly — AI will never replace you.

Who's actually left outside

Look at what actually changed. Not "the engineer became unnecessary" — what disappeared is specifically the gatekeeper role between the customer and the system spec. The person who sold themselves as the sole translator of wants into specs, who kept the customer on a short leash through weeks of sign-offs — that person is now without a function. The customer walks into a chat and walks out with a 27-page spec, a compliance tester, and a failure emulator. By themselves.

Until recently this was impossible, and an entire intermediary economy stood on that impossibility. Now it stands on nothing, and its inhabitants haven't noticed — they're writing me to say the customer can't formulate a spec.

You can absolutely sleep soundly. AI will never replace you.

That "the programmer is the crown of evolution" posture is starting to look a little sobering, isn't it?

Leave a Reply

Your email address will not be published. Required fields are marked *