AI doesn't change Conway's law

Every few years the software industry discovers a technology that is going to change everything, and the script reads much the same each time. Cloud computing was going to do away with infrastructure constraints. Microservices were going to dissolve the monolith and the bottlenecks that came bundled with it. DevOps was going to flatten the wall between the people who wrote the software and the people who had to keep it running at three in the morning. Now it is AI's turn at the front of the queue.

The specifics differ, but the promise underneath rarely does: software will be built faster, teams will get more productive, and organisations will deliver more with fewer constraints. Some of that is even true. The mistake, the one that survives every cycle entirely intact, is assuming any of it changes the underlying dynamics of how organisations actually build software.

It doesn't. Conway's Law remains, as ever, undefeated.

The law that keeps surviving

Back in 1968, in a paper titled "How Do Committees Invent?", Melvin Conway made an observation that has aged rather better than most things written about software:

Organisations design systems that mirror their own communication structures.

Nearly sixty years on, it is still one of the most reliable predictors of what a system will look like, often before you have read a single line of its code. Teams with strong boundaries build systems with strong boundaries. Organisations whose communication is fragmented produce platforms that are fragmented in precisely the same places. Groups that cannot agree on a decision turn out, with admirable consistency, to be incapable of producing anything coherent.

The technology changes every few years. The organisational behaviour underneath it almost never does. I've made a related argument about technical debt: the shape of a system is usually a faithful record of the organisation that produced it, incentives and org chart and all.

AI accelerates implementation, not alignment

The most visible thing AI does is lower the cost of implementation. Engineers can generate boilerplate, draft tests, explore a few approaches before committing to one, find their way around an unfamiliar codebase, write the documentation nobody ever volunteers for, and stand up a prototype in an afternoon. These are real gains, and I'm not interested in pretending otherwise.

What none of it touches is organisational alignment. AI cannot tell you which team owns a capability, what problem you are actually solving, which architectural direction to back, how to weigh two priorities pulling in opposite directions, or which trade-offs you are willing to live with. Those decisions remain stubbornly, inconveniently human. And in any organisation past a certain size, they are where the friction has always lived.

The bottleneck was never typing

For most of the history of this profession, organisations have behaved as though writing the code was the constraint. It rarely was. The large delays almost always originate somewhere else entirely: unclear ownership, conflicting priorities, an architectural disagreement nobody will arbitrate, a tangle of dependencies, an approval chain with too many links in it, risk controls, and the slow business of getting a roomful of stakeholders to agree on anything.

Projects very seldom miss a deadline because the engineers physically could not type fast enough. They miss deadlines because the organisation could not decide what to build. AI improves execution. It does precisely nothing for indecision, and indecision was always the expensive part. I've written before about why most engineering metrics fail for exactly this reason: the things that most shape delivery are usually the ones that never make it onto the dashboard.

Faster code just exposes the next bottleneck

Here is the part that tends to surprise people. Making implementation faster doesn't make an organisation's problems disappear - it makes them visible.

Suppose a team shaves thirty percent off its development effort with AI tooling. Do releases turn up thirty percent sooner? Almost never. The time doesn't vanish; it relocates. It moves into the architecture review, the security assessment, the testing, the change-approval process, the cross-team coordination that has to happen before anything ships. The engineering organisation hasn't become slower. The constraint has simply moved out from behind the implementation effort that used to hide it, into plain sight. It was, as I argued about DORA metrics, a property of the delivery system all along, and not of the people typing inside it.

This is the bit that should reframe how you think about the whole thing. AI doesn't remove the bottleneck. It relocates it - usually somewhere a good deal harder to fix than a slow keyboard.

Team topology still decides the game

Plenty of organisations are pouring money into AI capability while keeping the exact structures that made delivery painful in the first place. The symptoms are familiar to anyone who has worked somewhere large: several teams owning overlapping slices of the same domain, shared services with nobody clearly accountable, a platform team that functions mainly as an approval gate, dependencies running in every direction, and decision-making concentrated in two or three people who are permanently in meetings.

No quantity of AI-generated code fixes any of that. If shipping a feature requires six teams to agree, it will still require six teams to agree once each of them has a model on the desk. The code might arrive sooner. The coordination cost is sitting exactly where you left it.

AI might actually strengthen Conway's Law

There is a decent argument that AI makes Conway's Law more visible, not less. As implementation gets cheaper, the things it used to obscure (architecture, ownership, communication) become the dominant cost. The quality of a system starts to depend even more heavily on clear boundaries, shared standards and consistent decision-making, which is to say, on exactly the factors Conway was pointing at in the first place.

When generating code is hard, technical execution soaks up most of the attention in the room. When generating code becomes easy, organisational design is the thing left standing, with nowhere to hide. AI buys you tempo. It does not buy you a better position, and tempo spent from a bad position only gets you to the loss a little quicker.

The organisations that benefit most

The companies that get the most out of AI are not, as it happens, the ones with the most advanced models. They tend to be the ones that already had clear ownership boundaries, a strong engineering platform, governance that helps rather than obstructs, consistent architectural principles, and the ability to reach a decision without three weeks of meetings. Those organisations already convert decisions into software efficiently, so cheaper execution is pure upside.

The ones still struggling with alignment tend to discover something rather deflating: faster implementation does very little for overall delivery when the hold-up was never implementation. It is the same pattern I described in what AI adoption actually looks like across a few hundred engineers, and the same reason AI keeps sliding into the workflow as plumbing rather than rewriting the org chart around it. The tools commoditise. The operational discipline doesn't.

Technology changes. Coordination remains.

The industry has a long habit of reaching for a technical fix to an organisational problem. Now and then it works. Far more often it doesn't, and AI will be no exception. Engineers will spend less time on boilerplate, codebases will grow faster, and the cost of implementation will keep falling. None of that changes the basic fact that software is built by groups of people making decisions together, and that reality has outlasted every technology shift of the last half-century. There is very little reason to think this is the one that breaks the streak.

The question worth asking

So the question engineering leaders keep asking, "how do we get AI into the hands of our engineers", is not the interesting one. The interesting one is this:

What organisational constraints become visible once implementation stops being the bottleneck?

Because that is where the next delay is going to come from, and it was almost certainly there all along, sitting comfortably behind the work that AI has just made cheap. AI can accelerate how quickly you build software. It cannot accelerate organisational clarity, and organisational clarity remains one of the strongest predictors of engineering effectiveness anyone has ever found. Which is exactly why Conway's Law keeps quietly surviving every revolution that turns up promising to replace it.

Further reading

• Conway's Law (Melvin Conway's site): a short, canonical statement of the law straight from the source.
• Conway's Law (Martin Fowler): the clearest modern explainer, covering the three ways organisations respond to the law.
• Inverse Conway Maneuver (Thoughtworks Technology Radar): the canonical writeup on reshaping teams to get the architecture you actually want.