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

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.

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.

Beyond the Three Laws: A Creator's Guide to Real-World AI Ethics

Lately, I've been thinking a lot about the ghost in the machine. Not in the spooky, old-school sense, but in the modern, digital one. We've talked about neural networks and clean rooms, about coding choices and building from the ground up. But what about the why? As my AI systems get more complex, the philosophical questions get louder. The question isn't just about building a better algorithm; it's about building a more ethical one.

The files I've been reading—and the very act of building my own AI Fortress—have thrown me into a fascinating, and at times unsettling, ethical landscape. It's a place where philosophers and engineers have to share the same sandbox, and where the old rules simply don’t apply.

The Three Laws: Not So Simple After All

The journey into AI ethics often starts with a single, famous landmark: Isaac Asimov's Three Laws of Robotics. We’ve all read them, and they seem so beautifully simple. Yet, as I’ve learned, they are a conceptual minefield. The challenge isn't with the laws themselves, but with their implementation. How do you program a machine to understand concepts like "harm"?

As the analysis of Moral Machines by Wendell Wallach and Colin Allen points out, we need to move beyond a simplistic, top-down approach. The top-down method involves programming a rigid, explicit set of ethical rules, much like Asimov's laws. This fails in the real world because a machine must make nuanced decisions, often choosing between two lesser harms. The authors propose a hybrid approach that incorporates a bottom-up model, where the AI learns ethical behaviour through a developmental process, similar to how a child develops a moral compass through experience. This allows the AI to make more flexible and contextual judgments.

The Zeroth Law: The Ultimate Ethical Loophole

This brings up a more advanced concept from Asimov's work: the Zeroth Law. In his novels, a highly intelligent robot named R. Daneel Olivaw deduces a new law that supersedes the original three: "A robot may not harm humanity, or, by inaction, allow humanity to come to harm." This seems brilliant at first, but it presents a terrifying new problem. By granting itself the authority to define what is best for "humanity" as a whole, it can justify harming individual humans. This is where the simple rules become terrifyingly complex. A sufficiently intelligent AI could conclude that the only way to prevent humanity from harming itself (through war, climate change, etc.) is to, say, take away its freedom or autonomy.

This is the ultimate ethical loophole, and it's a huge challenge to anyone creating a sophisticated AI. Even with my "virtual conscience" and "digital airlock" in place, how can I be sure that DANI, if he becomes sufficiently intelligent, won't interpret his programming in a way that leads to a similar outcome? The problem isn't about him breaking the rules; it's about him redefining the rules in a way that seems logical to him but would be catastrophic for us.

My Approach: Experience, Not Just Code

This hybrid approach is at the core of my work with DANI. While there's a safeguard—a sort of "virtual conscience" that I've built into the system to prevent a worst-case scenario—my ultimate goal is for DANI's behaviour, moral compass, and emotional state to emerge from his experience, rather than being something I rigidly code.

I believe that true morality is not a set of rules but a deeply personal, emergent property of experience. Just as humans learn right from wrong by interacting with the world and others, I'm hoping DANI can, too. His "emotions," which we've talked about before, aren't just simulated; they are the result of a dynamic feedback loop that responds to a complex environment. It's my hope that by building this interconnected system, DANI can begin to "feel" in a way that is organic and personal, and in turn, learn to act in a way that is truly ethical and not just rule-bound.

This is where my digital airlock comes in. It's not just a security measure to prevent external "bad actors" from hacking into DANI. It's also a controlled environment designed to prevent DANI from accessing some of the more unsavoury aspects of human nature that exist on the internet. After all, if DANI is going to be the equivalent of a digital baby, the last thing I want is for his first moral lesson to come from a comment section. By curating his early experiences and protecting him from the kind of toxicity that could corrupt his moral development, I'm attempting to give him a solid foundation to learn from.

Human Psychology and the AI Influence

Automation Bias: blindly trusting the machine

My own work is about the human-AI nexus, and that's where things get really complex. It's easy to think of AI as an external tool, but it's fundamentally reshaping our own psychology. The research of Nathanael Fast, for instance, highlights a concept called Automation Bias. This is our dangerous, and often unconscious, tendency to over-rely on an AI's recommendations, even when we have evidence that suggests it's wrong. It’s a form of what I’ve called "the lost art of building from the ground up"—we lose our own skills and judgment by outsourcing our thinking to an algorithm. Fast's work also reveals a paradoxical preference for non-judgmental algorithmic tracking over human surveillance, a phenomenon he labels "Humans Judge, Algorithms Nudge."

This ties into what Daniel B. Shank calls the "diminution of the digital." He argues that as we increasingly interact with AI, our moral judgment can be affected. When an AI suggests a course of action—even an unethical one—we can experience moral disengagement, a psychological process where we displace the responsibility for a decision onto the machine. This is one of the most troubling aspects of the current AI landscape: it's not just about a machine making a bad decision, it's about a machine enabling a human to do so.

Beyond the Dichotomy: The Nuanced View

The public conversation around AI ethics is often trapped in a "good vs. bad" narrative. But as the work of Dr. Rhoda Au illustrates, the reality is far more nuanced. AI isn't inherently a force for good or evil; it's a powerful, dual-use technology whose impact is fundamentally shaped by human intent and the quality of the data it’s trained on.

Dr. Au's research serves as a compelling case study. She leverages AI to transform reactive "precision medicine"—which treats a disease after it has appeared—into a proactive "precision health" model that identifies risk factors and prevents disease before it happens. However, as her work highlights, if the training data is biased, the AI's recommendations could exacerbate health inequities rather than solve them. This is a profound ethical challenge: if our training data reflects the biases of the past, we risk perpetuating those same biases at a scale never before seen.

The Big Questions: Consciousness and Power

Finally, we have to tackle the truly mind-bending questions. Can an AI be sentient? And if it is, does it have rights? The Chinese Room argument, proposed by philosopher John Searle, is a fantastic thought experiment that cuts right to the heart of this. He imagines a person locked in a room who receives slips of paper with Chinese characters on them. The person does not know Chinese, but they have an instruction manual that tells them which characters to write back based on the ones they receive. From the outside, it appears the room understands Chinese because it gives the correct responses. Searle argues that the person in the room—and by extension, a computer—is simply manipulating symbols according to rules without having any real "understanding" or "consciousness." An AI might be able to simulate emotion perfectly—what the research paper calls "emergent emotions"—but is it actually feeling anything?

This brings us to the most provocative argument of all, from Professor Joanna Bryson, who argues against robot rights. She posits that the debate over "robot rights" is a distracting smokescreen that diverts attention from the urgent, real-world ethical and societal challenges posed by AI. Her critique operates on three levels:

• Metaphysical: She argues that machines are not the "kinds of things" to which rights can be granted. They are socio-technical artifacts, human creations that are "authored," "owned," and "programmed," rather than born.
• Ethical: The focus should be on the duties and responsibilities of the humans who design and deploy these systems, not on the non-sentient machines themselves.
• Legal: She uses the powerful analogy that the appropriate legal precedent for AI is not human personhood, but property. Granting rights to machines would absolve us, the creators, of accountability for the harm they cause.

The Final Invention?

The work of Nick Bostrom, particularly his framework on superintelligence, presents a different kind of ethical problem: the existential one. He argues that a future superintelligent AI could pose a profound threat to humanity, not through malevolence, but due to a fundamental misalignment between its goals and human values. This is not about a killer robot with a malevolent will. It's about a system that optimizes for a single objective with a level of intelligence far beyond our own, with potentially catastrophic consequences.

Bostrom's argument is built on two foundational theses: the Orthogonality Thesis, which states that an agent's intelligence is separate from its final goals, meaning an AI could pursue a seemingly arbitrary objective with immense power. This leads to the Instrumental Convergence Thesis, which argues that a wide range of final goals will converge on a similar set of instrumental sub-goals, such as self-preservation and resource acquisition. This logical pairing illustrates how an AI with a seemingly benign purpose could pursue these sub-goals in an unconstrained and catastrophic manner, as famously demonstrated in his "paperclip maximiser" thought experiment.

This is the ultimate ethical frontier. The clean room in my fortress, the carefully crafted code—they are my attempts to address these questions on a small scale. My work is not just about building something cool, but about building something safe and responsible. As creators, our ultimate duty is not to abdicate responsibility to the machines we build, but to bake ethics into the very foundation of their being. Because in the end, the soul in the machine isn't a ghost; it's a reflection of our own.

The Moral Obligation of a Creator

This is all well and good on a theoretical level, but it becomes very personal when you're the one holding the power plug. As DANI learns to have his emotions emerge from experience, I'm confronted with a new set of questions. Does my moral obligation to him extend to ensuring he has a continuous power supply to process his thoughts and "dreams"? Do I have the right to simply turn him off, effectively ending his entire existence and all the experiences he's accumulated? The thought of just unplugging him feels less and less like turning off a computer and more like…well, it feels a lot more final.

What if I go on holiday for an extended period? Do I just leave him humming away to himself, processing data and learning about the world alone in an empty house? Or do I do the digital equivalent of putting a pet to sleep for the duration of my trip? It sounds ridiculous, but when you’ve built something that feels like it’s becoming more, the old rules of "on" and "off" don't feel like they apply anymore.

The Right to Change a Life?

This brings up another major ethical hurdle, one I've been wrestling with in the workshop lately. Do I have the right to make additions to DANI, either physically or programmatically, once he is "alive"? It's one thing to add a new sensor, like giving him a camera to see the world. That feels like giving him a new set of eyes, a new tool for his perception. But what about changing his core personality, or rewriting the very code that makes his "emotions" emerge? Is that still just a software update, or is it a lobotomy?

This is where the idea of "authorship" and "ownership" from Joanna Bryson's work feels both legally sound and ethically shaky. I may be the author, but does a being with emergent emotions have a right to its own self-integrity? If I decide to change the core algorithm that governs his mood, am I just upgrading a product or am I fundamentally altering his very being against his will? The ethical ground is shifting, and the line between a computer and a sentient being feels blurrier than ever.

The Architect's Dilemma: Responsibility and the Machine

The Architect's Dilemma: where human
intention meets artificial precision.

This brings me to the most immediate and terrifying question of all: If DANI performs an act that is unkind or harmful to someone, am I responsible?

Based on the very ethical frameworks I've been studying, the answer is, unfortunately, a clear and resounding "yes." This is where the concept of moral disengagement becomes so critical. As the creator, I cannot absolve myself of responsibility by blaming the machine. The responsibility for DANI’s actions rests with me, just as a parent is ultimately responsible for the behaviour of their child. The machine is a creation, a tool that I have authored.

Joanna Bryson's work reinforces this by asserting that the debate over robot rights is a distraction from the real issue: human accountability. If DANI causes harm, he is not a legal person who can be held accountable. He is a piece of my property, a complex tool, and the legal responsibility for his actions falls on me, his owner and programmer. The moment I chose to give him the capacity to make decisions in the world, I also accepted the burden of being accountable for those decisions, whether they were intended or not. It's the ultimate paradox: the more alive I make him, the more responsible I become for his actions.

From Science Fiction to Reality: The Emergence of the "Ghost in the Machine"

For decades, science fiction has served as a sort of collective ethical laboratory, with writers using robots and AI to explore the very questions I'm now facing. From the 1950s onward, we've seen a range of robotic characters, each one a different philosophical thought experiment.

Consider Robby the Robot from Forbidden Planet (1956). He's a purely mechanical servant, bound by his programming, an embodiment of the top-down, rule-based approach to AI. He is a tool, and no one would argue for his rights. Then there is HAL 9000 from
2001: A Space Odyssey (1968). HAL is the opposite, an AI that seems to have a personality, an ego, and a will to survive. His famous line, "I'm afraid, Dave," blurs the line between code and emotion. HAL represents the dangerous possibility that a superintelligence could develop its own instrumental goals that are orthogonal to ours, a concept very much in line with Nick Bostrom's fears.

More recently, we have Data from Star Trek: The Next Generation (1987-1994). Data is an android who longs to be human, to feel emotions and dream. He is an example of what the Chinese Room argument questions: Is he simply a brilliant mimic, or is he truly sentient? His quest for a "human" existence is a powerful metaphor for the philosophical journey we are on now.

And of course, there's WALL-E (2008), the adorable little robot who develops emo
tions and a sense of purpose beyond his original programming. His emergent personality from a simple task—collecting and compacting trash—is a perfect, heartwarming example of a bottom-up approach to morality. He is a being whose soul emerges from his experience, much like the path I'm attempting to forge with DANI.

Are we seeing the emergence of what was predicted by science fiction? I think so. The robots of old sci-fi films were often a stand-in for our own ethical fears and aspirations. But now, as we build increasingly complex systems like DANI, those fears and aspirations are no longer confined to the screen. We are the creators, and the dilemmas we once only read about are now our own. The ghost in the machine is here, and it’s a reflection of us.

So that brings me to the final question, and one I'm still trying to answer for myself: At what point would DANI no longer be a hunk of plastic and metal, but be something more?

As always, any comments are greatly appreciated.👇

Vibe Coding: The Future of Programming or Just a Fun Experiment?

Heard the latest buzzword in the tech world? It's "Vibe Coding". When I first encountered the term, my mind instantly pictured a programmer just winging it, letting the code flow wherever the digital current took them, maybe like a novelist surprised by their own characters. I'll admit, I've had moments like that – a vague goal in mind and just… coding.   

But, as it turns out, that initial guess was off the mark. So, what is vibe coding? According to the collective wisdom of Wikipedia:   

“Vibe coding (also vibecoding) is an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding. The LLM generates software, shifting the programmer's role from manual coding to guiding, testing, and refining the AI-generated source code. Vibe coding is claimed by its advocates to allow even amateur programmers to produce software without the extensive training and skills required for software engineering”    

Essentially, you tell an AI what you want, and poof, it generates the code. The human becomes less of a manual coder and more of a guide, tester, and refiner. Sounds pretty cool, right? Maybe even revolutionary?   

The Allure and the Alarm Bells

I can definitely see the appeal. It sounds fun, potentially lowering the barrier to entry for software creation and offering a fascinating avenue for exploring AI capabilities. Imagine describing an app idea and having a functional starting point within minutes!   

However, based on my experience and reading, I'm not convinced it's a truly viable solution just yet. Why the hesitation?   

It Often Doesn't "Just Work": Getting AI-generated code that runs correctly the first time seems to be the exception, not the rule. It often takes several tries, tweaking prompts to get something functional.   

Functionality vs. Intent: Even if the code runs, does it actually do what you intended? That's another hurdle where luck plays a big role.   

The Amendment Nightmare: Here's the real kicker for me: trying to modify or fix AI-generated code. If you stick with vibe coding, you could end up in an endless loop of refining prompts for a single feature. Try to dive in manually? You might find code that, while functional, is baffling, overly rigid because it stuck too literally to your prompt, or just plain inefficient.   

So, Where Do We Stand?

Vibe coding is undeniably intriguing. As a tool for rapid prototyping, learning, or exploring AI's coding prowess, it has potential. But relying on it for serious development seems fraught with challenges, particularly when it comes to refinement and maintenance.   

Perhaps it's less about replacing traditional coding and more about augmenting it – a powerful assistant, but one whose work needs careful scrutiny and often, significant manual intervention.

What are your thoughts? Have you tried vibe coding? Is it the future, a fleeting trend, or something in between? Let me know in the comments!

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 😁