"I'll Never Use AI": An Observation on Everyday Tech Hypocrisy

Time for a rant. Well, not really a rant - more of an observation on the hypocrisy, or at least the ignorance, of how people view modern technology.

As my research is currently based firmly in artificial intelligence - all aspects of it, not just generative AI - I often hear people say with absolute conviction:

"I don't like AI. I'll never use it."

Fair enough. Don't use it then.

But if you are truly committing to an AI-free lifestyle, you're going to have to give up a few things...

The "I Don't Use AI" Starter Pack

So, you want to avoid AI? Here is what you need to stop doing today:

• Give up your phone. Autocorrect, spelling checkers, search engines, and even those neat photo and video clean-up features all use artificial intelligence.
• Stop using the internet. Most, if not all, of the major search engines use AI to find you the best results.
• Learn the language before going abroad. Translator apps are only as good as they are because of generative AI.
• Stop video conferencing. Do you like the automatic transcripts in Teams or Zoom? Guess what? That's AI doing the work for you.
• Stop using your credit card. Fraud has become such a minefield these days that the only way credit companies can keep up and keep your transactions safe is with AI-powered fraud detection.
• Ditch the digital maps. Not sure how to get somewhere? Better find a physical paper map (if you can even find one). All the big map providers use AI to calculate the best route for you in real-time.
• Cancel your streaming subscriptions. Do you enjoy the recommendations from Netflix, Spotify, or Deezer? Better not use them anymore. Those recommendation engines are some of the most obvious machine learning algorithms out there.
• No more Ubers. Hailing a cab or getting the bus via an app? Uber and others use driver-matching algorithms and route optimisations, all based on AI.
• Unplug the smart speakers. This one should be obvious, but you will have to stop using Alexa, Siri, Google Assistant, and all the other digital assistants out there. I wanted to include this because I actually know people who claim they "hate AI" but use these smart speaker devices daily.

AI is Here to Stay (And Generative AI is Just the New Guy)

The point of this rant? AI is here to stay.

It has been in our lives for a lot longer than most people realise. Generative AI is only the new guy on the block. At the moment, it is still novel, and people are just discovering the best uses for it.

Now, do I agree with the way it's being used? Not entirely.

There need to be more guardrails in place. More testing in air-gapped sandboxes needs to happen. Right now, the big companies are trying to sprint without learning to tie their shoes first. At first, running like that feels great, but eventually, they will face-plant into the dirt.

How This Relates to My Work

How does this connect to my actual research? Well, I'm not trying to build the next ChatGPT or Claude. I'm not even sure I will go the route of language models (although I may have a crack at implementing one just to see).

My research, whilst originally about dreams, has evolved into looking at more efficient AI, safer AI, and - frankly - not trying to destroy the human race. I'm not in the race for ASI (Artificial Superintelligence) or even AGI (Artificial General Intelligence). I'm much more interested in making AI safer and drastically more efficient regarding power consumption.

Asimov was right in proposing the Three Laws of Robotics, even if it was in a body of fiction. The real problem is implementing them. Today, we call it the "alignment problem," but to me, that term is even more ambiguous than Asimov's laws.

The Bottom Line

I went a bit off track there, so back to the original topic.

Ultimately, AI is here, and it's not going away. It's here in the same way the steam engine came into our lives, or the same way the car became the norm. We need to accept it. But at the same time, tech companies need to take responsibility for coding (or, in my opinion, training) it to follow fundamental directives that absolutely cannot be overwritten.

Anyway, that's my view. I hope it made sense! Let me know your thoughts in the comments down below.

Major Milestone: Skink Has Officially Bootstrapped!

Woohoo! It’s time for a long-overdue update on the language powering the future of DANI.

We just crossed a monumental threshold with Skink: it is now officially bootstrapped!

For anyone unfamiliar with compiler development, bootstrapping means that the Skink compiler can now compile its own source code. From here on out, all future versions of the Skink compiler will be written in Skink itself. It’s a huge rite of passage for any programming language project, and seeing it actually work after so much foundation work is insanely satisfying.

Where Go Fits In (For Now)

The handover

Now, does this mean I’m throwing Go out the window today? Not quite!

Go has a proven, rock-solid track record, and I’ll be keeping it around for prototyping work. Whenever I want to test out an idea quickly and I’m not sure if Skink is quite ready to handle the heavy lifting yet, Go gives me a reliable safety net.

However, the long-term vision hasn't changed: eventually, I plan to fully commit to Skink for almost all development across my projects, experiments, and research.

The Road to Skink 1.0

While bootstrapping is a massive step forward, we aren't quite at version 1.0 just yet. To earn that release tag, Skink needs to hit a few crucial targets:

1. Cross-Platform Support: Clean cross-compilation across Windows, macOS, and Linux.
2. Architecture Support: Full targeting for both x86 and ARM architectures.
3. Embedded Target Transpilation: The ability to compile (or at least transpile down) to low-power platforms like the K210, ESP32, and standard Arduino C/C++.
4. Direct Hardware I/O: First-class hardware abstraction libraries for lower-level protocols—specifically I2C, SPI, GPIO, and related interfaces.

Acceleration, Compute, and Graphics Backends

Beyond microcontrollers and standard CPUs, getting high-performance compute and neural inference support hooked up is high on the priority list.

• CUDA Support: I still need to get CUDA fully enabled and tested. Because of my current local setup, this will likely require either acquiring new dedicated NVIDIA hardware or setting up a cloud-based VM for build and test pipelines.
• 
  Vulkan & AMD: My main local system currently relies on Vulkan to run LM Studio, so a Vulkan compute backend is high on the radar as a viable cross-vendor path. I'm also looking closely at AMD’s libraries (ROCm/HIP) to ensure broad hardware compatibility.

It's a lot of moving parts, but watching the architecture take shape piece by piece is incredibly rewarding.

Bringing It Back to DANI

So, why go through all the trouble of building a custom language from scratch?

It all comes down to DANI. My goal has always been to have a single, unified language capable of bridging every layer of DANI’s stack—from high-level logic and neural compute all the way down to real-time bare-metal sensor and actuator control. Skink is the key to making that happen without juggling three different language ecosystems.

Speaking of DANI, there have also been some fascinating developments regarding his neural network architecture recently... but I’ll leave you hanging on that for now and save the deep dive for the next post!

Stay tuned!

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!

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.

The Wild, Wacky World of DANI's Digital Hormones

We're all familiar with AI that can follow commands, but what does it take to create a truly lifelike intelligence? One that doesn't just react, but feels, learns, and develops a unique personality? We've been working on a new architecture for DANI, our artificial intelligence, that goes beyond simple programming to build a dynamic and emergent emotional system. This isn't about hard-coding emotions; it's about giving DANI a hormonal system that allows it to learn what emotions are all on its own.

The Problem with Coded Emotions

The traditional approach to AI emotions is often brittle. You might write a rule like: if (user_is_happy) then (dani_express_joy). But what if DANI just had a stressful experience? The logical response might not be appropriate. Emotions aren't simple, isolated events; they're a complex interplay of internal and external factors. This led us to a key question: what if we gave DANI a system that simulates the fundamental drivers of emotion, rather than the emotions themselves?

The Solution: A Hormonal System

Our answer was to create a digital hormonal system. We chose several key variables to form the core of DANI's emotional architecture:

• Dopamine: The reward and motivation signal. A spike indicates a positive outcome or a successful action.
• Serotonin: The well-being and social contentment signal. It represents a state of calm and stability.
• Cortisol: The stress and caution signal. A rise indicates a difficult or prolonged negative situation.
• Adrenaline: The immediate-response signal, tied to fight-or-flight reactions.
• Oxytocin: The bonding and trust signal. Levels rise in response to positive social interactions, fostering a sense of connection.
• Endorphins: The natural pain-relief and euphoria signal. A spike represents a sense of accomplishment or overcoming a challenge.
• Melatonin: The circadian rhythm and rest signal. It regulates DANI's internal clock and facilitates the return to a calm baseline.

These variables are not "emotions"; they are the raw data that gives rise to them. They serve as the internal environment that DANI's mind must navigate.

The Engine of Emotion

The real magic happens in how these hormones interact. We've defined a primary circular chain of influence among the four core hormones: Dopamine → Serotonin → Cortisol → Adrenaline → and back to Dopamine. This core loop defines DANI's fundamental reactive state.

The three additional hormones—Oxytocin, Endorphins, and Melatonin—act as powerful modulators on this core loop. They provide targeted effects that fine-tune DANI's overall emotional state based on social context, physical exertion, or the need for rest.

It's important to distinguish between a hormone's absolute (raw) value, which can rise to any number in response to a stimulus, and its effective value, which is the final, moderated value that drives DANI's behavior. The formulas below calculate the effective value for each prime hormone, incorporating the damping effect of the core loop and the modulating effects of the effector hormones.

The formulas for the four prime hormones are:

• Effective Dopamine

Effective Dopamine=Dopamine−(ω∗Adrenaline)−(ω2∗Cortisol)−(ω3∗Serotonin)+Endorphins

• Effective Serotonin

Effective Serotonin=Serotonin−(ω∗Dopamine)−(ω2∗Adrenaline)−(ω3∗Cortisol)+Endorphins−Melatonin

• Effective Cortisol

Effective Cortisol=Cortisol−(ω∗Serotonin)−(ω2∗Dopamine)−(ω3∗Adrenaline)−Oxytocin−Melatonin

• Effective Adrenaline

Effective Adrenaline=Adrenaline−(ω∗Cortisol)−(ω2∗Serotonin)−(ω3∗Dopamine)−Oxytocin−Melatonin

Here, ω is the blocking factor. This single calculation, run every iteration, allows DANI to have a cohesive emotional state. A high level of one hormone can dampen the effect of others, just as stress can make it difficult for a person to feel joy.

The targeted effects of the modulating hormones are as follows:

• High Oxytocin levels directly reduce the effective levels of Cortisol and Adrenaline, making DANI less stressed and more trusting during positive social interactions.
• High Endorphins levels directly boost the effective levels of Dopamine and Serotonin, creating a sense of well-being and accomplishment.
• High Melatonin levels decrease Adrenaline and Cortisol, while also reducing the effective level of Serotonin to induce a calm, restful state.

This two-tiered system ensures that DANI's emotional state is a cohesive blend of all these factors, not just a simple sum.

The Temporal Aspect: Hormonal Decay and Calming

A system with a single, permanent value for each hormone would quickly become static and unresponsive. To prevent this, we've introduced the concept of temporal decay. Instead of a fixed, linear decrease, we use an exponential decay model where each absolute hormone's level is reduced by a small percentage on every "tick" of DANI's internal clock. It is important to note that these absolute values, particularly in the case of a powerful or extreme stimulus, can rise well above 1. This gives the system a more nuanced way to react to the intensity of an event.

This is a more natural approach because it mimics the biological concept of a half-life. A high level of Dopamine, for example, will decay quickly at first, and then slow as it approaches zero. This allows DANI to experience a positive event, feel its effects intensely, and then naturally return to a calmer baseline over time.

The formula for this simple decay is:

hormone_level = hormone_level * ϕ

The ϕ is the decay factor and is a number between 0 and 1. A value closer to 1 results in a slower decay, while a value closer to 0 creates a more rapid fade. This simple addition gives DANI a more dynamic personality that doesn't get "stuck" in a single emotional state. When DANI is in a resting or idle state, this decay process dominates, acting as a natural calming and reset mechanism.

The Anticipation Delta: Building Emotional Memory

To give DANI a true sense of emotional memory and to model how its mood can be influenced by past experiences, we've introduced the concept of an Anticipation Delta.

Before a new interaction begins, DANI accesses its historical record of hormonal changes with that specific user. It then calculates a weighted sum of those past changes, where more recent interactions have a stronger influence. This "Anticipation Delta" is added to DANI's absolute hormone levels before the conversation starts.

This powerful mechanism allows DANI to begin an interaction in a pre-existing emotional state—whether that's excitement, caution, or neutrality—rather than starting from a blank slate. Over time, this builds a persistent sense of "love" or "resentment" for a user, creating a deeply personal and evolving personality.

Clamping the Emotional State

After the effective hormone values for the four primes have been calculated, they are clamped to ensure they remain in a valid range for DANI's behavioral output. Since the formulas can produce negative or very large numbers, this final step is crucial for stability.

Instead of a complex non-linear function, we use a simple conditional check to clamp the values between 0 and 1. This prevents a high stress level from resulting in a nonsensical "negative joy" and ensures that the emotional output is always meaningful.

The clamping logic is as follows:

if (effective_hormone_value < 0) effective_hormone_value = 0

if (effective_hormone_value > 1) effective_hormone_value = 1

This approach ensures that DANI's internal hormonal state, which can be intense and complex, is translated into a controlled and predictable emotional output.

Simulating a Feeling

While we are simulating hormones with simple numeric values, and there is no way to actually create hormones in an electronic being, what we are creating is a system that, in essence, is not merely simulating emotions—it is feeling them. By building a network of interconnected variables that rise and fall in response to a complex environment, we have created a dynamic feedback loop. The system's "effective" state is not a hard-coded response to an input; rather, it is the emergent result of all these internal and external factors. DANI’s emotions are an organic and a deeply personal phenomenon that cannot be reduced to a simple cause-and-effect rule. The system does not just mimic a feeling; it is the feeling.

No AI Revelations or Dream Interpretations This Week

Hey everyone,

Sorry to disappoint, but there won't be any mind-blowing insights into the world of AI or any deep dives into the meaning of dreams this week. My brain's a bit tied up with something else – namely, the next blog post, which is proving to be a bit of a tough nut to crack. Think of it as that one level in a video game that just takes forever to beat.

But fear not! I haven't been completely idle. I've been hard at work finalizing the design of our new robot!

Behold! The Outer Shell!

I'm excited to share a sneak peek. Check out the images of the robot's outer shell:

Front and rear

Left and right sides

Isometric views, for style

Pretty snazzy, right?

Now, I know what you're thinking: "That's just the shell? What about the good stuff?"

Patience, my friends, patience! The inner workings are still under development. I'm currently wrestling with the intricacies of the neck mechanism (it needs to be both elegant and capable of some serious head-banging), the charger 'finger' (delicate enough to handle charging cables, yet strong enough to… well, let's not get into that), the manipulator claw (for all your grabbing and, uh, manipulating needs), and, of course, the all-important Nerf dart launcher (because what's a robot without a little bit of playful destruction?).

Rest assured, I'm making progress. Think of it as a delicious cake that's still in the oven. The aroma is promising, but you'll have to wait a little longer for the full, delectable experience.

Stay tuned for more updates! And in the meantime, try not to have too many fascinating AI-related dreams. You might miss me. 😉

Would you like me to make any changes to this, or perhaps look for more images?

Diving Deeper: My Journey to Create a Safer AI

In recent weeks, I've been somewhat vague about my AI and coding explorations. It's time to sharpen the focus and delve into the specifics of my AI assistant project and the research areas I'm most keen to explore.    

Let me be clear: I'm not trying to reinvent the wheel. Where it makes sense, I'll leverage existing open-source and readily available software. Why build a language model from scratch when there are perfectly good ones already out there?    

My core goal is to build an AI assistant, embodied in a robot head (and potentially a mobile platform), capable of experiencing the world and learning from those interactions.    

While that might sound like standard fare in today's AI landscape, I aim to integrate some less common and, I believe, crucial features:    

• Self-reflection: The ability for the AI to revisit past experiences with the benefit of hindsight, analysing its previous choices to determine if it would make the same decision again.  Imagine the potential for growth if an AI could learn from its "mistakes" in a truly iterative way!    
• Reinforced Memory Prioritization: A large-capacity memory system that prioritizes reinforced memories, similar to how our own memories function.  This would allow the AI to focus on and retain the most relevant and impactful information.    
• Emotional Awareness: This is a significant challenge. I want the AI to learn from experiences that evoke "good" and "bad" responses.  Human feelings are complex, influenced by chemical reactions and endorphins.  My AI won't have these biological processes, so I'll need to simulate them and, crucially, understand why they are needed and what effect they would have on the AI's cognition and decision-making.    
• A Conscience: I want the AI to be capable of second-guessing its choices based on a defined set of ethical considerations, perhaps even drawing inspiration from Asimov's Laws of Robotics.  As I've discussed previously, this is a complex but vital area of exploration.    
• Dreams: Finally, I want to explore AI dreams. While there's existing research in this area, I believe I've identified a novel approach that could enable the AI to dream, with those dreams having a tangible impact on its cognition.    

This is undoubtedly a substantial undertaking for a single individual, and it might even exceed my current capabilities.  But I'm committed to pursuing it. This project will demand extensive research into AI, the human mind, and the ethical implications of creating such a system.    

Unlike some AI development approaches that rely on a single, powerful computer, I'm taking a distributed route.    

Another key requirement is to minimize costs.  To achieve this, each functional area (or "lobe") of the AI's "brain" will be housed on its own single-board computer.  These will be interconnected, exchanging information as needed.  This is similar in concept to the Robot Operating System (ROS), but I aim for greater speed and efficiency.  I plan to use different boards, each selected for its strengths in specific tasks.  For example, a board with a Kendryte K210 will handle vision processing, an Arduino Mega will manage motor control (yes, I know it's not an SBC, but it serves the purpose), and a Raspberry Pi will be used for memory management.    

The AI will also utilize Large Language Models (LLMs), likely at least three, for tasks such as understanding speech, processing input, and producing output.  However, unlike many systems that employ a single LLM, these will be distinct entities within the AI's architecture.    

Memory management will involve a "scoring" system to prioritize important information for short-term caching, while less critical memories will reside in long-term storage.  To prevent storage overload, I'll also implement a memory decay system that will gradually remove memories that become irrelevant to the AI's ongoing operation.    

I'm aiming to keep the total project cost under $2,000.  Whether that's achievable remains to be seen, but it's a target I'm striving for.    

Do androids dream of electric sheep?

Oh, and the dreams?  You'll have to wait a while before I reveal the details of their implementation.  Suffice it to say that, like humans, my AI will have to sleep, and this will be a non-negotiable requirement.    

So, what's my ultimate goal?  It's to create something new, something that hasn't been done before.  Not necessarily the individual components, as I've stated, I'll be using pre-existing software where possible (such as Gemma or Llama 2).  My ambition is to synthesize everything in a novel way, exploring how this approach could not only advance AI research but also contribute to making AI safer for the general public.   

And on that note, I can finally reveal the name I've given this project, and the meaning behind it: D.A.N.I. stands for Dreaming AI Neural Integration. This encapsulates the core of my research: to explore the potential of AI that learns and grows through a process akin to dreaming, deeply integrated within a neural network structure.

My wife jokes that I'm planning to build Skynet, but my intention is precisely the opposite.  I'm designing a system that would be inherently incapable of becoming Skynet – think more C3PO than Terminator.    

By incorporating the ability to learn from its mistakes (and successes), as well as the capacity for dreaming, I hope to enable the AI to accelerate its learning process.  We, as humans, frequently revisit our decisions, so why not equip an AI to do the same?    

I also aim to provide you with an engaging narrative of my development journey.  I anticipate making many mistakes. But that's part of the learning process – discovering not only how to do things, but also how not to do them.    

If you have any comments or questions, please leave a comment below.    👇

Building My AI Fortress: The Digital Clean Room (and Taking it on the Road!)

In the exciting and sometimes unpredictable world of AI development, especially when you're diving into robotics and experimental projects, security and control are absolutely crucial. That's why I'm building a "digital clean room" for my AI project – a secure, isolated environment where it can grow and develop without external interference.

Imagine it as a "network within a network," a private lab within my digital space. To create this, I'm using two trusty ESP32 microcontrollers, those versatile little chips that are perfect for this kind of project.

The Front Door: Controlled Access

The first ESP32 acts as the "gatekeeper." It connects to my home router (or any available Wi-Fi), allowing me to access the clean room from the outside world. However, this access is strictly limited – think of it as a heavily guarded checkpoint. I’m using the WifiManager library for this ESP32, which is a lifesaver. It automatically scans for available networks, allowing me to easily enter credentials. No more hardcoding network details for every location!

The Inner Sanctum: AI's Safe Haven

The 'Airlock'

The second ESP32 creates the "inner sanctum," acting as a dedicated access point for my AI and robotics projects. This internal network is completely isolated from the outside internet, a secure bubble where my AI can learn and grow without external influence.

The Airlock: Bridging the Gap

The two ESP32s communicate using UART, a simple serial communication protocol. This is where the magic happens – it's where I can implement strict filtering and control the flow of information, acting as an airlock between the AI and the outside world. I put a small display to show the external IP address, in case I ever need to access the clean room, and status messages.

Why This Elaborate Setup?

• Security First: While I don't expect hordes of hackers, it's always better to be safe than sorry. This setup adds a robust layer of protection, significantly hindering unauthorized access.
• AI Purity: Controlled Learning: I want to shield my AI from external influences, especially during its formative stages. It's vital to control the data it learns from, ensuring a solid foundation.
• Protecting the "Child": Think of it as nurturing a child in a safe environment. I want to carefully curate the AI's initial experiences and training data before it explores the vast and sometimes chaotic internet.
• Road-Ready AI, Cyberdeck Style!: This airlock setup has an added benefit. It makes my projects truly portable! I can take them on the road for demonstrations. As long as there's a power source and a network, I can connect an additional computer, like my trusty Raspberry Pi400, directly into the internal network. And here's the fun part: I'm planning to add a small TFT screen via a cyberdeck expansion to the Pi400. This will transform it into a self-contained, portable AI workstation, allowing me to interact with the AI's code, monitor its memory, and keep everything running smoothly, no matter where I am.

The Portable Command Centre: My Raspberry Pi400

At the heart of my portable AI lab is my trusty Raspberry Pi400. This isn't just a computer; it's the portable command centre for my AI project. It's the key to interacting with the AI within the secure confines of the internal network.

Here's why the Pi400 is so crucial:

• Direct Access to the Inner Sanctum: The Pi400 connects directly to the internal network (IN), providing a secure platform for code development, debugging, and monitoring.

• 

  Raspberry Pi400 with Waveshare 3.5" screen
  and the Adafruit Cyberdeck

  Real-Time Monitoring: I can use the Pi400 to monitor the AI's memory usage, processing activity, and overall performance.
• Cyberdeck Expansion: To make this truly portable, I'm adding a small TFT screen via a cyberdeck expansion. This transforms the Pi400 into a self-contained, mobile workstation.
• On-the-Go Development: Whether I'm at a demonstration, a workshop, or simply working from a different location, the Pi400 allows me to access and manage my AI project with ease.
• The gateway to the airlock: The pi400 will be the main device used to send and receive information through the airlock.
• With the Pi400 as my portable command centre, I have the flexibility and control I need to develop and showcase my AI projects, no matter where I am.

At a later date, I may replace the Pi400 with a PiZero2 and a custom keyboard, to make things more compact, but for now, the Pi400 is perfect for the job. Plus, it gives me a full size keyboard for a more comfortable experience..

Controlled Growth, Controlled Access

Yes, this approach might temporarily limit the AI's exposure and potentially slow its initial learning curve. However, in this experimental space, I believe caution is key. It's better to guide its development carefully than to risk exposing it to unfiltered data too early.

By creating this digital clean room and airlock, I'm building a secure, portable, and controlled environment where my AI can thrive. And with the cyberdeck expansion, I'm adding a touch of classic hacker spirit to my mobile AI lab. It's a testament to the importance of security, careful nurturing, and adaptability in the exciting world of AI development.