Skip to main content

The Reluctant AI Adopter Who Never Looked Back

Image
By

I didn’t dive into AI. I was a reluctant adopter. Not because I feared it would take my job, but because I assumed the learning curve would be steep, time consuming, and probably frustrating. In reality, it turned out to be none of those things.

After spending a decent amount of time with ChatGPT and Claude, AI has become an essential part of the way I work. I wouldn’t want to be without it now. It’s made me more efficient in both my writing and my software development, and it’s slotted into my workflow far more naturally than I ever expected.

But, and this is important, I’m not sitting back and letting it just get on with it and neither should anyone else.

The Myth of “Vibe Coding”

There’s a perception floating around, often from people who don’t write software, that AI has unlocked a magical new world where anyone can describe an idea and AI will churn out production ready code without oversight, testing, maintenance, or even understanding.

This is, frankly, nonsense.

AI is powerful, but it isn’t a replacement for software engineering. You still have to check the output, iterate on it, shape it, correct it, and guide it. You still need to understand the constraints, the architecture, the data model, the error modes, and the trade‑offs. You still need to own the design.

“Vibe coding” isn’t engineering. It’s prompt‑driven prototyping. And prototypes are not products.

Two Strands of AI Use in Software

From where I’m standing, there are two very different types of AI‑driven “software development” happening right now:

1. The “Anyone Can Build Anything” Fantasy

This is the idea that AI democratises software to the point where domain expertise, experience, engineering discipline, and architectural thinking are optional. Just ask the model for an app, a system, a feature, whatever, and it does the rest.

No tests.
No reviews.
No maintenance.
No accountability.

This mindset is building up a bubble. And bubbles burst.

2. Ai as a Productivity Tool for Engineers

Then there’s the strand I live in: using AI as a productivity tool. Not a replacement for experience, but an amplifier of it. When used well, AI lets software engineers:

  • explore ideas faster
  • write boilerplate less
  • get unstuck sooner
  • iterate quicker
  • document more cleanly
  • and keep more of their headspace free for real engineering work

It doesn’t do the thinking for you, it creates more room to think. The people who can employ AI effectively are the same people who already understand how to build scalable, maintainable software. AI doesn’t eliminate the need for engineering discipline; it makes that discipline even more valuable.

The Bubble Is Real

I believe we’re heading toward a correction. Maybe in six months, maybe in twelve. But it’s coming.

Right now, non‑engineers are experimenting with AI‑generated software and believing it will carry them all the way to production. For small scripts, demos, or toys, maybe it will, but building something that lasts, something that scales, something that behaves as expected in the messy real world, still requires engineering fundamentals. AI won’t magically fill those gaps for people who don’t have them.

When the bubble bursts, the gold rush around “AI software development for non‑developers” will fade, and the real value will settle firmly where it belongs: in the hands of experienced engineers who are now significantly more productive than they were before.

That’s the real revolution.

Not replacement, acceleration.

The Future Belongs to Engineers Who Embrace the Tools

I may have been a reluctant adopter, but I’m fully converted now. AI has changed the way I work, not by writing software for me, but by helping me write better software faster. I don’t believe AI is here to take our jobs. I believe it’s here to make good engineers more productive.

And those who learn to combine their expertise with these new tools will be the ones who shape what comes next.

I’ve been asked many times recently what my thoughts on AI are. I’ve got limited experience so far, and my opinions come from some usage of Claude Code and ChatGP, Linkedin posts and talking to colleagues. I gave my thoughts to ChapGPT, told it what I wanted to say and how I wanted to say it. What you’ve read above is the result, plus some minor editing.

Comments

Post a Comment

Popular posts from this blog

Write Your Own Load Balancer: A worked Example

By
I was out walking with a techie friend of mine I’d not seen for a while and he asked me if I’d written anything recently. I hadn’t, other than an article on data sharing a few months before and I realised I was missing it. Well, not the writing itself, but the end result. In the last few weeks, another friend of mine, John Cricket , has been setting weekly code challenges via linkedin and his new website, https://codingchallenges.fyi/ . They were all quite interesting, but one in particular on writing load balancers appealed, so I thought I’d kill two birds with one stone and write up a worked example. You’ll find my worked example below. The challenge itself is italics and voice is that of John Crickets. The Coding Challenge https://codingchallenges.fyi/challenges/challenge-load-balancer/ Write Your Own Load Balancer This challenge is to build your own application layer load balancer. A load balancer sits in front of a group of servers and routes client requests across all of the serv...
Post a Comment
Read more

Remember to Delegate: The Triangle of Trust

By
So you think you can lead a team? I’ve been talking and writing a lot about leading a software engineering team in 2025. I started thinking about it more deeply the year before when I decided to give a colleague, who was moving into team leading, some advice: 'Doing the work' isn't the only way to add value Remember to delegate Pick your battles Talk to your team every day Out of this came a talk, “So you think you can lead a team?” which I gave at work, at meetups and at conferences in various different formats during the first quarter of 2025. Here I am looking at Remember to Delegate and an idea which came out of discussion around the talk, The Triangle of Trust, in more detail. Delegate Delegation is a crucial skill for any team lead, yet it is often one of the most challenging aspects of leadership to master. Many leaders, particularly those who have risen through the ranks as individual contributors, struggle to let go of tasks, fearing a loss of control or a dip in ...
Post a Comment
Read more

Catalina-Ant for Tomcat 7

By
I recently upgraded from Tomcat 6 to Tomcat 7 and all of my Ant deployment scripts stopped working. I eventually worked out why and made the necessary changes, but there doesn’t seem to be a complete description of how to use Catalina-Ant for Tomcat 7 on the web so I thought I'd write one. To start with, make sure Tomcat manager is configured for use by Catalina-Ant. Make sure that manager-script is included in the roles for one of the users in TOMCAT_HOME/conf/tomcat-users.xml . For example: <tomcat-users> <user name="admin" password="s3cr£t" roles="manager-gui, manager-script "/> </tomcat-users> Catalina-Ant for Tomcat 6 was encapsulated within a single JAR file. Catalina-Ant for Tomcat 7 requires four JAR files. One from TOMCAT_HOME/bin : tomcat-juli.jar and three from TOMCAT_HOME/lib: catalina-ant.jar tomcat-coyote.jar tomcat-util.jar There are at least three ways of making the JARs available to Ant: Copy the JARs into th...
22 comments
Read more