AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The show of hands at the start tells you what this session is really about. Roughly half the room had generated cost reports in the standard format. Considerably fewer had analysed or visualised the data (5:28).
That gap is the entire problem. Producing the export is a configuration step. Turning it into something anyone acts on is the work, and most organisations stop after the configuration.
The column that makes the standard useful
The single most valuable thing described is unglamorous: with the invoice identifier column, you can match the reported figures exactly to the invoice you actually paid (20:24).
That sounds like a reconciliation detail and it is the difference between a report and an accountable number.
Cost data that nearly matches the bill is worse than useless in a financial conversation, because the first question anyone senior asks is why the number differs from the invoice, and the discussion never gets past it. Every cost reporting effort dies at this step, usually because the tooling aggregates in a way that cannot be tied back to a specific charge.
Having an identifier that links a line in the analysis to a line on the invoice ends that argument. It is the least exciting feature in the specification and the one that determines whether the rest gets used.
What the work actually looks like
The session is honest about the remainder, which is data preparation rather than analysis.
Null values must be replaced with zeros or the calculations fail (18:34). A pattern-matching approach to extracting tag values captured more than a structured extraction did, and is described as more flexible (34:28). Calculations have to be duplicated so that costs can be viewed by application as well as by environment (38:11). Rows showing zero cost need filtering because they add nothing (39:07).
None of that is sophisticated and all of it is necessary, which is a fair description of financial operations work generally. The specification standardises the shape of the data. It does not standardise the quality of what organisations put into the tag fields, and the tags are what make the numbers meaningful to anyone outside the finance team.
Where the real difficulty sits
The tag extraction detail is more revealing than it appears. Needing a pattern-matching approach because structured extraction missed values means the tags are not consistently formatted — which is the actual state of every large estate.
Standardising the report format solves the problem of comparing across providers. It does not solve the problem of teams tagging resources differently, inconsistently, or not at all, and that inconsistency is why cost data cannot be attributed to owners.
The consolidated view built from multiple sources (15:50) makes the same point. Even with a common specification, assembling a cross-provider picture required pulling from separate toolkits and reference implementations. The standard reduced the translation work; it did not eliminate it.
Who this is for
The second show of hands is the informative one: a substantial part of the room had job titles with no connection to financial operations (5:28 onward).
That is the honest audience for this material. Cost analysis is increasingly done by engineers who own a service and are asked what it costs, not by a dedicated function. The consequence is that this work has to be doable by someone for whom it is not the main job — which raises the bar on tooling considerably.
Measured against that standard, the session is a fair account of the state of things. The format standardisation is real progress. The invoice identifier makes the output defensible. And there remain several hours of preparation between the export and anything a person would put in front of a budget holder.
Talk chapters
Key takeaways
- 01
About half the room had produced reports in the standard format and far fewer had analysed them, which is the gap the session exists to close. 5:28
- 02
The invoice identifier column lets reported figures reconcile exactly to the bill, which is what makes the number defensible. 20:24
- 03
Pattern matching captured more tag values than structured extraction did, which reveals how inconsistently tags are actually written. 34:28
- 04
Calculations must be duplicated to view cost by application as well as environment, which is representative of the manual work involved. 38:11
- 05
A cross-provider view still required assembling material from separate toolkits, so the standard reduced translation work rather than removing it. 15:50
Entities mentioned
Organizations
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.