AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The failure mode has a name now. Jay Raval calls it the prompt-and-pray loop: you describe a feature, the model responds enthusiastically, code appears, and it works — until you look closely (3:15).
What is missing at that point is not quality. It is the record. Which assumptions did the model make? Which requirements were vague enough to be filled in? What design was chosen, and against what alternatives? Where does that reasoning live? When a defect surfaces six months later, there is nothing to iterate against, so the loop restarts from the beginning.
The answer AWS presents is unfashionable: write the specification first, and commit it.
Three documents, and why they are documents
Spec-driven development produces three markdown artefacts before implementation begins — requirements, design, and tasks — and the fact that they are files in the repository rather than state inside a tool is the design decision that matters (12:44).
A reviewer questioning a choice in a pull request can follow it back: the task cites the requirement it satisfies, the design records why the approach was taken, the requirement states what was being asked for. Intent stops being something reconstructed from a commit message.
Requirements are written in a structured syntax rather than free prose — a deliberate constraint borrowed from established requirements practice (9:17). Harris is candid that this looks arbitrary until you see the purpose: disciplined natural language forces the ambiguity into the open, where it can be resolved, instead of leaving it to be silently resolved by whoever implements.
Each user story carries acceptance criteria, and those criteria do work later. When tasks are generated and executed, the criteria are what the output is checked against — so relevance to the original requirement is verifiable rather than assumed (8:16).
The human sits between the phases, not after them
The workflow's structural choice is that approval happens at each boundary rather than at the end.
The agent produces requirements, then stops and asks whether they are right. It produces a design, then stops. Only then does it generate tasks. Harris's framing of what the agent is doing during these phases is precise: resolving ambiguity, which means asking clarifying questions rather than choosing quietly (11:24). The example brief they use — a command-line tool with basic create, read, update and delete operations — is genuinely underspecified, and the agent makes decisions about it that a person might not have made.
Everything is settled before a line of code exists (11:09). This is the part that reads as a return to older practice, and to an extent it is. The difference is that the specification is not written for a downstream team to interpret in a meeting. It is written to be executed.
Rationale, not just decisions
The detail most likely to be undervalued is that the design document records reasoning alongside choices (13:45).
Most architectural documentation states what was decided. It rarely states what else was considered and why it lost, which is exactly what a reader needs when they are deciding whether the decision still holds under changed circumstances. A design document that carries rationale can be evaluated. One that carries only conclusions can only be obeyed or ignored.
This is also the property that makes the artefact useful to the next agent rather than only to the next person. A model reading a decision plus its justification can tell whether the justification still applies.
What it is trading away
Raval is explicit that they did not want to lose the fluency of prompt-driven building, and the tasks phase is where it returns — granular, pre-specified prompts the agent executes, either individually or in sequence (6:39).
The honest trade is still visible. Three documents and two approval gates is more process than typing a sentence and watching an application appear, and for a great deal of software the lighter path is correct. Their line is production: work that will be maintained, extended, or contributed to by others.
Which puts this session in direct conversation with the rest of the conference season. Wang's argument at Build was that specification is what contains model entropy at scale, with a reference implementation running to two thousand lines of markdown. This is the same claim arriving from the opposite direction — not as a technique advanced practitioners have discovered, but as a default the tooling now enforces.
The uncomfortable implication for anyone building this way is that the specification becomes the artefact of value, and the code becomes the derived output. That inverts an assumption most engineering organisations still run on, including how they review, staff and promote.
Talk chapters
Key takeaways
- 01
The failure being addressed is the prompt-and-pray loop: code arrives working, but with no record of the model's assumptions, the fuzzy requirements, the design chosen or the reasoning behind it. 3:15
- 02
Their design goal was explicitly to preserve the feel of prompt-driven building while adding the clarity and structure of specifications, rather than replacing one with the other. 6:39
- 03
Each user story carries acceptance criteria, which are later used to check that generated code actually addresses the requirement rather than merely running. 8:16
- 04
Requirements are written in a structured requirements syntax borrowed from established practice, a deliberate choice to bring disciplined natural language rather than free prose into the specification. 9:17
- 05
The full requirements and design are settled before any code is written, with the agent's role at that stage being to surface ambiguity as clarifying questions. 11:09
- 06
Design documents record not just the technical decisions but the rationale behind them, so a later reader can evaluate the choice rather than only observe it. 13:45
- 07
All three artefacts are markdown committed to the repository, so a reviewer questioning a decision in a pull request can trace it to the specification rather than reconstructing intent. 12:44
- 08
Generated tasks cite the requirement numbers they satisfy, closing the traceability loop from implementation back to the original user story. 15:09
Entities mentioned
Organizations
Related talks
Drawn from a year of engagements with more than a hundred companies, this is the most direct challenge in the season's programme to the assumption that faster code generation produces faster delivery. Mishra and Raja open with external evidence rather than their own: an industry study putting realised velocity gains in the ten to fifteen per cent range, and a controlled experiment in which developers using AI estimated themselves roughly a fifth more productive while measurement showed them a fifth slower. Their diagnosis is that both prevailing working styles fail for opposite reasons. Handing an ambiguous problem to an agent and awaiting a finished result produces a volume of code the developer must nonetheless sign for and cannot confidently review, so it stalls before production. The senior engineer's alternative — decomposing the work personally and inserting AI into narrow slots — keeps the intellectual load exactly where it was, and leaves the surrounding process untouched, so hours saved in editing are consumed by the meetings that process still requires.
Brooker builds the definition from the bottom up rather than asserting it, using a deliberately absurd arithmetic task to separate three categories: what a model computes reliably as a fixed function of its input, what merely needs to arrive in the system prompt, and what genuinely requires reaching into the world. Only the third category justifies a tool, and the distinction matters because most production disappointment comes from tools built for the first two. His working definition follows — a system given a goal that loops between inference and tool calls until it reaches one — with the observation that modern agents increasingly embed code in their definitions, not for expressiveness but because replacing inference steps with deterministic code improves reliability while lowering both latency and cost. The remainder covers what production actually demands around that loop: somewhere to run, memory that persists preferences, a gateway to internal and external tools, evaluation, and formal methods applied to policy.
The most concrete attempt this conference season to answer a question the agentic coding sessions mostly leave open: if commit counts and hours saved are the wrong measures, what replaces them? Otto's account is unusually specific about why the obvious alternative fails — summing the small time savings a platform team delivers produces figures exceeding a hundred per cent of a developer's time, and a minute returned is not code in production. Their replacement borrows from Amazon's retail supply chain, where cost to serve measures what it takes to place a package on a doorstep, and applies the same shape to software: total cost divided by units of delivery, with the unit chosen to fit the team. The supporting research is the more quotable finding — across tens of thousands of developers over five years, individual velocity reverts to the team's mean, making team velocity the strongest predictor of both individual output and perceived productivity, which is the empirical case against measuring individuals at all.
The framing statistic is organisational rather than technical: around eighty per cent of organisations expected to have platform engineering teams going into 2026, up from about forty-five per cent a couple of years earlier. The interesting part is the doubling. The problem described is teams solving the same problems separately, producing inconsistency and redundancy — dangerous not because of duplicated effort but because each independent solution has its own security properties, and the organisation's real posture is the weakest rather than the average. The most valuable content is that two financial services organisations went in diametrically opposite directions on workload identity and both are described as working, which implies the choice is determined by context rather than by a general answer. The honest note follows immediately: even with standardised patterns the result remains fragmented.
The line that explains this session comes from the customer in the last ten minutes: they are preparing for a world where metadata is how agent-based systems find the data they need and access it through the controls being built. That relocates a function — governance has spent two decades as compliance activity describing data that people locate by other means, and if agents navigate by the catalogue then the catalogue stops describing the access path and becomes it. An incomplete catalogue is a documentation problem when humans can ask a colleague; an agent has no such workaround. The most honest moment addresses the perennial failure that rules get written and ignored, with enforcement rather than publication as the argument. Generated descriptions and greyed-out classification suggestions divide the labour correctly, keeping a person accountable while removing the burden of finding candidates.
The most useful sentence here concerns where reliability is achievable: for workflows calling well-structured interfaces and producing checkable code, the path is faster. The implication is that there is a slower path, and it is the one most enterprise pilots are on. The division separates work whose output can be checked mechanically from work where correctness is a judgement, and only the first admits an engineering approach to improvement. The best illustration is browser automation that examines what the customer would observe rather than the underlying markup, walking checkout and booking flows and identifying revenue leakage — a framing that defines success in the business's own terms and is verifiable in the good sense. The demonstration's fifteen to twenty tool calls are the honest measure of what agentic means: not one clever response but a chain of decisions each depending on the last.