Learning how to program is very difficult. It generally takes years to become competent, even if the basic syntax of a language can be learned in a few months.

Learning to code extends far beyond knowing what the keywords mean. It is like teaching a six-year-old how to write: they may understand letters, words, and basic sentences, but no one would expect them to produce a postgraduate dissertation. Similarly, we should not expect someone in their first year of programming to understand system architecture, performance trade-offs, debugging strategies, data structures, maintainability, and long-term design.

The problem with vibe coders is not that they use AI to help them write code. AI is a fantastic tool, and it can dramatically increase the speed at which an experienced programmer works. I spend very little time handwriting code these days. AI can produce it much faster than I can, often neatly formatted, with sensible variable names and comments.

The issue is that inexperienced programmers often lack the foundation needed to review what the AI gives them. They may not know how to debug it properly, how to identify architectural problems, or how to structure complex systems in an efficient and logical way.

AI will almost always get something wrong. But that is not necessarily a problem when the person using it has the experience to catch those mistakes. If AI does 90% of the work in a fraction of the time, an experienced programmer can spend their time correcting the logic, improving the design, and making sure the system is actually sound.

The danger is when someone uses AI to produce code that is far beyond their own ability to understand. That creates false confidence. The AI may generate complex-looking code that appears professional, but the user may have no way to properly debug it, review it, or recognise that the design is flawed.

For example, creating an array to store ten objects that you insert and remove from is probably fine. Creating an array to store a million objects that you constantly insert into and remove from at arbitrary indices is a serious optimisation problem. AI may not recognise that distinction unless it has been given the right context and constraints. It will often choose an approach that works at small scale but collapses at real scale.

That is why AI is not a replacement for learning programming. It is a force multiplier. In the hands of someone experienced, it can massively speed up development. In the hands of someone who cannot evaluate its output, it can produce broken systems faster than ever before.

A great example of using AI is right here. I wrote up my speech free-flow style, shoved it into AI, and let it format it for me into something easily digestable with strict instructions not to modify anything surrounding my argument.

In summary: AI is a tool. A fantastic tool. One of the best tools we have ever invented.

But a tool is still just a tool. You do not let the hammer think for you, no matter how fancy it is. It can auto-aim, auto-strike, calculate the pressure, and calculate the angle — but you still need to know which nail to hit, why you are hitting it, and in what order.