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 ChatGPT, 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

  1. John Crickett17 January 2026 at 17:03

    Enjoyed reading that Paul, thanks for sharing.

    I would personally add a few more capabilities to the list of things it can do, and I 100% agree with this:

    "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."

    ReplyDelete
  2. John Hegarty19 January 2026 at 08:42

    I agree with you about those who lack engineering skills not producing production ready code, but the prototypes that you mentioned have a significant amount of value when "selling" an idea to those with some budget to get something proper created. This is a new thing and it is of benefit to real engineers.

    The other thing that these AI coding tools have changed is bringing some of the ex-coders like myself who spend all of their time managing, back in to the highly enjoyable world of actually building products. The next 12 months in software development are going to be very interesting for all of us.

    ReplyDelete
  3. Pau;20 January 2026 at 14:09

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

    This is the kind of thought that will lead you into redundancy while everybody else moves ahead. Keep it up :)

    ReplyDelete

Post a Comment

Popular posts from this blog

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

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

Do software engineering professionals still read? - survey results

By
  In order to gauge the potential audience for my book, So you think you can lead a team? , I conducted a small survey of my colleagues, co-workers and anyone from Linked. I read regularly, for work and pleasure, and assumed everyone else did too but did the responses I received confirm this? I polled 173 people, all within the software engineering field (including Product, etc), with a range of ages and years of experience in their role. What surprised me the most was that the majority of people, young or old, just starting or seasoned, still prefer reading physical books to blogs or e-readers. It also seemed that the older and more experienced were the most keen in learning more, and reading to expand or update their knowledge.  When it comes to reading habits between different roles the survey showed that software engineers and team leads read more regularly for their career than other roles, with 55 years old and over and 16+ years experience being the biggest readers over...
3 comments
Read more