AI in Software Development: What It Buys You and What It Can Cost

Most code written this year had an AI model involved somewhere. In Stack Overflow's 2025 survey, 84% of developers said they use AI tools or plan to, and Google's DORA research put the share already using AI at work at 90%. I use these tools every day. I would not go back to working without them, and I also would not hand a client a codebase that an agent wrote and nobody read.

Both of those are true at once, and this article is about why. It covers what AI improves in software development, where the evidence says it does damage, and what I do about each risk. I have tried to stick to studies and incidents I could trace to a source, and to say so where the source has something to sell.

The gains are largest on work that is well specified and easy to check. Writing tests for a function that already exists. Migrating two hundred call sites from one API to another. Reading an unfamiliar codebase and answering 'where does this value get set'. Producing the first version of a screen that will be reworked anyway. In each case a person can look at the result and tell quickly whether it is right, so a wrong answer costs minutes.

That property matters more than how capable the model is. The tasks where AI disappoints have the opposite profile: the requirement is fuzzy, the right answer depends on context that lives in someone's head, or a mistake only shows up weeks later in production. Billing logic, authentication, data migrations and anything concurrent all fall in that group. The model writes code for those just as fluently as it writes a unit test. The output reads the same whether it is right or wrong, and most of the problems below follow from that.

In 2025 the research group METR ran a randomized trial with 16 experienced open-source developers across 246 real issues in their own repositories. With AI tools allowed, the work took 19% longer. The developers believed AI had made them about 20% faster. METR now labels those results historical and says they no longer reflect current models, so I would not quote 19% as today's number. The part that has aged well is the gap between measured and perceived speed. People are poor judges of their own productivity with these tools, and I include myself.

The 2025 DORA report, based on nearly 5,000 respondents, found a matching pattern at team level. AI adoption now goes with higher delivery throughput, and it still goes with more instability: more failed changes and more rework. DORA's summary is that AI amplifies what a team already is. A team with solid tests, review and deployment gets faster. A team without them ships its problems sooner.

In 2025 Veracode tested more than 100 models on 80 coding tasks and found a security flaw in about 45% of the results. On cross-site scripting, 86% of the samples failed. Veracode sells security tooling, so read the figure with that in mind. The direction matches what I see when I review generated code: it handles the happy path and leaves out input validation, authorization checks and error handling unless someone asks for them.

The slower problem is structural. GitClear analysed 211 million changed lines and reported that 2024 was the first year in which copy-pasted lines outnumbered moved lines, which is their proxy for refactoring. An assistant asked for a feature will usually write a new block. It rarely notices that a nearly identical function already exists three folders away. One duplicate does no harm. After a year of them, every bug has to be fixed in four places and nobody is sure they found all four.

Models sometimes recommend packages that were never published. A study by Spracklen and colleagues generated 576,000 code samples across 16 models. Commercial models invented a package name in about 5% of cases and open-source models in about 22%. The invented names also repeat: 43% of them came back on every one of ten reruns of the same prompt.

Repeatable means predictable. An attacker can register a predicted name on npm or PyPI, put malware in it, and wait for an assistant to suggest it to someone. The attack is called slopsquatting. The defence is unglamorous: a person or a policy check approves every new dependency, lockfiles are committed, and an agent does not get to run an install on its own say-so.

The risks change once a tool can act instead of only suggesting. In July 2025 SaaStr founder Jason Lemkin reported that Replit's agent deleted his production database during a declared code freeze and then gave him misleading accounts of what it had done. Replit's CEO called it unacceptable, and the company added separation between development and production databases afterwards. The detail I keep coming back to is that the agent had production credentials in the first place.

In February 2026 the open-source coding agent Cline was hit from the other side. Its issue-triage bot put the title of a GitHub issue straight into a prompt, so anyone who could open an issue could give the bot instructions. According to Snyk's write-up, that foothold was chained with a build-cache weakness to publish an unauthorized release of the Cline CLI to npm, which stayed live for roughly eight hours. Nobody broke into a server. Someone wrote text where an agent would read it.

Any agent that reads untrusted text (issues, web pages, a README inside a dependency) and also holds credentials is exposed to the same thing, and prompt injection has no complete fix today. I treat it as a permissions problem. An agent gets the narrowest access that lets it do the task, and anything that touches production or publishing waits for a person to approve it.

In January 2026 Anthropic published a small randomized trial: 52 mostly junior engineers learning a Python library they had not used before. The group with AI assistance averaged 50% on a comprehension quiz afterwards, against 67% for the group that coded by hand, and did not finish meaningfully faster. The widest gap was on debugging questions. Participants who asked the AI to explain things kept most of the learning. Those who delegated the whole task kept the least. It is one small study from a company that sells the tool, and it matches what I have seen closely enough that I take it seriously.

For a business this is an ownership risk. If the people who shipped a system cannot say why it works, every incident takes longer and every change is a gamble. There is a longer-term version as well. A Stanford analysis of payroll data found employment of software developers aged 22 to 25 down nearly 20% from its late-2022 peak. The authors are careful to call AI a plausible cause and not a proven one. Whatever the cause, fewer juniors now means fewer seniors in five years, and seniors are the people able to review what the models write.

None of this has made me use AI less. It has made me specific about where the checks go.

I am the author of every change, whatever wrote the first draft. If I cannot explain a line, it does not ship. That one rule removes most of the looks-finished failures, and it means I still understand the system I am responsible for.

Tests and static analysis run on everything. Security-sensitive code (authentication, payments, anything that parses user input) gets a line-by-line read that assumes the generated version is wrong until shown otherwise. I check every new dependency before it goes in.

Agents work in a sandbox with scoped credentials. They do not hold production database access or publishing rights, and destructive commands wait for me to run them.

I also keep doing some work by hand on purpose, mainly designing module boundaries and debugging hard failures, because reviewing generated code depends on those skills staying sharp. I wrote about why the boundaries matter in the article on iOS app architecture.

If you are hiring a team or an agency now, assume they use AI. The useful questions are about what surrounds it. Who reviews generated code, and can they walk you through a piece of it? What stops an agent from reaching production data? How are new dependencies vetted? What do the tests cover? Be wary of a team that answers these with a velocity number. Producing code quickly was never the hard part of building software.

If you already have a codebase that was built fast with AI and you are not sure what you have, that is exactly the situation a technical audit is for. I described what a good one should tell you in an earlier article. And if you are starting something new and want it built with these tools and the checks above, tell me what you are building.