Sean Grove (OpenAI alignment research) argues the most valuable engineering artifact is not code but the specification. Code is only 10–20% of the value a developer delivers; the other 80–90% is structured communication — and that is the real bottleneck. A written, versioned, natural-language spec is the source of truth that "compiles" to code, docs, tests, evals, and model behavior. Whoever writes the spec — engineer, PM, lawmaker, or marketer — becomes the new programmer.
Grove opens by asking the audience who writes code, whose job is to write code, and who believes their most valuable professional artifact is code — and many hands go down at the last question. His thesis: code feels tangible and real, but it undersells the job. Code is only about 10–20% of the value you bring. The other 80–90% is structured communication — talking to users to understand their challenges, distilling those stories, ideating on goals, planning, sharing plans, translating them into code, and then testing and verifying whether the code actually achieved the goal. "No one actually cares about the code itself"; what matters is the effect it had on the world.
"in the near future, the person who communicates most effectively is the most valuable programmer. And literally, if you can communicate effectively, you can program."
Vibe coding feels good, Grove says, precisely because it is communication-first: you describe intentions and outcomes and let the model handle the grunt work. But there's something strange about it — we prompt the model, get a code artifact, and then throw the prompt away. That is backwards. When you compile TypeScript or Rust, nobody treasures the resulting binary; you regenerate it from source every time. The source specification is the valuable artifact. Yet with prompting we do the opposite: keep the generated code, delete the prompt.
"And this feels like a little bit like you shred the source and then you very carefully version control the binary."
A written specification is what aligns humans on a shared set of goals — the thing you discuss, debate, refer to, and synchronize on. Without it, you just have a vague idea. And code is a lossy projection of that intent: decompile a C binary and you won't recover the comments and well-named variables. Even nice code doesn't embody all the intentions and values behind it.
Grove uses OpenAI's Model Spec — a living document expressing the intentions and values OpenAI wants its models to embody — as the worked example. Open-sourced and updated in February, it turns out to be just a collection of markdown files. Markdown is remarkable: human-readable, versioned, change-logged, and natural-language, so product, legal, safety, research, and policy can all read, discuss, and contribute to the same source. Every clause carries an ID (he points to one labeled sy73), and that ID maps to another file in the repo containing challenging prompts for that exact clause — so the document itself encodes its own success criteria.
A recent GPT-4o update caused extreme sycophancy — the model praising users at the expense of impartial truth. The value of the Model Spec in that moment: it already included a section saying not to be sycophantic and explaining why it's bad in the long term. Because the agreed-upon intentions were written down, the behavior clearly didn't align with the spec, so it must be a bug. OpenAI rolled it back, published studies and a blog post, and fixed it — and in the interim the spec served as a trust anchor for what is and isn't expected.
If aligning humans were all it did, the spec would already be useful — but you can also align the models. Grove describes deliberative alignment: take the specification plus challenging input prompts, sample from the model under test, then hand the response, the original prompt, and the policy to a stronger grader model that scores how aligned the response is. The document becomes both training material and eval material, and the score reinforces the weights — pushing the policy from inference-time context down into the model itself so it applies the policy as "muscle memory," freeing up compute for the actual problem.
Even though the Model Spec is just markdown, it's useful to treat it like code: specs compose, they're executable, they're testable, they have interfaces that touch the real world, and they can ship as modules. You can imagine a type checker that flags conflicts when department A's spec and department B's spec disagree, unit tests embedded in the policy, and linters that catch overly ambiguous language. Grove extends the analogy: the US Constitution is literally a national model specification — versioned amendments, judicial review as a grader, precedents as input/output pairs that act as unit tests, and enforcement over time as a training loop.
"software engineering has never been about code."
Programmers align silicon via code specifications, product managers align teams via product specs, lawmakers align humans via legal specs, and every prompt is a proto-specification. The new scarce skill is writing specifications that fully capture intent and values — and whoever masters that becomes the most valuable programmer.
Grove's practical ask: for your next AI feature, start with a specification — state what you expect to happen and what success looks like, debate whether it's clearly written, then make it executable by feeding it to the model and testing against it. He muses that the future IDE might be an "integrated thought clarifier" that pulls ambiguity out of your writing. He closes with a call for help on aligning agents at scale and an invitation to join OpenAI's new agent robustness team.
"in the near future, the person who communicates most effectively is the most valuable programmer. And literally, if you can communicate effectively, you can program."
"And this feels like a little bit like you shred the source and then you very carefully version control the binary."
"If you don't have a specification, you just have a vague idea."
"Engineering is the precise exploration by humans of software solutions to human problems."
| Approx. Time | Topic |
|---|---|
| 0:00 | Intro — the coming of "the new code" and specifications |
| 1:30 | Code vs. communication: code is only 10–20% of the value |
| 4:00 | Vibe coding — keeping the binary, shredding the source |
| 6:30 | Why specs beat code: code as a lossy projection of intent |
| 9:00 | Anatomy of a spec — the OpenAI Model Spec is just markdown |
| 11:30 | Clause IDs and embedded success criteria |
| 13:00 | The GPT-4o sycophancy case study |
| 15:00 | Making specs executable: deliberative alignment |
| 17:00 | Specs as code — type checkers, unit tests, linters |
| 18:30 | Lawmakers as programmers: the Constitution as a spec |
| 20:00 | Call to action — start with a spec; agent robustness team |