The connective tissue

"I'm on the platform team. We own the billing service."

Two sentences. Most engineers could say their own version without thinking, and most would never notice how much work those sentences do. They're organisational statements (obviously), but psychological ones too, telling people who they are and what they're responsible for, and telling everyone else the same thing about them.

Teams are how humans make sense of work.

The worry, stated plainly

The "AI taking jobs" framing misses the thing actually worth worrying about. The jobs conversation is real and it needs having, but it's a conversation about headcount, and headcount is the part of this we at least know how to count.

The part I can't count is what happens when the team dissolves into a collection of individual operators with agents. We will be more efficient. Something else goes with it: the connective tissue that makes people feel they're building something together rather than accumulating their own output.

Why it isn't hypothetical

Follow the logic far enough and you reach an uncomfortable destination. If AI handles implementation, assists with prioritisation, and consensus is too slow for the pace of decisions, the optimal unit of software production isn't a cross functional team. It's one person with a fleet of agents, holding the vision, making the calls and directing execution at production scale. I keep seeing early versions. A designer shipping a full production feature front to back with no engineer involved, or a PM building and deploying an internal tool over a weekend.

Even where the team survives on paper, the way it decides together is under strain. Consensus breaks first: either one person decides or nobody does, and neither outcome looks much like a group of people building something together. The cross functional squad was designed for a world where those skills had to live in different people. Those boundaries are dissolving fast, and I've argued elsewhere that the org chart is the bottleneck, that the structure has to change for the gains to show up.

I still believe that. This piece is the cost of believing it.

What ownership felt like, and what it feels like now

One team shipped eleven changes to a single feature in one week. Not bug fixes. Substantive changes, driven by how people were actually using it, and by Friday the feature bore almost no resemblance to what launched on Monday. Nobody could say whether that was one feature or eleven, who owned it, or which version a customer would be filing a bug against. Not rhetorically, either. Ownership is the atomic unit of how I think teams should work, and it assumes there's a stable thing to own. People build psychological ownership around what they create, and when the thing you built on Tuesday has been rewritten three times by Friday, by agents acting on signals you never saw, it is not clear what you own, or what you are responsible for.

I noticed the engineers on those fast moving teams talk differently about their work. Less pride of authorship. More resignation to impermanence.

Resignation. Not a word you want anywhere near how people describe the thing they make, and not one any throughput chart from that week would have shown you.

The loneliest version

The loneliest version of the future I can imagine is one where everyone is productive and nobody is connected.

The software gets better. The experience of making it gets emptier.

Nobody would design that on purpose. You'd get there the way most organisations get anywhere, one reasonable decision at a time, each one justified by a metric that went the right way: fewer handoffs, faster cycle time, smaller teams, then teams of one. Every step defensible. The sum of them something nobody chose.

We measure what we can see, and throughput shows up on a dashboard. The feeling of building something with other people doesn't show up anywhere until it's gone, and then it shows up as attrition, or as a kind of quiet that's easy to mistake for focus.

What I don't know

I don't know how to prevent it.

I'm not going to pretend otherwise, and the honest position right now is that none of us has run this experiment long enough to see how it ends. What I'm sure of is that it needs naming out loud before we sleepwalk into it optimising for throughput. Every other piece on this site argues for removing friction, and I stand by them. Some of what looks like friction, though, was also the place where people found each other. A handoff is latency. It's also a conversation between two people who need each other to finish the job.

Remove enough of those and the efficiency case is airtight. So is the loneliness.

Who solves it

The teams that solve this won't be the ones with the best tooling or the fastest shipping. They will be the ones who find a reason for people to build together that has nothing to do with efficiency.

And I have no idea what that looks like.