Do I use AI?
Of course. The question is: how?

“Do you use AI when programming?”

I have been asked this quite often lately.

Each time, I want to answer with another question.

Do you use a compiler?

A debugger? IDE autocomplete? Power steering?

When you have a lot of wood to cut, do you use a chainsaw or a handsaw so nobody thinks you took the easy route? :D

Of course I use AI.

AI is a tool.

To me, the more interesting question is not:

“Does the developer use AI?”

but:

“What can they do without it, and do they understand what AI did for them?”

Developers have always used automation

Programming has never meant doing everything manually.

The compiler took over translating source code into executable form. The IDE suggests syntax, finds definitions and refactors code. The debugger lets you pause a program and see what is happening inside.

Version control solves problems that developers once tried to solve with folders:

…do not ask how I know this example :D

Then came frameworks, libraries, package managers, code generators, static analysis, CI/CD and thousands of other tools.

Nobody sensible insists that a real programmer must write their own TLS library, HTTP server and preferably a compiler as well.

Abstraction and automation are part of computing’s history. Generative AI is another tool in that line.

There is, however, one important “but”.

AI is not a compiler

The compiler comparison illustrates that using a tool does not remove human competence. Technically, however, the comparison is imperfect.

A compiler performs a precisely defined operation. A language model generates an answer from patterns learnt during training and the context it has just received.

It can produce an excellent function, a good test or a sensible explanation of a bug — then invent a library method that has never existed.

With exactly the same confidence.

That is why, for me, AI is more like a power tool than a compiler.

A chainsaw lets you do in an hour what would take half a day with a handsaw.

But it still helps to know which end to hold.

Does AI actually speed up programming?

This is where things get interesting, because the answer is: yes — but not always.

In a controlled GitHub Copilot experiment, 95 developers were asked to write an HTTP server in JavaScript. The Copilot group completed the task on average 55.8% faster than the control group.

That is a strong result. It shows code generation can genuinely reduce work on a well-defined task.

Real programming rarely consists entirely of small, isolated tasks, though.

Now AI slows developers down by 19%

In 2025, METR ran a very different experiment.

It involved 16 experienced open-source developerswho completed a total of 246 real tasks in their own mature projects. They had known the repositories for around five years on average.

They completed some tasks with access to the AI tools available then, and others without them.

Before the study, they predicted AI would reduce their working time by around 24%. Afterwards, they still believed it had made them around 20% faster.

The measurements showed the opposite: with AI, they needed an average of 19% more time.

The most interesting part is not even that AI slowed them down. It is that they believed it had sped them up.

So which study is true?

Both.

That is precisely the problem with simple slogans such as “AI increases productivity” or “AI just gets in the way”.

If the task is to generate standard code, prepare a structure, write boilerplate or solve a common problem, AI can be extraordinarily fast.

But when an experienced developer works in a large system whose architecture they have known for years, must understand dependencies between many components, then verify the generated change, the overhead of using AI can swallow the entire saving.

• write the prompt;
• clarify the context;
• read the answer;
• check it;
• correct it;
• generate it again.

A function you could have written in ten minutes ends up taking fifteen.

AI’s capability boundary is jagged

A useful description of this phenomenon is the jagged technological frontier — the uneven boundary of what the technology can do.

In an experiment with Boston Consulting Group, researchers studied 758 consultants performing realistic knowledge-work tasks.

Across eighteen tasks within GPT-4’s capabilities, AI users completed an average of 12.2% more tasks and finished them 25.1% faster, with better quality as well.

The experiment also included a complex task beyond the model’s capabilities.

On that task, AI-assisted participants were 19 percentage points less likely to reach the correct solution than those working without it.

AI can be fantastic at task A, excellent at B, average at C and completely mislead a person on task D — even if D looks similar at first glance.

The difficult part is that, before starting, you do not always know which side of that boundary you are on.

The less you know, the more AI can help. And the more dangerous it can be.

The study by Brynjolfsson, Li and Raymond covered 5,179 customer-support workers using an AI assistant.

The average productivity increase was around 14%. Among novice and lower-performing workers, the improvement reached around 34%, while the effect on the most experienced was small.

That makes sense. AI can quickly give a less experienced person patterns and knowledge they would otherwise take a long time to find.

Programming works similarly.

Cannot remember the syntax? AI can suggest it. Unfamiliar library? It can explain the basics. Need an example? You can get one in seconds.

But beginners have the least ability to assess whether the generated answer is correct.

An experienced developer sees: “Hang on, there is a problem here.” A beginner may only see: “It works.”

Developers already use AI. But they do not trust it.

The Stack Overflow Developer Survey 2025 illustrates this paradox well.

84% of respondents used or planned to use AI tools in software development. Among professional developers, 51% used them daily.

At the same time, 46% reported distrust in the accuracy of AI answers, while only 33% reported trust.

The most commonly cited frustration was solutions that are “almost right, but not quite” — reported by 66% of respondents. 45% also complained that debugging AI-generated code could take longer.

Anyone who has worked with this for a while probably recognises the situation.

The first 90% of a solution appears in seconds.

Then you spend half an hour working out why the final 10% does not work.

“It works” is not the same as “it is right”

There is security too.

In a study published before the current wave of much newer models, participants solving security-related tasks with a Codex-based assistant produced less secure code than the group without it. They were also more likely to believe their code was secure.

This is an older study and should not be directly applied to every modern model. The mechanism it demonstrates remains relevant, though: user confidence is not a test of code correctness.

This does not mean “Do not use AI for programming”.

It means:

AI-generated code must be reviewed and tested, and someone must take responsibility for it.

Exactly as with code written by a person.

AI can produce code much faster, though. It can therefore produce mistakes much faster too.

For me, AI works best as a second person at the desk

Not someone I tell:

“Build me an app. I will be back in an hour.”

More someone I can tell:

• “Look at this bit — something odd is happening; give me three hypotheses.”
• “I need to do X — what are our sensible options?”
• “Check whether I have missed anything here.”
• “Write the boilerplate; I would rather spend my time elsewhere.”
• “Read this error and show me where to look.”
• “I did it this way — try to find a reason why it is a bad idea.”

That is when it becomes genuinely useful.

Not as an oracle.

As a very fast sounding board.

The biggest mistake is handing responsibility to AI

You can give a tool some of the work.

You should not give it the responsibility.

If I publish a client’s website, I cannot later say:

“The form sends data into outer space, but that is what AI wrote.”

If an application has a vulnerability, “the model suggested that library” is not a particularly good answer either.

The client does not hire a model.

They hire a person who uses tools.

That person should know what has been deployed.

The skills needed to supervise the tool

When using a calculator, it helps to know roughly whether 19 × 23 should be closer to 400 or 40,000.

I do not need to calculate it manually.

But I should spot a completely absurd result.

AI is similar.

The more we delegate to the tool, the more important it becomes to judge its answers.

Paradoxically, AI may increase someone’s capabilities most when they can decide:

AI as an amplifier

DORA’s research into AI in software development reaches a similar conclusion.

The report State of AI-assisted Software Development 2025 describes AI’s main role as an amplifier: the technology magnifies an organisation’s existing strengths, but also its weaknesses.

A good process can run faster with it.

A mess can produce more mess faster.

That may be the best way to sum up the whole topic.

Do I use AI?

Yes.

I also use an IDE. Libraries written by other people. Search engines. Documentation. A compiler. A debugger.

I see no particular reason to deliberately give up a tool that, used in the right place, makes something faster or better.

But there is a fundamental difference between:

“I used AI to do this work”

and:

“AI did something I do not understand, but it looks good, so I am publishing it.”

The first is using a tool.

The second is gambling.

A chainsaw does not remove your responsibility for where the tree falls. Power steering does not decide where you turn.

AI does not relieve people of the obligation to understand what they are releasing into the world.

So “Do you use AI?” becomes less interesting to me.

Without AI, could you judge whether what AI has just done is good?

As long as the answer is yes, AI is a tool.

When the answer starts becoming “I do not know” , the problem begins.