AI Made Engineers Faster. It Also Made Teams Slower to Integrate.

One engineer can now build the whole feature alone. That's the win. It might also be the problem.

An engineer on a team I know shipped an entire feature last month (three services, a new queue, a schema change, the lot) in about four days. Alone. No design meeting, no integration huddle, no "can you walk me through how the payment service expects this." Just one person and a pile of agents, moving at a speed that would have taken a small group two weeks in the before times.

Then deploy day came, and everything stopped.

Not because the code was wrong. The code was fine. It stopped because the moment that feature had to leave that one engineer's head — to a devops person who owns the pipeline, to a reviewer who has to actually understand it, to the on-call rotation that will get paged when it breaks — nobody else had the map. The whole cross-service model existed in exactly one brain, and there was no cheap way to get it into a second one.

Here's the thing I keep circling back to, and the claim of this whole post: the velocity AI gives one engineer is borrowed against a collaboration tax the entire team repays at integration and deploy. And most of us haven't noticed the debt yet. The speed is real. It shows up on every dashboard we have. The tax is just as real, and it shows up nowhere, until the bill arrives at the worst possible moment.

I want to be honest up front: I don't have this solved. This is me thinking out loud about a pattern I keep seeing, in my own work and in teams I talk to. I'm more sure the problem is real than I am about anything we should do about it.

Let's start with the part that isn't a complaint, because it's important not to wave this away as hype.

The thing that's changed is the scope one person can hold. It used to be that a feature crossing three services crossed at least three people: somebody who knew the auth service, somebody who owned the data layer, somebody who lived in the front end. The boundaries between systems were also the boundaries between humans. You coordinated across services because you had to coordinate across people, and the coordination was the work.

Agents collapse that. One engineer can now open all three services at once, hold the full call path in working memory, and let the harness do the typing across every boundary at the same time. The auth change, the queue consumer, the migration, the client update, all built together in one session, by one person who never had to schedule a conversation to make it happen.

And it's fast. Not "feels fast." Measurably fast. The work that used to be gated on three calendars is now gated on one engineer's afternoon. If your only instrument is throughput, this looks like an unqualified win, and I understand why every engineering leader in the industry is leaning into it. I'm leaning into it. The output is real.

That's exactly what makes the rest of this hard to see.

When one person builds across three services in an afternoon, something quiet happens: the complete mental model of how those pieces fit together — why the queue retries the way it does, which failure the migration is guarding against, what the client assumes about the auth response — now exists in precisely one place. One head.

In the old world, that model was distributed whether you liked it or not. Three people built it, so three people held pieces of it, and the act of integrating forced them to reconcile their pieces out loud. The knowledge was spread across the team as a side effect of the work being spread across the team. Nobody designed it that way; it was just how building together worked.

The solo end-to-end build removes the side effect. The feature gets built, and the understanding of it doesn't spread, because spreading it was never required to ship it. You end up with a new kind of silo: not an organizational one, where a team hoards what it knows, but a structural one, where the knowledge was simply never externalized in the first place. It's invisible precisely because the building phase feels so good. One person, fully loaded with context, is the most productive unit in software. The problem is that productivity and resilience are pulling in opposite directions, and only one of them is on the screen.

Now, the obvious objection (and it's a good one) is that's what documentation is for. Write it down. Have the agent generate the design doc. Drop a markdown file next to the feature explaining every decision. We have better tooling for this than we've ever had; the model that built the thing can also describe it.

I used to find that answer fully convincing. I find it less convincing now, for two reasons.

The first is that a document encodes facts, not judgment. It can tell you the queue retries three times with exponential backoff. It struggles to tell you why three and not five, what got tried and rejected, which production incident from two years ago is the reason that number exists at all. The tacit reasoning — the part that's actually expensive to rebuild — is the part that's hardest to write down and easiest to leave out. And the model writing the doc doesn't know it either, unless the engineer thought to say it.

The second is that reading isn't free. A document doesn't transfer understanding; it transfers the opportunity to rebuild understanding, and the reader still has to pay for that with their own time and attention. A 4,000-word design doc that took an agent ninety seconds to produce can cost a reviewer an hour to genuinely absorb, and they still can't interrogate it the way they could interrogate a colleague. You can't ask a markdown file "wait, what happens if the migration runs while the old consumer is still up?" and watch its face change as it realizes it hadn't thought about that.

Docs help. I'm not anti-doc. But they move the cost; they don't remove it. And critically, they move it downstream: from the fast, cheap building phase to the slow, expensive handoff phase. Which is exactly where the bill is waiting.

Watch where the friction actually lands now. It's not in the building. Building is the part that got fast. The friction migrated to the seams: the places where the work has to pass from the one person who holds the whole picture to everyone else who needs a piece of it.

Deploy is the sharpest seam. The engineer who built the feature understands its rollout implicitly: this migration runs before that service restarts, this queue drains before the old consumer dies, this flag flips last. None of that is in the code in a form the pipeline owner can read off. So now there's a conversation. But not the cheap, in-flight kind that used to happen while two people built a thing together. It's an after-the-fact download: four days of dense, agent-assisted context, handed to someone who has to receive it cold, all at once, under deploy-day pressure.

Code review has the same shape. A reviewer faced with a three-service change built in one pass isn't reviewing a diff anymore: they're reverse-engineering an entire mental model from its artifacts, fast, so the thing can move. Multiply that by every solo-built feature in the queue and you get a review process that's quietly become the bottleneck the building used to be. We didn't remove the constraint. We moved it from "writing the code" to "transferring the context," and the second one is harder to parallelize because it lives in people, not in machines.

This is the tax: slower deploys, longer reviews, more coordination overhead exactly when you can least afford it. It's close to invisible on the instruments, because nobody books "the hour it took to explain the feature to devops" as a cost of the feature. It just shows up as deploys dragging a little, for reasons nobody quite names.

And there's a sharper edge to it: bus factor. When the complete model of a critical feature lives in one head and was never forced out into the team, that head going on vacation (or leaving) isn't a staffing inconvenience. It's a genuine hole in the system's operability that you discover at 2 a.m. when the thing breaks and the one person who understands it is unreachable.

Here's the part that worries me most, because it's not about deploy speed. It's about what we're becoming as teams.

I was talking to a developer about how his team works now, and he described their collaboration like this, with no irony at all: "Oh, we just pass each other PRs to review and send our agents at them." And I've been chewing on that sentence ever since, because it was offered as a description of collaboration and it describes something that isn't collaboration at all.

Two engineers each building in isolation, each generating a change neither fully holds, each pointing an agent at the other's output to review it. That's not two people solving a problem together. It's two factories running in parallel, shipping parts to each other across a wall. There's throughput. There's no shared understanding being built, no one teaching anyone anything, no junior watching a senior reason through a hard call and absorbing how the senior thinks. The thing that used to happen for free inside collaboration — the learning, the transfer of taste and judgment from one person to another — has been engineered out, because the friction it rode on is the same friction we just removed.

That friction was load-bearing. The annoying parts of working together — having to explain your thinking, having to reconcile your model with someone else's, having to slow down enough to be understood — were also the parts that spread knowledge through a team and turned a group of individuals into something that knew more collectively than any one of them did. We treated that friction as pure overhead and optimized it away, and I'm not sure we noticed that it was doing a second job the whole time.

As an engineering leader, this is the part I can't shrug off. I want my team to collaborate. I want people solving each other's problems, learning from each other, getting sharper because they're surrounded by people who reason differently than they do. "We send our agents at each other's PRs" is the opposite of that. It's efficient and it's lonely and it doesn't compound the way a team that actually learns together compounds.

This is the part of the post where the formula says I'm supposed to give you three practices and a tidy framework. I'm not going to, because I don't have them, and I'd rather be honest than tidy.

I have half-formed instincts. Maybe deploy-readiness has to become an explicit team artifact instead of one person's implicit knowledge. Maybe we need to deliberately re-introduce some of the friction we removed: pairing on the hard features even when one person could solo them, precisely because the solo path skips the part where the team learns. Maybe the unit of work shouldn't be "a feature one person owns end to end" but something that's harder to hold alone on purpose. I don't trust any of these enough to tell you to go do them.

If I had to name the category all three point at, it's this: we may need to treat knowledge externalization as a first-class, scheduled part of the work. Not something we hope happens as a happy side effect of coordination, but a deliverable in its own right, planned and resourced like any other. And we may have to accept slower individual throughput on certain classes of change (the load-bearing, cross-service, wakes-you-at-2 a.m. ones) in exchange for lower organizational bus factor and faster future changes. That's a real trade, not a free lunch. It only pays off if the second-order cost is real, which is the whole question I can't yet answer.

What I'm fairly sure of is the shape of the trap. Every individual incentive points at the solo end-to-end build: it's faster, it's satisfying, it makes you look productive. Every individual decision to work that way is locally rational. And the cost lands somewhere that no individual feels and no dashboard shows: on the team's collective understanding, paid back slowly, at the seams, in deploys that drag and knowledge that doesn't spread and a kind of working-together that's quietly stopped being together at all.

Here's where I have to check my own framing, though, because I build multi-agent systems for a living and it would be too easy to write "agents bad" and walk away. The honest version is narrower: this generation of agent usage is pointed at individual velocity, which is exactly the force pulling context into one head. There's no law that says the next generation has to be. You could build agents whose whole job is the opposite. Agents that force externalization and cross-model reconciliation instead of skipping it:

• agents that interrogate a build the way a teammate without the context would, asking "what happens if the migration runs while the old consumer is still up?", and making you answer before the work can ship;

• handoff artifacts generated not as prose docs but as queryable models of the decision space, something the next engineer can actually ask questions of instead of reading cold;

• multi-agent setups where separate agents role-play platform, security, and on-call during the build phase, so the reconciliation that used to happen between people happens before the work ever leaves one person.

None of that exists in a mature form yet, and I'm not claiming I've built it. But it shifts how I read the problem. It isn't "AI killed collaboration," full stop. It's that the first thing we aimed these tools at was individual speed, and the layer that pays the cost back (the one that rebuilds the reconciliation step inside the machine) is a layer we mostly haven't built. That's a more interesting problem than a complaint.

So I'll ask the people actually living this, because I think the answer is out there in your teams and not in my head:

Is this even a problem where you work? Or am I mistaking a transition for a loss? I'm especially interested in teams that have been working this way for six to twelve months: are you seeing the second-order effects yet (the bus-factor holes, the learning that quietly stopped), or am I over-weighting the transition period and this all settles out? And if it is a problem, what are you actually doing about it? Have you found a way to keep the velocity without hollowing out how your team learns from each other? I want the real answers, including "you're wrong, here's why." I'm working this out, and I'd rather work it out with you than pretend I've already figured it out.

Tell me in the comments. I'm reading all of them.