The interesting observation in this session is not about capability. It is about where a developer's attention now sits.
Engineers increasingly do not open an editor. They file a ticket, and the code comes back (6:02). Set it and forget it, as one participant puts it — which sounds like a small change in workflow and is actually a change in what the surrounding tools are for.
The chat window becomes an interruption channel
Follow the consequence and the interface design falls out of it.
If the agent works while you do something else, the conversation between you stops being where the work happens. It becomes the mechanism by which the agent asks for something it cannot get on its own — a decision, a credential, a piece of context it discovered it needs partway through (6:14). The chat window is no longer a workspace. It is an interrupt handler.
That reframing has consequences the industry has mostly not absorbed. Interfaces built for continuous conversation optimise for flow: keeping you engaged, keeping context visible, making the next turn easy. Interfaces built for interruption should optimise for the opposite — surfacing the question with enough context to answer it, and getting out of the way.
A related constraint arrives immediately. An agent that starts a long-running job cannot simply block until it finishes (12:01). Something has to be true about the runtime — that work can be suspended and resumed, that the agent can pursue something else meanwhile, that a user can intervene mid-flight. These are workflow-engine problems rather than model problems, and they are the ones that decide whether the ticket-based pattern actually works at scale.
Why the framing is hard to get right
One participant makes an observation that explains why so much tooling in this space disappoints.
Software development resists encapsulation as a single action (3:19). A developer reads, reasons about a system they did not build, decides what should exist, writes some of it, reviews more of it, negotiates with people about the rest. Tools that model the job as one action — generate this function, fix this bug — capture a slice and leave the surrounding activity untouched.
That is the honest explanation for why measured productivity gains keep landing below expectation. The automated slice was never the expensive part.
What is left
The session ends where these sessions increasingly end, and the phrasing is worth keeping because it resists the usual comfort.
The hard skill, one panellist says, is deciding what should be built — and it has always been the hard problem (29:01).
Read one way that is reassuring: the human keeps the interesting work. Read more carefully it is a warning, because deciding what to build is not a skill that survives on its own. It is downstream of having built things, seen them fail in contact with users, and developed the judgement that comes from that. If the intermediate work through which judgement was acquired is the part now being delegated, then the skill everyone agrees will matter most is the one whose training pipeline is being dismantled.
Nobody on this panel says that. It follows from what all of them do say.
演讲章节
关键要点
- 01
Engineers increasingly file a ticket rather than opening an editor, and receive the code back — a change in workflow that changes what surrounding tools are for. 6:02
- 02
When the agent works while you do something else, the chat window stops being a workspace and becomes the channel through which it asks for what it lacks. 6:14
- 03
An agent that starts a long-running job cannot block until it completes, which makes suspension and resumption a runtime requirement rather than a nicety. 12:01
- 04
Software development resists encapsulation as a single action, which is the honest explanation for why tools modelling it as one keep underdelivering. 3:19
- 05
Their closing position is that deciding what to build is the hard skill and always has been. 29:01
提及的实体
相关演讲
Four of Google's model, product and search leads on what changes once agents run for hours rather than seconds, and the most quotable argument comes from Dean: the constraint is moving out of the model and into the tools around it. By Amdahl's law, an agent spending half its time in tools built for human-speed interaction cannot gain more than a doubling however fast the model becomes — which reframes a great deal of current infrastructure work as latency debt. Their internal response is concrete: rewriting Python tooling into Go, framed as a fully specified translation task rather than an open prompt, produced order-of-magnitude speedups overnight. Reid supplies the counterweight from Search, where acceptable latency turns out to scale with how much work is being taken off the user rather than being a fixed budget. Woodward's detail is the quietest and perhaps the most telling: teams that have stopped writing product documents for humans and now write context files for models to act on directly.
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 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.
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 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 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.