My Obligatory AI Post, or: What Specifications?

You tell a friend a stupid idea. They make a face. You tell a colleague and they laugh. You tell your boss and you might get fired.

You tell an AI and it builds it for you. With tests. It deploys it to the cloud. It explains how to manage your application secrets — the part you’ll ignore because you’re moving fast or you don’t have a clue on what that is all about. It never once stops to ask if any of this is a good idea. Is it?

There’s a new narrative going around: building is now the easy part. Developers are writing specs and telling Claude Code, Cursor, Copilot to write the code for them. Then product people show up saying “we can do that too — we’re the ones writing the specs anyway.” And then come the managers, directors, C-levels and founders, saying they can write the best strategy ever, with the pillars and diamonds and KPIs, and they’ll ask ChatGPT (the free version) to translate all of that into software specifications, requirements, Jira tasks and user stories so that Claude Code can build the code for them and they can cut everybody and keep the profits. I honestly don’t know what they’ll use Jira for at that point, but it seems like a certainty. Along with the PowerPoints.

This narrative is all over LinkedIn, Medium, Substack — all the cool places. I’m pretty sure most of it is written with heavy AI assistance, and its “validation.”

But wait. What specifications? What requirements? What strategy?

Spend a few months in the IT industry — startups, big corporates, the HR consultancy disguised as a software company — and you will hear “I don’t understand the requirements” from developers, “you should assume…” from product people, and a different, unclear strategy every year from your talkative and mostly oblivious CEO. And with the state of written communication these days — people who haven’t written a full paragraph since university, entire organisations that communicate exclusively in Slack one-liners and emoji reactions, a generation that was never taught to structure an argument on paper — this is only getting worse. But sure, specifications will save us. The people who can’t write a clear email are going to write clear software requirements. I’m exaggerating, and I know it. I’m leaning on stereotypes on purpose, being deliberately unfair to many brilliant product people, managers, and leaders I’ve worked with and admire. But not by as much as I’d like.

How exactly do you expect any AI, however sophisticated, to build a decent product out of that chaos? Production ready? For users that require legal consideration? With data consistency? GDPR compliance? People can’t even agree on what “deleting data” means.

In more than ten years of software engineering, I’ve seen very few projects — and even fewer organisations — where requirements, specifications and documentation were up to date. Never mind clear, readable, or consistent. Most of the time stakeholders don’t know what they want, or can’t explain it, or don’t understand the constraints they’re dealing with. So they ask for… engineers.

Do you really think specifications are going to solve the problem? Replace developers? Please ask yourself: what specifications? The ones people are asking AI to spit out? The contradictory filler you write to appease “the process”?

And here’s a thought from the other direction. Most good developers and engineers can actually write pretty well. They could probably get a two or three year old AI model to produce a passable business plan, strategy PowerPoint, or any other corporate artefact you’d care to name. If we’re turning roles into prompts, that sword cuts both ways.

And don’t forget: developers and engineers also get the productivity benefits of AI-assisted coding. The difference is they can challenge it. They can look at what the AI produced and say “this won’t scale,” “this has a race condition,” “this ignores half the edge cases.” That’s not a small difference. That’s the whole point.

To be clear: AI coding tools are genuinely useful. Scaffolding a project, exploring an unfamiliar API, writing boilerplate, generating tests, prototyping an idea before committing to it, working in a language you don’t use every day — all of that is faster now. This website was built with heavy AI assistance. But the decisions about what to build, how to structure it, what to include and what to leave out — those were mine. The tool helped me move faster. It didn’t tell me where to go.

I’m not here to argue that developers should seize the means of production, nor that everyone should panic about losing their jobs. What I am saying is that the narrative being pushed by leaders, influencers and big corporations right now — the “just write specs and fire the engineers” take — is doing far more harm than good. It’s built on ignorance of how software actually gets made. Hint: it’s not based on well written specs and clear information. When that is a thing we can talk again.