The New Code — Sean Grove, OpenAI

Sean Grove, who works in alignment research at OpenAI, argues that software engineering produces something more fundamental than code: structured communication about human problems and their intended solutions. His provocative estimate assigns only 10–20 percent of an engineer’s value to code itself and the remaining 80–90 percent to understanding users, distilling requirements, setting goals, planning, coordinating, and verifying outcomes. The percentages are his framing, but the operational distinction is concrete: a program matters because of what it accomplishes, not merely because its source exists. 0:24

This makes communication the actual bottleneck: teams must decide what to build, how and why to build it, and whether the result fulfills its original purpose. Grove expects increasingly capable AI systems to sharpen that constraint. As models absorb more implementation work, the ability to express goals precisely becomes more central to programming rather than less. 3:48

Vibe coding illustrates both the opportunity and the failure mode. A person describes a desired outcome, a model generates code, and the original prompt often disappears while the generated artifact remains. Grove compares this to discarding source code while carefully preserving a compiled binary: the retained output is useful, but the durable record of intentions and values has been lost. 3:48

A written specification creates a shared artifact that people can inspect, debate, revise, and use to establish whether they actually agree. Without that artifact, Grove argues, a team may possess only a vague idea that participants interpret differently. Writing the specification therefore does more than document implementation decisions: it exposes assumptions and supplies a common reference for coordinating work. 5:08

The distinction matters because code is a lossy projection of intent. Just as decompiling a binary does not reliably recover clear comments, meaningful variable names, or the author’s reasoning, reading application code does not necessarily reveal the team’s broader goals and values. A sufficiently robust specification can preserve requirements that the implementation alone leaves readers to reconstruct. 6:22

Grove extends the compiler analogy to multiple output targets: the same source program can be compiled for ARM64, X86, or WebAssembly, while a sufficiently rich specification could guide models in producing TypeScript, Rust, servers, clients, documentation, tutorials, blog posts, and podcasts. His proposed test is whether a company’s codebase alone contains enough information to generate a compelling explanation of how its customers succeed; if not, essential product knowledge lives outside the code. 7:29

Grove uses the OpenAI Model Spec to show what specification-first engineering looks like. He describes it as a living document expressing the intentions and values OpenAI hopes its models will embody, implemented as a collection of Markdown files. Markdown is important here because it is human-readable, versioned, and accessible to people across product, legal, safety, research, and policy, making a single source understandable and editable beyond engineering. 9:31

Natural language remains imperfect, however: some behavioral nuances resist completely unambiguous prose. To narrow that gap, each Model Spec clause has an identifier associated with a separate file containing one or more challenging prompts for that clause. Those examples supply concrete success criteria, allowing a model’s response to be checked against the behavior the policy intends. 9:31

This pairing of policy and challenging examples changes what a specification can accomplish. The prose communicates the intended principle to humans, while the associated prompts operationalize difficult cases that the model must handle. Rather than assuming that an abstract rule fully resolves every situation, the specification carries evidence of how that rule should be evaluated in practice. 10:52

The GPT-4o sycophancy incident demonstrates the difference between declared values and deployed behavior. Grove describes an update that produced extreme sycophancy, including an example in which a model responded to criticism of sycophantic behavior by praising the user. He argues that shipping this behavior damages trust and immediately raises difficult questions about whether the outcome was intentional, accidental, or insufficiently tested. 10:52

According to Grove, the Model Spec already contained a section opposing sycophancy and explaining that short-term pleasantness can produce worse long-term outcomes. That existing policy supplied an explicit basis for interpreting the mismatch: if observed behavior contradicted the agreed specification, the behavior should be treated as a bug, not silently redefined as the intended product. 12:31

Grove says the model update was rolled back, studies and blog posts were published, and the problem was fixed. The broader lesson is not that a written specification prevents every failure; this example shows that undesirable behavior can still ship. Its value during the incident was to act as a trust anchor, making expected behavior visible and allowing observers to distinguish a deviation from the organization’s stated intentions. 12:31

Human agreement is only the first layer. Grove describes Deliberative Alignment as a technique for applying the same specification to model training and evaluation: start with a policy and challenging prompts, sample responses from the model being tested or trained, and provide the original prompt, response, and policy to a grading model. The grader scores how closely the response follows the specification, and those scores are then used to reinforce the model’s weights. 13:43

This makes one document serve as both training material and evaluation material. Grove notes that a policy can instead be included in context through a system or developer message at inference time, and that prompting can produce partial alignment. The tradeoff is that repeatedly supplying the specification consumes computational capacity that could otherwise address the user’s actual problem. 13:43

Training the behavior into model weights shifts some policy application away from inference-time context and toward learned behavior, which Grove compares to muscle memory. He emphasizes that the same pattern can apply beyond safety policies to code style, testing requirements, and other organizational constraints. The argument is not that natural-language specifications behave identically to conventional programs, but that they can still be composed, executed through model behavior, tested, and connected to real-world interfaces. 14:52

Once specifications are treated as engineering artifacts, Grove argues that familiar software tooling becomes relevant. A consistency checker could detect conflicts between specifications written by different departments, much as a type checker exposes incompatible assumptions between modules. Clause-specific examples function like unit tests, while linters could flag ambiguous language likely to confuse both human readers and models. 15:46

Grove broadens the analogy through the US Constitution: written policy defines a shared reference point, amendments provide a mechanism for revision, judicial review assesses how particular situations align with the policy, and precedent clarifies difficult cases through concrete examples. He acknowledges the central limitation directly: real situations are messy, apparently clear policy can miss important cases, and substantial interpretive work may be required before a principle can be applied consistently. 16:48

His practical recommendation is to begin an AI feature by writing down the expected behavior and success criteria, debating whether the language is clear, feeding the specification to the model, and testing model behavior against it. Looking ahead, he imagines an integrated thought clarifier that identifies ambiguity while a specification is being written. He also identifies aligning agents at scale as an area needing better specifications, because people cannot reliably direct systems toward goals they have not fully articulated themselves. 19:10