AWS's Marc Brooker: Specs, Not Code, Are the Hard Part

AWS VP and Distinguished Engineer Marc Brooker joins Simon Maple to discuss what makes agent-written software trustworthy: specifying the desired behavior, checking outcomes, learning from production failures, and enforcing limits on agent actions. His central forecast is that implementation and maintenance will become automated once software can be specified sufficiently precisely—not that complete specifications are already easy to produce.

This summary uses the saved English YouTube caption track (kind: caption), with light source-faithful transcript cleanup; it was not checked against the original audio. Operational lessons are Brooker's experience, future directions are his proposals or forecasts, and AWS product descriptions are vendor claims, not an independent assessment.

Specifications need ways to judge the result

• Automating implementation still leaves the specification problem. Brooker expects agents to build and maintain reliable, efficient implementations from sufficiently complete descriptions. He says narrowly defined tasks, such as implementing a well-described file format, already illustrate this direction. His stronger hypothesis is that most software can eventually be specified crisply enough for such automation; it is a forecast, not a claim that today's agents can independently specify arbitrary systems 31:58–34:36(opens in a new tab).
• A correctness oracle is a way to decide whether the software is good. Brooker places substantial human work in creating these checks. Formal specifications can suit precisely defined components, but customer-facing systems may need customer feedback, production metrics, or comparisons between implementations. His database example is differential fuzz testing: comparing how two database implementations behave on the same generated inputs. The broader point is to give the automation loop evidence about outcomes, not assume that every useful requirement has a deterministic test 34:36–37:36(opens in a new tab).
• Describe required behavior separately from implementation choices. Brooker calls testing an informal specification technique. His criticism of current spec-driven development is that it still mixes what the software should do with implementation choices such as the programming language. He wants specifications and tests to focus on good outputs, while more internal design decisions become automated 38:25–40:13(opens in a new tab).

Production experience and policy constrain autonomy

• Incidents reveal failure dynamics that theoretical knowledge can miss. Brooker describes on-call work as a major source of learning about real systems and customer needs. His concrete example is a metastable failure: an overload or component failure pushes a system into a persistent failed state, so repairing the initial cause does not restore service. Studying incidents helps distinguish what triggered the outage, what kept it going, and what enabled recovery 06:59–07:54(opens in a new tab), 10:40–13:17(opens in a new tab).
• Learning from incidents can use retrieval, memory, and reusable tools. Brooker describes agents searching similar postmortems, remembering which recovery attempts worked, and turning repeated steps into code they can reuse as tools. Feeding that operational learning back into architecture and development is a further goal: he explicitly says the industry is earlier in that cross-workflow loop than in optimizing the individual agents 14:12–18:39(opens in a new tab).
• Clear targets are easier than ambiguous customer experience. Brooker contrasts a measurable gap in orders or instance launches with reports that a product feels slow or less reliable. Agents can help investigate the latter, but he says they are less capable of understanding the full customer context; expressing that context as metrics is itself difficult 18:39–20:39(opens in a new tab).
• Enforce action boundaries instead of relying on repeated approvals. Brooker argues that humans are poor continuous supervisors, especially as failures become rarer and harder to recognize. He proposes defining permitted behavior in advance—for example, allowing Git operations only in the repository being worked on. He describes AWS's Dogwood policy language as supporting constraints on both actions and their ordering; this is his product claim, not a demonstrated security guarantee in the interview 20:39–23:33(opens in a new tab), 24:38–27:21(opens in a new tab).
• Policy needs organizational and task-specific inputs. Brooker expects most people to describe rules in natural language and have them translated into a policy language for enforcement. In his proposed workflow, security and legal requirements combine with developers' personal and task-specific limits. Examples include company rules for customer data, protecting personal documents from deletion, and requiring Rust's Clippy linter to pass before committing code. A disposable demo could have looser development checks 27:21–31:58(opens in a new tab).

Start with usable feedback and shared context

• Use simple checks before sophisticated memory techniques. For teams starting with agents, Brooker recommends an agent-instructions file that states what good work looks like, including requirements to pass tests and Clippy checks before shipping. He urges teams to use these low-overhead techniques before pursuing more sophisticated memory methods 46:35–48:19(opens in a new tab).
• Make learned context available across the team. Brooker says memories retained by individual agents do not spread well across a team. He describes agents recording guidance in a small shared wiki so other agents can use it. He also recommends giving agents search access to relevant information already recorded in organizational documents 48:19–51:07(opens in a new tab).
• Human communication still requires ownership. As agents take over implementation, Brooker sees code becoming less of a medium for human communication. Prose still asks for readers' time, so he believes authors owe them careful thought and ownership of the words. He keeps his blog human-written. For work documents, he would accept AI adding a concise paragraph of business metrics, but rejects expanding a short prompt into pages that waste readers' time 40:13–45:39(opens in a new tab).
• Keep a path into engineering for newcomers. Brooker argues that organizations must teach and bring in junior engineers rather than rely only on existing senior expertise. He acknowledges uncertainty about the day-to-day training practices, while valuing the fresh ideas of graduates who have learned with agents 52:03–54:46(opens in a new tab).

Full interview: https://www.youtube.com/watch?v=nSRpnjkLqgc(opens in a new tab)