Is it bad for developers to use AI? It depends on who does the thinking

A pull request lands on a Friday afternoon. It is clean, the tests pass, and it was written in about an hour. You ask the developer one question: why does it cache the result there? They don’t know. The AI wrote it, it worked, and they moved on.

That moment is the whole argument about developers and AI in one scene. Nobody serious is asking whether AI can write code anymore. It can. The real question is who is doing the thinking.

I build WordPress themes and plugins, I run a production website, and I teach web development part-time. I use AI every day. Here is where I think the line is, and what the research says about each side of it.

Am I cheating the development process if I use AI?

It depends on who did the thinking. If you vibe coded the whole thing and couldn’t tell me what it does, then yes, you skipped the part of the job that matters. If AI helped you while you kept doing the critical thinking, deciding the approach, reading every line and testing it, then no. That is using a good tool.

Andrej Karpathy coined “vibe coding” in February 2025 for a way of working where you describe what you want, accept whatever the AI produces and stop reading the code. He was describing weekend projects, and for those it is fine. A throwaway prototype, a script you will run once, a quick experiment to see if an idea holds up: vibe away.

The trouble starts when vibe-coded work ends up in production. Payments, logins, forms that collect personal data, anything a customer depends on. There, “it seemed to work” is not a standard.

So the test I use is simple. Could you explain this change to a colleague without the AI open? Could you defend why it is built this way and not another? Could you fix it at 2 a.m. when it breaks? If the answer is yes, you used a tool. If it is no, you handed over the job.

Does AI actually make developers faster?

Sometimes, and less often than it feels. The most cited evidence comes from METR, a research group that ran a randomised trial in early 2025 with 16 experienced open-source developers working on 246 real tasks in projects they knew well. Each task was randomly assigned: AI allowed or not. With AI allowed, tasks took 19% longer.

The part that stuck with me: before the study, the developers expected AI to make them about 24% faster, and even afterwards they believed it had made them about 20% faster. The feeling of speed and the speed itself pointed in opposite directions.

METR ran the experiment again in late 2025 with newer tools and published an update in February 2026. This time the estimate pointed the other way: about 18% faster for the developers who came back, and about 4% faster for new recruits. But METR called its own data weak. Many developers now refused to work without AI at all, and some held back tasks they did not want to do by hand, so the study was missing exactly the people and tasks where AI helps most. Its honest conclusion was that developers are probably faster than they were in early 2025, and that nobody can yet say by how much.

That doesn’t mean AI never helps. My read is that these developers knew their projects deeply, which is where AI has the least to add. On boilerplate, unfamiliar syntax or a first draft of tests, the gain can be real. But you can’t trust the feeling. If you want to know whether AI makes your team faster, measure the time from starting a task to shipping it, including the review and the fixes, not the time it took to get a first version on screen.

The speed you feel is not the speed you ship.

Should AI change your development process?

No. AI should be a tool, not a process. Your process stays where it is: understand the problem, decide the architecture, write the specification, build, review, test, release. AI is something you pick up inside those steps to reach the destination with less effort or fewer mistakes. It is not the route.

A lot of companies have this backwards. They adopt AI to expedite the process, then measure success by how much faster code appears. Somewhere along the way the real goal gets lost. Users don’t care how quickly the code was generated. They care whether the thing you shipped matters to them and keeps working.

Google’s DORA research programme found the same pattern from the other direction. Its 2025 report on AI-assisted software development, based on a survey of nearly 5,000 technology professionals, found that about 90% of them now use AI at work, and that AI acts as an amplifier: it magnifies the strengths of teams that already work well and the problems of teams that don’t. A team with a clear process gets a faster, sharper version of itself. A team without one gets more chaos, sooner.

So before asking how AI can speed up your process, make sure you have one worth speeding up.

Is “treat AI like a junior developer” good advice?

Only if you know how to lead a junior. It is one of the most repeated pieces of advice in the industry right now: treat AI output like a pull request from a fast junior developer. Read it, question it, test it, and never merge it on trust.

As far as it goes, that is right. The catch is the word “junior”. Leading juniors is a skill of its own. When I have led developers and mentored juniors, the work was never only reading their code at the end. It was setting the architecture before they started, writing a spec clear enough that it could not be misread, holding the standards, and recognising a wrong turn early.

Treating AI as a junior without that experience doesn’t work. If you can’t set the base, the AI will set it for you, and you won’t know whether it is sound. If the base is built on sand, the foundation is shaky, however good each file looks on its own. Garbage in, garbage out: a vague prompt from someone who doesn’t know what good looks like produces confident, plausible code that is wrong in ways they won’t catch.

The advice should really be: treat AI like a junior, if you are qualified to lead one. If you aren’t yet, that is the skill to build first.

Is AI-written code safe to ship?

Not without a proper review. Veracode’s 2025 GenAI Code Security Report tested more than 100 language models on 80 coding tasks and found that the generated code introduced security flaws from the OWASP Top 10 in 45% of cases. Cross-site scripting was the worst: the models failed to defend against it in 86% of the relevant tasks, which matters to anyone who builds WordPress themes and plugins, where escaping output is daily work. Newer models got better at writing code that works, but no better at writing code that is secure, and bigger models did not do significantly better than smaller ones.

There is a quieter risk too. A study of package hallucinations presented at the USENIX Security Symposium in 2025 had 16 models write 576,000 code samples and checked the 2.23 million packages those samples asked for. 19.7% of the packages did not exist. For commercial models the rate was at least 5%, for open-source models about 22%. Attackers have noticed: they publish malicious packages under the names models tend to invent, so a developer who installs whatever the AI suggests can pull malware straight into the project. It has a name now: slopsquatting.

None of this means AI code is worse than human code by default. It means AI code needs the same review a person’s code gets, plus a few extra checks:

• Read every line before it ships, especially anything that handles input, output, logins or personal data.
• Check that every package the AI adds really exists, is maintained and is the one you meant.
• Run your security scans and tests on AI changes exactly as you would on anyone else’s.
• Be wary of code that looks finished. Plausible is not the same as correct.

Can AI make you a worse developer?

It can, if you let it do your learning for you. In January 2026 Anthropic published a randomised study of 52 mostly junior engineers learning Trio, a Python library none of them had used before. Some had an AI assistant; the rest coded by hand. Afterwards, everyone took a quiz on what they had just used. The AI group averaged 50%, the hand-coding group 67%. The biggest gap was in debugging, the skill you need most when AI-written code goes wrong. And the AI group was not meaningfully faster.

The detail that matters most is how people used the assistant. Those who asked conceptual questions, asked for explanations alongside the code, or asked follow-up questions to check their understanding kept most of their learning. Those who simply handed over the task, or leaned on AI more and more as they went, did worst.

I see the same thing in teaching. Two students can hand in the same working contact form. Ask each of them to add one more validation rule, and the difference shows straight away: the one who asked why the code works makes the change in a few minutes, while the one who pasted the answer starts again from a fresh prompt. The students who get stronger with AI are the ones who ask it why, not just to write it.

If you are early in your career, this is the section that matters most. Use AI as a tutor that explains, not a ghostwriter that does the work. The day something breaks in production, you will need the understanding you built, not the code you copied.

How do I use AI without handing over the job?

I keep the thinking and give AI the parts that don’t need it. This is how I work, as a checklist you can copy:

1. The architecture is mine. I decide how the pieces fit together before any code is written.
2. The specification comes first. I write down what the code must do, and what it must never do, before I ask AI for anything.
3. The base and the critical code are mine. Anything the rest of the system depends on, I write myself.
4. AI helps me go faster on the routine parts: boilerplate, repetitive changes, first drafts.
5. AI stress-tests what I build: edge cases I may have missed, a second opinion on an approach, tests I hadn’t thought to write.
6. I review every change before it ships. If I can’t explain it, it doesn’t merge.
7. User journeys are tested end to end with Playwright, so the flows people depend on are checked in a real browser, whoever wrote the code.

There is more on how I work with AI on the homepage, and on how I have led and taught developers on the About page.

What should teams and hiring managers expect?

Expect everyone to use AI, and judge them on whether they understand what they ship. Stack Overflow’s 2026 Developer Survey, published in October 2026 with more than 30,000 respondents, found that 66% of developers who use AI use coding agents, and 73% of those who use AI assistants or agents do so every day.

Trust is a different story. In Stack Overflow’s 2025 survey, only 33% of developers said they trusted the accuracy of AI tools, down from 43% the year before. In 2026, 93% said they need to see where an answer came from before they trust it. And developers are drawing their own line: only 20% use AI to deploy, operate or troubleshoot production systems.

For teams, that means:

• Don’t ban AI, and don’t mandate it either. Expect it, and keep the same review standard for every change, whoever or whatever wrote it.
• Measure what you ship and how often it breaks, not how fast code appears.
• Make the architecture and the spec someone’s job before AI is involved.

For hiring managers, asking “do you use AI?” tells you nothing now. Ask candidates to walk you through code they wrote and explain the decisions in it. Ask what they would check before merging an AI-generated change. The developer who can answer those questions is the one you want, with or without AI.

Before you merge your next AI-assisted change, try explaining it out loud without the AI open. If you can, ship it. If you can’t, that is not a reason to stop using AI. It is a sign of where the thinking still needs to happen.