The problem SAFe does not solve, because it solves the wrong one
SAFe is often mentioned in the same breath as Scrum. Its structural flaw, however, is a different one — and it shows very precisely where it leads to answer a coordination problem with even more coordination.
The previous article in this series argued that Scrum solved two different problems at once: coordination between people, and uncertainty about the real requirements. SAFe is frequently understood as "Scrum, just bigger" — as if you simply applied the same recipe to more teams. That misses the actual difference.
A coordination problem, answered with more coordination
SAFe attempts to scale coordination cost at the organisational level by introducing additional process layers: program increments, release trains, additional roles meant to mediate between individual teams. At first glance that looks consistent — if one team needs coordination, then ten teams need more of it.
The problem lies in what does not happen along the way: consistency checking across the entire body of requirements is not solved by those additional layers. It merely gains one more layer, which itself has to be coordinated. A data model that is supposed to stay consistent across ten teams does not become more consistent through an additional PI planning session — all that is introduced is one more meeting in which somebody is supposed to spot the inconsistencies by hand before they turn into problems.
SAFe therefore answers a coordination problem with more coordination, instead of structurally reducing the need for coordination. In that sense it is almost the counter-example to what AI-supported development is making possible right now.
Why this is becoming visible now
For as long as coordination between people was unavoidable, SAFe's answer was not unreasonable — more process for more complexity is a natural reaction when no better alternative is available. The problem was never that SAFe was ill-intentioned. The problem was that it was the only available answer to a scaling problem for which there had been no structural solution.
When a growing share of implementation coordination moves to AI agents, that starting position changes fundamentally. Not because AI agents "coordinate better" than people, but because the quantity that has to be coordinated becomes smaller in the first place. A conflict between two AI-generated proposals can be checked mechanically against a shared body of requirements that is kept consistent — with no PI planning, no additional role, no further meeting in which people try to hold in their heads something that is really too large for a single head.
The actual lesson from SAFe
SAFe is a good case study in what happens when you scale a problem at the wrong point. More process overhead does not solve a consistency problem; it merely distributes responsibility for it across more people, who then have to coordinate with one another in turn. The real solution does not lie in more coordination but in a mechanism that makes consistency directly checkable — regardless of how many teams or how many features are working on it at the same time.
The next article is about exactly that mechanism: three independent axes along which every development method can be measured — and why one of them is becoming technically solvable for the first time through AI, while another stays unchanged no matter how much process you pile on top.