What happened – OpenAI’s “The New Code”: The Rise of Spec-Driven Development
At the AI Engineer World’s Fair 2025, OpenAI’s Sean Grove laid “The New Code”, a vision for replacing ad-hoc prompt engineering with spec-driven development, a workflow centered on writing structured specifications.
Grove’s keynote contrasted today’s ephemeral prompt habits with a future of persistent specs. He observed that developers often experiment by prompting LLMs and then discard those prompts, keeping only the generated output.
“We keep the generated code and delete the prompt … like you shred the source and then very carefully version control the binary” .
Prompt instructions are transient, leaving no lasting record, underscoring how current prompt engineering lacks a persistent source-of-truth . In contrast, capturing intents and requirements in written specs outlive any single model run. Grove concludes that “a written specification effectively aligns humans” on shared goals – it’s the focal point for discussion, debate, and agreement.
By making the spec the centerpiece, all stakeholders stay synchronized on what the AI should do and why. Grove used OpenAI’s own “model spec” as an example. This internal specification (now open-sourced on GitHub) is a living Markdown document defining the intended behaviors and values of OpenAI’s models. My friend Patrick Debois refers to it as the “code of conduct for LLMs and models”.
Every clause in the model spec has a unique ID and associated example prompts that serve as unit tests, ensuring that for each stated principle, the model’s responses can be checked against it.
Enjoy being informed about the AI Native Development space (AIND)? We are building the AIND community, where we cover the most relevant dev-focused news. For the busy folks, we send out a crisp one-pager newsletter read by 7,000+ AI tinkerers every week – free and straight to your inbox!
Impact – How Specs Could Reshape Development Workflows (In The Near Term)
On the development side, specs could mandate upfront planning about what to program, edge cases and encourage devs to seek clarity about desired output, tests and success criteria. Developers would articulate “what do we actually expect to happen?” and “what does good look like?”
Grove mused about the IDE as “integrated thought clarifier”. Imagine modifying a specification clause and the IDE immediately showing how the model would interpret it. This tight feedback loop would make spec authoring a first-class part of development, not a separate documentation task. With this in mind, players like Cursor, or Windsurf, could incorporate support for specs via a panel that their environment use to assist code generation or validate outputs.
We might also see spec repositories emerging, for example, shared libraries of common spec clauses (similar to how open-source code libraries exist) that teams can reuse for standard needs like “do not output sensitive data” or “follow company style guide.” Specs might also become part of the agent development toolkits, by providing spec templates where developers can define an agent’s purpose and constraints.
We could also see collaboration and cross-functional input. Because specs are in natural language and accessible, they could become a communication bridge between disciplines. This mirrors how product requirement documents function – the result could be better shared understanding across the team; a single source of truth for what the project and code should do.
The AI-Native Dev Take – Why the Next Great Devs Will Be Great Spec Authors
What does this all mean for developers and their evolving role? It appears that as AI systems become more prevalent, devs will take on the mantle of spec authors and curators.
“whether you realize it or not, you are spec authors in this world … whoever writes the spec … is now the programmer.”
If the future of development is spec-centric, we will naturally evolve into spec engineers. It reveals a horizon, not far off, where the best developers are also the best spec authors. This is both exciting and challenging.
This doesn’t mean traditional coding skills become unimportant, but it does suggest a shift in emphasis. Much as high-level languages and tools abstracted away some low-level coding work, powerful AI might abstract away some implementation work; placing more importance on defining what the software should do in exact terms.
Perhaps the often mentioned “prompt engineer” role could evolve into something like “AI specification engineer”. In practical terms, companies hire for engineers’ ability to write an excellent AI spec and to understand complex project and architecture requirements.
“…moving forward, the new scarce skill is writing specifications that fully capture the intent and values. And whoever masters that, again, becomes the most valuable programmer.”
Get Started – How To Experiment With Specs
For developers and teams looking to get ahead of the curve, a few practical steps are suggested:
- The key is to capture the intent clearly before diving into implementation. Grove’s closing advice was literally to “start with the specification”. Describe the feature’s goal, the assumptions and constraints, and some example inputs/outputs or success criteria. A well-structured Markdown document is a good start.
- Experiment building projects with specs and treat it as a living document that evolves with the project. Use version control for it. Encourage discussion with your peers, experiment how spec changes affect your project/feature(s) – as you would do code reviews, do spec reviews.
- Over time, build a repository of specs (and their history) which will be a valuable knowledge base. It’s not far-fetched to imagine reusing snippets from previous specs for new projects.
