AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
Jeff Dean spent most of his segment at I/O describing a constraint that has nothing to do with model quality.
If an agent spends half its running time inside tools, then by Amdahl's law no improvement to the model — however dramatic, however magical the hardware — can deliver more than a doubling (16:21). The models got faster. The tools around them did not, because they were built for a person clicking, waiting and reading.
That reframes a large amount of current infrastructure work as latency debt, and it is the most portable idea from a panel that was otherwise about Google's own surfaces.
The rewrite, and why it worked
Google's response to its own diagnosis is the detail worth stealing.
Much internal tooling was written in Python, chosen for the reason such things usually are. Startup time alone made it unsuitable for agents calling it thousands of times. So they translated it — and Dean is precise about why the translation succeeded where an instruction to "write this faster" would not have.
Asking a model to write code from a natural-language description is an underspecified problem; the model fills gaps with assumptions. Asking it to translate a working program plus its test suite into another language is fully specified: the behaviour is pinned by the tests, and only the implementation changes. Internal tools were rewritten for ten to twenty times the speed in about a night of work (18:54).
The generalisable lesson is not about language choice. It is that the tasks agents complete reliably are the ones where correctness is already defined somewhere, and that a codebase with tests contains far more such tasks than it looks like it does.
Latency is not a budget, it is a ratio
Liz Reid supplies the counterweight from Search, and it corrects an assumption that runs through most agent design.
Acceptable latency is not fixed. It scales with how much work is being displaced. A question the user could have answered themselves demands an instant response, or the wait is an insult. A task that would have consumed twenty minutes buys ten seconds easily. Something that produces an artefact used for weeks can take a minute, because the user sets it going and leaves (5:17).
This is more useful than a general injunction to be fast. It means the design question is not how long users tolerate waiting but what the wait is being exchanged for — and that a product can become slower and better received simultaneously if it takes on more.
Writing for machines instead of people
Josh Woodward's contribution is the quietest and possibly the most telling.
Teams in his organisation have not written a product requirements document in months. What replaced it is not nothing — it is context files written to be read and acted on by a model rather than discussed by humans (19:19). The example he gives is a design specification file, since open sourced, that encodes an application's design language so an agent can apply it consistently.
The shift is subtle and worth naming. A requirements document is an instrument of human coordination; its ambiguity is tolerable because a meeting resolves it. A context file is an input to execution, and its ambiguity becomes the model's assumption. Organisations that make this transition without noticing will find their documents have quietly acquired a new failure mode.
The claim underneath all of it
Dean's structural argument arrives late and is the one that would matter if it holds.
Software has always been standardised because creation was expensive. You shipped something general enough to serve many situations, and every individual situation accepted a poor fit. If long-running agents can produce bespoke software per context — for a person, a team, a moment inside a search result — then the economic reason for standardisation weakens (36:41).
Kavukcuoglu offers the scale evidence: hundreds of agents working for roughly a day and a half producing a functioning operating system (34:13). Reid offers the organisational evidence, which is more persuasive because it is more embarrassing — the developer agent platform now sits inside Search, an arrangement she says would have sounded absurd four months earlier (35:22).
What they have not solved
Dean is candid about the part nobody has an answer for.
A dashboard scales to perhaps ten concurrent agents. It does not scale to a hundred. His question — how a person coordinates thirty virtual interns — is left genuinely open, with speculation about hierarchies or agents reporting to each other in some structured way (30:12). Woodward, whose team built the current dashboard, says he would be surprised if it were the final form.
This is the honest gap in an otherwise confident hour. The infrastructure argument is settled: tools must get faster, context must become machine-readable, environments must be shareable. The interface argument is not, and it is the one that decides whether any of this reaches people who do not write code.
Asked for the most important developer skill of 2026, Dean does not hedge — learn to use these tools and agents to build at greater scale. Coming immediately after an admission that nobody knows how to supervise thirty of them at once, the advice reads less like a conclusion than like an instruction to go find out.
Key numbers
Talk chapters
Key takeaways
- 01
Dean applied Amdahl's law to agents: if half the time is spent in tools, no model speedup — however magical the hardware — can deliver more than a doubling, making tool latency the binding constraint. 16:21
- 02
Google rewrote internal Python tooling into Go for ten to twenty times the speed in about one night of model-assisted work, because a tested program plus its tests is a fully specified translation task rather than an ill-specified prompt. 18:54
- 03
Reid's finding from Search is that acceptable latency is not fixed but proportional to work displaced: a quick question demands an instant answer, while a task that would have taken the user twenty minutes buys ten seconds or more. 5:17
- 04
Woodward reports teams that have not written a product requirements document in months, writing machine-readable context files instead — including a design specification file Google has since open sourced. 19:19
- 05
Google's TPU designs have split along training and inference lines rather than serving both from one architecture, which Dean ties directly to the inference speed users experience. 3:34
- 06
Kavukcuoglu described hundreds of agents working for roughly a day and a half to produce a functioning operating system, offered as evidence of what sustained orchestration now reaches. 34:13
- 07
Search was built on the same Antigravity SDK released to external developers — Reid notes that putting a developer agent platform at the heart of Search would have sounded absurd four months earlier. 35:22
- 08
Dean's structural argument: software was standardised because creation cost was high, and long-running agents make bespoke software per setting economically viable for the first time. 36:41
- 09
On interfaces, Dean noted a dashboard scales to perhaps ten concurrent agents but not a hundred, posing the open question of how a person coordinates thirty virtual interns. 30:12
- 10
Asked for the most important developer skill of 2026, Dean answered without qualification: learning to use coding tools and agents to build at greater scale. 37:46
Entities mentioned
Related talks
The anecdote that opens the panel does the work: a robot asked to pick up the extinct animal selected a dinosaur toy, with nothing in its training data connecting the phrase to the object. That transfer from language models into machines with hands is the premise of the current wave. What the practitioners then describe is where it stops. Physical intelligence is about exerting force and using a body to do it, which is knowledge about consequences — the one thing a corpus of internet images contains almost nothing about. The humanoid question gets an honest treatment: not that human shape is optimal, but that the world is already built for it, plus a development-loop argument about collecting data and deploying on the same hardware. The most useful passage is scepticism about the field's favourite shortcut: generated video looks realistic and does not hold up for dexterous manipulation, because looking right and being physically consistent are different properties.
Pichai's framing of Google as the buffer between people and the raw internet is offered as continuity — search did it, browsers did it, agents do it more — and it is also the most contested claim in the industry, because a buffer decides what passes through. He reaches immediately for the counterweight, the connection people feel to creators they follow, which is precisely the tension the company is currently managing without resolving. Two answers are sharper than the format usually produces. On competition he describes participants running on different pre-training and release cadences rather than at different speeds in one race, which is a more honest account than the leaderboard framing and comes from someone with an interest in leaderboards. On security he acknowledges models improving at cyber work, which is the one domain where better capability does not obviously net out positive, since an attacker needs one vulnerability and a defender needs all of them.
The clearest statement at I/O of how an agent API differs from a chat API, and the reasoning behind each departure is stated rather than assumed. Three changes matter. Conversation state moves to the server: a call returns an identifier, and passing it back continues the thread, retiring the client-side history array. The data model abandons alternating user and model turns for discrete steps, on the argument that a trace containing reasoning, tool calls, environment responses and compaction was never really a conversation and modelling it as one distorted it. And agents receive their own persistent remote environment rather than acting on the caller's machine — addressable by identifier, and shareable, so a research agent's output files become an application builder's input without passing through the context window. Schmid is explicit that scaffolded environment files are deliberately not model input, which is what keeps large artefacts out of the context budget. Schaeff's first half covers the real-time voice path, where the notable property is speech-to-speech across ninety languages with transcription of both directions.
The observation that organises this session is not about capability but about attention. Engineers increasingly file a ticket rather than opening an editor, and the code comes back — which changes what the surrounding tools are for. If the agent works while you do something else, the conversation between you is no longer a workspace; it is the mechanism by which the agent surfaces a question it cannot resolve alone. Interfaces built for continuous conversation optimise for flow, and interfaces built for interruption should optimise for the opposite. A runtime constraint follows immediately: an agent that starts a long-running job cannot block until it finishes, which turns out to be a workflow-engine problem rather than a model one. The panel's closing formulation — that deciding what to build is the hard skill and always was — reads as reassurance and functions as a warning, since that judgement is downstream of exactly the work now being delegated.
The most honest moment here is an aside about how the presenters have tracked their own projects: plans in documents, plans in spreadsheets, plans in bug comments, and once a plan written on a receipt. That describes the actual category being addressed — not software nobody has built, but the small internal tool every team improvises badly because building it properly was never worth the effort. The demo turns on a single question: the generated app is strictly single player, so what happens when you want to share it with the team? That boundary is where improvised tools historically died, because it is where accounts, shared storage and access rules begin. Here it is crossed in one step, with the access rules generated and deployed automatically — which is convenient, and is also the moment the application acquires obligations nobody reviewed.
The case for local inference is made in three clauses representing different kinds of constraint: cost, where a local model removes an API call; availability, where the application works on a flight; and data, where requirements prevent information leaving the device. Only the third changes what is buildable rather than what is affordable. What makes this newly practical is unglamorous — instruction set extensions integrated into the runtime rather than a modelling breakthrough — with around thirty per cent improvement reported in image editing functions. The guidance on fine-tuning inverts the usual advice: adaptation matters most for the smallest models, because their capability budget is already spent and getting them to perform on your problem means spending some of it there. The two examples do the real work, since neither is a cheaper version of a cloud application.