AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The statistic that frames this session is about organisational structure rather than security: around 80 per cent of organisations are expected to have platform engineering teams going into 2026, up from about 45 per cent a couple of years earlier (2:35).
The speaker is right that the interesting part is not the level but the doubling. Something changed to make a function that half of organisations lacked into one that most of them have.
What platform teams are actually for
The problem described is recognisable: different teams solving the same problems separately, producing architectural inconsistency and redundancy (3:21).
That is not primarily wasteful because of duplicated effort. It is dangerous because each independent solution has its own security properties. Ten teams building their own approach to the same problem produce ten different answers to who can access what — and the organisation's actual security posture is whichever of those is weakest, not the average.
A platform team exists to make the good answer the easy one. Where that works, security stops depending on every team getting it right and starts depending on the paved path being correct.
Two customers, opposite directions
The most valuable content is that two financial services organisations went in diametrically opposite directions (42:31), and the session presents both without declaring a winner.
One standardised on the platform's own workload identity mechanism. The other took the opposite approach. Both are described as working.
That is more useful than a recommendation. It implies the choice is determined by context — existing estate, regulatory position, team structure — rather than by a general answer, and it means anyone copying either without examining why is copying the wrong half.
The honest note follows immediately: even having created standardised patterns, the result is still fragmented (48:14). Platform engineering reduces variance; it does not remove it, and a session claiming otherwise would be less credible.
Where automation earns its place
Two operational details are worth extracting.
Pre-configured protection rules curated by workload type, reducing setup from hours (21:03), and managed rules blocking traffic to known bad addresses and domains with a single action (25:59).
Neither is intellectually interesting, and both address the actual failure mode in web application protection: the rules are configurable, configuring them well requires expertise most teams lack, and the result is either a default configuration nobody tuned or a custom one somebody got wrong. Curated defaults by workload type are not a sophisticated answer. They are the correct one for the median team.
The scale argument, and its limit
The provider's own numbers — the aggregate attack surface across its domains, with attacks stopped daily (14:45) — are offered as evidence of what a large operator sees.
It is a real advantage and worth stating precisely. Threat intelligence has genuine returns to scale: an operator seeing attacks against everyone identifies patterns before they reach any individual customer.
What it does not transfer is configuration. The provider's scale tells you which addresses are hostile. It does not tell you which of your own services should be reachable from where, and that is where most breaches actually originate.
Key numbers
- 45% → 80%
- share of organisations with platform engineering teams, over roughly two years 2:44
Talk chapters
Key takeaways
- 01
Around eighty per cent of organisations are expected to have platform engineering teams going into 2026, up from roughly forty-five per cent two years earlier. 2:35
- 02
Teams solving the same problems separately produce inconsistency whose danger is that the organisation's posture is the weakest independent answer, not the average. 3:21
- 03
Two financial services organisations took diametrically opposite approaches to workload identity, and both are presented as working. 42:31
- 04
Even with standardised patterns in place, the result remains fragmented — platform engineering reduces variance rather than removing it. 48:14
- 05
Curated protection rules by workload type reduce setup from hours, which is the correct answer for the median team rather than a sophisticated one. 21:03
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 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.
The most useful sentence here concerns where reliability is achievable: for workflows calling well-structured interfaces and producing checkable code, the path is faster. The implication is that there is a slower path, and it is the one most enterprise pilots are on. The division separates work whose output can be checked mechanically from work where correctness is a judgement, and only the first admits an engineering approach to improvement. The best illustration is browser automation that examines what the customer would observe rather than the underlying markup, walking checkout and booking flows and identifying revenue leakage — a framing that defines success in the business's own terms and is verifiable in the good sense. The demonstration's fifteen to twenty tool calls are the honest measure of what agentic means: not one clever response but a chain of decisions each depending on the last.