A distinguished engineer who has read close to four thousand postmortems has a blunt view of where software development is headed: the code was never really the point.

Marc Brooker is a VP and Distinguished Engineer at AWS, where he has spent much of the last few years building the infrastructure and tools behind agentic development, including Strands, AWS's open source SDK for building agents. He joined The AI Native Dev to talk through what he calls the agentic software development hypothesis, effectively his own take on spec-driven development, and the conversation ends up being as much about specification and testing as it is about agents themselves.

The core claim is simple to state and harder to sit with: once a piece of software has a complete enough specification, building and maintaining a reliable implementation of it becomes, in Brooker's words, something that can be automated over time. It can be helpful to think about that claim in three strengths, weak, strong, and strongest, each betting on how much of the software industry's work can eventually be described crisply enough for automation to take over.

Why testing just became the hardest part of the job

For a long time, testing was treated as the unglamorous cousin of building. Brooker argues that framing no longer holds. "Testing is now the most important part of software development," he said, adding that it may always have been true, it just was never the shiny object for most developers.

In practice, this reframes what a specification is for. Brooker describes an oracle as whatever tells you if the implementation you built actually matches what you wanted, and building that oracle is often harder than building the thing it's checking. Some domains make this easy: implementing a well-described file format is close to fully specifiable. A customer-facing UI is a different story, where the oracle has to lean on production metrics, customer feedback, or a human in the loop rather than a deterministic check.

This is where the practical tension shows up for teams adopting agentic coding today. It can be helpful to separate two things that specifications tend to get tangled up in: the declarative requirement, what the software should do, and the implementation detail, which language or UI framework it uses. Brooker's frustration with the current moment in spec-driven development is that these two still conflate more than they should. As a system builder, he'd rather not care about the implementation choices at all, and would prefer the specification and the tests to focus entirely on what good looks like for the output.

Teaching agents to learn from your postmortems

If testing captures explicit intent, postmortems capture the intent nobody wrote down until something broke. Brooker has personally read three to four thousand of them, and says the biggest thing they taught him was a kind of humility: the gap between believing you can solve a problem and watching, in detail, how it actually failed.

One specific pattern he points to is metastable failure: a system absorbs an overload or a component failure, goes down, has its immediate cause fixed, and still doesn't recover because it's stuck in a stable down state. Understanding that dynamic, he explained, has been central to avoiding entire classes of long, painful outages, and most of that understanding came from studying real incidents rather than reasoning about failure from first principles.

The more interesting question Brooker raises is whether agents can absorb that same kind of learning. His answer is that it's already happening, in a handful of concrete ways: giving an agent a tool to search semantically over an organization's postmortems, letting it write its own memory of what it tried and what worked, or having it build small reusable tools that encode a fix so the next agent can pull it off the shelf. He calls this procedural memory, and it sits alongside context engineering practices like team wikis and organizational context tools that let a whole team's agents share what any one of them has learned.

There are limits, though. Brooker is clear that agents are strongest where the goal is unambiguous, a metric that should look a certain way and doesn't. They're weaker at the fuzzier end of a postmortem: interpreting a handful of complaints on social media, or figuring out what "feels slow" means to a customer. That gap between clear, measurable goals and softer judgment calls is, in his view, where human context still does the most work.

What this means for agentic policy, and for juniors

The second half of Brooker's recent focus has been agentic policy: the question of what an agent is and isn't allowed to do, and how to describe that with enough precision that an organization can actually trust an agent to act autonomously. He's skeptical that classic, human-style authorization models transfer cleanly to agents, since humans bring judgment and feedback that a permissions list doesn't capture. The customers he talks to increasingly want a way to describe, deterministically, what an agent can do and in what order, which is part of why AWS built a dedicated policy language for it.

Brooker also draws a line from decades-old research on human supervision, including the well known Ironies of Automation paper, to why he thinks the honest endpoint here is more autonomy rather than more human monitoring. Humans, he argues, are simply not good at watching a system for rare, high stakes failures and reacting correctly in the moment.

He closes with something more personal: advice for bringing junior engineers into an industry that's changing this fast. His view is that the postmortems, the customer conversations, and the ownership that used to be reserved for senior developers need to reach junior engineers earlier, not later, because the industry can't grow if experience becomes the only path in. The junior engineers coming out of AI-native curricula, he notes, arrive with fewer preconceptions and a genuinely different set of instincts, which he sees as a real advantage rather than something to correct.

It's a fair note to end a conversation about specifications and automation on. The tools for building software keep changing, but the way people actually get good at building it, by watching things fail and learning why, sounds a lot like it always has.