When code can be regenerated on demand, the thing worth keeping — versioning, protecting — is the statement of intent: the spec. Code becomes a build artifact. It was also the most productively contested claim of the conference.
Four consecutive talks in the Software Engineering track, plus a keynote and the interviews. Unlike most themes, these speakers shared a room for the afternoon — and still disagreed.
¶1For one afternoon on the second day, the Software Engineering room held a running argument. Four talks in a row — Nick Beaugeard on spec-driven development, Jakub Riedl on agent instruction files, Ben Taylor on engineering without reading code, Josh Gillies on documentation — kept arriving at the same question: when machines write the code, what exactly is the thing we keep?
¶2Beaugeard put the sharpest version of the answer. “We've all been backing up the wrong files” Beaugeard ▸ ≈01:06 — we review, version and protect the code, then throw away the prompts and intent that produced it. His reframe: “The spec is the source of truth. The code is a build artifact” slide — with a pocket test to go with it: if you can regenerate it, it's a build artifact. And a report from his own practice that would have sounded absurd two years ago: “For my whole career, I've read code written by people. And now I read code written by nobody… I read the tests.” Beaugeard ▸ ≈13:02
¶3The next three speakers, whether they meant to or not, spent the afternoon disagreeing with him — usefully. Riedl's case: no hand-written file stays true. Whatever you write down captures “single person taste… the single moment… one particular repo” Riedl ▸ ≈01:23, and “the perfect instructions right now ain't gonna be perfect tomorrow” Riedl ▸ ≈14:02 — so the durable thing isn't the artifact, it's the loop that keeps correcting it. Gillies came from the other side entirely: the code and its schemas are the truth — “why read the manual, when you can ask the codebase” slide — and stale documents actively poison an agent's context. But even he ended somewhere close to Beaugeard: “code captures the outcome of a decision. It does not capture the decision itself.” Gillies ▸ ≈16:29 Machines recover the what and the how; the why still has to be written down by a person.
¶4The cautions came from use, not theory. Ben Taylor's team found the bottleneck simply moved — writers unblocked, review swamped — and he warned about what happens to people who merely supervise: monitoring a system, we miss more than we do as active participants. Taylor ▸ ≈12:11 Jeremy Howard told the second morning's keynote about 200,000 lines of vibe-coded software where “the pace we've moved at has slowed down as models get better and token spend increases.” Howard ▸ ≈11:49 And Beaugeard undercut his own thesis before anyone else could: specs rot too, and “shitty specs deliver shitty software. They always have. They always will.” Beaugeard ▸ ≈16:41
¶5Off stage, the shift sounds matter-of-fact. Adam Hudson, who builds agent infrastructure at Notion: “I don't find myself writing code in an editor anymore ever.” And Annie Vella's keynote gave the career version: the craft is relocating — toward the domain, “capturing the what and the why in well-written specs”, or toward building the machine that builds the machine. Vella ▸ ≈13:26 Nobody in that room defended the old default — intent living in people's heads, code as the only artifact. What they couldn't agree on is what replaces it.
“So here's the thing to think about. We've all been backing up the wrong files.” On the slide: “THE HOOK — We have been backing up the wrong files.”
“For my whole career, I've read code written by people. And now I read code written by nobody. And I don't really read the code much anymore, to be honest with you. I read the tests. I read the results of them.”
“Everything you put in there is basically capture of single person taste… it captures the single moment that the user is writing it, so over time it will get worse and worse and worse — and at the end, you're doing that for one particular repo.”
“It's more important to focus on the learning loop and how your agents improve over time than whatever is the perfect instructions right now — because the perfect instructions right now ain't gonna be perfect tomorrow.”
“What it cannot do, regardless of how much compute you throw at it — it cannot answer the why. Code captures the outcome of a decision. It does not capture the decision itself.”
“We've got 200,000 lines of vibe-coded software at this point… the pace we've moved at has slowed down as models get better and token spend increases, because we generate more and more code with less and less careful engineering.”
“Shitty specs deliver shitty software. They always have. They always will.” And from his closing slide: “Specs rot too — a spec can drift from reality just like a comment.”
“If you're really passionate about the domain, you might lean towards capturing the what and the why in intents, in well-written specs, and feeding that to the agents. If you're more interested in building the machine that builds the machine, you might lean towards the harness.”
“I don't find myself writing code in an editor anymore ever… most of it is through writing some kind of spec and passing it through a model to produce my code for me.”
“It allows me to think more about what I want to do than having to worry about the actual execution of what I want to do… it's the shortest path from idea to execution.”
“Don't outsource your thought to AI. You still need to be the one who's in control of it.”
“My controversial take is that vibe coding is really exciting for engineers — and as an engineer, you should be trying it out… but you need really high engineering standards, particularly if you're working with children and children's data as we are.”
“It's more important to focus on the learning loop and how your agents improve over time than whatever is the perfect instructions right now — because the perfect instructions right now ain't gonna be perfect tomorrow.”
Three answers to “what do we keep?” Beaugeard: the spec. Riedl: the loop that keeps it honest. Gillies: the code speaks for itself, and people keep only the why. What nobody defended was the old default — intent living in people's heads, and code as the only artifact.
| Engineers | Commit the spec with the code. Beaugeard: “we rewrite our prompts every time and instantly forget what they were.” His test for what to keep: if you can regenerate it, it's a build artifact — version the things you can't regenerate. |
|---|---|
| Team leaders | Give corrections a home that compounds: Riedl's pattern — feedback lands as markdown in git (specs, ADRs, patterns, glossary), reviewed as pull requests, instead of being repeated in chat forever. |
| Org leaders | Treat specs and ADRs as governance, like branch protection — “pay it now, or pay it after the incident” (Beaugeard). Gillies: ADRs are “the one document machines cannot write for you.” |
| Key takeaway | Stop half-automating review. Taylor: people monitoring a system miss more than active participants — either engineer the system to be safe without a human backstop, or keep humans genuinely in the loop. The middle is where errors live. |
Beaugeard, Riedl and Gillies give three answers to “what do we keep?” — the spec, the loop, the why. Run it for your own stack: what would you keep, and what could you honestly regenerate?
For now these are placeholders. Once the individual sessions are up on Conffab, each title here — and every quote above — will link straight to the talk: video, transcript and all.