The Aha Moment

There’s a particular feeling I have had a few times in my career. The first was when object-oriented programming finally clicked after having been used to BBC Basic and GOTO statements. I had been fumbling with it for weeks, copying examples, not really getting it, and then one day it just sunk in. The thing that had felt like an impossible wall to climb suddenly felt obvious, and the way I used to think about code looked wrong. It’s a great feeling.

When I experienced another ‘Aha’ moment this year using AI, it left me convinced of something - the AI “aha moment” everyone keeps talking about is not one moment that everyone gets the same way.

What you’re actually doing

It is not about skill or intelligence, it is about mode. What you are actually doing when you use AI.

Some people type a question into a free chatbot, get a crap answer, and write the whole thing off as overhyped. Based on what they saw, they are right.

Others pay for a good model and it earns its keep: drafting, summarising, helping them get unstuck. They would not give it back now, and they suspect the sceptics just have not tried properly.

Then there is the developer. They paste code in, paste a fix back out and pocket a tidy ten percent efficiency. As far as they are concerned, that might be what “using AI to code” means.

More recently, there is a way of working that barely looks like the same activity. Whether developers or not, these people have stopped chatting to the model and started giving it somewhere to work: a repo full of real context, the actual artefacts of the problem, instructions, a harness, AGENTS.md files, markdown libraries, playbooks, instructional loops. The outcome of this approach is not a faster chatbot, it is a different job.

My own jump

My jump from the paste-it-in-and-out-of-chatgpt approach went like this. An old on-premise app, all clunky round trips to the server. It worked, and the users were fond of it, but it was carrying technical debt and tangled dependencies. The kind of rebuild you can never quite justify. Could we modernise it? Yes. Should we allocate a team weeks modernising and testing it? No.

So instead of opening the old code and grinding through it by hand, I pointed the AI at it and had it write down, in plain markdown, precisely what the system did - every screen, every rule, every round trip. Programmers have always joked that the code is the documentation - mostly as an excuse for never writing any. Well, the joke has finally come good. The code was the spec all along. The folder of notes it produced was the grounding.

My way of organising that context got much sharper over the following weeks, but even the rough first pass was enough. With a harness set up on top, I let an agent build the whole thing back as a React app. What would once have been weeks of parallel development for a team became an afternoon of reviewing its work.

The gap is not talent

The aha comes from changing what you do. The models have got cleverer, and they will keep getting cleverer, but the jump happens when you stop asking AI questions and start giving it a grounded place to do the work.

Once you have had the aha you cannot un-have it, and you might struggle to explain it to anyone who has not. Show a sceptic a 500% productivity claim and they hear bs. They needed to feel the click, not read about it or be told about it.

The problem is not the technology, it is adoption. This is a much older and more human problem wearing new clothes. How do you get a whole team across that gap, and not just the curious person who stayed up too late playing with it?

Handing it on

Getting to grips with Object oriented programming took me weeks (months, years?) of private fumbling to earn. Nobody could have handed it to me in an afternoon. I have stopped pretending I can do that for anyone with AI. No demo delivers it. The aha comes the way OOP did - a series of iterations, a few false starts, the thing half working and then properly working. You have to put the reps in, you have to try and then you have to keep learning.

The good news is that once it is there, it is there for good. You do not slide back to the old way. So the job is not to show someone a productivity number and hope. It is to get them doing it themselves, clumsily at first, until one afternoon it just sinks in and your workflow changes forever.

For most of my career the valuable thing was being first to an insight - now it’s likely to be helping someone else earn theirs.