Hold Your Horses, HAL: Are We Rushing Our AI Implementation?

You can't throw a USB stick these days without hitting an article, a webinar, or a coffee mug proclaiming "The AI Revolution is Here!" And look, the excitement is understandable. As someone who works with this technology every day, I can tell you the advancements are genuinely amazing.

And yet... I'm worried.

I’ve been noticing a worrying trend of "AI FOMO" (Fear Of Missing Out) in the industry. We're in such a rush to implement Large Language Models (LLMs) that we’re tripping over our own feet. We're so busy trying to run that we forgot to learn how to walk.

The "How-To" Guide is Missing a Few Chapters

First off, we're asking engineers who aren't AI specialists to wire up these incredibly complex models. They're given an API key and a "good luck," and sent off to integrate an LLM into a critical workflow.

It's a bit like asking a brilliant plumber to rewire a skyscraper. They can probably follow the diagram and get the lights to turn on, but they might not understand the deep-level electrical engineering... or why the elevator now seems to be controlled by the breakroom toaster. Having a deep understanding of a technology before you bake it into your business is paramount, but it's a step we seem to be skipping.

The "Black Box" Conundrum

This lack of understanding leads to an even bigger problem: explainability. Or rather, the total lack of it.

Even for experts, it's often impossible to trace why an LLM gave a specific answer. It's a "black box." If the AI makes a bad decision—like denying a loan, giving faulty medical advice, or flagging a good customer for fraud—and you can't explain the logic behind it, you're facing a massive legal and ethical minefield. "The computer said no" is not a valid defense when that computer's reasoning is a complete mystery.

Confident... and Confidently Wrong

Ah, "hallucinations." It's such a polite, almost whimsical term for when the AI just... makes things up. Confidently.

Even with the right data, if you don't ask the question in just the right way, the model can still give you a wildly incorrect answer. We try to patch this with "prompt engineering" and "context engineering," which, let's be honest, feels a lot like learning a secret handshake just to get a straight answer. These are band-aids, not solutions.

The Unscheduled Maintenance Nightmare

And that "secret handshake" of prompt engineering? It's a brittle, temporary fix.

What happens when the model provider (OpenAI, Google, etc.) releases a new, "better" version of their model? That perfectly-crafted prompt you spent months perfecting might suddenly stop working, or start giving bizarre answers. This creates a new, unpredictable, and constant maintenance burden that most companies aren't budgeting for. You're effectively building your house on someone else's foundation, and they can change the blueprints whenever they want.

Using a Sledgehammer to Crack a Nut

This leads to my next point: using AI purely for the "clout." I've seen demos where an LLM is used to perform a task that a traditional, boring-old-app could have done in a tenth of the time.

As the document I read put it: "Would you use a large language model to calculate the circumference of a circle, or a calculator?"

We're seeing companies use the computational equivalent of a sledgehammer to crack a nut. Sure, the nut gets cracked, but it's messy, inefficient, and costs a fortune in processing power. All just to be able to slap a "We Use AI!" sticker on the box.

The (Not-So) Hidden Costs

That sledgehammer isn't just inefficient; it's absurdly expensive. These models are incredibly power-hungry, and running them at scale isn't cheap.

We're talking massive compute bills and a serious environmental footprint, all for a task that a simple script could have handled. Is the "clout" of saying "we use AI" really worth the hit to your budget and the environment, especially when a cheaper, "boring" solution already exists?

A Quick Rant About "Innovation"

This brings me to a personal pet peeve. Companies are claiming they are "innovating with A.I."

No, you're not. You're using A.I.

You're using someone else's incredibly powerful tool, which is great! But it's not innovation. That's like claiming you're "innovating in database research" because you... used SQL Server. Creating a slick front-end for someone else's model is product design, not foundational research. Let's call it what it is.

Let's Tap the Brakes

We see a lot of pushback against self-driving cars because they're imperfect, and when they go wrong, the consequences are catastrophic.

Shouldn't we have the exact same caution when we're dealing with our finances, our sensitive data, and our core business logic? In an age of rampant data and identity theft, hooking up systems to a technology we don't fully understand seems... bold.

The acceleration of these models is incredible, and I use them every day. But they are not 100% ready for primetime. They make mistakes. Most are small, but some aren't.

So, maybe we all need to take a collective breath, step back from the hype train, and ask ourselves a few simple questions:

1. Do I really need an LLM for this? Or will a calculator (or a simple script) do?
2. Do we really know what we're doing? Can we explain its decisions?
3. Is it safe? Is our data safe? What happens when it's wrong?
4. Will this negatively affect our customers?
5. How will this affect our employees?
6. Does the (very real) cost of using this outweigh the actual gain?

Let's walk, then run.

A Commentary: The Lost Art of Building from the Ground Up

If you've taken a peek at my bio, you'll know I've been programming and wrestling with code for a good long while. And when I say "programming," I'm not just talking about typing out lines of code. That's the easy part, honestly. But I digress.

What's been on my mind lately is the growing number of developers – and let's lump programmers, coders, and even those "script kiddies" into one big, friendly group – entering the industry with a heavy, sometimes too heavy, reliance on the current favourite framework or that magical library that makes life easier. Don't get me wrong, these tools are fantastic. I use libraries in almost all my projects. But here's the rub: many of today's rising talents seem unable to build anything without them.

Over the past decade, I've seen this reliance grow, while the fundamental skills of building without these crutches seem to be fading. I learned my craft before most of these libraries even existed. Heck, I recently realized I'm older than C++! I was a year old when Dennis Ritchie invented C at Bell Labs. So, I had no choice but to learn things from the ground up.

I had to master the basics. And I'm not talking about assembly or machine code, though I can still wrangle 6502 assembly. I mean understanding how to make a language do what you want with its core features, no external libraries or frameworks. I can already hear the C, Go, and Rust folks saying, "But <insert language here> provides standard libraries!" And you're right, but that's not what I'm talking about. I'm referring to those third-party libraries and frameworks you install separately. Some have become so ingrained in our workflow that they're almost mistaken for the language itself (looking at you, jQuery).

Take JavaScript, for example. I've written tons of it over the years. Sure, I could use React, and I probably will at some point. But for everything React does, and it does it well, I've likely built something similar in plain, native JavaScript. The same goes for Go, C++, or any other language I've worked with. I like to know how things work; I don't trust black boxes I can't peek inside.

I've worked with many talented university graduates who can create impressive projects. The UI is slick, the responsiveness is spot-on. But when something goes wrong, especially if it's within a library they're using, they hit a wall. And if you ask them to modify something built without their favourite framework, it takes far longer than it should. A solid grasp of the language's fundamentals is always essential.

So, how does this relate to my current projects? Well, I'm obviously going to be leaning on neural networks for a lot of the heavy lifting, likely recurrent neural networks. But before I even started this project, I knew I'd be using them. It's just the direction things are heading. To prepare for the onslaught of libraries and frameworks (like TensorFlow) in this area, I decided to build my own.

Let me be clear: my neural network is nowhere near as sophisticated as TensorFlow. For my limited dataset, I could probably have written a traditional program faster and more accurately. But that wasn't the point. The goal was to understand what's happening inside those infamous "black boxes."

I've since refined my network with concurrency and better activation functions, but that's just icing on the cake. By learning how these networks work, even at a basic level, I'm much more comfortable using them in my projects. I might even have to create my own, as I'm not sure there's one that perfectly fits my needs, but now I feel equipped to do so.

So, if I could offer one piece of advice (and I have many, but we'll stick to one for now), it would be this: Learn the basics. Get a book on the core language before diving into frameworks. If you need to learn a specific algorithm, try building it yourself first, without any external libraries. It doesn't have to be perfect, or even good. But by doing so, you'll gain a much deeper understanding of what those libraries are doing under the hood. Maybe not the exact details, but you'll have a solid conceptual grasp.

Don't let the convenience of libraries and frameworks replace the satisfaction of building something from the ground up. You might be surprised at what you can achieve.

Whether you agree, or disagree, I would love to hear your thoughts 👇

And yes, that is an AI generated image 😁