2 posts tagged with "Architecture"

In the previous post, we mapped the core laws governing engineering teams: Conway, Brooks, Parkinson, Dunbar, Goodhart, and Ringelmann. Each one describes a force that operates on communication structures, coordination overhead, and cognitive limits.

Now introduce AI agents — systems that write code, execute tasks, and produce artefacts autonomously, at a pace no human engineer matches. Do the laws still hold?

Yes. But they don't hold in the same places.

The way you build teams is the way you build software. Not as a metaphor — as an empirical, observable, repeatable outcome. The laws governing how teams form, communicate, and decompose work have been documented since the sixties. They don't care about your best intentions. They operate whether you acknowledge them or not.

Here's the punchline up front: Conway explains where the architecture will fragment. Dunbar explains when. Brooks explains why the obvious fix makes things worse. Parkinson explains why the problem stays hidden. Goodhart explains why your metrics won't save you. And Ringelmann explains why even the people you already have contribute less as you add more. Taken together, they form a coupled system with predictable failure modes — and predictable design levers.

A note on terminology: none of these are laws in the physics sense. They're sociological observations and empirical regularities — patterns that have held up across enough organisations, over enough decades, to be treated as defaults rather than suggestions. They can be worked with, designed around, and occasionally overridden. But they can't be ignored.

This post maps the key laws, shows how they interconnect, and draws out the strategies that follow when you take all of them seriously at once.