The four stages every developer goes through with AI

Almost every developer who joins one of our AI-led projects goes through the same four stages, in the same order. Whether it works out for them is settled in the third.

AI itself isn't new at TSD. We've built systems on machine learning and Bayesian classification for the best part of fifteen years, long before anyone put the label on a sales deck. The change over the last couple of years is who uses it. A few of us used to build it into specific products. Now the whole team leans on it every day, for writing code and for running the business.

We've built several systems almost entirely with AI agents, and our development cycle has settled into a shape we're happy with. Watching new team members join that process has been the interesting bit. I've had enough conversations about it lately, inside TSD and out, that it seemed worth writing down.

This is the first of three posts on what AI has changed for us, starting with the development team. The next two look at operations and the wider business.

Stage 1: Awe

The first week is great fun. You describe a feature, and a few minutes later there's working code and a migration, plus tests you never asked for. Most people start doing the maths on how much faster everything is about to get.

Stage 2: Reading the code

Then you sit down and read what it wrote.

Some of it is very good. Some of it picks a pattern that would suit plenty of codebases and happens to clash with yours. Now and again it solves the problem you described, and you realise you described it slightly wrong. You still can't ship any of it unread.

Stage 3: The micromanager

People stall here for a while. Scepticism creeps in, sometimes tipping into cynicism, and developers start steering. Prompts get longer. Every step gets checked before the next can begin, until the agent is on such a short lead that writing the code by hand would be quicker. Which, of course, confirms the scepticism.

Anyone who cooks low and slow knows the rule: if you're looking, you're not cooking. Each time the lid comes up the heat goes out, and a brisket that should take ten hours takes fourteen.

Agents respond to the same treatment. Do the work before the lid goes down. Write a clear brief and the constraints, agree what done looks like, and have tests ready to prove it. Then leave it alone and judge what comes out.

Why our managers got there first

At TSD, the people who move through this fastest tend to be the ones who already manage people.

Managing well takes two things. One is subject knowledge, knowing what good looks like and spotting when something's off. The other is people skills, and an agent has no use for those. Phrase things however you like; a blunt code review won't ruin its week. We still encourage the team to say please and thank you, partly out of habit and partly in case our future overlords are keeping notes.

So directing agents suits a particular kind of developer, the excellent engineer who has no wish to run a team. It draws almost entirely on what they already know.

Their stumbling block is the one every new manager hits. You have to let go of doing the work yourself, hand over the outcome you want, and let someone else work out the steps. Our managers learned that years ago, mostly the hard way. For a developer it's a new lesson, and the micromanager stage is what learning it looks like.

Stage 4: Delegation

Developers who make it through hand the agent an outcome and spend their own time on the specification and the review. The agent gets on with the bit in the middle, and the code quality comes good.

Gartner drew this curve for whole technology markets back in the nineties.

The Hype Cycle climbs to a peak of inflated expectations, drops into a trough of disillusionment, then works up a slope of enlightenment to a plateau of productivity. Each of our developers runs the whole thing personally, in a matter of weeks. I've yet to see anyone skip the trough.

What's on the other side

Once the team reaches stage four, our delivery timelines stay about where they were. I hadn't expected that.

The output is where the difference shows. Every method has unit tests wrapped around it, with documentation alongside, and a small team ends up delivering to a standard that used to take an enterprise-sized one.

METR's research lines up with our experience on speed. They ran a randomised controlled trial in early 2025 with experienced open-source developers working on their own codebases. With AI tools allowed, the developers took 19% longer to finish tasks, and afterwards believed they'd been around 20% faster. METR then tried to repeat the study with newer tools and couldn't get a reliable result, partly because so many developers declined the tasks where AI wasn't allowed.

That refusal tells me more than the 19% does. I'm fairly sure our team would turn those tasks down too, and the reason they'd give is the quality of what comes out.

The catch

Thoroughness costs something, and I'm less sure we've got this bit right.

Most of our projects are mid-market builds. They need rigour, at a level well short of what you'd put around a banking platform. An agent that wraps tests and documentation around every method by default is doing good engineering, and it's also adding overhead the project may not need. Someone still has to review and maintain all of it, and the client pays for that time.

Requirements have gone the same way. AI makes it easy to think a brief through in fine detail, so our product requirement documents have grown. Many are excellent. A few are overkill for the size of the job.

I'd put the level of rigour in the scope, agreed with the client up front. Left to its own devices, the agent defaults to maximum every time.

Two side effects

I have more side projects open than at any point in twenty-odd years. Once starting something costs almost nothing, you start a lot of things. Some have shored up work we already had running, and plenty are half-baked ideas sitting in a folder.

The other side effect is more serious. Ask an AI to build you a wall and it will build you a wall. As someone put it to me recently, the trouble is knowing what that wall is made of. You might have needed stone and been given timber, and to an untrained eye both look like a wall.

We keep coming across systems assembled from components that each look sensible on the surface, quietly pulling in enterprise machinery a business of that size would never need. The people who built them aren't engineers, so they'd have no way of knowing. A few months ago I wrote about a 120MB home page, and it had the same root cause.

Knowing what the wall should be made of is what our developers bring to stage four. I suspect AI will close that gap too, possibly soon. Until then, it's what makes code worth owning.

From the trenches

Here's what we've learnt the hard way, for anyone setting this up.

Treat your skills like code

Most of what makes an agent useful to us lives in skills. A skill is a folder of instructions, sometimes with scripts or reference files alongside, that the agent loads when a task calls for it. Ours cover everything from code review checklists to how a ticket should be written.

It's tempting to keep them wherever you happened to write them, at which point any improvement stays with whoever made it.

We keep ours in a shared GitHub repository. Anyone on the team can add or change a skill, every change is tracked, and each skill carries a changelog saying what changed and why. If an agent starts behaving oddly, we can find the edit that caused it and roll it back. And when reviews keep catching the same mistake, the fix goes into a skill so every agent on every project knows about it from then on.

If you take one thing from this post, make it this one. A skill in a shared repository keeps paying back across the whole team, long after the chat where someone first worked it out has scrolled out of sight.

Build the reviews into the pipeline

Our development pipeline runs from ticket to pull request with the reviews built in. Tickets come in from Productive, our project management tool. A planning agent reads each one, looks for gaps in the requirements and turns the acceptance criteria into things that can be tested. Implementation agents build the change and its tests, in parallel where they can, and the build and test suite both have to pass before anything moves on.

Two review agents then go over the work at the same time. One behaves like a senior tech lead, checking the architecture and running the code against our quality checklist. The other hunts for security problems, from authentication to how input gets validated. Whatever they flag is fixed and reviewed again. Only then does a pull request open, with the evidence attached, to go through GitHub Copilot's review and the CI build. A human still merges every change.

For an SME, this is the big win. A dedicated security review on every change was never realistic for a team our size. Now every change gets one, and nobody has to remember to ask.

People struggle with it at first, though, and I think it's stage three again. Anyone who still wants to steer every step is handed a process that runs from ticket to pull request on its own. It feels like losing control.

Being clear about where the pipeline stops and asks has helped. We approve omissions automatically and send deviations to a person. If the agent adds error handling or input validation the ticket implied but never spelt out, it carries on. Something nobody asked for gets flagged for review. A change to what was asked for halts the pipeline until someone signs it off.

The same rule accounts for a fair amount of the extra thoroughness I mentioned earlier, since tests and error handling count as omissions and always go in.

Whenever a reviewer, human or Copilot, spots something the agents missed, it goes into the checklist the review agents work from. Nobody should have to make the same comment twice.

Plan for the trough

Warn new starters about the trough on their first day, so they recognise it when it arrives. Then put your developers' time into the brief and the tests, which is where it pays back now.

Track quality and rework alongside speed. If speed is the only number you watch, you'll conclude it isn't working and pull the plug just before it starts to.

And decide how much rigour each project needs before the agent decides for you.

Next time: the biggest gains we've had came from work we'd always meant to do and never found time for.