One of the things people often bring up when talking about AI and coding is “hallucinations.” You’ll hear it framed as AI confidently doing the wrong thing, and therefore being unsafe or unreliable as part of a development team.

I code with AI a lot, and honestly, this does happen. Sometimes the output is clearly not what I asked for, and I’ll tell it to stop and start again.

But here’s the thing. I don’t get my own code right on the first try either.

When I’m solving a problem, I usually explore a few different approaches. I might write something, realize halfway through that my understanding of the problem has shifted, and then rewrite parts of it or throw it away entirely. That’s not a failure. That’s just how thinking works while building software.

So when AI produces code that misses the mark, I don’t see it as hallucinating in a human sense. I see it as the AI forming a reasonable interpretation of my prompt based on the information I gave it. Sometimes that interpretation aligns perfectly with what I want. Sometimes it doesn’t. And sometimes it exposes that my request wasn’t as clear as I thought it was.

In those moments, the “wrong” answer is still useful. It forces me to be more precise. It highlights missing constraints. It pushes me to explain the problem better, which often leads to a better solution overall.

If we treat AI like a junior developer who needs context, feedback, and refinement, the experience makes a lot more sense. The iteration loop is just faster, and the cost of trying another approach is close to zero.

In that light, AI hallucinations feel less like a fundamental problem and more like a natural part of collaboration. They’re a reminder that software development has always been iterative, exploratory, and conversational — and that hasn’t really changed just because the collaborator happens to be a machine.

When I have spare time or feel bored, I like to experiment with AI by building small reference websites that help me learn new things. I call most of these projects “Master X Training,” where X stands for whatever topic I’m exploring — like “Master CSS Training” or “Master Git Training.” Each site is a compact, self-guided learning hub designed to structure information in a way that makes it easy for me to revisit, practice, and reinforce what I’ve learned.

AI plays a major role in creating these sites. When prompted effectively, it can organize concepts, explain details, and even suggest related ideas that I might not have thought of before. Often, I’ll ask AI to expand a page, add examples, or generate new sections. Then, as I review the content it produces, I discover insights and techniques that deepen my understanding of the subject. It becomes a cycle of exploration—AI helps me build the resource, and the process of reviewing it helps me learn even more.

The overall goal behind these projects is simple: to make learning efficient, engaging, and easily accessible. Each site acts as both a personal knowledge base and a quick reference tool. Whether I want to refresh a skill, explore a new technology, or just satisfy my curiosity, these “Master X Training” sites give me a structured and enjoyable way to learn.

Master Git

https://master-git.cairnsgames.co.za/

Master CSS

https://master-css.cairnsgames.co.za/

Master HTML

https://master-html.cairnsgames.co.za/

Master Accessibility

https://master-accessibility.cairnsgames.co.za/

Learn Interactive Elements without Javascript

https://master-interactive.cairnsgames.co.za/

Different websites as Style Guides

https://styleguide.cairns.co.za/

If you find an error in any of these sites please let me know

I built a simple, fast-paced course called Master CSS:
https://master-css.cairnsgames.co.za/

It’s a self-paced, self-guided course designed to help you jump straight into CSS. You pick the topics you want to explore, read short explanations, and see how the code works — no long lectures or filler.

Many tutorials spend too much time talking about CSS instead of showing it. This course flips that around: quick demos, real examples, and you learn by experimenting.

It started as a small Flexbox refresher for myself — and just kept growing from there.

I’ve seen a growing number of posts lately about how terrible AI-generated code will supposedly be to maintain. The argument usually goes something like this: “Sure, it’s fast now, but in a year or two no one will understand it.” And while that might sound reasonable on the surface, it misses an important point—maintaining code has always been difficult. Anyone who has joined a new project knows the pain of trying to decipher another developer’s “clever” logic from three years ago.

AI doesn’t change that reality. What it changes is the speed and accessibility of getting to a working solution. Whether that code is maintainable or not still comes down to the same thing it always has: the habits and discipline of the person writing it. If you’re sloppy, AI will happily amplify your sloppiness. But if you care about structure, clarity, and testing, you can guide AI to produce the same level of quality you would yourself—and then improve it further.

That’s the key mindset shift. Using AI doesn’t absolve you of responsibility; it amplifies it. You become the reviewer, the architect, and the quality gate. You’re no longer just typing code—you’re designing how that code should exist and evolve.

The irony is that AI is also excellent at refactoring. It can take legacy code and clean it up faster than most developers can finish their morning coffee. The trick is knowing how to use it: guiding it with context, giving it examples, and holding it to the same standards you’d expect from any human teammate.

When used properly, AI isn’t lowering the quality bar—it’s raising it. It gives us the opportunity to focus on architecture, testing, and maintainability instead of boilerplate. And yes, it’s faster. Much faster. But speed isn’t the problem—lack of care is.

One of the unexpected benefits of coding with AI generation is how it naturally pushes you toward writing modular software. When you describe what you want clearly enough for an AI to generate it, you start breaking your ideas into smaller, more independent parts. Each piece has a clear purpose and boundary — just enough context to stand on its own.

As a result, my GitHub repos have become cleaner and leaner. There’s no half-finished idea in a corner, no unneeded scaffolding, no “maybe I’ll use this later” utilities. Each repository does one thing, and it does it well. The code reads more like a set of purposeful tools than a workshop full of scraps.

AI generation forces clarity — if you can’t describe a function or module precisely, it won’t generate what you want. That discipline carries over to the code itself. The outcome is concise, readable, and free of clutter. Clean code, in the truest sense, is not about clever tricks or perfect architecture — it’s about removing everything that doesn’t need to be there.

I think the hardest part of joining a new company as a Senior Software Engineer, is taking that first step to confidently approve Pull requests.

You have to feel confident in your knowledge of the code base, the architecture used, the libraries used in the project, and the team’s coding standard. You also know that one Approval means the code makes it’s way into the main code base and will go to production…. Being confident enough to do this is scary!

And then of course you know the Lead will check the code anyway, and if you approved something that was blatantly incorrect, you really feel you let the team down.

But once you have the confidence to start approving, your contributions to the team are increased significantly as you make the code flow faster, and you take some of the load off the Lead.

Last night I built a small website to show different webpage styles. So if you have wondered what Glassmorphism vs Neomorphism vs Minimalist web page styles look like, you can find them all on this page.

https://styleguide.cairns.co.za/

The amazing thing is they are all done using Tailwindcss with no custom classes being defined. All 29 style pages are all done without any custom CSS.

(Yes I used AI to generate most of this)

I’ve seen quite a few posts lately talking about how important context is when using AI to code. I couldn’t agree more. For me, vibe coding isn’t about asking the AI what to code, it’s about explaining what we want to achieve. It reminds me of something I heard years ago—programming is less about knowing how to do something and more about knowing what can be done.

As a senior developer, I’ve built up a strong understanding of the tools at my disposal—React, REST APIs, SQL, and many others. I also know what I want to achieve with the products I’m developing. When I bring that knowledge into the conversation with AI, I can guide it in the right direction and ensure the tools are being used correctly. That combination feels like a genuine superpower.

I wouldn’t claim that AI makes me ten times faster, but it has changed the way I work. I’m now able to deliver far more value in the same amount of time. That shift in output and focus is where the real impact or AI Coding/Vibe coding lies.

When we talk about software architecture, it’s easy to get lost in diagrams full of boxes, arrows, and buzzwords. But for most startup projects, the foundation doesn’t need to be complicated.

At its simplest, you need three layers. The front end, where users interact with your product. The back end, which includes authentication and the business logic that powers the experience. And the database, where the information lives. That’s enough to get started and build something meaningful.

And here’s the exciting part: today we can vibe code across all of these layers. Tools like Bolt.new make it quick to spin up front ends. ChatGPT or GitHub Copilot can help shape the back end and authentication logic. They can even guide you through setting up and querying your database. Beyond those, there’s a growing world of AI tools that can fit in wherever you need them.

You don’t need queues, event buses, or complex logging right away. Keep it simple, focus on delivering value, and let these tools accelerate your progress. The sophistication can always come later—when your product, team, and users are ready for it.

When we talk about being successful with AI-assisted coding, I think it’s easy to focus too much on the “magic” of the AI and forget the fundamentals. But success doesn’t come from just pressing generate. It comes from the same balance we’ve always needed in software: good ideas, the right technologies, and solid practices.

The first part is the idea itself. It’s tempting to throw every half-baked thought at an AI and hope it will shape it into a masterpiece. But that usually leads to messy, disconnected code. A better approach is to move step by step, layering features carefully so that modules fit together naturally. Just like in traditional coding, structure and pacing matter.
The second part is the technology. AI can write React code, for example, but it won’t decide for you whether state should sit inside a component, live in a shared context, or be managed through a dedicated state manager. Understanding those building blocks is what keeps a project performant, secure, and scalable. Without that knowledge, it’s very easy to end up with something fragile.

And then there are best practices. File sizes grow too large if you never pause to split them. APIs can quickly become unmaintainable if you don’t validate authentication properly. Test coverage, error handling, naming conventions — these are the details that separate “something that runs” from “something that lasts.”

There are other pieces too: version control discipline, clear documentation, and thinking about deployment early rather than as an afterthought. All of these add up. AI coding helps us move faster, but it doesn’t replace the craft, it amplifies it. And when we respect both the creativity of the idea and the discipline of the practice, that’s when we start to see real success.