The forecast this session opens with is over 1.3 billion AI agents in production by 2028, offered with the suggestion that it may be conservative (3:18).
Treat it as a statement about connection counts rather than a market prediction and it becomes useful. Whatever the real number is, the claim being made is that the thing on the other end of a database connection is increasingly not a person, not an application deployed by a person, but something that decided moments ago that it needed storage.
Everything else in the session follows from taking that seriously.
Why provisioning time becomes the product
The comparison offered is deliberately unflattering to relational databases: a table in a key-value store is available in seconds, roughly the time it takes to create a basic desktop database, while a production relational database with the full set of capabilities takes considerably longer (18:41).
For a human developer that difference is an inconvenience absorbed once per project. For an agent constructing an application in a single session, it is the difference between a step and a blocker. The demonstration makes the point concretely — an application described in natural language, scaffolded automatically, and very quickly determining that it needs to store something (15:33).
The agent cannot proceed to the next step until storage exists. Provisioning latency, which for two decades has been a background annoyance, becomes a hard dependency in the critical path of an automated build.
The maintenance numbers point the same way
The operational claims follow the same logic. Patches applied in seconds, and switchover during a blue-green deployment in under thirty seconds (45:44).
Read against the agent framing, these are not incremental improvements to a maintenance window. A maintenance window presupposes a human operator who scheduled it, notified the dependent teams and is watching. Systems where an agent provisioned the database and no person is tracking its lifecycle need maintenance that does not require anyone to be told.
The comparison the industry usually makes here is to serverless computing, and it is apt in one way and misleading in another. Serverless removed the need to think about capacity. What is described here removes the need to think about the operation being available at all — which is a different property and a harder one, because the state persists.
The migration that grounds the abstraction
The most substantial number in the session comes from a customer: eight engineers moving four and a half petabytes from one managed relational service to another in under 120 days (37:53), for a platform serving 27 million funded accounts (34:43).
That figure deserves scrutiny in a way conference numbers usually do not, because it is doing real argumentative work. Eight engineers and four months for four and a half petabytes is a small team by the standards of migrations at that scale, and the claim is credible mainly because the source and destination are closely related systems with tooling built for exactly this path.
Which is the honest caveat. The migration was fast because it was between two products of the same family. It is evidence about managed-service tooling, not about database migration in general — and reading it as the latter would set expectations no team could meet.
The regulatory detail alongside it is more transferable: retaining and accessing customer data within 24 hours of any transaction, described as saving millions in potential penalties (40:40). That is the kind of requirement that determines architecture far more often than performance does, and it rarely appears in a database session at all.
The optimiser change worth understanding
Buried at the end is a genuine engineering improvement. An index that earlier versions could not use for a particular query shape — forcing a full table scan — becomes usable if the optimiser treats it as a collection of smaller indexes, one per distinct value (54:05).
This is the sort of change that has more real-world effect than most announced features, because it silently fixes queries that teams had already worked around. It is also a reminder of where the actual difficulty sits: not in provisioning speed or patch windows, but in whether the query planner makes a good decision on data it has not seen before.
An agent writing its own queries will not have hand-tuned any of them. The quality of the optimiser is what stands between 1.3 billion automated connections and 1.3 billion table scans.
关键数据
演讲章节
关键要点
- 01
The session opens on a prediction of over 1.3 billion agents in production by 2028, described as possibly conservative. 3:18
- 02
A key-value table appears in seconds while a full production relational database takes far longer — a gap that blocks an agent mid-build rather than merely annoying a developer. 18:41
- 03
Patching in seconds and blue-green switchover under thirty seconds matter because unattended databases have no one to schedule a maintenance window. 45:44
- 04
Eight engineers migrated four and a half petabytes in under 120 days, a number credible mainly because both ends were closely related products. 37:53
- 05
An optimiser change treating one index as a set of per-value indexes silently fixes queries teams had already worked around. 54:05
提及的实体
相关演讲
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 hardest problem in this session has nothing to do with machine learning: you cannot reliably tell who owns a machine. Unlike vehicles, which carry an identification number and go through state registration, heavy equipment has no equivalent — someone can simply assert ownership. Everything the connected-product strategy promises depends on solving that, because every step after fault detection requires knowing who to contact. The estate explains why it was not solved earlier: millions of machines with 1.5 million connected, and around 160 dealers who are independent businesses with their own systems, holding the service history that makes telemetry meaningful. The prior state is described directly — multiple accumulated platforms, and dealers confused because the same question returned different answers, which destroys trust in all of them including the correct ones.