MY PERSONAL AI JOURNEY SO FAR: WHAT TWO YEARS OF AI DEVELOPMENT ACTUALLY TAUGHT ME

When OpenAI first landed, myself and the team went into full geek overdrive.

I think I had a Microsoft Word add-in half-written in C# after about two hours of playing. Well, 60% of it and a lot of build failures. I handed it to someone in the team and we ended up with a beautiful little add-in. Nice UI, custom branding, all fully AI-generated. We were buzzing.

“Stop…!” I said to myself.

I realised that if we’d done it in 16 hours of messing around, Microsoft had almost certainly done a much better job already. Then along came Copilot.

At least we only burned 16 hours and had a lot of fun doing it.

That moment stuck with me though. It was the first in a series of realisations over the next couple of years that completely changed how I think about AI. In development, in business, and in how we work at Digital First. This isn’t a polished framework or a consultant’s hot take. It’s an honest run-through of the stages I went through, and what I’d tell anyone going through them now.

The Exploration Phase

Running a business means that others get to have all the fun while you juggle everything, and it took me about nine months to really get past the obvious hype and properly dig in.

When I did, Claude became the tool that let me finally build out all my ideas in one go. In a single day I had 10,000 lines of code. I’m not exaggerating, it was amazing.

Then it took me five days and about 20,000 lines of PowerShell scripts to actually have anything remotely close to a working solution. It was an internal application for our team and it still stands up to this day, which says something. Production ready though? Not even close.

That gap between “this is amazing” and “this actually works” was the first real lesson. AI could generate code at a speed I’d never experienced, and generating code and building software turned out to be very different things.

Feeling the Vibe

Somebody showed me Replit one day, and I immediately built about four web apps. One of them came purely off the back of a friend saying “wouldn’t it be cool if you could do this…” and boom, four hours later we had what I’d say was a reasonable marketplace application. It worked, the pages probably only had 5,000 lines of code each. The only thing is, it would have fallen over like a cheap council fence in the wind if it was stress tested.

This was the vibe coding phase for me. The dopamine hit of seeing something functional appear in hours was genuinely addictive, and I was confusing velocity with progress. Every one of those apps looked impressive in a demo and would have embarrassed me in production. There’s an important difference there that took me a while to sit with.

The 80/20 Moment

On Christmas Day, because apparently I can’t switch off, I created my own need for an iPhone app. My own idea, fully integrated with cloud APIs, all singing all dancing. The real question was: could I actually build it with AI?

I soon realised that what you could build in two days would take you 80% of the way to realising a product vision, and absolutely take your breath away. The speed, the capability, the fact that one person could prototype something that would have taken a small team weeks. It was extraordinary.

That final 20%? Still working on it, two months later. Admittedly it’s part-time and a passion project for now, and the point stands regardless. The last 20% is where the real engineering lives. It’s where edge cases hide, where architecture decisions come back to haunt you, where the difference between a prototype and a product becomes painfully clear.

Playing by the Rules

This was the turning point. I put my Computer Science hat back on and had an honest conversation with myself.

Vibe coding is not AI-assisted development. They look similar, they use the same tools, and one of them is throwing prompts at a wall hoping something sticks while the other is engineering with a very capable collaborator.

I built out a set of evolving guardrails and architecture principles. Things like files shouldn’t exceed 500 lines, every generated component needs a clear architectural home, the AI proposes and the developer validates. Suddenly regressions were few and far between. Code was readable. Progress was actually measurable rather than just impressive-looking. The work we’re doing for clients at Digital First and my own personal app are both developing at a speed that genuinely wasn’t possible a year ago.

The irony isn’t lost on me. I had to slow down to go faster.

The AI Dev Team

The other thing I’ve come to appreciate, and I think a lot of people are starting to realise this, is that each AI tool and model has different strengths. They’re not interchangeable.

The way I explain it to like-minded friends is this: think of it like a development team. You’ve got your solution architect, Claude for example, thinking through structure, patterns, and approach. Then you’ve got a reviewer, maybe ChatGPT, catching what the first one missed. Run a few feedback loops between them and the output is significantly better than any single model on its own. The best part? No ego, no office politics, and nobody passive-aggressively CC’ing the project manager.

Agentic AI is obviously playing a huge part of this now, and I still want to be able to read the code and challenge the thinking. Ultimately, AI hasn’t nailed it yet. I don’t think it will be long, and that’s exactly why the guardrails matter now more than ever.

So What Would I Tell You?

Have the fun. Seriously. Build the thing in a day, feel the buzz, show your mates. That phase is important because it’s where you learn what’s possible and what gets you excited.

Then do yourself a favour and put the engineering hat back on. Treat AI like a very fast, very capable junior developer who still needs architecture, guardrails, and code review, not like a magic box that replaces your judgment. The magic box phase is fun. The engineering phase is where the actual value lives.

Two years in, I’m more excited about AI in development than I’ve ever been. Not because it’s getting better at generating code, although it is, rapidly. I’m excited because I’ve finally learned how to work with it properly, and that made all the difference.