Vibe coding is an unbelievable accelerator.

Over the Christmas holidays, I built an app that I would previously have estimated would take a full year. That speed-up is real, and it is exciting. But this is not a story about how nobody needs to learn to code anymore. In fact, it is the opposite.

Vibe coding means everyone now needs computational thinking, because coding is becoming a foundational skill in the same way spreadsheets did. You do not need to be an accountant to use Excel, but you do need to understand formulas, structure, and data. Coding is heading in exactly the same direction. Those who cannot reason computationally will struggle to access many graduate roles, even outside traditional tech.


From ChatGPT to Anti-Gravity

I have been experimenting with vibe coding for around two years. It started with ChatGPT, then moved on to Cursor, and in November I started using Anti-Gravity. At first, I treated each new tool as just another autocomplete on steroids. Useful, but not transformative. Then something changed.

I saw that Google had spent around 2.4 billion dollars on Anti-Gravity. I assumed it was just another Cursor-style editor. It was not until Sethi took my open source RDPT code and, within minutes, turned it into a fully functioning website that my perspective shifted completely.

That was the moment I realised this was not just faster coding. This was a different way of building.


The Shed Analogy

Vibe coding is brilliant at making sheds.

By that, I mean small, useful, impressive projects. The kind you proudly show your neighbours. They work. They solve a problem. They look great.

But if a professional developer looks at the code, they will usually say something like:
“Nice prototype.”

Then they will gut it and rebuild it using scalable data models, cleaner abstractions, and safer structure.

This is not a criticism. It is exactly what we would expect.

Vibe coding currently makes the same mistakes that beginners do in their first hour of programming:

  • Incorrect indentation
  • Variables changed before being initialised
  • Logic that works once, but does not scale

Professionals will absolutely use AI to speed things up, but they also know when to stop, refactor, and take control.

And here is the important part: most gardens benefit from having a shed. There are thousands of useful projects that simply never got built because the friction was too high. Vibe coding removes that friction.


Turning an Idea Into a Real App

At the start of the holidays, I asked a simple question:
Could this be turned into Python so it could run as a desktop app?

Within minutes, I had a working prototype.

That was enough to hook me. A few hours later, I signed up for Google AI Pro, helped by the fact that the first month was free.

Over the break, I built the reading tool I had wanted for years. A tool designed to help students read faster, especially:

  • learners with English as an additional language
  • students with dyslexia
  • students who need to memorise passages, particularly drama students

This was not just about speed. It was about removing barriers.


What I Would Recommend If You Are Starting Out

If you have never coded before, start with Canva or Google Opal. They are safe, self-contained playgrounds where you can build fun, interactive tools without breaking anything. (Read our article comparing them.)

If you have even a tiny bit of coding experience, go straight to Anti-Gravity. Vibe coding currently works best with JavaScript and Python. That is because:

  • JavaScript code is everywhere on the open web
  • Python is heavily used in open source projects

Both languages act like glue. Need to export PowerPoints? There is a module. Need a database? There is a module. Need to process text? There are dozens.

Swift is still usable, but language models are noticeably weaker with it.


The Biggest Trap: Everything Is Data

This is the most important lesson I learned, and it will frustrate new programmers. As far as a language model is concerned, everything is data. It does not understand that some parts of your code should not be touched. Lists, constants, configuration files, and logic are all fair game unless you actively protect them. So what can you do?

1. Back up every time

Back up your code before every prompt. Not sometimes. Every time.

2. Use small files

Break your project into small, focused modules. This is good practice anyway, but with AI it becomes essential.

3. Separate data aggressively

For small projects, you can paste lists back in manually.
For larger ones, use JSON files. Models tend to interfere with them less.
Once your data grows beyond a megabyte or two, use a database. I was genuinely surprised at how good AI is at writing SQL.

4. Keep a human in the loop

Do not let the tool run fully unattended. As Hannah Fry puts it: “Keep a human in the loop.” With those guardrails in place, you can safely hit the accelerator.


Using AI Beyond Coding

The final surprise was realising that the same tools could help with teaching vocabulary. In an ideal world, vocabulary teaching does not stop at definitions. It includes characteristics, examples, and non-examples. That is exactly what a Frayer-style model requires. When access to online models became limited, I turned to GPT4All and installed the Mistral 7B Instruct model locally. On a MacBook Pro with an Apple M3 chip and 16 GB of memory, each definition took around one and a half seconds to generate. GPU usage regularly hit around 90 percent. The trade-off was faster battery drain, but the system remained usable for other tasks. It was the first time I properly appreciated how little I normally use my GPU.


From Idea to Classroom Impact

The basic version of Arctic Reading Tools is already live on the Windows App Store. When the EAL department saw it, they wanted it immediately. The reaction from staff said everything: “This will save hours and hours of planning.” A strong EAL teacher might spend 5 to 10 minutes creating one high-quality Frayer definition. At scale, this database would have taken around 16,000 hours, or roughly 14 years of work.

Which is oddly fitting, because I first imagined this project about 20 years ago.

Author