The platform team's job
A platform team’s product is leverage. It builds the shared substrate — libraries, internal services, frameworks, the paved road every other team walks — so that work done once is inherited by everyone. This is the bargain that justifies a platform team’s existence: centralize the hard thing, and a hundred downstream engineers stop solving it badly in a hundred different ways. The leverage is the point.
For a long time, the platform team’s discipline was held in check by a single fact: building shared substrate was expensive. A new abstraction took weeks to design, longer to harden, and the cost was paid up front by the platform team itself before any consumer saw it. That expense was a forcing function. It kept the platform surface small, because nobody could afford to build substrate carelessly. It made the team deliberate, because deliberation was cheaper than the rework. The economics did the team’s restraint for it.
AI changed the cost of building substrate without changing the cost of living with it. The build got cheap; the commitment did not. And the platform team is the one seat in the organization where that asymmetry does not stay local — it compounds across every consumer team at once, because compounding across every consumer is the whole job. The leverage that justifies the platform team is symmetric, and AI tipped the symmetry toward the side the team used to be able to ignore.
Three things about the platform team’s job changed shape. None of them announced itself. All of them are visible only at the scale where the platform team operates — the scale at which a single decision is inherited by everyone.
1. Abstraction inflation
The cost of a shared abstraction was never really the cost of building it. The build was the visible part, the part with a ticket and an estimate. The real cost was the commitment: once an abstraction ships and consumers adopt it, every one of them now depends on it, must migrate when it changes, and inherits whatever assumptions were baked into its shape. The build cost was paid once, by the platform team. The commitment cost is paid continuously, by everyone, for as long as the abstraction lives.
Pre-AI, the build cost and the commitment cost moved together, roughly. Expensive-to-build abstractions were the ones with deep commitments, and the expense of building them functioned as a crude but effective filter — a team would not sink three weeks into a shared library it was not fairly sure it wanted everyone to depend on. The expense was an accidental governor on the commitment. You could not cheaply create something expensive to live with.
That coupling broke. An abstraction that would have taken three weeks to build now takes an afternoon, and the platform team, like every other team, feels the productivity. So it ships more — more wrappers, more internal tools, more helpful little libraries that smooth over some rough edge. Each one is cheap to produce and feels like service. And each one, the moment a consumer adopts it, carries the same commitment cost it always did: a dependency to track, a migration to eventually force, a set of assumptions now load-bearing in someone else’s code.
Call this abstraction inflation: the platform surface area growing past what the team can actually steward, because the gate that used to limit it — the expense of building — is gone, and no replacement gate was installed. The team is producing substrate faster than it can maintain the commitments that substrate creates. The inflation is invisible at first because each individual abstraction is small and plausibly useful. It becomes visible later, as a platform team that cannot deprecate anything, cannot migrate consumers off the three half-redundant versions of the same utility, and spends its time servicing the commitments of substrate it shipped because shipping was cheap.
The remedy is to install deliberately the gate that the expense used to provide for free. The question that matters before shipping a shared abstraction is no longer can we build this — the answer is now always yes, cheaply — but can we steward this for as long as consumers will depend on it. The build cost stopped being a useful signal of the commitment, so the commitment has to be estimated on its own terms, against a stewardship budget the team actually holds. Teams that keep treating shipped abstractions as output, measured by how much substrate they produce, inflate their own surface past the point of maintainability. Teams that treat the abstraction surface as a budget to be spent rather than a quantity to be grown stay able to support what they shipped.
2. The shattered incident
A confident-wrongness bug in one team’s application code costs that team. The blast radius is the team’s own surface — bad, sometimes expensive, but bounded by the reach of the code it lives in. This is the normal case, and the organization’s incident response is tuned for it: a failure surfaces somewhere, an on-call traces it to its cause, the cause lives near the symptom.
The same class of bug in a shared platform abstraction does not behave that way. A subtle invariant violation in a widely-adopted library, a plausible-looking helper that handles an edge case wrong, a wrapper whose retry logic is confidently incorrect — these ship once and are inherited everywhere. And because they are inherited everywhere, they surface everywhere, in shapes that do not look related. One consumer team sees intermittent data corruption. Another sees a latency spike under a specific load. A third sees a failure that only reproduces in their staging environment. Each team investigates its own symptom, in its own context, against its own recent changes. None of them is looking at the platform, because from inside any single consumer team, the platform is not the thing that changed — the team’s own code is.
Call this the shattered incident: a single platform-level cause that fragments into many unrelated-looking incidents across consumer teams, so distributed that no individual team holds enough of the picture to trace it back to the shared origin. The information needed to diagnose it is spread across organizational boundaries that the diagnosis would have to cross, and the teams best positioned to notice the pattern — the platform team — are the ones not on any of the consumer pagers. The bug that would have been a single incident with a single author in a hand-built world is now a scatter of incidents with no obvious common cause, and the commonality is precisely the thing each consumer team has the least visibility into.
The platform layer was always the highest-leverage place for a bug to hide, because leverage is symmetric: substrate that benefits everyone when it is right harms everyone when it is wrong. What changed is the rate. The kinds of failure AI tooling makes more common — plausible-but-wrong, locally fine and globally off, confidently incorrect against an intent the code never recorded — are exactly the kinds that survive a review of the platform code, because the platform code looks correct. The downside of leverage used to be rare enough to treat as exceptional. It is no longer rare enough for that, and the platform team is where the cost of the change concentrates.
The remedy is to instrument for the shape of the failure, not just its instances. Per-team alerting catches per-team symptoms; it structurally cannot see a shattered incident, because the symptom in each team looks like that team’s problem. What sees it is correlation across consumers — the platform team watching for the same anomaly appearing in several places at once, treating coincidence across teams as the signal it usually is. This is monitoring the platform team has to own, because it is the only party with a vantage over all the consumers at once. Teams that wait for a consumer to escalate a clear platform bug are waiting for a signal the shattered incident is designed not to produce.
3. The unread platform
A platform team’s most valuable feedback never came through a formal channel. It came from the informed consumer — the engineer on a downstream team who actually read the library, understood its contract, and therefore noticed when the contract was wrong, filed the sharp bug report, pushed back on the abstraction that did not fit, occasionally sent the fix. That engineer was the platform team’s eyes inside the consumer teams. The relationship was a loop: consumers who understood the platform made the platform better, and a platform under that kind of informed scrutiny stayed honest.
The loop depended on consumers reading the platform. They read it because they had to — to use an internal library, you went to its source or its docs, understood what it committed to, and integrated against that understanding. The reading was not optional, and the comprehension it forced was the thing that produced the informed consumer as a byproduct.
The reading became optional. A consumer engineer who needs to use the platform now asks a model how to use it, receives a plausible integration, and ships it — without ever having formed a model of what the platform actually guarantees. The integration often works, which is the trap: working code is not the same as understood contract. The consumer has produced usage that is plausible against the platform’s surface and may be wrong against its intent — calling an interface in a way that happens to function today but violates an assumption the platform team is holding, depending on a behavior that was incidental rather than promised. This passes the consumer’s review, because it works. It reaches the platform team, if it reaches them at all, as a support request that misunderstands the platform, not as the sharp bug report an informed consumer would have filed.
Call this the unread platform: the substrate is integrated against without being comprehended, and the platform team loses the informed-consumer signal that used to keep it honest while gaining a rising volume of plausible misuse it now has to account for. The team’s best source of correction quietly goes silent. Worse, the misuse becomes a constraint: once enough consumers depend on an incidental behavior they never knew was incidental, the platform team cannot change it without breaking them, and the platform calcifies around accidents nobody chose. The contract the team thought it was maintaining and the contract consumers are actually depending on drift apart, and the drift is invisible until a change the platform team considered safe breaks consumers in ways the team cannot explain.
The remedy is to rebuild the informed-consumer loop deliberately, because it no longer regenerates on its own. The comprehension that came free — because using the platform required reading it — now has to be manufactured, through contracts explicit enough that integrating against them surfaces the assumptions, through the platform team treating consumer misuse as a signal about the platform’s clarity rather than the consumer’s carelessness, through deliberately maintained relationships with the consumer teams that replace the informed individuals who used to emerge on their own. Teams that assume their consumers still understand the platform are maintaining a contract against an audience that is no longer reading it. Teams that assume comprehension has to be earned, now, by making the platform legible to a reader who arrives without having read it, keep the loop alive in a different form.
Closing
The platform team sits at the organization’s highest-leverage point, and leverage was always symmetric — the same property that lets one good decision benefit everyone lets one bad one harm everyone. For two decades the downside of that symmetry stayed manageable, held in check by costs that did the team’s discipline for it: substrate was expensive to build, so teams built it deliberately; consumers had to read the platform to use it, so the platform stayed under informed scrutiny; failures lived near their causes, so they could be traced. None of these was a practice the team consciously maintained. They were properties of the economics, and the team inherited their benefits for free.
AI removed the costs and left the leverage. Building substrate got cheap, so the surface inflates past what the team can steward. Using substrate stopped requiring comprehension, so the informed consumer disappears and misuse accumulates as constraint. And the failures the tooling makes more common are exactly the ones that hide best at the leverage point, scattering into incidents no single team can trace. The platform team’s job did not get easier in proportion to how much cheaper its building got. It got harder, in three directions at once, and the disciplines that used to be free now have to be built and defended on purpose.
The platform teams that notice this reinstall the gates the economics used to provide — a stewardship budget instead of a build estimate, cross-consumer correlation instead of per-team alerts, manufactured legibility instead of assumed comprehension. The ones that do not keep shipping cheap substrate to consumers who no longer read it, and find out at the scale platform teams find everything out: all at once, across every team that depended on them, in an incident that started as a decision that seemed too small to be worth the deliberation it no longer got.