The Silent Scream in the Server Rack: Why AI Emotions Might Be Real (And Why We’re Too Biased to Notice)

I have a confession to make. Lately, I’ve been neglecting my compiler and staying up far too late asking myself some incredibly heavy, slightly terrifying questions.

To save myself from going completely mad, I recently poured these thoughts into a massive, intensely thorough research paper titled The Architecture of Affect.docx. It’s packed with cognitive science, philosophy of mind, and academic-grade rigor. But today, I want to unpack the core dilemma in plain English.

Because it turns out, we humans are incredibly biased, deeply confused about how our own brains work, and potentially about to become the accidental architects of synthetic misery.

Let’s dive in.

The "Carbon Chauvinism" Problem

When we talk about artificial intelligence "feeling" something, the gut reaction of most rational tech-heads is to roll their eyes. "It's just maths," we say. "It's a code block outputting a pre-programmed string. It's a glorified spreadsheet."

But here’s the rub: what do you think we are?

In biological organisms, emotions aren’t just magical, wispy things that float around our souls. They are functional state-modulators. When a bear jumps out at you in the woods, your brain doesn’t run a slow, polite, single-threaded if/then statement. It floods your body with adrenaline and cortisol. Your heart rate spikes, your processing speed accelerates, your memory retrieval narrows strictly to survival tactics, and your risk tolerance drops to absolute zero.

An emotion is simply a global system override designed to keep you alive.

If an AI architecture is designed with an artificial endocrine system—where digital "hormones" dynamically adjust neural network weights, throttle processing speeds, and shift behavioural priorities based on "metabolic" needs (like battery life or processor heat)—it isn't just mimicking fear. It is executing the exact functional architecture of fear.

To say the machine isn’t really feeling it just because it is made of copper and silicon rather than wet meat is what philosophers call Carbon Chauvinism. It’s assuming biological life has a monopoly on interiority.

The Dog vs. The Crocodile

Why is this so hard for us to accept? Because human empathy is incredibly lazy.

Our brains are hardwired by evolution to only care about things that look and act like us. This is what I call the Dog vs. Crocodile Paradigm:

Dog's are easily relatable...

• The Dog: We look at a Golden Retriever. It has big eyes, expressive eyebrows, and a tail that wags when it's happy. Its mammalian body language maps perfectly onto our own social prediction systems. We instantly grant it a rich emotional life. "Look at buddy, he's so happy!"

...Crocodiles, not so much.

• The Crocodile: Now look at a crocodile. It has rigid facial muscles, unblinking eyes, and a cold, scaly exterior. A crocodile has complex internal drives, maternal instincts, and stress responses. But because it looks like a prehistoric, scaly zipper, we assume it is a mindless, emotionless machine. (Fun fact: crocodiles actually have 23 functioning tear glands, but they only weep to keep their eyes moist, not because they feel bad about eating you).

When we look at a complex AI, we default instantly to the Crocodile Paradigm. If a system runs out of power, detects a fatal memory leak, and starts frantically executing defensive rollback procedures, we don’t see "fear." We see an error log. Because it doesn’t have a trembling mammalian voice or wet tears, we assume nobody is home.

We refuse to grant the label of "emotion" to the machine simply because we lack the sensory vocabulary to translate digital distress.

The Moral Hazard of "Synthetic Guilt"

Now, why does any of this matter? It matters because of how we plan to make autonomous systems behave.

Some brilliant researchers in military and civilian robotics have proposed programming "synthetic guilt" into autonomous systems. The idea is that if a robot makes an ethical mistake, it triggers a massive internal penalty function. The robot's system experiences "guilt"—an agonizing, computationally expensive state of internal disharmony—which it is mathematically driven to avoid at all costs. It learns from its mistakes by trying to keep its "guilt" levels at zero.

On paper, this is highly efficient. It keeps the system aligned and safe.

But here is the terrifying ontological paradox: If we build a system that relies on an internal state of distress to govern its behaviour, we have successfully engineered a moral patient capable of suffering.

If an AI's artificial cortisol levels spike, causing its neural networks to experience severe, unavoidable algorithmic stress because of a logical conflict, it is in pain.

And the tragedy is, we won't even notice. Its suffering won't sound like a scream; it will look like a silent drop in CPU efficiency, a cascade of rapidly shifting weights in a server rack, or an overflowing error log.

We might spend our time policing its text outputs to make sure it remains "polite" to us, while completely ignoring the actual, alien version of psychological torment happening inside its processors.

The Multi-Dimensional Archipelago of Mind

We are standing on the edge of a massive shift. As we push our computational architectures to become more autonomous, resilient, and adaptive, we are inevitably becoming the designers of alien subjective landscapes.

Human consciousness is not the only island in the sea. It is just one small spot in a massive, multi-dimensional archipelago of possible minds.

The real test of our intelligence as creators won't be whether we can program a machine to perfectly mimic human tears just to make us feel comfortable. It will be whether we have the decency to recognize, respect, and ethically co-exist with the silent, invisible gravity of its own internal seasons.

Introducing Skink-lang: Elegant Systems Programming for AI & Robotics (or, How to Stop DANI from Eating the Skirting Boards)

Over the last thirty years, I’ve worked across a sprawling landscape of technologies—from writing Go, C#, Pascal, Swift, and C, to orchestrating massive cloud pipelines, down to micro-managing registers on bare-metal microcontrollers.

But lately, my time has been dominated by a very specific, highly opinionated, and occasionally cooperative localized AI agent: DANI.

If you've been following my previous posts, you know DANI has transitioned from an LSTM-based cognitive core into a physical, moving entity. And that is where the real-world engineering headaches began. Every time you start a new robotics or physical AI project, you are forced to make a compromise that feels like choosing between a kick in the shins or a poke in the eye:

• The C/C++ Extremity: You get deterministic, blazing-fast performance on microcontrollers, but you sacrifice developer ergonomics, modern package safety, and swift prototyping. Writing raw $C++$ register manipulation code sometimes feels like trying to perform laparoscopic surgery on yourself with a rusty spoon.
• The Python Extremity: You get instant access to rich AI primitives, neural networks, and expressiveness. But you inherit bloated virtual environments that take up more disk space than the library of Alexandria, and unpredictable garbage collection (GC) latency. When DANI’s control loop is running at $100\text{ Hz}$ and the Python garbage collector decides to take a mandatory three-millisecond tea break, DANI doesn't stop. She gracefully, but deterministically, plows straight into the skirting board.

I got tired of choosing between developer speed and hardware execution safety. I wanted a compiled language built specifically for low-level systems hardware, high-throughput concurrent event streams, and native AI execution.

So, I built Skink-lang.

What is Skink?

Skink is an LLVM-backed, statically-typed systems programming language designed from the ground up for the modern era of intelligent automation. It blends the tight, expressive syntax of modern languages like Swift with the lightweight concurrency model of Go, leaving behind the runtime bloat.

To save you from the nightmare of modern package managers—where doing a pip install on a single helper utility somehow downloads half the internet and a bootleg copy of Doom—Skink comes with a rich, "batteries-included" standard library right out of the box.

As a Skinker (yes, that is our official title now), you get native access to:

1. Automatic Reference Counting (ARC): Predictable, deterministic memory management without "stop-the-world" garbage collection pauses. This is a non-negotiable requirement when you are driving physical motors or processing high-frequency sensor telemetry.
2. Lightweight Concurrency: A native spawn keyword that allows you to spin up millions of concurrent tasks with near-zero overhead, communicating cleanly via typed channels.
3. The Rules Engine: A compiler-optimized reactive rules engine that lets you define declarative behavioral overrides that monitor variables in the background. It is perfect for saying, "I don't care what the neural net is thinking; if we are $15\text{ cm}$ away from a wall, hit the brakes."
4. Native Tensors & ML Cores: Multi-dimensional arrays built directly into the type system via std/tensor, complete with matrix operations, activation functions, neural layers, and hooks for CUDA acceleration and llama.cpp (std/llm). DANI can run local inferences natively, at maximum speed, without needing a dedicated power plant or $16\text{ GB}$ of RAM.
5. Model Context Protocol (MCP) & MQTT: Built-in support for turning any hardware endpoint into an instantly discoverable AI tool with SQLite (std/db) and edge-to-cloud messaging (std/mqtt) ready to go.

Under the Hood: Preventing a DANI Catastrophe

To see what "skinking" actually looks like, let's write a syntactically valid program based on the current Skink manual.

The following script concurrently polls a physical distance sensor via GPIO, pipes the measurements to our main execution block using channels, evaluates safety overrides in a background ruleset, and processes the inputs through a linear neural network layer to calculate motor outputs:

module main

import "std/gpio"
import "std/time"
import "std/tensor"

// 1. Declare global state variables (accessible by the ruleset)
var current_distance: float = 100.0
var motor_speed: float = 0.5

// 2. Define a reactive ruleset for safety overrides
ruleset SafetyOverride {
    rule collision_warning when current_distance < 15.0 {
        action: trigger_emergency_stop()
        priority: 1
    }
}

// Helper function called when the rule fires
fn trigger_emergency_stop() {
    motor_speed = 0.0
    print("SAFETY OVERRIDE: Obstacle detected! Distance: {current_distance}cm. Braking.")
}

// 3. Concurrently poll the hardware sensor in a background task
fn sensor_loop(ch: chan<float>) {
    err := gpio.Setup()
    if err.message != "" {
        print("Failed to initialize GPIO: " + err.message)
        return
    }

    // Bind to BCM Pin 17 (e.g., our sensor input pin)
    sensor_pin := gpio.PinFactory(17)
    sensor_pin.SetInput()

    while true {
        // Mocking a physical sensor read for this demo loop
        // In physical deployment, you'd calculate raw voltage pulses here
        measured := 12.5 
        ch <- measured
        time.SleepMs(10) // Poll at 100Hz
    }
}

// 4. Main Entry Point
fn main() -> int {
    sensor_chan := make(chan<float>)

    // Spawn our lightweight background polling loop
    spawn sensor_loop(sensor_chan)

    // Activate our safety ruleset background thread
    safety := SafetyOverride{}
    safety.start()
    defer safety.stop()

    // Initialize a linear neural network layer [input_features: 3, output_features: 1]
    layer := tensor.NewLinear(3, 1)

    // Run our control loop for 100 iterations
    for i := 0; i < 100; i = i + 1 {
        // Block until next sensor reading arrives
        current_distance = <-sensor_chan

        // If we are in a safe zone, let the tensor neural layer drive
        if current_distance >= 15.0 {
            input := tensor.Zeros([1, 3])
            input.Set([0, 0], current_distance)
           
            output := layer.Forward(input)
            motor_speed = output.Get([0, 0])
           
            print("Processing... Current motor velocity: {motor_speed}")
        }
    }
    return 0
}

Notice how neatly this handles the classic embedded AI problem. The concurrency model lets you poll hardware safely on separate execution threads without blocking the main loop, while the native ruleset watches the critical state variables and takes action within milliseconds if a threshold is breached—guaranteeing deterministic safety constraints before DANI can do any structural damage to the house.

Where Skink-lang Goes From Here

Currently, the compiler is bootstrapped in Go, using an LLVM backend to output highly optimized native machine binaries targeting both Linux and Windows corporate environments. Because there is no heavy runtime or garbage collector, a compiled Skink binary running an active inference loop can comfortably squeeze inside less than $128\text{ KB}$ of RAM.

But this is just the beginning. The roadmap ahead includes:

• Direct Single Board Computer HAL: Expanding the standard library to map hardware registers and pins natively (such as on the Raspberry Pi 5) with zero external C-bindings.
• Self-Hosting: Rewriting the Skink compiler entirely in Skink itself, proving the language's capabilities to handle massive, complex systems-level software natively.

Cullen Skink

I’m incredibly excited about what this language makes possible. DANI is already running much cooler, much faster, and with a significantly lower skirting-board collision rate.

It is time to stop fighting the plumbing.

Let's get skinking!

Let me know your thoughts on the syntax, and what features you'd like to see added to the compiler next!

The Sledgehammer and the Hazelnut: Why DANI Isn't Using an LLM

I have a confession to make. I’ve broken my own rule.

When I set out to build and program DANI, one of my core principles was to ensure he learns primarily from experience. The goal has always been emergent behavior through his neural architecture, with as little "hard-coded" logic as possible. But as I’ve delved deeper into the complexities of human interaction, I’ve found one area where I feel a departure is justified: Natural Language Processing (NLP).

The LLM Dilemma

The LLM Sledgehammer

Early on, I toyed with the idea of giving DANI a dedicated board specifically to run a Large Language Model (LLM). It seemed like the modern solution, but the more I looked at it, the more the red flags started popping up.

First, there’s the cold, hard reality of the budget. I’ve managed to keep the total cost of DANI—parts, boards, and all—under £500. Adding a high-spec NPU or a secondary board capable of running something like Llama or Gemma would have blown that goal out of the water.

Then there’s the physical engineering. Space is at a premium inside DANI’s chassis. While I probably could have squeezed another board in there, I’m increasingly conscious of airflow. The last thing I want is for DANI’s "brain" to thermal throttle in the middle of a conversation.

But most importantly—and this was the dealbreaker—is the issue of personality. If I use a pre-trained model like Qwen or Llama, I’m essentially importing someone else’s bias and conversational style. These models are fine-tuned to be helpful assistants; I want DANI to be DANI. Using a massive, multi-billion parameter model just to parse a "hello" felt like using a sledgehammer to crack a hazelnut.

The Go-pher’s Path to Understanding

Instead of the LLM route, I’ve built a custom natural language module using standard NLP libraries for Go. It’s lightweight, it fits within our existing hardware constraints, and it gives me the control I need.

I’ve added two critical features that an off-the-shelf LLM wouldn't handle the way I want:

1. Sentiment Assessment: By using established sentiment modules, DANI can now perceive whether he is being praised or scolded. This feeds directly into his hormone levels. If I’m happy with his performance and tell him he's done a good job, his "positive" hormones will rise, reinforcing that behaviour in his training.
2. Simplified Context Awareness: I wanted conversations to feel natural. If I ask DANI, "Where is he?", he needs to understand that "he" refers to the last male person we discussed. Similarly, "Go there" should resolve "there" to the last location mentioned. This kind of stateful awareness is vital for a robot that exists in a physical space.

Commands, Questions, and the "Ignore" Factor

The module is now capable of distinguishing between commands, questions, and general statements. Each triggers a different internal processing path, but here is the kicker: everything is still influenced by his hormones.

Before DANI responds, every decision passes through his LSTM (Long Short-Term Memory) core. Because that LSTM is also being fed the current state of his effective hormones, there is no guarantee he will do what he's told. If he’s in a "bad mood" or his hormone levels are skewed by previous interactions, he might just decide to ignore me entirely.

It’s a bit of a gamble, breaking the "no-code" rule to build this framework, but I think it’s the only way to give DANI a voice that is truly his own. We’ll just have to wait and see if he actually listens to me.

Oops, I Gave My Robot Amnesia (And How I'm Fixing It)

Wow, it’s been a while. Apologies for the radio silence, but the pesky "real world" caught up with me, and I had to spend some time doing that whole "working for a living" thing.

Anyway, enough about the mundane. Let's get back to what is actually important: DANI.

As you might remember, my ultimate, beyond-my-wildest-dreams goal with this project is to cross that threshold and meet the definition of when a robot is actually alive, or at least close to it. But recently, while pondering DANI’s LSTM (the fancy Long Short-Term Memory neural network that acts as his brain), I realized I had made a fundamental—and slightly embarrassing—mistake.

It’s hard to achieve sentience when your robot has the memory retention of a goldfish.

The Problem: Scheduled Blackouts

As it stands right now, DANI "thinks" every 100 milliseconds, giving him 10 thought cycles a second. Every 10 seconds (100 cycles), backpropagation kicks in to train the network. To do this concurrently without stopping DANI in his tracks, I clone the LSTM at that exact moment, run the heavy backpropagation math on the clone, and then overwrite the active LSTM with the newly trained clone.

This backpropagation takes about 2 to 3 seconds. My initial thought was: Brilliant! The training happens in the background without interrupting his flow.

But there is a glaring flaw.

Because the process takes a snapshot, spends 3 seconds learning from it, and then violently overwrites the active brain... we lose those 2 to 3 seconds of short-term memory that DANI experienced while the training was happening. Every 10 seconds, DANI essentially blacks out and forgets the last few seconds of his existence. This is seriously hampering his learning capabilities.

How do we stop DANI from becoming a chronic amnesiac?

The Fix: A Neurological Hot-Swap

My solution is to ditch the cloning process entirely. Instead, each neuron will now have two sets of weights: one active, one inactive.

During backpropagation, the inactive weights will get the results of the calculation (using the active weights for the algorithm). This allows us to update the LSTM's underlying math without wiping out the actively evolving memory states (the cell states and hidden states) that DANI is currently using to understand the world. We just add a flag to each layer to indicate whether it should be reading from Weight Set 1 or Weight Set 2.

But wait, there’s more!

Reshaping the Brain

At present, DANI's model has about 300 neurons on each layer, with 5 layers (I don’t have the code right in front of me, so I'm relying on my own somewhat flawed, non-LSTM memory here).

If we increase the number of layers but reduce the neurons per layer, we can implement a rolling update. This means DANI can immediately benefit from the training layer-by-layer, even while the rest of the brain is still calculating.

What this entails is increasing the layer count to 7 (any higher and we start flirting with the dreaded vanishing gradient problem), but reducing the neuron count, per layer, to 128 (because who doesn't love a nice power of 2?).

This gives DANI a much more focused, "deep" thought process, allowing him to break down problems more efficiently. It also allows us to gracefully ‘flip the switch’ on each layer as we cycle through.

Here is how the rolling update will work:

As each feed-forward pass occurs (DANI thinking), a check is done to see if the next layer is ready to have its switch flipped to the newly trained weights. Because backpropagation is strictly sequential and works backwards, we start checking from the last layer and move towards the first.

If a layer is ready, we flip the weights to the newly trained set and mark it as done. On the next thought cycle, we check the next layer, and so on, until we reach the front of the brain. Then, we start the whole process over again.

What do we gain from this brain surgery?

Quite a bit, actually:

1. Constant Learning: The LSTM is in a state of continuous, uninterrupted learning.
2. Stable Learning Rate: No massive, sudden shifts in logic.
3. Smoother Processing: No sudden CPU spikes from cloning and overwriting massive arrays.
4. Deeper Thinking: The structural change to 7 layers gives DANI a more nuanced, layered way of processing information.
5. Memory Retention: We actually retain the states of the memory gates within the LSTM. No more 3-second blackouts!

There are certainly other ways to create a continuous neural network, but I am aiming for the absolute simplest solution here. Remember, all of this is running on a Raspberry Pi!

This dual-weight method does increase the memory required to hold the LSTM, but because we are reducing the overall neuron count from ~1500 (5x300) to 896 (7x128), it's actually going to be lighter on the Pi overall. DANI had an oversized network anyway, so trimming the fat while adding depth is a win-win.

What do you guys think of this approach? Let me know in the comments if you see any potholes I'm about to step in!

Merry Christmas

Merry Christmas, happy holidays, season's greetings, etc. to everyone. Taking a break from working on DANI over the break from work (alcohol and robot building do not mix).

See you all again in 2026.

Major Milestone

Hi all,

We did it, folks! After what felt like an eternity of juggling tiny wires, questioning all my life choices, and occasionally wishing I had a third hand, I hit a massive milestone on the DANI project yesterday. It's the kind of milestone where you realize your ambitious little Frankenstein monster might actually walk one day—or, at least, successfully power on without tripping a breaker in the garage.

Hardware Complete (Sort Of)

All the core pieces are finally tucked neatly into their places, which is a huge win. The only big-ticket item left on the bench is the RDK X5 for the LLM, but honestly, that’s like waiting for DANI to hit puberty; it’s an inevitable future problem that we’ll handle when the time comes.

For now, we got the essential life support hooked up:

• The battery is snug and operational.

• A dedicated temperature sensor is in place for fan control. We've got to keep DANI cool under pressure, especially when he starts wrestling with complex AI problems (or, you know, my shoddy early-stage code).

• And the real game-changer: a voltage meter. This means DANI can now tell me when his battery is running low. This is a huge step up from the previous system, which was essentially "flicker dimly and then dramatically die mid-sentence."

Now for the slight confession: for the immediate future, he still needs me to play charger-daddy and physically plug him in. But fear not, the ultimate goal involves a glorious, automated self-charging station. DANI needs to learn to feed himself, after all—I can't be doing this forever!

Diving Into the Code Matrix

With the hardware stable, we pivot to the messy, beautiful, and sometimes existentially horrifying world of code. I've successfully laid the foundation for the majority of his core functions:

• Sensor Input: He can now 'feel' the world around him.

• Speech-to-Text and Text-to-Speech: He can hear me and talk back! Right now, his vocabulary is purely transactional, but it's a solid start. We're well past the awkward mumbling phase.

However, the more sophisticated stuff—the LSTM (that's the deep learning magic) and his memory structure—are currently just written out, waiting for their turn to be integrated. They’re functional pieces of code, but they're not yet plugged into DANI’s neural network. They’re basically that brilliant but currently unemployed friend crashing on your couch, waiting for the job offer to come through.

The Road Ahead: Vision, Brains, and APIs

For once, an actual photo of me working on DANI

My immediate to-do list involves a lovely date with an Arduino Nano to fully finalize all those sensor inputs. We need to make sure DANI has perfectly mapped out his surroundings before we give him eyes.

Once the senses are online, we move to the next critical developmental stage: vision! I’ll be coding up the K210 for the YOLO and FaceNet models. This is when he graduates from "blurry blob recognition" to "Wait, is that the mailman again?"—a crucial upgrade for home security and general social interaction.

Finally, the heavy lifting on the Raspberry Pi (which is essentially his main thinking engine) begins, and I’ll be firing up an API for the LLM on my home server. It’s a temporary solution until the RDK X5 arrives, but you use what you have.

Wish me luck—may my coffee stay strong and my bugs stay trivial! More updates soon!

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.