AI can now write much of the routine code, so development teams can be smaller and the work is shifting from typing code to specifying, reviewing and testing it. From what I've seen, experience matters more, not less: knowing what good looks like, spotting what the AI got wrong and owning the result is still a human job.
I was a day-one developer on Microsoft Access v1, and I cut my teeth on Pascal and COBOL when they were the industry standard. For most of the years since, I've led development teams rather than written the code myself. In 2024 I got back on the tools, this time with AI beside me, and I've been building with it every working day since.
This article is what I've learnt about how AI is changing development teams, and an answer to the question I get asked most: with AI writing the code, does experience still matter? It does. I think it matters more than it did.
I first wrote about this in February 2025, in The Future of Development Teams in an AI-Augmented World, when I'd been back on the tools for a few months. That article stays up as it was. This one asks the same question again, after another year and a half of daily use and with the research that's come out since. Most of it has moved on.
What is an AI-augmented development team?
An AI-augmented development team is a team of developers who use AI assistants and coding agents as part of everyday work, with people still responsible for design, review and delivery. The AI does a share of the writing. The team does the deciding.
There are two kinds of tool, and they change the work in different ways. An assistant suggests code while you type. GitHub's own description of Copilot is that it suggests code as you type, answers questions about a codebase, reviews your changes, and works on tasks you assign it (GitHub Docs, 2026). You stay at the keyboard and accept or reject each suggestion. An agent takes a task and makes changes across a codebase. Anthropic describes Claude Code as an agentic coding tool that "reads your codebase, edits files, runs commands, and integrates with your development tools" (Anthropic, 2026). GitHub's Copilot cloud agent "can research a repository, create a plan, make changes on a branch, and open a pull request for review" (GitHub Docs, 2026), and GitHub's own risk notes say its pull requests must be reviewed and merged by a human. The agent can't approve or merge its own work.
That last point is the whole shape of an AI-augmented development team in one sentence. The tools can now do a large share of the typing. What they can't do is take responsibility for the result. I see this from both sides of the fence. I've been in technology since 1994, and you can read the full career on the Damian Hartin home page. I founded Hartsco in 2011 and I'm still its Founder and CEO. And since 2024 I've been writing production code again, with AI assistants and agents as part of every day.
What has actually changed in day-to-day development work?
The biggest change I've seen is where the time goes: less of it writing boilerplate, more of it explaining what I want, reading what comes back and testing it properly.
A concrete example. At the start of 2025 I built a full-stack application in React with a Node.js backend, neither of which I'd touched before. It went from concept to deployment in two weeks. Earlier in my career that would have been months of learning the JavaScript ecosystem, React's component model and a modern deployment pipeline before a line of useful code existed. The AI wrote with me, but it was also the documentation, the mentor and the debugging partner. An authentication system that once would have taken weeks of research and building took days. I could describe the requirements and the security principles in plain English, leave the implementation detail to the AI, and concentrate on the architecture.
Not everything got faster. The tasks that resisted were the ones where the hard part was never the code: working out what the business actually needed, deciding how two systems should share responsibility, or untangling a problem where the requirements were the real bug. The AI could write any of the options quickly. Choosing between them was still my job, and no quicker than before.
So the working day has a different shape. I spend far less time typing and far more time specifying, which means writing down what I want clearly enough for a machine to act on it. Then I read. I read every change that comes back the way I'd read a pull request from a new team member, then I test it, because the only thing worse than code that fails is code that fails quietly. Leading a team that works this way every day is a bigger subject, and I'll come back to it in a separate article.
The same hands-on habit runs through my other experiments with AI. The personal AI images with LoRA I wrote about earlier came from it too: if you want to know what a tool really does, use it on something that matters to you.
Does experience still matter when AI writes the code?
Yes. AI produces code that looks right far more often than it is right, and experience is what lets you see the difference before it reaches production.
Three things can't be handed to a model. Judgement: knowing which of several working solutions will still be working in five years. Architecture sense: seeing that a change which passes every test has quietly coupled two parts of the system that should never have met. And business context: knowing why a rule exists, which is the only way to tell when the AI has implemented it wrongly in a way that still passes the tests you wrote.
The failures are specific, and anyone who's used these tools for a while will recognise them. I've had an agent fix the function I asked about and, in the same change, rewrite a working function nearby into something subtly different. I've had it call a library method that doesn't exist, with complete confidence. I've had it report that the tests passed when they hadn't been run. None of that is a reason not to use the tools. It's the reason an experienced person has to read the output. The 2025 Stack Overflow Developer Survey found the biggest single frustration, cited by 66 per cent of developers, is "AI solutions that are almost right, but not quite", and that experienced developers are the most cautious of all, with the lowest "highly trust" rate (2.6 per cent) and the highest "highly distrust" rate (20 per cent) (Stack Overflow, 2025). Those are the people who've seen what almost right costs.
The lessons from enterprise systems carry over directly. Migrating over 50 billion rows between energy retailers' systems taught me that the expensive mistakes are the plausible ones: they pass the obvious checks and surface months later. AI output needs exactly that kind of scepticism. How to review AI-written code before it ships deserves its own article, and I'll write it. The short version: review it as if a capable stranger wrote it, because one did.
What does the research say about AI and developer productivity?
The measured evidence is mixed: developers report heavy and growing use of AI tools, but controlled studies haven't all found that it makes experienced developers faster.
Usage is close to universal. The 2025 Stack Overflow Developer Survey reports that 84 per cent of respondents are using or planning to use AI tools in their development process, up from 76 per cent the year before, and that 51 per cent of professional developers use them daily (Stack Overflow, 2025). Trust hasn't kept pace. More developers actively distrust the accuracy of AI tools (46 per cent) than trust it (33 per cent), and positive sentiment fell from above 70 per cent in 2023 and 2024 to 60 per cent in 2025.
Google's DORA research tells a similar story at the team level. The 2025 State of AI-assisted Software Development report found 90 per cent of its nearly 5,000 respondents use AI at work and more than 80 per cent believe it has increased their productivity, while 30 per cent report little or no trust in the code it generates (DORA, 2025). Its central finding is that "AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones." On delivery, the 2025 report says AI adoption now improves software delivery throughput, a reversal from the 2024 report, which had estimated a 1.5 per cent reduction in throughput and a 7.2 per cent reduction in stability for every 25 per cent increase in AI adoption (DORA, 2024). But the 2025 report is plain that AI adoption "still increases delivery instability", and that teams are adapting for speed before their systems have evolved to manage it safely.
The sharpest result is from METR. In a randomised study published in July 2025, 16 experienced open-source developers worked on 246 real issues in large repositories they had contributed to for years, mostly using Cursor Pro with Claude 3.5 and 3.7 Sonnet. When AI was allowed, they took 19 per cent longer. They'd expected to be 24 per cent faster, and even after the study they believed AI had sped them up by 20 per cent (METR, 2025). METR was careful about the limits: it called the result "a snapshot of early-2025 AI capabilities in one relevant setting", didn't claim its developers represent most software work, and said AI is plausibly useful for less experienced developers or in an unfamiliar codebase. In February 2026 it published a follow-up with 57 developers and said the original results are now out of date and that developers are likely faster with AI than in early 2025, while warning that its newer data is only weak evidence, because so many developers now refuse to work without AI that the experiment itself is skewed (METR, 2026).
My reading of why perception and measurement disagree: the time AI saves is visible and the time it costs isn't. You see the function appear in seconds. You don't count the twenty minutes spent reading it, the test it broke two files away, or the afternoon lost to a design the AI chose and you accepted without thinking it through. The people in these studies and surveys aren't lying about feeling faster. They're measuring the wrong thing, and so was I until I started keeping track.
What happens to team size and roles?
Some work that needed several people can now be done by fewer, but the people who remain carry more of the responsibility: for where the work goes, whether it's any good, and whose name is on it.
This is my view, not a forecast I can prove. A team that once needed a developer for every stream of routine work needs fewer of them, because routine work is where AI is strongest. What it still needs, and I think needs more of, is people who can turn a vague business need into a precise specification, people who can review a large volume of generated code without their attention fading, and people who'll put their name on what ships. Those have always been senior skills. The difference now is that they're most of the job.
The obvious worry is where the next generation of seniors comes from if the AI takes the junior work. I don't think the answer is as bleak as it sounds, but it deserves more than a paragraph, so I'll take it up separately.
What has not worked for me?
Plenty. AI has cost me time as well as saved it, and the failures are as useful as the wins.
The most expensive pattern has been accepting a design the AI proposed because it was quick and looked reasonable, then paying for it weeks later when the system grew and the design didn't fit. The second is scope creep inside a single request: ask for one fix, get the fix plus three improvements nobody asked for, each of which has to be read and some of which have to be reversed. The third is the confident wrong answer: the invented API, or the test reported as passing. Each of these cost me more than an hour. The first one cost me days.
What I changed was simple. I now write the specification before I write the prompt, and I keep it. I ask for small changes, one at a time, and I read every one. I run the tests myself rather than taking the AI's word for it. And when a design decision matters, I make it, then ask the AI to implement it, rather than the other way round. The tools haven't got worse. I've got better at knowing where they stop.
So here's where I've landed after more than a year of daily use. AI has made me faster at the work I already knew how to do, and it's made my experience worth more, not less, because the scarce skill is no longer writing the code. It's knowing whether the code is right. If you've found it otherwise, I'd like to hear about it: info@damianhartin.com. There's more of my writing on AI and software development on the articles page.
The views here are my own. This article was written with AI assistance.
Common questions
- Will AI replace software developers?
- Not in my experience. It replaces a share of the typing, and it moves the human work to specifying, reviewing and owning the result. The tools themselves are built around that: GitHub’s agent can’t approve or merge its own pull requests.
- What is an AI-augmented development team?
- A team of developers who use AI assistants and coding agents as part of everyday work, with people still responsible for design, review and delivery. The AI does a share of the writing and the team does the deciding.
- Do AI coding tools make experienced developers faster?
- The measured evidence is mixed. METR’s 2025 randomised study found experienced open-source developers took 19 per cent longer with early-2025 tools, while believing they were faster, and its 2026 follow-up says developers are now likely faster but the data is weak. My own results depend on the task.
- What skills matter most when AI writes the code?
- Writing a precise specification, reviewing generated code with full attention, testing it yourself, and the judgement to know which of several working answers will still be right in five years. Those were always senior skills. Now they’re most of the job.
- Should a team let AI write code that goes into production?
- Yes, with the same gate as any other code: a human who understands the system reads it, the tests run, and someone puts their name on it. The risk isn’t AI-written code. It’s AI-written code nobody read.
Sources
- Stack Overflow, 2025 Developer Survey, AI section
- DORA (Google Cloud), State of AI-assisted Software Development 2025
- Google Cloud, Announcing the 2025 DORA report (24 September 2025)
- DORA (Google Cloud), Accelerate State of DevOps Report 2024
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10 July 2025)
- METR, We are Changing our Developer Productivity Experiment Design (24 February 2026)
- Anthropic, Claude Code overview
- GitHub Docs, About GitHub Copilot
- GitHub Docs, About GitHub Copilot agents
- GitHub Docs, Risks and mitigations for GitHub Copilot cloud agent