Why Your Next Software Project Might Only Need One Person

When we first published this piece, the argument was simple: AI compresses software teams, and what survives is a small core that owns direction, judgement and governance. A year of actually building this way has firmed up the shape, but it has also changed our answer about who sits in the three seats. The durable trio is a prompt engineer who builds, an architect who sets the guardrails, and a tester who owns confidence. And on the smallest projects, all three are the same person wearing different hats.

Why teams keep shrinking

The mechanics are not mysterious. Code generation, refactors, glue work, boilerplate, first drafts of tests and docs: all of it has moved to AI, and it happens in minutes rather than days. What AI does not supply is knowing what to build, keeping a system coherent, and knowing whether the result actually works. Those are the jobs that still need people.

There is a second force pushing the same direction. Every extra person on a project is a coordination tax: another handover, another meeting, another chance for the plan to drift. Big teams existed because producing code needed that many hands. Once it doesn't, the tax stops buying you anything. A tight trio with good tooling now ships what used to take a floor of people.

The three seats

The prompt engineer, who is really a developer. This is the person building the product day to day. The title is honest about how the code gets written now: their craft is breaking work into pieces an AI can do well, feeding it the right context, and reviewing what comes back with a developer's eye. Anyone who thinks this job is typing clever sentences has not done it. It is software development where the typing got cheap and the judgement got expensive.

The architect. When code arrives faster than anyone can hold in their head, someone has to keep the system from quietly turning to soup. The architect decides the boundaries, the patterns, what the AI is allowed to touch and what it must not, and which shortcuts are acceptable this month versus which ones will strangle the project next year. On a three-person team this is less about diagrams and more about saying no at the right moments.

The tester. This is the seat we undersold in the original version, and we now think it is the one that decides whether the whole model works. AI-generated code looks right, reads well, and is wrong in quiet ways. When code is cheap, confidence is the actual product, and the tester is the person who manufactures it: acceptance tests that pin down what "done" means, property-based tests that hunt the edge cases, a pipeline where green genuinely means something. We made the fuller argument in AI Won't Replace Developers: It'll Make Testers the Most Valuable People in Tech.

Sharp-eyed readers will notice a seat missing from the original trio: the delivery manager. Outcomes, risk and rollout still matter, but on a team this small they are a hat, not a chair. Direction lives in the conversation with the client or the business, and the trio shares it.

Sometimes the team is one person

Here is the part that would have sounded absurd three years ago. With current tooling, one experienced engineer can hold all three seats, and we increasingly see it done well. Not by being superhuman, but by rotating deliberately: architect first, to set the boundaries before any code exists; prompt engineer through the day, directing the AI inside those boundaries; tester at the gate, where nothing merges until the contracts pass.

The rotation works because the hats check each other. The architect hat stops the prompt engineer hat from accepting convenient shortcuts; the tester hat stops both from believing plausible-looking code. The failure mode is equally clear: under deadline pressure the tester hat is the one that gets skipped, and with AI in the loop that is exactly the hat you cannot skip. A solo operator without a serious test suite is not a three-person team in one body. They are just fast.

What this means if you are buying software

If you run a small or medium business, this shift is quietly in your favour. You no longer need to fund a seven-person team for months to get real software built. A disciplined trio, or even a disciplined individual with the right pipeline, can deliver what used to be enterprise-budget work.

The word doing the work in that sentence is disciplined. Cheap code has also made it easier than ever to ship confident-looking rubbish. So when you evaluate a supplier, ask the three-seat questions: Who directs the AI, and how do they review its output? Who owns the architecture, and what is the AI not allowed to touch? And the one most suppliers cannot answer: who verifies the result, and can they show you the tests? If the last answer is vague, the price is not as good as it looks.