AI Tooling and Conway’s Law

A working theory about why AI is moving our team boundaries fast and our org structures slow, what I think leaders should do about the gap, and where I’m probably wrong.

In 1967 Melvin Conway wrote down an observation that has outlasted nearly every methodology we have layered on top of it since. Organizations that design systems are constrained to produce designs that copy the communication structures of those organizations. We went from waterfall to agile, monoliths to microservices, the data center to the cloud, and it held every time. Systems keep looking like the teams that build them. Not because engineers lack imagination, but because information flows along the path of least resistance, and that path is social before it is technical.

I have spent a good chunk of the last year debating, mostly with myself and a few people patient enough to sit through it, about whether that still holds when a large share of the implementation is done by an AI agent instead of a person. If the thing writing the code is a model reading a context file, does the law that ties architecture to human communication still apply?

Before I go further I want to be upfront about what this is. This is my opinion, not a finding. A lot of what follows is gut feel formed from building this way and watching teams build this way, and I am sure some of it is wrong in the specifics. Only time and a lot of real teams are going to sort out which parts hold. I would rather be transparent and be corrected than hedge it into mush.

With that said, my honest belief is that Conway applies more now, not less. The law was never really about the engineer being human. It was about design decisions carrying the shape of the information that was available when they were made. Engineers build toward the context they have and away from the context they lack, and interface boundaries show up at the edges of shared understanding.

What is actually new is not a new participant in that conversation. The agent does not have opinions or relationships, it does not sit in standup, it is not a voice in the room. What is new is where the conversation gets written down. A big share of the architectural intent that used to live in people’s heads and get exchanged in meetings and code review now gets encoded in a file the agent reads before it works. The CLAUDE.md, the scope declaration, the constraint spec. That file is a new medium for an old conversation. The architecture still mirrors the communication. The communication just has a new place to live.

That is the whole shift and while it feels different it largely mirrors the way that we’ve been working, and it is why I think Conway’s law becomes even more important rather than less. The agent is a faithful conduit. It reproduces whatever shape is in the context you hand it. If your architectural intent is in that file, the system reflects your intent. If it is not, the system reflects whatever the agent found locally convenient, and you have shipped a structure nobody chose. Conway did not get a new node. It got a new substrate, and most of our implementation decisions now pass through it.

Fixed principles and blurry boundaries.

The core principles of organizational design are not being rewritten. The unit that is moving fast is the team, its size and its boundaries. The unit that is moving slow is everything larger, the org structures, the career ladders, the platform charters. We are getting a fast change at one layer sitting on top of a slow change at the layer beneath it, and most of the pain I see right now lives in that gap.

Team size is the most concrete piece, and also the place I am least sure of, so let me show my work and my doubt at the same time. The old communication-overhead math has not gone anywhere. With n people you have n(n-1)/2 channels between them. Eight people is twenty-eight channels, twelve is sixty-six, and that growth is the real reason strong teams have always clustered around five to nine people regardless of individual talent. AI does not change that math. What it changes is how much implementation surface a small team can carry, because an agent working in a well-scoped context is not a communication node. It does not sit in standup, does not become a blocker, does not add to the channel count. So my gut says a team of three to five can now hold the surface area that used to take seven to ten.

To be clear, that three to five is a hunch, not a derivation. The math argues for smaller, it does not tell me how much smaller. And the thing that would actually identify the number, the new overhead AI introduces in place of the old, the work of keeping context files accurate and current so the agents stay correct, I do not have a clean way to measure yet. It might land at two to three. It might depend entirely on the domain. And concentrating that much surface area on a small team, usually with one lead holding system coherence, is a real risk I do not have a good answer for. So take the number as a direction, not a target. The direction I am confident about is smaller and sharper. The exact size, time and real world practice will tell.

The other boundary worth naming is the one with no pre-AI equivalent, the scope of the context file itself. The temptation is to treat it as a security control, a way to keep the agent from touching things it should not. I think that framing misses the point. Access control asks what damage the agent can do. The real question is what coupling the agent will produce, and that is slower to show up and harder to see. The scope file is an architecture document that happens to be machine-readable, and it deserves the same care you would give an architecture decision, specifically those that are harder to unwind.

One positive outcome I did not expect. When an agent keeps reaching outside its assigned scope to finish a task, that is a signal the boundary is in the wrong place (although that creates overhead to observe the agents behavior and actions). The agent’s context dependencies are a readable hint about where your real seams are, something that used to take a human architectural review to surface. I find that genuinely useful, though I will admit I have seen it more as a pattern than actually measuring it.

Organization complexity and team topology.

Smaller and more focused teams with strong boundaries sounds great on paper, and is also an accelerant in practical application. The problem is that while individual teams can absorb these changes faster, the organization as a whole will move much slower. That shows up in the organizational machinery (career growth, promotions, title changes), org design, capabilities mapping and ownership, and it is not keeping pace, which is exactly where I think leaders should be looking.

One early example is how we grow senior engineers. The reason a senior can write a spec that produces correct output, or feel the integration risk in a design before it bites, is that they spent years building and breaking things that they then had to troubleshoot and learn from. That comes from exposure to consequences. When agents take over routine implementation, those learning surfaces shrink. More junior engineers can ship faster, which is positive but they may do it without building the mental model that lets them spec accurately or stay calm in an incident because they deeply understand the systems they are building within. The deficit is invisible for two or three years and then shows up as team members are looking to make the leap from a junior to a mid-level or senior role. Is the role the same? Are the responsibilities the same? The answer is likely no, or at least not quite but the judgement, the ability to diagnose and troubleshoot, the ability to mentor are all durable and you need reps to build those muscles. Team boundaries are changing rapidly but the machinery that feeds those teams runs on a multi-year clock.

This is a hard problem to solve because this is all so new. And this might not be something any single org can solve, there probably won’t be a single way to solve this either. If a small AI-augmented team is cheaper and faster, the rational move for any one company is to stop developing juniors and let someone else carry that cost, and that is how you get an industry-wide senior shortage that no individual leader chose. The mitigations I believe in at the org level, which I will get to, are necessary. I am not convinced they are sufficient on their own, and I think anyone claiming certainty here is guessing as much as I am.

Let’s move to another problem that could surface as individual teams scale faster than the organization as a whole. Platform teams, teams established to help empower engineering teams sitting closer to their end users. For example, if you let every team build its own AI infrastructure, you get Conway applied to the factories themselves. Each team’s practice gets shaped by its local context and ends up incompatible at the seams with the team next door. Cross-team learning gets hard, cost governance gets impossible, and you spend the next year untangling bespoke solutions that did not need to exist. Centralizing that infrastructure under a platform team is an efficient move. I don’t want to sell this too hard because a platform team that does not treat its tooling as a product becomes the new bottleneck, and teams will end up working around them. Centralizing is the right call in my view, but it has its own well-known (and well documented) way of going wrong.

Data contracts are in the same risky space. In a human-only shop, teams aligned on interfaces through meetings and the slow osmosis of having worked together long enough to understand each other’s systems. Accidental conversations and ad-hoc whiteboarding sessions have helped smooth out disagreements and alignment over the years. Agents however cannot negotiate an ambiguous interface in the hallway. They implement whatever the spec allows. So the contract has to carry the communication that used to happen around it, which means contracts start needing ownership and versioning and review like a production API. It also requires that the spec captures a level of specificity that specs written for humans don’t necessarily capture. It’s a different way of thinking, writing, and designing. That is a change in how the organization communicates, and communication habits do not turn on a dime.

What I’d ask of engineering leaders.

I am not writing this to tell anyone to slow down on the tooling. The productivity is real and I want it. My argument is narrower. The principle has not changed, so I would stop hunting for the new framework that supposedly replaces Conway, and spend that energy on the gap between fast-moving team boundaries and slow-moving org structure, because that is where I think the architectural debt and the talent debt are quietly building.

A few things I would do, holding them as strongly held guesses rather than answers.

Design the boundaries before you scale the tooling, not after. My read is that velocity from AI is conditional on the boundary work, and teams that skip it get a short burst of speed followed by drift that is costly to reverse. I could be overstating how fast that drift shows up. I do not think I am wrong about the direction.

Treat your scope files as architecture artifacts, owned by whoever owns system coherence and reviewed with real seriousness. Traditionally as soon as something is documented, that documented becomes outdated. As we continue to adopt more and better AI tooling, that documentation and ongoing maintenance of it becomes a core part of our roles. The neglect or mismanagement of that documentation can show up as an architectural risk.

Build the slow-layer mechanisms on purpose, because they will not emerge on their own. Make engineer development an explicit output alongside features. Run incidents as learning events (there are a ton of playbooks around mock incidents and chaos engineering). Put articulation requirements into architecture review so people have to explain why a system is shaped the way it is, not just what it does. And keep the collective-action problem above in mind, because none of this is guaranteed to be enough.

Measure against the right denominator. The question for an AI-augmented team is not how many points it shipped, it’s all about how much value is being delivered, and how durable that value is. It’s also about how much architectural discipline is being reinforced while shipping at that speed. A team that delivers volume while piling up technical debt is trading long term value for short term.

Conway’s prediction was never that good tooling would save you from your own structure. It was that your systems will tell the story of how you coordinate, including the parts you did not choose on purpose. I do not think AI changed that. I think it gave us a faster way to write the story and a new place for it to show up. Where I will happily be proven wrong is on the specifics, the exact team size, how fast the drift hits, whether the slow layer can be fixed at the org level at all. Those are the things real teams will settle over the next few years, not blog posts like this one. What I would put money on is the shape of some of the problems in front of us. The principle holds, the boundaries are moving faster than the structures around them, and the leaders who do well will be the ones who keep their org design moving closer to the speed of their tools while staying honest about which parts will never move that fast.