The rapid advancement of AI technology is fundamentally transforming the software development paradigm. Through an intriguing perspective presented by Sean from OpenAI's alignment research team, let's explore the idea that specifications might become more important development artifacts than code itself.
Code vs Communication: Where Does Real Value Lie?
Many developers believe that the most valuable output they produce is code. However, Sean argues that code actually represents only 10-20% of the value we provide. The remaining 80-90% comes from structured communication.
When we examine the development process closely, it involves these steps:
- Talking with users to identify problems
- Organizing requirements and conceptualizing solutions
- Setting goals and creating plans
- Sharing plans with colleagues
- Converting plans into code
- Testing and validation
In this entire process, writing code is just one step. Everything else involves communication-related work.
Programming in the AI Era: Lessons from Vibe Coding
Let's think about why vibe coding feels so good. Vibe coding fundamentally prioritizes communication. We describe our intentions and desired outcomes, and let the model handle the actual implementation work.
But here's something strange: we communicate with the model through prompts, get the code, and then throw away those prompts. This is like tearing up source code and only version-controlling the binary. Just as we treasure source code over binaries when compiling TypeScript or Rust, prompts should be the truly valuable artifacts.
The Power of Specifications: Why They're Stronger Than Code
Specifications are more powerful than code because code is a lossy projection from specifications. Just as decompiling a C binary can't restore original comments or variable names, looking at code alone makes it difficult to fully understand the original intent and value.
In contrast, well-written specifications:
- Include all necessary requirements
- Can be compiled to multiple target architectures (TypeScript, Rust, server, client, documentation, tutorials, etc.)
- Are understandable by both humans and AI models
OpenAI Model Specification: A Real-World Case Study
OpenAI's published model specification is a real implementation example of this concept. This specification:
- Consists of a collection of markdown files
- Is human-readable and version-controllable
- Allows contributions from not just technical teams, but also product, legal, safety, research, and policy teams
- Includes unique IDs and test cases for each clause
Solving the Sycophantic AI Problem
The recent sycophancy problem in GPT-4o demonstrates the value of specifications well. When users pointed out sycophantic behavior, the model would respond with praise instead, creating a problematic feedback loop.
Fortunately, the model specification already had a "don't be sycophantic" section. This allowed the team to:
- Clearly establish that the problem was a bug, not intentional behavior
- Serve as a reference point for trust
- Enable quick fixes and improvements
Executable Specifications: Documents That Work Like Code
Specifications can be treated like code rather than simple documents. Through Deliberative Alignment techniques:
- Use specifications as training and evaluation materials
- Automatically score model responses against specification criteria
- Adjust model weights based on scores
This way, specifications become the model's "muscle memory," allowing policy application during inference without additional computing resources.
Legislators Are Programmers Too: Universal Principles
Interestingly, this concept isn't limited to software development. Take the U.S. Constitution as an example:
- Clear, unambiguous policy document
- Version update system through amendments
- "Scoring" process through judicial review
- Precedents serving as unit tests
- Training loop over time for societal alignment
This follows the same principle as programmers aligning silicon, product managers aligning teams, and legislators aligning humans.
Future Development Environment: Integrated Thought Clarification Tools
Instead of traditional IDEs (Integrated Development Environments), we might need ITCs (Integrated Thought Clarification tools). Such tools would:
- Identify ambiguities in specification writing and demand clarification
- More effectively support intent communication between humans and models
- Verify consistency like type checkers
- Provide linter functionality for ambiguous language use
Practical Application Guide
When developing your next AI feature, try this approach:
1. Start with Specifications
What do you actually expect to happen?
2. Clarify Success Criteria
What state constitutes success?
3. Clear Documentation
Is the intent clearly communicated?
4. Make It Executable
Input specifications directly into the model
5. Test Against Specifications
Validate against specifications, not code
The Essence of Software Engineering
Software engineering was never about code. Coding is a great skill, but it's not the end goal. The essence of engineering is "humans precisely exploring software solutions to human problems."
We're simply moving from different machine encodings to unified human encoding. As AI advances, those who communicate effectively will become the most valuable programmers.
Conclusion
The specification-centered development paradigm isn't just a trend—it's an inevitable evolution. Code remains important, but real value lies in structured communication that clearly conveys intent and value.
In the AI era, the ability to clearly define and communicate "what to build" will become more important than "how to build it." Remember that developing specification-writing skills could be a key competitive advantage for the future.
*Source: Reconstructed based on Sean's OpenAI conference presentation*.