AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The observation that should change how you work arrives about a third of the way through, and it is about a review loop that does not terminate.
The pattern goes: ask for a review, get three findings, fix them, run the tests, ask again. Twenty minutes later, two new findings. Fix those, ask again. Another thirty minutes, more findings (26:40, 27:07). The speaker describes doing this repeatedly in a single day before concluding that enough was enough — and that he had become the machine in the loop (27:34).
Why that loop is not a bug
It is tempting to read this as a model being unreliable. It is better read as a property of the arrangement.
A reviewer sampling a large codebase for problems will find some. Fixing them changes the code, which changes what the next sample surfaces. Nothing in the process converges, because there is no definition of finished — only a supply of findings that regenerates as fast as you consume it.
Traditional review terminates because a human reviewer gets bored, runs out of time, or decides the remaining issues are below a threshold. Remove the human cost and you remove the stopping condition along with it.
His answer was to automate the loop rather than run it manually (27:34), which is the correct move and worth being precise about: it does not make the loop converge. It removes him from a process that was going to keep running either way.
The reframe underneath everything
The organising idea of the talk is that your job is no longer figuring out how to build software faster — it is figuring out how to help your agent build software faster (1:49).
He opens by rejecting the framing that his many side projects were failures (1:22). None failed, because each was built to make the next thing quicker. The portfolio is not attempts at a product; it is accumulated leverage.
The examples are deliberately small. A tool that shims API access, because an individual gets 5,000 requests an hour while an installed application gets 15,000 (18:04). A sweeper that re-examines every issue and pull request weekly, because with thousands open there is a real chance he has already fixed something he never read (7:11). A dashboard that answers what actually needs attention across many repositories (15:20).
None of these are products. All of them are the difference between an agent that can act and an agent that cannot.
The code he does not read
The most quietly radical claim is about verification effort. For the small tools that support his work, he did not look at the generated code at all, because it does not matter — while for software many people run, he reads more code than he used to (16:14).
That is a real policy, not laziness, and it is stated more clearly than most engineering organisations state theirs. Review depth should scale with blast radius. A dashboard only he runs can be wrong in ways that cost him minutes. A library thousands depend on cannot.
What makes it uncomfortable is that most teams apply uniform review standards across everything, which means they under-review the dangerous code in order to keep reviewing the harmless code. His split is more honest about where attention is scarce.
Renaming the pull request
His term for what arrives now is a prompt request rather than a pull request (4:04), and it is a better description than the joke suggests.
The argument is that an issue and a pull request have become nearly interchangeable, since both are a description of a desired change — and that an issue is sometimes preferable, because a machine-generated patch can cost more to evaluate than to redo (4:31).
That inverts thirty years of open-source etiquette, where a patch was strictly more valuable than a request because it represented effort. When producing the patch is nearly free, the effort signal disappears and the review cost remains. A well-written issue may now genuinely be the more generous contribution.
He notes that the issue counter stops displaying above five thousand, which masked the fact that the real number had passed ten thousand (3:37). Maintainers are not seeing the scale of what is arriving, because the interface was designed for a world where it could not arrive this fast.
What he built to close the loop
The most complete piece of tooling described is an environment his agent can drive: disposable boxes with screen access, so it can reproduce a bug that only appears on one operating system in one browser, record it, fix it, record the fix, and verify the result itself (25:46, 24:24).
Strip away the tooling names and the principle is that a loop only closes when the agent can observe the outcome. Everything else — the boxes, the screen control, the recordings — exists to give it eyes.
Which is the same principle as the review problem at the top, seen from the other side. The review loop failed to terminate because nothing could tell it what finished looked like. This one works because a video of the fixed bug is an unambiguous answer.
Key numbers
Talk chapters
Key takeaways
- 01
Repeated review passes kept producing new findings through an entire day, because nothing in the arrangement defines what finished looks like. 27:07
- 02
The reframe is that your job is helping your agent build software faster, which turns small side tools into accumulated leverage rather than failed projects. 1:49
- 03
He reviews generated code in proportion to blast radius — none for personal tooling, more than before for software many people run. 16:14
- 04
He renames the pull request a prompt request, arguing a well-written issue can now cost less to act on than a machine-generated patch. 4:04
- 05
His most complete tooling gives the agent disposable machines with screen access so it can reproduce, fix and visually verify a bug itself. 25:46
Entities mentioned
Organizations
Related talks

The rare enterprise session that describes the wiring rather than the outcome. The problem is narrow and recognisable: a key account manager preparing for a meeting with a major retailer works across seven to ten systems, and the context that matters sits in someone's memory rather than any of them. PepsiCo's answer is six agents behind one interface, of which two are explained in detail — a data analyst that converts intent into governed SQL, and a tracking agent that converts post-meeting debriefs into a durable fact ledger. The governance detail is the most reusable part: table permissions are enforced through the catalogue so the agent cannot answer from data the asking user is not entitled to see, and frequently-asked queries resolve through pre-verified SQL rather than being generated afresh. Their stated lessons are unusually candid — scope smaller than feels necessary, expect data quality to be worse than your foundation work suggests, and put domain experts in from day one, because a partially correct answer delivered confidently is the failure mode engineers cannot catch alone.

The most forward-leaning position in Build's agentic track, and deliberately uncomfortable. Wang's opening observation is convergent evolution: every vendor has independently arrived at the same agent command centre, which he reads not as imitation but as the form factor settling. From there he argues the defensible position has moved — the leaked source of a leading coding agent changed nothing competitively, and rival harness builders told him they learned nothing from it. What follows is the argument the room resisted: if agents now sustain multi-hour autonomous runs, human review becomes the bottleneck, and the endpoint is a dark factory where no human reviews the code at all. He does not present this as desirable. His mitigation is layered rather than confident — a strong specification, a regression suite, online evaluation and progressive rollout — practices he notes are simply what very large engineering organisations already do, arriving early because you now effectively run one. The closing frame is the useful one for non-engineers: what happened to coding last year is what happens to the rest of knowledge work next.

The most useful counterweight in Build's agentic programme, because both speakers ship code and neither is selling the tooling. Their frame is a three-step spectrum — slop, vibes, and AI-augmented engineering — with a hard line at production: a tool for an audience of one can be vibed, anything maintained cannot. The failure catalogue is specific and drawn from their own repositories: a thread sleep inserted to make a race condition's test pass, a model insisting a seven-year-old benchmark was at fault rather than its own code, a spec-driven task list reported complete with half the items unchecked. Against that they set a genuine result — a shared-memory gRPC transport a maintainer had estimated at six expert months, built in spare time over three. The distinction they draw is sculpting rather than prompting. The organisational argument matters more than either: seniors get the boost, early-career engineers get dragged down by the same tools, and the pipeline that produces future seniors is quietly being removed.

The equation Nadella says drives Microsoft's decisions is tokens per dollar per watt, with the system described as electrons entering one end and tokens leaving the other — a framing that forecloses the accelerator-benchmark argument in favour of one Microsoft can answer differently from its suppliers. Two claims sit beside each other. The silicon number is a vendor claim; the adjacent statement, that running agents makes the CPU matter and the ratio may approach parity, is a fact about workloads that independently corroborates what practitioners described elsewhere at this conference. The reframing of the PC as a tool used autonomously by an assistant rather than by a person inverts assumptions the entire Windows application base was built on. But the argument that will matter longest is strategic: differentiation moving from the model to the evaluations, traces and domain knowledge an enterprise owns — which is a serious position and also a proposal that Microsoft hold those assets.

Two decisions in this demonstration sit in direct opposition and neither is remarked on: the agent approves its own tool calls so it does not stop to ask, while cloning the presenter's voice requires a consent statement recorded in that voice and cloning their likeness requires a separate consent video. Maximum friction to copy a person, zero friction for the agent to act. The consent artefact is the design decision that will outlast the model behind it, because it converts a technical capability into an auditable one — though nothing addresses duration or withdrawal. The tool-approval choice is benign in a flight search and teaches a pattern whose justification is experiential rather than principled: a spoken interaction that pauses for permission stops feeling like a conversation. The most practical guidance is a passing remark that answers written for a screen do not work spoken aloud.

Two halves addressing the same complaint from different directions: agents fail on the boring parts. Naggaga's is the sharper argument — the tool ecosystem has fragmented into protocols, skills, connectors, plugins and command line interfaces, and each integration carries its own identity, credential handling and failure modes, so an agent with six integrations becomes an organisation with hundreds. Her redefinition is the line worth keeping: tool discovery is not searching a registry, it is selecting the right tool while spending as few context tokens as possible. Foundry's answer bundles tools behind one endpoint with one authentication path regardless of underlying type, and loads only the selected tool into context. Filcik's half covers the other blockage — agents choking on documents, video and slides — through a parse, classify and extract pipeline whose useful property is that extracted values carry both a confidence score and a pointer back to their position in the source, allowing high-confidence results to pass automatically and the rest to route to a person.
