The statistic this session opens on is that over 74 per cent of companies surveyed are not set up to succeed at their data and AI initiatives (1:48).
Vendor surveys deserve scepticism, and the diagnosis that follows is more interesting than the number. The obstacles are not model quality or data volume. They are new and complex tool sets that customers have to stitch together manually, which makes the work slower and more expensive rather than more agile (2:14).
That is a claim about integration cost, and it means the product answer has to be integration rather than capability — which the session says explicitly: the investment went into how services work together rather than into more services (3:39).
What "working together" means in practice
The most concrete demonstration of the principle is small. When a query runs in one part of the environment, the result is automatically stored in a variable available to the code that follows, without any additional step (36:26).
This is not glamorous and it removes a real tax. The alternative — exporting, re-importing, writing the plumbing to move a result between the query layer and the analysis layer — is work that produces nothing and that every analyst does dozens of times a day.
The language argument is the same idea generalised. Supporting both a query language and a general-purpose one is not new and nobody expects credit for it; the actual difficulty is moving between them as a task demands, using whichever fits the step you are on (33:43).
Anyone who has done analysis knows the shape of that friction. The natural expression of a filter is one language, the natural expression of a transformation is another, and the cost of the boundary is paid many times per session.
Why the setup page matters more than it looks
The simplification highlighted is a single starting page with one substantive decision: choose the permissions role (29:10).
That is the correct thing to have made hard to get wrong, because it is the decision that determines what a user can see and do, and it is the one most often deferred and then never revisited. Making it the only choice on the page forces it to be considered.
It also sets up the exploration workflow. The first action shown is checking what data the current identity can actually reach (40:33), which is the right first question and one that most environments make surprisingly difficult to answer.
The demo that fails, and keeps going
The most credible sequence is one where the analysis does not work.
A hypothesis is formed from a column noticed while exploring — that customer satisfaction relates to long-term value (43:43) — pursued, and abandoned when it does not hold, with the analyst turning instead to a broader search for factors that do affect the outcome (46:55).
Demonstrations almost never show this, and it is the honest depiction of what the work is. Most hypotheses fail. A tool that only looks good when the first idea is correct is not describing analysis.
It also clarifies what the assistance is actually for. The value is not that the system found the answer — it did not, on the first attempt. The value is that the cost of testing an idea fell far enough that abandoning one stops being expensive. That changes how many ideas get tested, which is the mechanism by which any of this improves results.
The dependency underneath
The generation quality rests on metadata: because the system reads the data catalogue, it knows which columns and attributes exist and can be specific about them (37:48).
This is the load-bearing assumption of the entire session and it goes unexamined. An organisation with a well-maintained catalogue gets specific, accurate generated queries. An organisation without one gets plausible queries against columns that may not exist.
Which means the seventy-four per cent who are not set up for success are unlikely to be fixed by better tooling alone. The tooling works well on top of well-described data, and describing the data is the work that nobody has done — the same work, under a different name, that made the tool sprawl unmanageable in the first place.
关键数据
- 74%
- share of surveyed companies described as not set up to succeed at data and AI initiatives 1:48
演讲章节
关键要点
- 01
Over 74 per cent of surveyed companies are described as not set up to succeed, with manual tool integration named as the primary obstacle. 1:48
- 02
The stated investment went into making existing services work together rather than into adding more capabilities. 3:39
- 03
A query result is automatically available as a variable to the code that follows, removing plumbing that produces nothing. 36:26
- 04
The demonstration includes a hypothesis that fails and is abandoned, which is the honest depiction of analysis. 46:55
- 05
Generated queries are specific because the system reads the data catalogue, which makes catalogue quality the load-bearing dependency. 37:48
提及的实体
相关演讲
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.