What We Lose When We Build Alone

Spend any time on LinkedIn and you get the impression that with AI, one person can now do the work of a team. Soon there will be one-person unicorns. Why hire engineers, designers, or product people when a founder with the right prompts can ship it all alone?

I understand the appeal: an assistant that never tires, never disagrees, and never needs a meeting. But producing code was never the bottleneck. The hard part is deciding what to build, noticing when you are wrong, and getting better over time. All three come from working with other people.

Some people really do build amazing things alone: Jonathan Blow, Eric Barone, Fabrice Bellard. My unease is not with them but with the narrative around them: that teams are a cost AI finally lets us cut.

Where ideas come from

Good ideas rarely arrive fully formed. They start as half-thoughts said out loud to someone who pushes back. A colleague asks “why not do it the other way?” and the idea gets sharper, or it dies, which is just as valuable. A vague hunch becomes a decision you can defend by surviving people trying to knock it down.

This works because everyone brings a different past: years in another industry, an outage they still remember, a customer they watched struggle. Nobody sees their own blind spots. A group with different scars covers for each other. An AI can generate alternatives all day, but it will not stop you in the hallway two days later because something about your plan kept bothering it.

What feedback does

Knowing that a person you respect will read your code changes how you write it, before a single comment arrives. A good review also shows you what an experienced reader notices, what they worry about, and what they let go. Over hundreds of reviews, in both directions, a team develops shared taste.

The feedback that never lands in a review tool matters just as much: the raised eyebrow in a design discussion, the teammate who tells you the demo was confusing before the customer does. People invested in the outcome give you the criticism you need, not the agreement you asked for.

How we learn

Most of what I know about building software I did not learn from documentation. I learned it by watching people work: how a senior engineer narrowed down a bug, what a good reviewer let go, how someone calmly ran an incident at 2 a.m. Judgment is learned from people, in real situations with real consequences.

Teaching runs both ways. Explaining a design to a junior colleague forces you to understand it properly, and their naive question is sometimes the one everyone else was too experienced to ask.

Use the tool, keep the team

None of this is against AI. I use it daily and it makes me faster. But a team was never just a way to parallelize typing, and colleagues are not a cost to optimize away. They are where the value was coming from all along.

A skilled guitarist can sound great alone in the basement. A band is a different thing: you listen, adjust, leave space, push each other somewhere none of you would go alone. And you show up on the weeks you would have skipped, because the others count on you. Building software is closer to the band than the basement.

Delegate the typing, gladly. Keep the band.