Replacing your data analyst with tools and AI: where it works, where it doesn't

Ten years ago, delivering a moderately complex internal system meant one of two things. Either you found a full-stack developer who could hold the lot in their head — JavaScript, CSS, HTML, PHP, MySQL, plus enough operating-system knowledge to deploy it — or you assembled a small team and passed the work between specialists. Front-end to back-end to DBA to infrastructure. Each handoff had a meeting, a ticket, and a delay.

AI has not eliminated those specialisms. It has, however, materially changed what a single competent engineer can hold in their head, and how quickly. The result is faster delivery and a new problem: development is now outrunning support.

The old shape of a project

A typical small operational system, pre-AI, looked like this:

• A back-end developer for the database, models and APIs.
• A front-end developer for the screens and the JavaScript.
• A designer or design-conscious developer for the CSS.
• Someone for the deployment, the server, the backups, the SSL certificates.
• Someone, often the project manager, holding the requirements and translating between everyone.

The full-stack developer who could do all five existed but was rare and expensive. The team version was more common and more expensive in a different way — the cost of coordination, the latency between “the API is ready” and “the front-end uses it”, the eternal mismatch between what the back-end exposed and what the front-end actually needed.

Either way, a small operational system was a six-month engagement, and a meaningful change to a live system was a fortnight.

What changed

A senior engineer with AI assistance does not become a different person. They become a person with much less friction at the boundaries between specialisms.

• The MySQL query they would have asked the DBA to write — they write it themselves, and the model checks it.
• The CSS layout that would have taken an hour of trial-and-error — they describe what they want and get a starting point in seconds.
• The unfamiliar piece of legacy JavaScript — they ask the model to explain it before changing it.
• The deployment script for a new piece of infrastructure — the model writes the first draft, the engineer reads it, fixes the wrong bits, runs it.

None of these are new skills for the engineer. They are old skills that have become much faster to deploy. The cognitive cost of switching between “I am writing back-end code” and “I am writing CSS” used to be high enough that teams specialised to avoid it. The cost has dropped, and so the specialisation matters less.

The result is that a single senior engineer can now deliver, in two months, what a three-person team used to deliver in six. That is the headline. The footnote is more interesting.

The hidden constraint: support

Software does not stop on the day it goes live. From the moment it is in use, it generates a steady stream of support work: questions, training, small adjustments, bug reports, change requests, integration with the next-bought tool, reports the users want that the system does not yet produce.

For most internal systems, the support work over five years dwarfs the build work. A six-week build that runs for five years will, on average, generate something between three and twelve months of cumulative support effort in that time. The exact ratio depends on the breadth of the system, the size of the user base, and how often the surrounding business changes.

And here is the awkward truth: AI has made the build phase between two and four times faster, but it has not made the support phase faster by anything like the same factor.

Support work is not boilerplate. It is conversations with users, judgement calls about which requested change is real and which is a workaround, code archaeology in an unfamiliar part of the system, small careful changes with low blast radius. The model helps, but the human work dominates.

What happens when build outruns support

Three things, in sequence.

1. The backlog of small changes grows

Each user’s “could we just add a column for X” lands in a queue. The build team are off building the next system, because they can. The queue grows. The users start losing trust that small changes will ever happen, and they revert to spreadsheets to handle the bits the system does not yet cover.

This is how a brand-new system, eighteen months in, has its own shadow spreadsheet next to it.

2. The system starts to feel inert

A system that does not change feels old, even when its code is six months new. Users notice. Trust degrades. The next round of investment goes into replacing the system rather than improving the one that was just built.

3. The build team accumulates technical debt at higher speed

AI-assisted development produces a lot of code. If nobody is reading it carefully, it accumulates the kinds of inconsistencies that compound — slightly different patterns in different parts of the system, hardcoded values, near-duplicate models. The support team inherits all of it and has to make sense of it. The support team did not write it. The model did not write it either, in the way that matters. Nobody really wrote it, and it shows.

What we have changed in our own practice

We have made three structural changes since AI moved from experiment to default tool. None of them is technical. All of them are about pacing.

Build to a support budget, not a calendar. When we estimate a project, we now estimate the cumulative support cost over a five-year window before we agree the build scope. A system that we can build in eight weeks but will require half a developer-day a week to keep running is sometimes a worse deal than a smaller, simpler system that takes ten weeks and runs itself.

The engineer who builds it owns it for the first year. Not forever. But for long enough to feel the consequences of every shortcut they took. This is the cheapest discipline we know for keeping AI-assisted code honest.

Slow the release cadence on purpose. We can ship features faster than the users can absorb them. Most weeks the right move is not to. The discipline is to write the feature, sit on it for a sprint while the users adjust to last week’s changes, and release it when they are ready. The build team finds this counter-intuitive. The users find it deeply reassuring.

The new shape of a small team

For us, the team that delivers a small operational system now looks like this:

• One senior engineer who can hold the whole stack, supported by AI for the bits outside their daily groove.
• One product-minded operator who spends as much time with the users as with the engineer.
• A reviewer — sometimes a second engineer, sometimes a consulting partner — who reads every change and asks the awkward questions.

The team is smaller than the old five-person version. It is also slower per feature than the headline suggests, because the discipline of “build at a pace the users can absorb” is more important than the discipline of “ship as fast as possible”.

That is the shift. Not fewer skills required; the same skills, in fewer people, applied with more judgement about when not to use them.

If you are thinking about how to size a team for an AI-era internal system, we are happy to compare notes. The trap is sizing for the build phase and forgetting that the system you ship in eight weeks will need to be loved for five years.