Is it a new "programming" paradigm from OpenAI? In fact, it's the return of the waterfall model: "Listen to the PM and write requirement documents."

At this year's AI Engineers Conference, Sean Grove, a researcher at OpenAI, delivered a speech titled "The New Code." Some people believe that "this is a revolutionary concept": in the era driven by AI, clear and human-readable specifications (specs) will replace traditional code as the core output of software development.

"The essence of programming is communication," Grove believes that software development is never just about writing code. Its core is a structured form of communication: first understand the requirements, then clarify the goals, and finally convey these ideas clearly to team members and computers.

Grove emphasizes that this shift from code to specifications is not just an update of methodology but the future direction of engineering practice. He points out that code itself is only a "distorted reflection" of human intentions, and information loss or distortion is inevitable in the process of translating ideas into reality. The truly scarce ability is no longer writing code, but how to accurately translate human intentions into clear specifications and prompts.

Grove's remarks have sparked quite a discussion in the tech community.

A netizen sharply commented: "This line of thinking essentially boils down to 'listening more to product managers' and driving the development process by writing better specification documents. From Grove's description, this model actually turns engineers into 'product managers who maintain requirement documents'."

In short, he wants you to listen more to product managers and constantly refine requirement documents.

Specifications are requirement documents. He doesn't advocate for direct use of 'ambient programming' or pair programming. Instead, he advocates for 'ambient programming' with intelligent agents by continuously updating requirement documents. Prompt engineering is not outdated. The title is misleading (Editor's note: this was the original title of the video when it was first released, "Prompt Engineering is Dead"). He just hopes it can be applied at a higher level of abstraction and be reusable.

The ideal state is to transform code writers into product managers who maintain requirement documents. However, he hasn't provided evidence that this approach can currently run automatically. He also mentioned that these requirement documents are mainly for coordinating interpersonal work. He did describe the basic update process they used in the 4.0 project, but there isn't anything particularly innovative about it (when the specification document changes, a new or updated scorer will be added).

Other netizens also agree, believing that Grove's subtext is that everyone's roles are converging, and everyone is moving towards the role of a product manager.

nomad_manhattan: This is exactly what product managers have been doing - collecting user needs and requirements, drafting product requirement documents (specifications), and reaching an agreement with various stakeholders on key performance indicators (KPIs) and success metrics, while consulting with data scientists and engineers on feasibility and workload estimates. What the speaker didn't clearly point out is that the roles are converging; everyone is becoming a product manager.

natenoonen2235: The Agile Manifesto was written because developers always saw themselves as programmers rather than managers. AI doesn't bring anything new; it's just a validation for those who have always advocated for agile development, test-driven development, behavior-driven development, and focusing on results over processes. However, like any tool, the key lies in the user, not the tool itself.

Other netizens also expressed their agreement, believing that Grove's underlying message is that everyone's roles are converging, and everyone is moving towards the role of a product manager.

Of course, some people have come out explicitly against the statement that "specifications are the new code": "If your application crashes at 3 am, you'll still be debugging the actual code, not the Markdown document. When the AI generates faulty code (which will happen sooner or later), guess what we'll be fixing? The answer is simple: not the specifications. Code is the ultimate executable truth, and everything else is just a nice aspiration."

However, it's undeniable that the "specification-driven development" path depicted by Sean Grove does represent an important turning point in current AI programming: as models become more powerful and code becomes easier to write, the value of human programmers may be shifting from 'inventing the wheel' to 'setting the direction'.

Here are some core points summarized from Grove's speech, which are well worth pondering:

• The bottleneck in software development is shifting from writing code to the process of writing specifications (specs);
• Specifications are the "new code";
• Code is just a lossy projection of specifications;
• Code itself does not contain the original intent; it's more like a "compiled product" of intent;
• Throwing away the prompt and keeping only the code is like throwing away the source code and keeping only the binary file;
• A good specification document should be able to: detect intent conflicts, provide strategy examples, mark ambiguities, and express "intent" rather than syntax;
• Treating specifications like code means that everyone can contribute;
• The next-generation IDE will be similar to existing IDEs, but the focus of its functions will shift from type management, syntax logic, auto-completion, etc., to helping generate clear intent documents, managing intent conflicts, highlighting ambiguities, and testing whether the expected results match human intent, etc.

To gain a deeper understanding of Grove's complete thinking, we've translated his speech:

The "New Code" Revolution: From Traditional Code to Clear Specifications

Today, I'd like to talk to you about the new future of programming in my eyes - especially the new specifications. This also represents the long - standing expectation of the entire industry: write code once by expressing intent and then it can run anywhere.

Let me introduce myself briefly. I'm Sean, working at OpenAI, specifically in alignment research. Today, I want to talk about the value of code and communication, and why we should use new specifications to achieve this goal.

Next, I'll use the model specification as an example to discuss how to communicate intent with other collaborators, including the issue of "version 4.0 being overly accommodating".

The discussion will cover how to implement specifications, how to convey intent to others, and how to translate specifications into code for processing. Finally, I'll share a few open questions. First, let's start with code and communication.

Code Accounts for Only 10%; Where Lies the Value of the Other 90%?

If you're a programmer, you probably think the code you write is the most valuable professional output, right?

This may sound like a no - brainer, as we're all using code to solve problems. We communicate with others, collect requirements, think about implementation details, and integrate information from different sources. And the final output is code.

Code is what we can operate on, measure, and discuss. However, this way of thinking underestimates the work we do to some extent. Code actually accounts for only 10% to 20% of the entire value - creation process. The rest lies in structured communication.

The specific situation may vary, but the general process is like this: first communicate with users to understand the challenges they face. We extract conclusions from the narratives and then figure out how to solve these problems. What are the goals to be achieved? Next, we plan the methods to reach these goals and have further discussions with colleagues.

Then we translate these plans into code, which is of course very important. After that, we conduct testing and verification - this has nothing to do with the code itself, right? In other words, we focus on whether the code can achieve the goals when running and whether it can alleviate users' problems.

We focus on the impact of code on the real world, so communication, understanding, extraction, conception, planning, sharing, translation, testing, and verification are all important parts of the work. These are what I call structured communication, and it's also the biggest bottleneck in the work. It's about clearly defining what to build, communicating with others and collecting requirements, knowing how and why to build, and finally judging whether the build is correct and whether the original goals have been achieved.

And as AI models become more advanced, this bottleneck becomes more restrictive.

Let's take ambient programming as an example. The experience of ambient programming is great because it starts with communication, and the code is a natural by - product of communication.

We only need to describe our intentions and the desired results, and then the model will handle the tedious work for us. We communicate with the model through prompts, express our intentions and values, and finally get the code artifact. After that, the prompt is no longer useful.

If you've written TypeScript or Rust, you know that code always goes through a compiler to be compiled or converted into a binary file. This binary file isn't important; the source specification is the core and the truly valuable part.

But when using prompt models, we do the opposite. We keep the generated code and delete the prompt. This is like tearing up the source code and carefully version - controlling the binary file.

That's why we need to clearly specify intentions and value propositions through specifications.

Clear specifications facilitate efficient collaboration, enabling team members to move towards a common goal and ensuring that everyone is on the same page. This is the result of our discussions, debates, references, and synchronization. This is very important, so I want to emphasize it again: clear specifications enable efficient collaboration and represent the result of communication, discussion, debate, reference, and synchronization. Without specifications, everyone would only have a vague concept in their heads.

Specifications Are Often More Powerful Than Code

Now, let's talk about why specifications are often more powerful than code, because code is actually a lossy projection of specifications.

It's like when we decompile a compiled C binary file, we'll definitely lose clear comments and well - named variables. Then we have to infer what the developer was trying to do at that time? Why was this code written like this? This is a lossy translation. Similarly, even the best code often cannot directly reflect all the initial intentions and value propositions. When reading code, we have to infer what the development team was trying to achieve.

Therefore, the communication process reflected in written specifications is more useful in this regard. It actually aggregates all the necessary conditions for writing code. It's like passing the source code to the compiler and then compiling it for different architectures. The information in the source document can fully describe the entire conversion process.

Similarly, a robust model specification can also generate excellent TypeScript code, Rust code, servers, clients, documents, tutorials, blog posts, and even podcasts.

For companies whose main customers are developers, consider this question: if you put the entire codebase, all documents, that is, the entire business operation code, into a podcast generator, can it produce interesting and engaging content to tell users how to successfully achieve their goals? Or is the information in the code not enough and additional supplements are needed?

So, looking to the future, the new scarce skill will be how to write specifications that can comprehensively capture intentions and value propositions. Those who master this skill will become the most valuable programmers.

Actually, many programmers today are already doing this, including product managers and legislators, who are doing similar work.

This is actually a general principle.

Is the "New Code" Just a Bunch of Markdown?

Now, let's take a look at what a real specification looks like. Here, we'll use the OpenAI model specification as an example. Last year, OpenAI released its specification, which is a dynamic document aiming to clearly introduce the intentions and value propositions of the models announced by OpenAI.

This specification was updated and open - sourced in February this year. Now, you can visit GitHub to view the specific implementation of the model specification (https://github.com/openai/model_spec). Unexpectedly, all I saw was a bunch of Markdown documents. I'm not saying that the Markdown format is bad. It's easy to read, supports version control, and includes change logs. And because it's in natural language, everyone can contribute to it, including product, legal, security, research, and policy personnel. They can read, discuss, debate, and contribute to the source code. In this way, everyone can stay unified around the same set of intentions and value propositions.