I just watched this talk by Sean from OpenAI about how specifications will become “the new code,” fundamentally changing what it means to be a programmer. (Go watch it if you haven’t!)
This is the core thesis:
As AI models advance, writing clear specifications in natural language will become more valuable than traditional coding skills
While I appreciate the vision (conflicts of interest aside!), I think there are some fundamental challenges that make this transition harder than it appears.
Let me jump into a different domain to explain my point.
Why Legalese Exists
If everyone can be a programmer tomorrow, everyone would have been a lawyer decades ago. Sure, if you’re arguing with your friend about who should pay for dinner, you can probably make your case just fine. But in a real court case, with real contracts and real consequences, you need lawyers for a reason.
There’s a joke that lawyers are the only people who can write a 100-page document to say “don’t steal” and still leave room for interpretation. Legal documents aren’t written in that tortured, verbose style because lawyers enjoy making things complicated (maybe they do? IANAL). They’re written that way because centuries of litigation have taught us that every ambiguity in natural language becomes a potential loophole or misinterpretation.
When you write “the software should be fast,” what does that mean exactly? Fast compared to what? Fast for which operations? Fast under what load conditions? The more precise you try to be in English, the more you start sounding like… well, like a legal contract. Or code.
You want to build a new internet?
The Sycophancy “Bug” Is the Point
To be fair, Sean does mention they told their models “Don’t be sycophantic,” but the models continued being sycophantic anyway. He promptly dismissed this as a “bug” - but that’s exactly the point.
This was not so much a bug, but a demonstration that natural language specifications are inherently ambiguous, and non-deterministic systems will interpret them in ways you didn’t intend. What does “sycophantic” mean exactly? When is agreement genuine versus sycophantic? These distinctions that seem obvious to humans are actually incredibly nuanced.
The fact that OpenAI - with their deep expertise in language models - struggled to specify “don’t be sycophantic” in a way that actually worked should give us pause about how easy this specification-driven future will be.
It does make sense for OpenAI
For OpenAI’s specific use case, specifications as code actually makes perfect sense. They’re dealing with fundamentally non-deterministic outputs where traditional specifications and tests are already somewhat useless. When your system is designed to be creative and contextual, having human-readable specifications that capture intent and values is genuinely valuable.
LLM behavior is already so variable that adding another layer of interpretation through natural language specifications doesn’t significantly increase the unpredictability. In fact, it might make the system more transparent and easier to reason about.
Not there yet for the rest of us
When I write code, I want predictable, deterministic behavior. I want to know that calculateTotal(items) will always return the same result for the same input. I want my functions to have clear contracts and my tests to either pass or fail consistently.
When something breaks with the “new code”, you’re not just debugging the code - you’re debugging the specification, the AI’s interpretation of the specification, and then the generated code. It’s three potential points of failure instead of the one I’m handling today.
I think the most honest assessment is that specifications as code will be transformative for certain types of problems - particularly those involving human-AI collaboration where flexibility and intent-capture matter more than deterministic behavior.
For building user interfaces, content generation, or systems that need to adapt to changing requirements, specification-driven development could be revolutionary. For building anything that is business critical, I want my precise, deterministic, well-tested code.
English is hard, intent is complex, and sometimes you just need code that does exactly what you told it to do - no interpretation required.
For now, I’m keeping my debugging skills sharp (while going all in on vibe-“engineering”!)