I recently came across a post by Cory House on Twitter, making a prediction about the future of software development:

Development teams are going away. We will increasingly work alone instead of on teams.

His argument is that we formed development teams partly because writing software took so much time and specialised knowledge. Now, a capable engineer can direct several AI agents to do work that once needed multiple developers. Eventually, he suggests, developers might build and maintain entire applications on their own, calling on colleagues for advice rather than working on the same code every day.

I think there’s a good chance he’s right about how we write code.

I have a rather different view of how we build software.

Writing code is not the same as building a product

An experienced engineer with a group of capable agents can already do an impressive amount of work. They can explore an unfamiliar codebase, build features, write tests, review changes, and investigate failures. I expect that capability to improve considerably.

It isn’t hard to imagine one engineer doing the implementation work that once kept a small team busy. Maybe, eventually, AI will handle almost all of the coding with little or no human intervention.

That’s still a big if. Reliable software has a habit of exposing gaps between an impressive demonstration and something that works for years, with real users and real consequences.

But even if we grant the premise entirely, I don’t think the conclusion follows.

A product is not simply the sum of its code. A product is a set of choices about whose problems matter, which compromises are acceptable, what should be easy, and what should not exist at all.

Those choices don’t become obvious just because implementation becomes cheap.

The perspectives we don’t have are the ones we need

Imagine we’re building an app for people who use public buses.

One engineer, supported by agents, could build a polished interface with live locations, route search, arrival predictions, notifications, and payments. It could be technically excellent.

Then someone who actually rides those buses might point out that the biggest problem isn’t finding a route. It’s knowing whether the bus shown on the map is really coming.

An operations manager might explain that location data is often delayed or missing. A person with a visual impairment might tell us that the lovely interactive map is nearly useless to them. A driver might describe a problem with the proposed boarding process that nobody sitting in an office considered.

None of these people needed to write a line of code to change what we should build.

And none of those conversations can be replaced by asking an agent to make the original plan faster.

This is why I value working with people who see the problem differently. The designer who questions an interaction everyone else likes. The person dealing with customers who knows which complaints keep coming back. The engineer who refuses to accept a convenient assumption. The client who asks a question we hadn’t thought to ask.

Sometimes, the most useful contribution comes from someone whose first reaction is, “I don’t think that’s the right problem.”

Good products need arguments, not just answers

There is a version of teamwork I would be very happy to see disappear: endless handoffs, status meetings, and the need to coordinate five people just to change a button.

AI can eliminate a lot of that overhead. Good.

But there’s another kind of teamwork that I hope becomes more common: people debating ideas, challenging each other’s assumptions, trying things out, and changing their minds when the evidence points somewhere else.

I want to work with people who disagree with me. People who suggest experiments I wouldn’t have run. People with strange, impractical-sounding ideas that turn out to be worth exploring. People who notice when a technically elegant solution makes life harder for the person using it.

An AI agent can play devil’s advocate. It can suggest alternatives, simulate a critique, and help us explore more options than we could have afforded before. That’s useful, and I expect to use it more.

But a generated user persona is not a user. A simulated disagreement is not the same as hearing from someone with different experiences, incentives, or responsibilities. And ten agents reasoning from the same incomplete brief can still miss the same thing.

We don’t need more agreement around a flawed assumption. We need more chances to discover that the assumption is flawed.

The team may change shape

I don’t think this means we need to preserve today’s development teams exactly as they are.

We may need fewer people working on separate parts of the same implementation. A single engineer might own much more of the technical delivery, using agents for work that previously crossed several desks.

Meanwhile, the conversations around the product could become more important: with customers, designers, domain experts, people responsible for operations and support, and colleagues prepared to challenge a decision.

That doesn’t mean every idea needs a large committee, either. Solo founders and independent developers can build excellent products. But the good ones don’t have to think alone. They talk to users, seek feedback, test assumptions, and invite criticism. Their collaborators don’t all need to be on the payroll or in the repository.

And I don’t expect the roles to remain fixed. Engineers can do product discovery. Designers can build prototypes. Product managers can test an idea without waiting for a development sprint. Agents may make those boundaries much less rigid.

The point isn’t how many people contribute code. It’s whether enough different perspectives contribute to the decisions.

The more we automate, the more attention we can give people

Running a software services firm has made me appreciate a simple fact: a lot of the work that changes the outcome of a project happens in conversations, not in an editor.

It happens when a client explains what they actually need. When a colleague spots a problem with a proposal. When someone tries a feature and uses it in a way nobody expected. When we realise that the original requirement was wrong and decide to change course.

That work has often competed for time with the effort of writing and maintaining code.

If AI really makes implementation dramatically cheaper, I hope we spend some of the time we save on more of those conversations. More research. More prototypes put in front of real people. More experiments. More thoughtful disagreement. And more willingness to discard an idea that sounded great until someone challenged it.

There is, of course, a less appealing possibility: we use the same tools to produce more features, faster, without ever asking whether anyone needs them. That would be a productivity gain on paper and not much of an improvement in software.

The difference will come down to what we choose to value.

Cory may well be right that developers will spend less time working together on the same code. I wouldn’t be surprised if that happens.

But I don’t think the future of good software is one person, alone, asking an army of agents to build whatever they have in mind.

If AI solves the coding part, building software doesn’t become less human. It becomes an opportunity to be more human than ever.