Shadow of the Spec
For years in IT, there was a simple hierarchy of values - at the very top was code, followed by architecture, then documentation, and at the very bottom were requirements specifications, which you only read when there was really no other way out.
The real work began when you could finally open an IDE and write something, not when you had to think about what exactly you were supposed to write. Documentation was a necessary evil, the specification a rite of passage into the “real” phase of the project, and business analysts were akin to priests performing incomprehensible rituals in a conference room.
Meanwhile, it’s becoming increasingly clear that this pyramid is flipping upside down. We’re spending more and more time not hammering out code, but translating human ideas into something a computer even has a chance of understanding. The cult of meetings, backlog boot camps, weeks of refinements, reading tickets about fixing other tickets, and endless clarifications of what “faster” and “more intuitive” actually mean. Code is often just the final artifact of a long negotiation between what we want and what can realistically be done by Friday. And if you add language models that can digest a sensible, precise specification and spit out working code, things start to get interesting - and for some, also unsettling.
Because suddenly it turns out that the biggest bottleneck is no longer who can write a microservice the fastest, but who can clearly and unambiguously describe what that microservice is supposed to do and what it absolutely must not do. Somewhere in the back of your head, Greg Brockman’s line from OpenAI comes back - “Spec is the new code"... and the prophecy that the programmers of the future will be those who write the best specifications, not the actual code. It sounds like a provocation, but the longer you think about it, the less it feels like a joke and the more like brutal logic.
A sensible, precise specification is an oxymoron known to anyone who’s ever received a requirement like “it should work faster and be pleasant to use,” and then wondered why the team delivered something that met both criteria only in a PowerPoint presentation. In a world where AI takes specifications literally, such gems won’t just be anecdotes for a retrospective, they’ll be real sources of bugs, costs, and frustration. One badly chosen word, and instead of an optimization we’ll get functionality that is perfectly aligned with the letter of the spec and completely at odds with its spirit.
The programmer of the future is starting to look less like a coding ninja and more like a hybrid of a business analyst, a poet, and a contract lawyer. We’ll have to write specifications so that they’re unambiguous, testable, and resistant to creative interpretation by an algorithm that can, with equal grace, generate a microservice and a recipe for potato cake. Instead of debating whether to use Spring or FastAPI, we’ll argue about whether the spec should say "the system should” or “the system must,” because one extra word and suddenly we get an endpoint that does exactly something else than we wanted, but very elegantly.
There’s something beautifully ironic about all this. For years, we joked that the real work was programming and the rest was corporate theater, and now it turns out the theater is coming back to the main stage, just with a new leading actor - the language model. Of course, this isn’t the end of code, just as assembler didn’t disappear when C showed up, it’s a shift in the level of abstraction. The difference is that the weight of competence will start moving from how to implement something to what exactly we want to implement and why. And that’s a skill we are painfully lacking in many projects.
Today, we often treat requirements as a necessary evil, something to get through so we can finally write code, but in a world where the specification becomes the new code, that won’t hold up. There, every imprecise thought will come back to us in the form of a wrong, though syntactically perfect program. So maybe in a few years a programmer’s portfolio won’t be a link to GitHub, but to a repository of specifications, with a note saying that this particular spec generated a system serving ten million users, or that it was so good the AI didn’t break anything for three sprints.
We can keep laughing at analysts and product owners, or we can start learning from them. Because if the specification really is becoming the new code, it’s high time we stop treating it like a boring prelude to the real work and come to terms with the fact that it may be the real work, while the keyboard is just a tool for writing very, very precise wishes.