The City That Built a Flyover for Every Driver
A city decides to fix its traffic. Instead of widening its junctions, it gives every regular commuter a private flyover from home to work. Journey times collapse. Nobody waits at a light, and nobody has to merge with anyone else.
For a while, it looks like the best infrastructure decision the city has ever made. Then the side effects appear. Two flyovers turn out to have been built along the same route. Nobody meets at a crossroads any more, so nobody hears that the bridge on the east side is closing. The city's map slowly stops matching the city.
Nothing failed. Every flyover works exactly as designed. The city removed its junctions, and with them the places where people had to stop, see each other and adjust.
That is what AI tooling is quietly doing to many engineering organizations.
Two Teams, One Sprint, the Same Tool
One of the most-discussed engineering threads this month asked a simple question: are we back to silo engineering? The most-upvoted answer, with 535 upvotes, described leads spending a whole sprint building the same AI tools as each other. Its blunt summary was that "nobody is coordinating." Another highly upvoted reply made a quieter point. The idle conversation that used to fill the day was where a lot of passive knowledge transfer happened, and it has largely stopped.
None of this sounds like a technology problem, and that is why it gets misread. Leaders hear "collaboration is dying" and reach for culture fixes: more stand-ups, an offsite, a reminder that the team is a team. Those fixes treat the symptom. They assume people stopped talking because they stopped caring.
The more likely explanation is structural. For decades, engineering coordination was not mainly the result of good intentions. It was the result of friction. You had to talk to the person who owned the service because you could not change it without them. You asked a colleague because they were faster than the documentation. You waited for review from the one engineer who understood the module. Those dependencies were annoying, and they were also the network that carried context around the organization.
AI assistants removed a large share of that friction in about two years. The engineer no longer needs to ask, because the assistant answers. The lead no longer needs to find out whether another team already has an internal tool, because building a new one takes an afternoon. Each decision is locally rational. The result is a set of fast individuals who no longer meet at any junction.
The Wrong Diagnosis
The common diagnosis is behavioral: people are busy, remote work has thinned relationships, and AI has made engineers prefer the tool to the team. Some of that is true. But it leads to interventions that ask people to coordinate against their incentives, and those never last. A mandatory sync meeting is still a meeting with nothing on the agenda that requires it.
What is actually happening is that the organization's coordination system was never designed. It was emergent. It came from dependencies, and the dependencies have changed. This isn't a culture problem. It is an operating-model problem wearing culture's clothes.
The consequences show up in three places.
Duplicate internal tooling. When building an internal AI helper takes a day, five teams build five of them. Each has its own prompt conventions, its own access to production data, its own failure modes and no owner beyond the person who wrote it. Nobody decided to have five. Nobody decided not to. The thread about massive AI bills (128 upvotes, 275 comments) is partly a symptom of the same pattern: spend that nobody coordinates is spend that nobody can explain.
Knowledge stops moving. The questions engineers used to ask each other now go to an assistant. The assistant may answer well, but the answer stays private. The colleague who would have said "we tried that in 2023, and here is why it broke" never hears the question. Over months, the team's shared understanding of its own system thins out, and nobody notices until an incident needs it.
Local decisions, global drift. Each team, with its own assistant, makes sensible local choices about libraries, patterns, data access and interfaces. Individually, every choice passes review. Collectively, the architecture fragments. That is the opposite of the failure most of us were trained to fix. The old problem was too much escalation: every decision dragged into a committee. The new problem is that nothing crosses a boundary at all.
Coordination Used to Be a Side Effect. Now It Has to Be Designed.
Conway's Law, Melvin Conway's 1968 observation that systems mirror the communication structure of the organizations that build them, still holds. What has changed is the communication structure itself. If AI tooling reduces how often teams need to communicate, Conway's Law predicts more fragmented systems. That is not a malfunction. It is the law working as stated.
Team Topologies gave many organizations a vocabulary for designing team interactions deliberately: collaboration, X-as-a-service and facilitating modes, and an explicit concern with cognitive load. That work matters more now, not less. Most teams used those interaction modes as a description of how teams happened to work. In an AI-assisted organization, they have to become a specification of how teams must work, because the old forcing functions are gone.
In practice, redesigning coordination comes down to four changes. Teams can start two of them on their own: giving shared AI tooling an owner, and replacing the conversations they lost with rituals that carry knowledge. The other two only the technology leader can make.
%% caption: Where coordination came from before AI tooling, and where it has to come from now
flowchart TB
subgraph Before["Before: coordination as a side effect of friction"]
A1[Need a change in\nanother team's system] --> A2[Ask the owner]
A3[Stuck on unfamiliar code] --> A4[Ask a colleague]
A5[Need an internal tool] --> A6[Check what exists,\nbecause building is slow]
A2 --> A7[Context spreads\nacross teams]
A4 --> A7
A6 --> A7
end
subgraph After["With AI tooling: coordination by design"]
B1[Shared AI tooling\nwith a named owner] --> B5[Context spreads\non purpose]
B2[Decisions that must\ncross a team boundary] --> B5
B3[Rituals that\ncarry knowledge] --> B5
B4[Team boundaries redrawn\nfor how work flows now] --> B5
end
Before -- "AI removes the friction" --> After
Give Shared AI Tooling an Owner
Duplicated internal tools are the most visible symptom and the easiest to fix. They are a platform capability that nobody was asked to own. Treat them the way a mature organization treats any internal platform. Decide which AI tools, agents, prompt libraries and integrations are shared. Give each one a named owner and a way for other teams to find it. Make building a private duplicate a conscious exception rather than the default.
This does not mean a central AI team gatekeeping every experiment. Experimentation should stay cheap. It means that once a tool is used by more than one team, or touches production data, it moves from someone's side project into something with an owner, a backlog and an adoption measure. The failure mode to avoid is the one described in Your Platform Team Is Building a Product Nobody Asked For: capability built in isolation from the teams who need it. AI tooling now creates the reverse problem as well. Teams build in isolation from each other, with no platform involved at all.
Replace the Conversations You Lost With Rituals That Carry Knowledge
The idle conversation that disappeared was doing real work. You cannot mandate it back, but you can replace its function. The test of a coordination ritual is simple: does it move context that would otherwise stay with one person?
Short internal demos of AI tools and agents
Fifteen minutes every two weeks, where teams show what they built or automated. The demo is not the point. Seeing it is how the second team finds out before building its own.
Cross-team review rotations
Periodically route a sample of pull requests to a reviewer from an adjacent team. Most of the value is not catching defects. It is that a second team now knows how the first one's system works.
A written decision log that agents and humans both read
When an assistant makes it easy to change something, the reason it was built that way needs to be readable by whoever, or whatever, changes it next. Nobody Uses ADRs as an Agentic Decision Log. They Should. makes this case in detail.
Incident reviews that cross boundaries on purpose
Incidents are where hidden dependencies surface. Inviting the teams whose systems were touched, not just the team that was paged, is one of the cheapest ways to keep shared understanding alive. Your On-Call Log Is Your Real Org Chart shows how much structural truth that data already holds.
What the Technology Leader Owns
Tooling owners and knowledge rituals can be started by any engineering manager. Two decisions cannot, because they change who is allowed to decide what, and where one team's work ends and another's begins.
Make Explicit Which Decisions Must Cross a Team Boundary
When I worked with a Series A SaaS company that had grown from 15 to 80 engineers in 18 months, the problem was too much coordination: every technical decision required a cross-team meeting. Making it explicit which decisions belonged to a team, and which genuinely needed cross-team input, cut cross-team blocking issues by 40%. The same discipline now has to run in the other direction. Some decisions must cross a boundary, and AI tooling makes it easy to skip that step without noticing.
| Decision type | What used to force coordination | What happens with AI tooling | Design response |
|---|---|---|---|
| Interface and contract changes | Another team had to change their side | An assistant adapts both sides in one pull request | Contract changes require the consuming team's sign-off, not just a passing test |
| New internal tool or agent | Building took weeks, so people checked first | Building takes an afternoon | A shared register checked before building; duplicates are a conscious exception |
| Data access patterns | Access requests went through an owner | An agent wires up access with existing credentials | Data owners are notified of new consumers by default |
| Shared libraries and patterns | Adoption required persuasion | Each team's assistant suggests its own | A short list of standard patterns, with deviations recorded as decisions |
The point of the table is not more gates. Most decisions should still sit with the team. The point is to name the small number of decisions where skipping coordination creates cost for someone else, and to make that coordination non-optional. That is the core of Decision Velocity Is Not a Leadership Problem, It Is an Architecture Problem: speed comes from knowing where a decision belongs, not from removing decisions.
Redraw Team Boundaries for the Work as It Is Now
Team boundaries drawn before AI tooling assumed a certain amount of work per team, a certain set of dependencies and a certain need for specialists. Those assumptions have shifted. A team that once needed another team for every data change may now be able to make the change itself, which is fine if it also owns the consequences and not fine if the other team is still on the hook when it breaks.
When I was Chief Architect at a healthtech product company, we restructured teams around product modules, using Domain-Driven Design and Event Storming to find where the real boundaries were. That kind of exercise is worth repeating now, because the boundaries that made sense two years ago were drawn for a different division of labor. Ask where teams now reach into each other's systems through their assistants, and either make that ownership explicit or move the boundary.
This is also where AI-native teams need named owners. An AI-assisted team can produce work far beyond its old scope. Ownership has to keep up with output, or the organization ends up with a lot of code that nobody feels responsible for.
What the Market Is Showing
Two signals point the same way.
The conversation
The conversation among practitioners this month is not about whether AI makes individuals faster. It is about what happens to the team. Beyond the silo engineering thread (967 upvotes, 284 comments), a thread asking when the AI reality sets in for middle and senior management drew 568 upvotes and 627 comments. On Hacker News, a post arguing that using AI well takes skill drew 805 points and 607 comments. The common thread is a gap between what tools promise individually and what organizations experience collectively.
The job market
Employers are describing the same need in their hiring. In 38 senior architecture and engineering-leadership postings reviewed for this piece across New Zealand, Australia, the UK and remote roles, 18 asked for leading, building and scaling teams or for organization design (my own tagging of the posting text). Gentrack's Director of Engineering APAC asks for organisation design, for removing "friction and unnecessary complexity", and for leading the adoption of AI-enabled software development, all in one role. Rightmove's Head of Architecture is framed around enabling more than 40 engineering teams to make architecture decisions. Hiring leaders are not looking for someone to add AI to the organization. They want someone to keep the organization coherent while AI changes how it works.
Action Plan
This Week
Ask three questions of your own organization:
- How many internal AI tools, agents or scripts exist that do roughly the same job, and who owns each of them?
- In the last month, which interface, data-access or shared-library change happened without the affected team hearing about it beforehand?
- If a senior engineer left tomorrow, what would the team lose that never got written down because the questions now go to an assistant?
If you cannot answer the first question, you already have the problem.
Next 30 Days
Build a simple register of shared AI tooling: what exists, who built it, who uses it, what data it touches. Pick the three or four decision types where skipping coordination costs another team, and make that coordination explicit. Start one knowledge-carrying ritual, such as fortnightly tool demos or cross-team review rotation, and watch whether duplicate work drops.
3 to 6 Months
Revisit team boundaries against how work actually flows now that teams are AI-assisted. Move shared AI tooling into an owned platform capability with an adoption measure. Make the decision log something both people and agents read before changing a boundary. Then check whether the integration surprises, duplicate spend and "nobody knows how this works" moments are falling.
Final Thought
The city with a flyover for every driver did not get worse at moving people. Every flyover works. What it lost were the junctions, the places where people had to stop, see each other and adjust, and nobody had decided those were worth keeping.
Two leads spending the same sprint on the same tool is not a story about bad engineers. It is a story about an organization whose coordination ran on friction, and the friction went away. AI did not break collaboration. It removed the reasons collaboration used to happen by default.
So the useful question is not how much faster each engineer has become. It is where your teams still meet, and whether anyone designed those meeting points.
If someone did, AI makes a coordinated organization faster. If nobody did, it makes a fragmented one faster at fragmenting.
Redesign Coordination Before It Fragments Your Architecture
If your teams are faster on their own but keep rebuilding the same things, surprising each other at integration time, or losing track of how their own systems work, that is not a culture problem. It is a coordination system that was never designed, now running without the friction that used to hold it together.
or
Coordination used to be free. Now it has to be designed.
