By month three, that team was producing more on the AI-assisted work, faster, at higher quality. The dashboards were healthy. The rest of the work was slower. Two senior engineers had quietly checked out. A third had resigned. Priya was explaining to her CTO why a productivity win was producing the opposite signal on the ground.
It is the same shape PSL has described in delivery for years: a stretch of raised load, an apparent win on the measurable parts, and a delayed wave of absence and attrition that no one traces back to the cause. The trigger is new. The mechanism is the operating model.
There is a company-level version of this story, the one where AI adoption climbs and the business results stay flat. That is a separate piece. This one is about the layer beneath it: what the same pressure does to the people carrying it, and why the damage surfaces first as a problem of Capacity.
AI is not the cause of the failure. The structural design around it is. AI is a load amplifier. The signature insight · Sustainable Capacity
Why it lands on Capacity first
The Performance System reads delivery across three rings: Identity, Execution, Capacity. AI tests all three, but the failure surfaces first on Capacity. Working with AI is genuinely faster on the visible output, and the speed is the trap. The work behind it is a new shape: prompting, checking, correcting, deciding when to override. The shift now has a name, from doing the task to orchestrating the system that does it, and that supervision is heavier than the task it replaced, not lighter. The output dashboard moves. The capacity ledger does not.
So the expectation moves first. A person who now delivers in three hours what took six is not given three hours back. The new ceiling becomes the floor, and exploration, redesign and coordination are piled on top of the day job rather than in place of it.
Why the dashboards miss it
Most AI governance watches adoption: logins, prompts, feature uptake. Those measure whether people use the tool, not whether the system around them has changed. And the signal of AI-assisted work is everywhere now, down to which suggestions an engineer accepts and which survive review. The lesson is the one that matters: capturing the what is easy, and it is the wrong place to stop. A dropped output can be a skill gap, or fatigue, or a broken workflow. Only the context tells you which. Dashboards report the what. They are silent on the why, and the why is where Capacity fails.
"But the gains are real"
If the gains are real, is some turbulence not a fair price for a faster organisation? Inside one quarter, refused recovery looks like peak throughput. Across four, it rarely is. A strong first quarter, a depleted second, a brittle third and a rebuild fourth, with the knowledge of how AI was wired in walking out of the door, totals less than a team that holds a steady high. Designed capacity is not lost productivity. It is how the gain compounds instead of eroding.
The reframe
AI is not the cause of the failure. The design around it is. It amplifies output, accelerates change, and compresses the time to absorb each shift, none of it bad in itself, all of it needing a capacity design that was built rather than hoped for. The question is not whether to deploy AI. It is whether the operating model carrying it is built to absorb the new pace, or only to endure it.
Three questions worth asking. Does your AI governance include a structural view of capacity, beyond adoption metrics and vendor dashboards? Does the cadence let the team return to baseline between waves of change, or does each wave start higher than the last? Are the managers holding the agenda together given the time and authority it now takes, or absorbing it as load on an unchanged job?
The Performance Diagnostic is the fastest way to see whether your operating model is built to absorb AI-driven change or only to endure it. Around seven minutes, a read across Identity, Execution and Capacity.