14. When AI Enters the Team: Reordering Coordination

A team of ten. Since the start of the year, everyone has been on Cursor, a few have switched to Claude Code, a couple have built their own Skill libraries. Every individual feels it: writing is faster, boilerplate gets typed for you, getting up to speed in an unfamiliar module is lighter than it used to be. At the monthly retro, every person says they are roughly thirty percent more productive.

A quarter goes by. Look at delivery velocity. The number of completed tickets did go up versus last quarter, but nowhere near thirty percent — barely ten. Slipped projects are still slipping. Firefighting is no less frequent. Cross-team integration still requires meetings to align. Everyone says they are thirty percent faster individually; pile that up at the team level, and you are left with under ten percent. The other twenty percent — where did it go?

Each person's local loop really did get faster. You can see it from the desk. The problem sits one layer up. Individual speedup and team speedup are not in a simple additive relationship. Conflating them is the first illusion AI coding hands a team after it walks in the door.

14.1 A Different Kind of "Productive" for Each Person

Back to that ten-person team. Zoom in on how each engineer is actually using AI locally.

Engineer A is the fastest. Their prompts are a few words long, because they know the codebase cold and they know the agent will infer the rest by glancing at neighboring code. They almost never write full prompts; the prompts live in their head. Engineer B is more careful — has the agent draft a plan first, reads the plan, then lets it execute. The process is slower, but the resulting code is something they will merge directly. Engineer C took a different route — built up their own Skills for the handful of recurring task types in this project. New tasks come in, they load the matching Skill, and to a newcomer the agent's output looks like the engineer is using cheats. Engineer D prefers to let the agent write a long stretch in one go and then review it themselves; they trust their own eye over the agent's caution.

Each of those four styles makes the person using it faster. Stitch the four outputs together and odd things start to happen. A's code reads choppy — the agent was riding A's brain. A reads it fine; whoever picks it up next has to first guess what A was thinking. B's code is tidy but its style does not match A's; merged together they show a visible style seam. The Skill C uses is invisible to anyone else; a newcomer inheriting C's code is still working from the code, not from the Skill. D's long-form output frequently hides one or two issues even D didn't catch — they only surface in the next review.

Each of the four hits a real thirty-percent gain in their own workflow. That number is not made up. The moment the code merges to main, the moment the requirement crosses people, the moment a new hire joins — the stitching cost between them spikes.

To see the stitching cost clearly, look at the seams that already existed. A changes an interface B doesn't know about. C cannot read the test B wrote. D leaves traps that only show up in the next review. None of this is new. Twenty years ago, projects had the same friction. Pre-AI, each person filed two or three PRs a week; stitching events were sparse, the organization had room to absorb them. The friction was always there in absolute terms; it was hidden under the slow tempo of production.

What did AI actually change? One thing is density. Production-side rate is up by an order of magnitude. A can have the agent rework an interface three times in a day; B writes eight tests in a day; C accumulates five Skills in a week. The cost per stitching event has not changed. Multiply that cost by the new frequency and the cumulative alignment time scales by the same factor. A small conflict that used to happen once a week now happens three times a day. The friction that used to sit below the waterline is now exposed, because the production tempo has drained the water.

The other change is sharper. AI introduced categories of stitching cost that have no counterpart in the pre-AI world. The most cutting one is misalignment between agents' contexts. A's Cursor has loaded A's understanding of the project — A's Skills, A's accumulated prompts, A's personal memory. B's Cursor has loaded a different one. A and B sit down and align on the interface should change like this; their two agents do not align. Next time A asks an agent to touch the interface and B asks an agent to write a test, the two agents are working in two different world models. In the pre-AI era, when two engineers aligned, they aligned. Their cognition propagated directly between them. In the AI era, you have to align twice — once between humans, once between their two agents' contexts — and the second one is almost never done.

In the pre-AI era, the small scripts C accumulated either lived as personal shell aliases — private, no one expected to share them — or landed in the repo's scripts/ directory as shared utilities everybody could use. The Skills C accumulates today sit in a new in-between zone: they are extremely useful to C's agent, but because they encode C's judgment frame, they cannot just be handed to B. They are a new class of asset, with no counterpart in the old asset taxonomy: private, growing more useful per individual the more they accumulate, and producing diminishing marginal returns at the team level.

Every stitch costs alignment time. Every alignment eats into the thirty percent. By the time you reach the team layer, less than ten percent is left.

Each person being most productive in their most-comfortable style is locally optimal. It is not necessarily team-optimal. The sum of local optima does not equal the global optimum, and sometimes it is negative.

14.2 The Individual Loop and the Team Loop Are Not the Same Thing

Why does an individual flow smoothly with AI? Not the tool. Installing Cursor does not automatically make you faster. Setting up Claude Code does not automatically make you write quicker. What actually makes you fast is the picture in your head — you know what this codebase looks like, you know which files this edit will ripple into, you know that when the agent emits a certain style of code it has misread your intent. None of that lives in the prompt or the Skill. It is the implicit substrate underneath your collaboration with the agent.

That is the truth of individual productivity. An individual flows smoothly with AI on the strength of implicit cognition — familiarity with the codebase, a grip on intent, expectations about the agent, knowledge of how to clean up when something goes wrong. None of it has to be written down. You are the one using it; you do not need to explain it to yourself.

A team is different. The next person picks up your code, reads your spec, uses your Skill — they do not have your picture. They do not need your implicit cognition; they need an explicit contract they can pick up without you explaining it. Code has to be readable by someone else. Specs have to be editable by someone else. Skills have to be callable by someone else.

Between implicit cognition and explicit shared contract sits a gap of translation. The gap existed in the traditional era too — but the traditional era had something doing the translation for you: the act of writing the code itself. You wrote a piece of code slowly, weighing each step, and the weighing forced your implicit cognition to come out a bit at a time as explicit code, comments, names, and abstractions. By the time you were done, the code was no longer just for you; it had already become, in part, code for someone else to read. Slow writing was, accidentally, a translation pass.

The AI era skips that translation. You think clearly about what you want, throw a few words at the agent, it generates code. The code is enough for you, because your implicit cognition fills in what the agent left blank. To anyone else, the same code is bare. It has elided the picture in your head — the picture that, in the old era, would have slowly settled into the code through the writing process.

This is the same arc as Chapter 11's spec-driven discussion. Chapter 11 was about moving constraints out of the chat window into the repo, depositing the things you keep telling the agent into specs the project can read. This chapter pushes the same move to team scale. Translating individual implicit experience with AI into shared explicit contracts is the same act, at a larger radius. An individual using AI smoothly can skip writing specs, skip maintaining Skills, skip leaving notes — their head holds it all. A team turning AI into a real productivity gain cannot skip it; there is no central brain in the team to fill in the gaps between individuals.

A shared contract takes a few concrete forms inside a team. The shallowest layer is project-level AGENTS.md and coding conventions, answering what style should the agent write code in, in this project. One layer in: shared Skill libraries and prompt templates, answering for the recurring task types, what stable posture do we use. The deepest layer: evaluation sets and acceptance tests, answering what counts as the work being done. Together those three form a team's explicit substrate. Each layer is the translation of one person's implicit cognition into something the rest of the team can read, edit, and use.

Skip the translation and a very specific phenomenon shows up. The person on the team using AI best becomes the bottleneck. Because they are personally thirty percent more productive, everyone leans on them — they get pulled into key modules, pulled into helping others tune their agents, pulled into explaining how their Skill works. Their implicit cognition is not translated into a shared contract, so they have to be physically present. They have become a bridge that only stands while they are standing on it. The more competent they are, the more critical the bridge, the more the team's pace gets locked to one person's pace.

That is the substantive difference between individual productivity and team productivity. A high-output individual who does not open outward is not, to the team, an asset. They are a dependency.

14.3 Conway's Law Is No Longer a Long-Range Rule. It Is the Bottleneck of the Day.

Conway's Law was stated in 1968: the structure of a system reflects the communication structure of the organization that built it. For five-plus decades that has been a structural long-range rule in traditional software engineering. The way your organization is split, who reports to whom, eventually shows up in the architecture you ship. Microservice architectures often appear in companies that split by business line; large monoliths often appear in functional organizations. All true — and all measured on long horizons. An org reorganization shows up in the architecture, but the time between cause and effect is usually measured in quarters.

In the AI era the law has changed flavor. It is not invalidated; it is amplified, but the time constant has compressed from years down to weeks. Conway's Law has gone from being a structural long-range rule to being the bottleneck of the day.

To see this, do a rough calculation. In the traditional era, an engineer takes most of a day to ship a PR; ten people in a week ship maybe a few dozen PRs; the coordination among them takes maybe twenty to thirty percent of total delivery time, leaving seventy or eighty for actual coding. AI compresses production-side cost down to minutes per PR; ten people in a week can ship hundreds. Coordination cost has not moved. A meeting is still thirty minutes. A cross-team alignment still has to be scheduled. A merge conflict still has to be untangled by humans. Production cost has dropped an order of magnitude; communication cost is standing still. Communication's share of total delivery time has flipped to dominant.

In many teams it is already visible: every individual is fast, but the requirement is still slow at the team layer. The agent writes blazing fast, and PRs pile up in the review queue like a parking lot. There are more parallel workstreams than can be tracked, and the team spends its days coordinating instead of coding.

That points at a counter-intuitive judgment: for the first time, the gain from optimizing organization design has overtaken the gain from optimizing technology choices. In the traditional era, technology-choice debates were loud — switch the language, switch the framework, switch the IDE — and these choices moved individual output by a few percent. In the AI era, switching to a better model can lift individual output further, but team-level output may not move at all, because the bottleneck has long since left the production side. Reverse it: get the org structure right, push communication cost back to a reasonable level, and team output can double directly. The dividend from tuning the organization vastly exceeds the dividend from tuning the tools. That kind of statement barely existed in traditional vocabulary. It is what the collapse of production-side cost has finally exposed.

Communication cost also depends on team size. Draw the team as a graph, each person a node, each pair-alignment an edge. The number of edges grows quadratically with people: three people, three edges; ten people, forty-five; thirty people, four-hundred-plus. That has been in software engineering textbooks for decades. In the traditional era, production cost was high enough that the coordination inefficiency of a large team got covered by it. AI brought production cost down. Communication cost is now naked, and the coordination loss inside large teams is sharply visible. The optimal organizational form converges to small, autonomous, closed-loop. Small to control the quadratic blow-up. Autonomous to reduce cross-team coordination. Closed-loop so a complete business capability can travel from requirement to launch inside one team. Those principles existed before; in the traditional era they were nice-to-haves. In the AI era they are mandatory, because the cost of not following them got multiplied by an order of magnitude.

The traditional Conway's Law says the organization shapes the system: how you split the org, the system grows into that shape. That direction held because, in the traditional era, production capacity was the scarce resource. A small team could not independently deliver a large system; large systems had to be carried by large organizations cooperating across divisions; the system therefore had to grow into the org's shape. The AI era removes that premise. A team of three to five with agents has enough throughput to independently deliver a system that previously took twenty people. Production capacity is no longer a scarce resource that has to be amortized across an org's size. It travels with the agent; a few AI-fluent people can finish the work.

Which means something counter-intuitive: system structure starts to push back on organization structure. A team that wants to deliver in a new system shape can be small, can be autonomous, can be closed-loop, because it does not need a large organization's division of labor to compensate for production capacity. The organization is no longer being designed in the system's shape — it can be designed in the shape it actually wants, as long as that shape can deliver the system. Conway's arrow flips direction.

To judge whether a team's AI dividend will actually land, do not look at which model they are using. Look at how dense their communication graph is. Model differences move the needle by a few percent. Org-design differences can move it by 1× or 2×. This has nothing to do with which tool faction you back, nothing to do with who chases new models hardest. It has to do with the structure of the organization itself.

14.4 Alignment Among a Group of Agents

Even when the team is small enough, the way humans communicate has itself changed.

In the traditional era, communication on a team was human to human. Let me bring you up to speed, let me sync on progress, let's discuss this design. The cost was mostly spent on letting the other person understand what I currently know, what I plan to do next, what I need from them. It was slow, but with a hidden payoff: while the two of you were syncing background, you were also incidentally aligning the working context for what came next. I'm changing the user-login module — and now in your head there is a picture of which files I will touch, which conflicts to avoid, when you can pick up where I leave off.

The AI era has changed that. Each engineer comes with an agent. Each agent has its own state — which files it has read, what is sitting in its context window right now, which Skills it is loaded with, which constraints the engineer set on it earlier. Communication between two engineers has become, in substance, alignment between two agents' contexts.

Take a concrete scene. Engineer A had their agent rename a column on the user table from user_name to username — and, in the same pass, had it sweep the project for every reference and update them all, scan, rewrite, run tests, all green, merged. Engineer B is on a different machine; their agent's context still has the old state. The code it was reading still has the old name; the new code it generates uses the old name. B runs it, fails, assumes it is a local environment problem, wastes time poking around before realizing the column name changed.

That troubleshooting time did not exist in the traditional era. Back then, A renames the column; B, when pulling main, would most likely see the commit; even if not, B would write new code from memory, and somewhere in that memory the alarm did the column name change? would fire. But B is no longer writing themselves — B's agent is. The agent has no I changed this last week memory; it sees only its context. The misalignment between A and B surfaces, ultimately, as B's agent producing wrong code.

This kind of failure is more insidious than traditional miscommunication. Traditional miscommunication has explicit signals — at some point B realizes I never heard A talk about this, and B asks. Inconsistent agent contexts have no such signal. When B's agent writes wrong code, its tone is exactly as confident as when it writes right code. It will not say I do not know whether this column was changed recently; it will write to the version it knows. Inconsistency among a group of agents' contexts is structurally the same as inconsistency among a group of people's mental models, except it does not announce itself, which makes it harder to catch.

This connects directly to the context-engineering arc earlier in the book. The single-agent context window — managed as a system bus, a control point — was about keeping one agent uncluttered. Pushed up to team scale, the analogue is keeping a group of agents uncluttered, which is fundamentally an organization-level cognitive consistency problem.

In engineering terms it produces some very concrete actions. A team-shared Skill library — its real value is not that reuse saves work; that is secondary. Its real role is to act as the team's shared context anchor. The recurring task type is handled by everyone's agent through the same Skill, so the resulting code naturally takes the same form, and merging does not produce friction. A project-level spec checked into Git is not for show; it is so that every individual's agent, when generating code, starts from the same baseline context.

In an AI team, those things are the physical substrate of coordination. Without them, agents' contexts drift from each other, and communication cost does not drop — it inflates, in a new and harder-to-notice form.

14.5 What Happens When Skill Walls Come Down

AI is reshaping the organization in another direction at the same time. It is erasing technical capability as a traditional axis on which to draw team boundaries.

A backend engineer with an agent can now write frontend code. The old path — three months learning a framework, learning styles, learning browser quirks — collapses to a week of getting up to speed and shipping a respectable page. A backend writer can pair with an agent for SQL, ops scripts, frontend tweaks; the threshold drops to nearly zero. The skill curve has not vanished; the climb time has been compressed by an order of magnitude.

The consequence is direct: the cost of being full-stack went down. Traditional organizations split engineers into frontend, backend, mobile, QA, ops. The unstated premise of that split was that the skill wall itself was the cost — nobody can be excellent at all of them, so splitting by skill is rational. Half of that premise has been pulled out from under it. Excellent at all of them is still unrealistic. Capable in all of them is now realistic. The distance between the two is the part of the skill curve the AI is climbing for you.

From the organization's vantage point, that produces a sharper read: the case for splitting teams by function has lost half its rationale. In a traditional org, frontend and backend were separate teams; a feature looped between them — frontend waiting for backend's API, backend waiting for frontend's requirements. That split was rational in the old era because the skill gap was wide enough to be worth paying coordination cost for. The AI era is closing that gap. Coordination cost has now become the dominant burden. A three-person team — one mostly frontend, one mostly backend, one mostly QA, each able to cross over with an agent — likely outproduces two two-person specialist teams plus the coordination wall between them.

That is the surface. Push deeper and a sharper question emerges.

The point of division of labor was never let people who are good at X do X. That is its presentable framing. The actual mechanism of division of labor is to externalize the things you are not good at: I am not good at frontend, so I hand frontend to a frontend engineer, and now it is no longer my problem. My workflow is simplified; I can focus on what I am good at. The essence of division of labor is to let everyone work inside a simplified, controllable slice.

The AI era changes that. The agent absorbs the parts you are not good at, internally. You no longer have to externalize them to someone else. Most of the frontend work, the agent does for you; what is left to you is judgment and backstop. So what gets pulled out from under division of labor is not a particular boundary (frontend versus backend); it is the underlying logic of division of labor itself — externalizing what you are not good at has been partially absorbed.

What is genuinely scarce after that? It is not skill. It is judgment. Whether to do this thing at all, how far, in what way, when to stop, when to throw it out and start over. The agent cannot stand in for those calls. It can write the code; it cannot decide whether the code should be written. It can refactor; it cannot judge whether this refactor is worth doing. It can hand you a technical proposal; it cannot weigh whether that proposal is right for this project, this team, this phase.

In the traditional era these judgments were carried by senior engineers, architects, tech leads; they made them on experience and instinct. Division of labor partially masked them, because the judgment scope of each role was sliced apart — the frontend engineer did not have to worry about the backend's calls. The AI era blurs the role boundary, and these judgments come back onto every engineer's desk, weighted heavier than before.

The T-shaped talent model is failing. The horizontal of T was breadth, the vertical was depth; the model held in traditional vocabulary because depth was scarce — most people could only have real depth in one or two directions, so breadth had to fill in. The AI era has driven down the cost of having multiple depths in parallel. Personal value no longer flows from what I can do; it flows from what I can judge — should be done, to what extent, when to stop. That is a concrete role shift, from execution toward judgment.

In organizational terms, this points at a specific move: org reordering is not renaming. Renaming the frontend team to full-stack, renaming the backend team to business team, leaving headcount, reporting lines, and review criteria unchanged — that change does nothing. Real reordering is reallocation of resources. The team's center of gravity moves from clustering by skill to closing the loop on a problem — from all the frontend people together do frontend to everyone needed to ship a business capability is together. The first optimizes skill reuse. The second optimizes problem solving. In the AI era the dividend on the second far exceeds the dividend on the first.

14.6 An Anti-Pattern: Spinning Up an Independent AI Team

The first thing many companies do when they decide to embrace AI coding is pull a few people together into an AI team, charged with setting standards, building tooling, training other teams, and driving AI adoption. In traditional organizational behavior, that move feels natural: important things get a dedicated team. That is the standard answer organization management has given for decades.

Applied to AI coding, the move is structurally going to fail. It is not that some company's execution is poor; the failure is in the structure itself.

To see why, look at what the AI team setup actually creates.

The first thing surfaces fast: business teams treat AI as an outsourced capability. Since there is a dedicated AI team, when business teams hit AI-related problems they take them there. The agent keeps writing wrong code, take it to them. Cannot write a Skill, take it to them. The prompt does not work, take them. The AI team has become a new helpdesk; the business teams have become its customers. A wall is now standing between AI-related work and the business team's actual work.

Next, the AI team gradually drifts away from real business scenarios. An independent AI team's metrics become AI-flavored numbers — adoption rate, agent task success rate, number of teams onboarded. Those numbers sit a layer of fog away from what the business teams actually feel painful. The AI team, in their own view, is doing serious work. The work they are doing may not match what the business teams actually need. The specs, Skills, and tooling they ship often end up the same way — comprehensive on paper, awkward in use.

Deeper still: business teams' AI-use muscle never grows. The core of using AI well is engineers iterating in their own workflow, slowly finding postures that fit their specific business. That process cannot be outsourced, because only the people closest to the business know which posture is right. A team that hands all its AI questions to the team next door never builds that muscle. Long term, that team gets left behind by people who can use AI and also understand the business.

Now the issue is clear. Spinning up an independent AI team is the organization trying to solve a new problem with the old playbook. The old playbook says important things get dedicated owners, which worked because the important things were usually a particular professional skill — needed dedicated long-term investment to master. AI coding is not like that. It is not a localized professional skill; it is a capability substrate sinking into everyone's day, and what it reshapes is every engineer's way of working. The reshaping has to happen inside every business team. It cannot be outsourced to a single specialist department.

The right move is not to centralize AI; it is to embed it. Each business team grows its own habits with AI, figures out for itself how the agent should be used in its own business, and accumulates its own Skills and conventions for its own scenarios. A platform team can provide the substrate — model access, quota management, security audit, shared tooling — those are organization-level infrastructure, and centralizing them is rational. The site of use must stay inside the business teams. It cannot be peeled off.

14.7 Where the Coordination Dividend Actually Comes From

Back to the scene at the top of the chapter. Thirty percent evaporates at the seams, disappears into communication cost, gets eaten by misaligned cognition. The places it disappears are also the places it can be rebuilt.

Translate individuals' implicit cognition into the team's explicit shared contracts, and the dividend has a way to cross the seam. Lift organization design above technology choice on the priority list, and communication cost can come back to a reasonable level. Treat the alignment among a group of agents as an organization-level cognitive consistency problem, and shared Skills, shared specs, shared evaluation sets stop being nice to have and become the physical substrate. Loosen the old rationale of splitting teams by function, and the organization's resources can flow toward what is actually scarce — judgment.

These actions share one thread: in the AI era, a team's advantage is not who picks up AI first, but who first translates individual dividend into coordination dividend. The tool gap closes in three months. The organization gap is what produces the real distance.

The next chapter pushes the same lens one level out. Once individual dividend has become coordination dividend, the question moves to the organization — how does an organization absorb hundreds of Skills, watch for silent rot, decide whether middle management still makes sense, and assign accountability when the chain stops being made of human hands.