The Architect Developer

I have generally felt that a solution architect is the most important person on a software project. They should be the one who decides what gets built and who understands how it hangs together and who typically spends most of their energy getting other people to build it.

I spent a year training and work experience doing something gloriously old-fashioned: Systems Analysis, Design and Programming. The course covered all three, often on the assumption that the same person would sit with the business to work out what was needed, design the solution, and then write the code. Analysts, designers and developers were not three people. In small businesses, they were often three things a system analyst was expected to do before we had cloud systems and enterprises that scaled massively.

Many larger organisations have spent the decades since pulling these functions apart. Building was slow and expensive, so you needed a team, and the work split into specialists: business analysts to capture the requirements, architects to design, developers to build. The gaps between them were where projects failed - handover documents nobody read, and the thing that got built was never quite the thing that was designed.

That split is now closing, and it is changing who does what.

The build stopped being the bottleneck

When a well-grounded repo, with its agents and subagents, can do three weeks of a developer’s work in an afternoon, the economics that justified the split fall apart. The architect no longer has to hand the design over and hope. They will likely be able to build it themselves, or close enough to it, and find out within the hour whether the design actually holds together.

I have felt this directly. I have worked on projects as the person who designed systems and then worried about missing something while other people wrote the code. Lately I have been building the things I used to delegate, not because I suddenly have more hours, but because the building stopped being the part that ate the hours. Design and build have collapsed into the same activity, and so has the analysis that used to come before them. The person doing all three is not new at all. It feels like a systems analyst role I trained as decades ago - part business analyst, part architect, part developer when everything was written in VB6. Call it the architect-developer: the same old role, now able to build, with no friction at all, the thing it has just analysed and designed.

So how big is the team?

If in some scenarios an experienced person with a good agent and a harness can do what used to take five people a month, how big does a team need to be?

I do not think the answer is “one”. Big systems still need more than one head, if only to have someone to disagree with. But the shape changes - you need fewer hands turning a design into code, because that could be automated now, and you need more judgement about what to build, whether it is right, and what to do when it is wrong. Initially, the instinct is that the team gets smaller and more senior. Not because juniors have nothing to offer, but because the work that used to be theirs has moved. But as an industry we have a responsibility to find more appropriate work for the juniors so they can become senior.

When rework is cheap, do we need change control?

There is a knock-on effect that matters more than the headcount question. For decades our main way of controlling a project was built around the fact that building was expensive and rework was painful. Sign-offs, change requests, scope freezes, sprint commitments, the careful protection of the build from anyone who might want to alter it. A main reason for that was that changing your mind late used to cost a lot of money.

When building is cheap and rework is fast, that machinery starts to look strange. If I can rebuild the screen from the new requirement in ten minutes and we have a Playwright regression test suite built up front, what is a change request protecting me from? The slow, expensive work may no longer live in the build. The cost often lives in updating the ceremonial artefacts - the user stories, the governance, the sign-offs and working out who is allowed to want what.

The bit that is hard

We are changing what we are asking people to be good at. For a long time we rewarded people for being fast at the build, the ones who could close the most tickets, who could triage bugs the fastest, who understood the code. That skill is depreciating in front of us. The skill that is appreciating is older and harder to teach: knowing what is worth building, noticing when the thing being built is wrong, and carrying the judgement that no agent will give you.

So I do not think developers disappear as AI gets better. Developer and architect roles will become more blurred, and those who can build harnesses with guardrails that juniors can use effectively will be hard to compete with.