AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The most useful admission in this session is that intuition is what fails. The team stepped back because they were not getting as far or as fast as they wanted on performance work, and found that their instincts were the thing leading them astray (7:39).
That is an unusual thing to say from a stage, and it sets up the only methodology in the talk that matters.
Why one fix does not produce the expected gain
The mechanism is stated plainly: bottlenecks hide others. You remove the one you can see, and discover a worse problem that was masked behind it (5:24) — which is exactly what happened in the case they describe, where the expected improvement only arrived after finding the second constraint (5:50).
This is why performance work so often produces a fix that changes nothing. The measurement said this was the limiting factor, the fix was correct, and the number did not move — because the moment the first constraint lifted, a second one that had never been reached became binding.
The consequence for planning is that you cannot estimate performance work by counting the problems you can currently see. The visible list is a lower bound, and there is no way to know how much is behind it until you start removing things.
Wide before deep
Their working method is the practical answer, and it is worth stating as a rule.
Rather than pursuing the first suspicious statistic, they survey broadly before drilling in. The example is explicit: check whether the processor's back end is the worse problem, find that it is not — stalling on only a fifth of cycles — and set it aside so effort goes to the front end instead (29:44).
That is disciplined in a way most performance work is not. The instinct on finding a bad number is to explain it, and explaining it takes hours. Checking every number first costs minutes and tells you which explanation is worth buying.
The instrumentation choice supports it: everything is enabled, accepting the overhead in exchange for the hundreds of statistics they want (11:43). That trade only makes sense under a wide-first approach — if you were going deep on a hypothesis, you would instrument narrowly and keep the measurement clean.
The number that reframes the problem
The diagnostic figure is instructions per cycle averaging below one, against modern processors capable of eight to twelve (28:49).
Stated that way, the finding is not that the code is slow. It is that the processor is idle most of the time — spending cycles waiting rather than working. The subsequent statistics say why: instruction cache misses around sixty per thousand instructions, and address translation costs that are also high (30:39).
None of those are algorithmic problems. Nothing about the program's logic is wrong. The code is laid out in memory in a way that makes the machine spend its time fetching rather than executing, and every fix that follows is about layout rather than logic.
What twenty per cent cost
The tunings applied are all in that category: keeping code in contiguous memory, constraining the space so methods pack better, and enabling larger memory pages to reduce translation pressure (31:34, 32:31).
The result is close to twenty per cent more throughput at 4,750 requests per second, with the ninety-ninth percentile still under a hundred milliseconds — described accurately as a cheap return (32:57).
Cheap is the operative word. No code was rewritten. No algorithm changed. The application does exactly what it did before and the machine executes it more efficiently, which means the twenty per cent came from configuration rather than engineering effort.
That is the strongest argument in the session for doing this work at all. Twenty per cent through code changes would require review, testing and risk. Twenty per cent through runtime configuration requires a benchmark and a deployment.
The honest picture of the process
The idealised loop is presented and then corrected. In theory you define what to measure, measure it, understand it, tune it, and get performance (6:18). In practice the path meanders, with false turns and dead ends before a tuning opportunity appears, and then you go back and measure again (7:11).
Combined with what they call a search space explosion (5:50), that is a fair warning about scheduling. Performance engineering does not decompose into estimable tasks, because you cannot know what the second bottleneck is until the first one is gone.
Which makes the wide-before-deep discipline more than a preference. It is the only part of the process that bounds the search, because surveying everything at least tells you the size of the space you are searching.
Key numbers
Talk chapters
Key takeaways
- 01
Bottlenecks hide others, so removing the visible constraint often reveals a worse one that was never reached before. 5:24
- 02
They survey every statistic before drilling into any of them, setting aside the processor back end once it proves not to be the limit. 29:44
- 03
Instructions per cycle below one against hardware capable of eight to twelve means the processor is idle rather than the code being slow. 28:49
- 04
Nearly twenty per cent more throughput came from memory layout configuration with no code changes at all. 32:57
- 05
The idealised measure-tune loop is corrected on stage: the real path meanders through false turns and dead ends. 7:11
Entities mentioned
Related talks
The practical counterpart to the argument made elsewhere this season that specification is what contains model entropy. Raval and Harris name the failure they are addressing precisely — a prompt-and-pray loop in which working code arrives with no record of what the model assumed, which requirements were fuzzy, what design was chosen or why, leaving nothing to review and nothing to iterate against when a defect surfaces months later. Their answer is three committed markdown artefacts: requirements written in a structured requirements syntax with acceptance criteria attached to each user story, a design document carrying technical decisions together with the reasoning behind them, and a task list whose entries cite the requirement numbers they satisfy. The traceability is the point — a reviewer questioning a decision in a pull request can follow it back through the task to the design to the requirement, all in the same repository. Notably they keep the human between each phase rather than after it, with the agent surfacing ambiguity as questions before proceeding.
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.