I recently entered a T-shirt design competition at work and used AI to help create the final design based on an idea I had. When the submissions were shared, someone commented: “I fear we are missing the creative element of this competition.”

That comment stuck with me. Not because I disagreed with the concern, but because it made me wonder whether we might be mixing up two different things: creativity and artistic ability.

When I created my design, the process did not feel uncreative. I had a clear idea of the message I wanted to communicate and the symbolism behind it. I described that idea to the AI, experimented with variations, and refined the result until it matched what I had imagined.

Throughout the process I was making decisions. I chose the concept, shaped how it should look, and selected the version that best expressed the idea. The AI simply produced the visual interpretation. In that sense it felt more like a tool than a replacement for the thinking behind the design.

This is where the distinction becomes interesting. Creativity is about ideas and imagining something new. Artistic skill is the ability to translate those ideas into drawings, illustrations, or designs.

For someone like me, AI removes a barrier that previously existed. I enjoy ideas and concepts, but I do not have strong artistic skills. AI allows me to explain what I am imagining and see that idea rendered visually.

So when I read the comment about creativity being missing, I wondered if the real concern might be about artistic craftsmanship rather than creativity itself.

AI may not remove creativity. It may simply allow more people to express it.

We are entering a new phase of software engineering where writing code is no longer the hardest skill to learn. With AI tools able to generate working applications in minutes, the real challenge has shifted. As engineers, and especially as people who mentor or teach others, we need to rethink how we help upcoming engineers learn their craft.

AI can write both good and bad code, often with equal confidence. If someone is learning purely by prompting and accepting the output, they are not learning how to think like an engineer. They are learning how to copy and paste. Teaching now needs to focus less on code volume and more on decision making. Why this structure. Why this responsibility. Why this trade off.

I believe the right starting point is architecture, kept deliberately simple. At its most basic, most systems consist of a front end, a backend, and a database. If an upcoming engineer understands what belongs in each of these layers and how data flows between them, they already have a mental model they can apply almost anywhere.

Only after that model is solid should we start introducing best practices. Testing, validation, authentication, authorization, state management, and similar concerns are all important, but not all of them are critical on day one. Teaching everything at once often hides the architecture under a pile of rules and libraries. Instead, we should help learners get the structure right first, then add these concerns one at a time and explain why they exist.

Used this way, AI becomes a teaching aid rather than a crutch. We can ask it to generate examples, then walk through them with learners, questioning what is good, what is risky, and what could be improved. The goal is not to produce perfect code immediately, but to develop the ability to recognise quality.

If we teach upcoming engineers to anchor their thinking in architecture and use AI as a tool rather than an authority, we give them something far more valuable than syntax. We teach them how to build systems that make sense, even as the tools continue to change.

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.