I was intrigued by Casey's comments on Conway's Law, and reading the original paper, Conway was mapping the relationship between information flow among designers and system structure. The paper argues that interfaces (APIs, documentation, etc.) form where communication has to cross boundaries between humans or teams, so taken as a whole, interfaces in a program mirror the communication graph among the programmers, and as a consequence, products reflect the org chart.
When I try to apply the same model to agents, I don't think it maps cleanly even if the underlying analysis is sound, because agents don't operate the same way humans do. Agents communicate at a much higher speed than humans, but have no project-specific shared prior with the user, because while human memory accumulates across time, an agent's context window is a fixed space with a token budget that resets each session. Once training is completed, agents can only learn about their environment through tool calls and what's loaded into the context window.
Breaking communication into speed of transfer and shared priors (see my previous post on communication tax), organisations rationally optimise themselves and end up bottlenecked by their interfaces, which is why Conway's org-chart mirror is the visible shape of that constraint. More humans or agents on the same team, even with shared priors and maximum bandwidth, does not scale as well as parallel teams, because the cognitive budget kicks in and, if the team is not organised towards a common goal, the added members hurt more than they help. Pollution of other priors or contradictory communication diminishes the effective communication bandwidth.
With agents, the same effect shows up as context pollution, which is especially apparent in multi-agent systems and which is why ultra or multi-agent mode is often worse than dedicated single agents on xhigh. In human teams, we often hear the term "to avoid working in silos" when silos are a product of optimising for efficiency.
"Interfaces" are dynamic bounded channels, not static bridges, and their capacity limits how effective the surrounding system can be. We more or less have settled on an optimised human-human interface through open systems and closed teams after decades of experimentation. Agent-agent or even human-agent integration remains such an open question that claiming or offering an "AI teammate" is essentially snake oil, as anyone realises the moment they try to use it.
Applying the extension of Conway's Law I detail in this paper, human-agent interaction is bottlenecked on the speed at which the human reads what the agent produces, and subsequently on the decisions that need to be made as a result of understanding the output. While there have been people advocating that we don't need to read the code, as Joel Spolsky would put it, the chat is a leaky abstraction of the code, which is a leaky abstraction of the domain and problem you are trying to solve. As errors accumulate, you will at some point need to read the code from scratch to understand how to fix it, so the question becomes whether you read the code incrementally and take advantage of the human memory mechanism of accumulation over time, or pretend that you are an AI agent that can load the entire context in your head and debug from there.
The rate of human reading is more or less constant, and the latency of text generation is trending toward zero. The only meaningful thing to optimise is the time the human takes to process what they've read and decide. As humans we are bottlenecked by the quality of the prose (thus the general anger over reading Claudish) and the expressiveness of the language it is written in.
There is much discussion about needing a programming language for agents, and text generation speed keeps rising while tool latency trends down. But the choice of language matters more for the humans reading the code than for the agents, since the code is the documentation interface between them. Code is read more than it is written, so code should reduce the communication tax, adaptive to the human where possible.
The usual answer is cyclomatic complexity, but in practice increasing the number of functions actually increases the burden on humans who have to navigate the code through tool use at rates much slower than agents. Consider Linus Torvalds' example of good taste in code. More code (to explain edge cases) is worse than fewer edge cases (and thus less code). Designing the solution such that you don't even need to take a decision on the edge cases at all reduces the complexity and time needed for humans to decide, and thus improves the efficiency of communication.
While Linus is an expert and can do it in C, most of us aren't Linus and would very much rather not write C in our day-to-day job. What other languages offer this reduced complexity in solution by default then? I would like to think Clojure is one, through immutable data eliminating classes of bugs at once, though encapsulation in functional programming leaves a lot to be desired. I remain unconvinced that Rust is the solution, given how it leaks memory management internals to code, which increases the number of decisions you have to make.
For me, it is not enough to have a sane default. Such a language has to present the edge cases explicitly and allow me to prune them visually in some way, like how we can have AI present the program flow as 2D ASCII diagrams instead of reading text linearly, which would increase the bandwidth of communication by one dimension.
If this analysis holds (and assuming we still want humans involved), we may see a new renaissance for programming languages, designed for humans.
canonical : https://danieltan.weblog.lol/2026/09/conways-law-and-programming-languages
Top comments (0)