DEV Community: Shaquille Niekerk

The Last Generation of Developers Who Learned to Code Manually

Shaquille Niekerk — Mon, 15 Jun 2026 06:21:15 +0000

There was a time when software engineers had to understand the machine almost as much as the software itself.

Not metaphorically. Literally.

Game developers working on older consoles didn’t just write games, they engineered around physical limitations. Cartridges weren’t just storage devices. Developers learned how to manipulate the hardware itself to squeeze out more performance, more memory, more possibilities. Every byte mattered.

And that got me thinking about AI.

Not in the “AI is replacing developers tomorrow” kind of way. More in the:
“What actually happens to software engineering when the hardest part is no longer writing the code itself?” kind of way.

Because if you zoom out far enough, software engineering almost feels like a long history of abstraction. Each generation moves one layer further away from the metal.

From Hardware Wizards to Software Builders

Early programmers needed to think about hardware constantly.
Memory constraints.
CPU cycles.
Storage limitations.
Manual optimization.

Then came higher-level programming languages. Suddenly we weren’t flipping bits or writing assembly for everything anymore. Languages started handling more complexity for us. Eventually memory management became less painful too.

Manual garbage collection gave way to runtimes and managed environments.
Frameworks appeared.
Libraries exploded.
Open source communities grew.

And slowly, software engineering started becoming less about building everything yourself, and more about knowing how to assemble systems effectively.

The Internet Changed the Developer Brain

Then came another massive shift: the internet.

More specifically, searchable knowledge.

Sites like Stack Overflow completely changed how developers worked. Before that, a lot of programming knowledge lived in books, documentation, university courses, or the minds of senior engineers guarding ancient deployment rituals like dragons protecting caves of gold.

Then suddenly:

someone somewhere had already solved your problem
explanations were searchable
code snippets were one copy-paste away

Developers joked about it constantly.

“99% of programming is just Googling.”

“Stack Overflow is my senior developer.”

At the time, some people criticized this shift.
“You don’t really understand the code.”
“You’re relying too much on external knowledge.”

But something interesting happened. Developers didn’t become less productive, they became dramatically more productive.

The value wasn’t memorizing syntax anymore.
It became understanding systems, architecture, trade-offs, debugging, and knowing how pieces fit together.

And now AI feels like the next evolution of that same pattern.

AI Might Be the Biggest Abstraction Layer Yet

Today, AI can:

scaffold applications
explain concepts
generate APIs
debug code
write tests
create SQL queries
refactor components
summarize documentation

Sometimes frighteningly well.

The weird part is that this changes the development process itself.

For years, writing code was the bottleneck.
Now the bottleneck is slowly becoming:

knowing what to build
verifying correctness
designing systems properly
communicating intent clearly
understanding whether the generated solution is actually good

Maybe the future software engineer spends less time manually writing every line and more time acting like:

a systems architect
a technical director
a reviewer
a validator
an orchestrator of intelligent tools

Not replacing engineering knowledge, but changing where that knowledge gets applied.

The “Copy-Paste” Debate Is Happening Again

What’s fascinating is how familiar this all sounds. People once mocked developers for relying on Stack Overflow. Now people mock developers for relying on AI. But maybe we’re watching the same cycle repeat itself.

Every major leap in software engineering seems to create fear that “real engineering” is disappearing.

Higher-level languages.
Frameworks.
Libraries.
Search engines.
Open source.
Cloud infrastructure.

Each abstraction reduced friction.
Each abstraction also changed what skills mattered most
And every time, developers adapted.

We’re Still in the Launch-Window Era of AI Development

One thing I keep thinking about is console generations in gaming.

If you compare early games released on a console to games released near the end of that same console’s life cycle, the difference is insane.

Developers eventually learn:

the quirks of the hardware
optimization tricks
hidden capabilities
workflow improvements
what not to do

By the end of the generation, you get masterpieces that seemed impossible when the console first launched.

That honestly feels a lot like where we are with AI right now.

We’re still shipping the equivalent of launch titles.

Some AI-assisted software today feels messy.
Over-engineered.
Poorly understood.
Built too fast.
Held together with hope, dreams, and motivational quotes.

But that might simply be the awkward early phase of learning a new tool.

Over time, developers will probably learn:

when AI helps
when it hurts
how to structure workflows around it
how to validate outputs properly
how to combine speed with quality

And eventually, teams that truly understand these tools may build things that feel impossible by today’s standards.

So… What Does a Software Engineer Become?

I don’t think software engineers disappear. At least not in the way some people predict, but I do think the role evolves.

The same way engineers once moved:

from hardware-focused thinking
to software-focused thinking
to framework ecosystems
to cloud-native systems

…we may now be moving toward intent-driven development.

Where the real skill isn’t:
“Can you write every line manually?”

But rather:
“Can you design, guide, validate, and refine complex systems effectively?”

Because AI can generate code.

But understanding:

trade-offs
scalability
maintainability
security
user experience
business logic
architecture

That still matters, and maybe now more than ever.

Final Thoughts

I don’t think we fully understand yet how AI will reshape software engineering.

Honestly, I think we’re still in the experimental phase where everyone is simultaneously excited, confused, skeptical, and slightly terrified.

But looking back at the history of software development, one thing seems consistent:

Every major abstraction changed the way engineers worked.
And every time, the developers who learned how to properly use the new tools ended up building incredible things.

Maybe AI is just the next chapter in that story, or maybe it’s the biggest shift yet.

Either way, I think we’re witnessing a fascinating moment in software engineering history.

And I’m very curious to see what developers become on the other side of it.

What do you think?

Are we moving toward a future where developers become architects of intent?
Or do you think AI-assisted development is being massively overhyped?

The Real Power of Claude Code Isn’t the Code Generation

Shaquille Niekerk — Mon, 08 Jun 2026 12:01:51 +0000

I would like to take some time to talk about AI coding tools, specifically my experience moving from GitHub Copilot to Claude Code CLI.

This isn't going to be a "Copilot vs Claude" cage match. I still use Copilot daily inside VS Code. It's great at what it does.

But over the last few months, I noticed something changing in the way I worked with AI.

I started with Copilot mostly with:

autocomplete
inline questions
formatting help
quick logic block reviews

Alongside that, I'd use ChatGPT for debugging, refactoring, tests, and explaining concepts when my brain temporarily hits a blue screen. And all this worked well.

Then one day, my company got a subscription to Claude, and things started shifting pretty quickly.
Not because the code generation was magically better. But because Claude Code made me think differently about context.

The early days

The first moment that really sold me on Claude Code wasn't some massive autonomous feature implementation. But rather a skill.
I had set up a reusable skill that updated multiple files across a test structure while keeping formatting and conventions consistent.

That was the moment it stopped feeling like "smart autocomplete" and started feeling collaborative. And honestly, the transition wasn't too difficult for me because I was already used to properly prompting AI by:

giving enough context
clearly defining goals
discussing changes before implementation
reviewing plans before execution

The harder part was learning how to structure everything around Claude Code, because once you start using the skills, hooks, CLAUDE.md file, and agents, you realize pretty quickly:

The real power of Claude Code isn't the code generation.

It's the systems you build around it

Copilot vs Claude Code

Copilot still shines for quick edits for me. If I'm manually working through a logic block and know exactly what I want, Copilot's inline autocomplete is fast and lightweight. I still use it constantly.

Claude Code feels different in that it feels more context-aware, especially when working across multiple files.

With Copilot, I tend to monitor more closely. With Claude Code, I spend more time planning before implementation even starts. And strangely enough, that planning phase has made me think more like an architect than just a developer.
This honestly has been one of the biggest benefits for me.

My Claude Setup

Every project I work on now has its own Claude structure:

.claude/
 | skills/
 | agents/
 | hooks/
 | docs/
CLAUDE.md

This setup was heavily inspired by Anthropic's courses, which I'd genuinely recommend if you want to use Claude Code properly. They are free to all.
The ones I found most useful were:

What I like about project-specific setups is that each codebase gets its own context. A React TypeScript frontend gets frontend-focused skills. A Go backend gets backend-focused skills. And each CLAUDE.md file contains things like:

coding standards
naming conventions
architecture rules
project overviews
patterns to follow

Even some simple rules have a huge difference in consistency.

The skill I use the most

The skill I always use is a planning skill.
The workflow is simple:

I describe the feature or bug
The skill scans the codebase
It identifies what exists and what may need to change
It creates a planning document inside: .claude/docs/

Once the document is created, I manually review and approve it before implementation starts.

The approval step matters the most because one thing I've learned real quick is this:

AI should not be left alone to do the heavy lifting

Hooks, Guardrails, and Security

Another thing I think many developers overlook with AI tooling is security. These tools can read a lot if you let them.

I use hooks to prevent Claude from accessing sensitive files using PreToolUse matchers for:

Read
Edit
Write
Grep (this one is often overlooked) A simplified version looks something like this:

{
   "matcher": "Read|Edit|Write|Grep",
   "block": [
     ".env",
     "secrets/",
     "private-keys/"
   ]
}

It's not perfect, but it adds guardrails. And I think guardrails should be one of the most important parts of AI-assisted development. Because AI tools are incredibly capable, but they're also extremely confident, sometimes they're confidently wrong.

The best description I've heard, and the one I now use constantly, is this:

Treat AI like a super confident junior developer.

It will be Fasr, Helpful, and sometimes brilliant, but they still require oversight.

Where I am today

Right now, I still don't fully trust Claude Code to implement large features without supervision. And I think that's a healthy mindset because sometimes it hallucinates patterns, over-engineers, or confidently walks directly into the architectural equivalent of a wall.

But despite that, it has already changed the way I develop software. I spend more time planning, more time thinking about systems, and creating reusable workflows instead of solving the same problem time and time again.

My goal is not to stop coding, it's to code better. AI should not be used to replace developers, but rather to help developers think at a higher level.

That’s it from me for this post.
I'd love to hear how other developers are using Claude Code, Copilot, Cursor, or any other AI tooling in their workflow.

What's your current setup looking like?
And which AI has become your go-to coding copilot so far?

Comms Under Fire - Update 01

Shaquille Niekerk — Fri, 16 Jan 2026 13:27:50 +0000

This is a major update that I've done on my game.
From a shift in the overall purpose of the game, to the mechanics, down to how things look. Below I will go over everything that I've done and try and explain why I've done it.

Purpose

Originally I wanted to create a web demo of a game I've wanted to create for PC, a game where you're in the drivers seat of a propaganda machine, and the middle man between soldiers on the ground and the powers that decide the fate of the nation. Oh, and this takes place during a war...
Once I created the demo I realised that the tools I had to create this proved to be more difficult, so I stripped back on some functionalities and in doing so I realised I was working toward a different idea. a classic competitive typing game.
This will have leader boards, with those who have the highest WPM sitting at the top, challenge modes where you can challenge other users to see who types the fastest, and a story mode, if you just want to improve in a relatively stress free mode, while getting the gist of what the story would be in this world.

Mechanics

The mechanics have not changed that much, the major change is that I am trying to remove any mouse input. Having the main element of the game be controlled solely by keyboard inputs.

Looks

Originally I had two monitors on screen. One that displayed the text you needed to type, and the other displaying the text that you were typing.
This approach brought a few issues. Firstly people kept getting lost where they were in the text because they had to move their eyes between two monitors. The fix for this was to show a cursor of where you were as you typed, but this just made people only focus on that one monitor, making the two monitor approach seem redundant... Now I think I will still keep the two monitor approach for the main game I plan on creating, but for now one monitor seems to do the job just fine.

Update 01

So here we are with the first update.
A whole new game mode, from a story driven typing game to a ranked typing game. A whole new look, from a two monitor setup to a single monitor setup that can be controlled entirely with the keyboard.

For Update 01 I've only included the story mode. But rest assured that I am working on many updates to get this thing having all game modes I've mentioned, and any new ones that come to mind as I go.

Thank you for reading,
And please check out the game here.
And leave a comment on what you think, or let me know if you have any issues

How One Game Made Me a Gamer Again

Shaquille Niekerk — Tue, 13 Jan 2026 14:56:04 +0000

Lately, games have started to feel less like an escape and more like a chore.

Every new release seems to come with a trade-off. Battle passes, cosmetic shops, seasonal content, daily logins. The message feels clear: the more money you spend and the more time you sink, the more fun you’re allowed to have. Microtransactions are “optional,” of course. Just like breathing.

I started wondering if the problem was me.

Maybe I’ve just lost the patience to really get into games. Maybe adulthood hollowed out that part of my brain. I’d watch reviews where someone confidently stamped an “8/10” on a game, boot it up myself, and immediately feel like I’d played it already. Same mechanics, different coat of paint. Or worse, a game that felt unfinished unless I paid to fill in the gaps.

Then, almost by accident, I played Dispatch.

For those who don’t know it, you’re in charge of a superhero group, managing crises and sending heroes out to fight crime. No endless progression systems. No dangling carrots. Just a focused idea, executed well.

I finished it in one sitting. And immediately wanted to replay it to see the other outcomes.

That hasn’t happened to me in years. I still haven’t finished The Sims 2, and I started that around 2007.

That experience made me pause. Maybe I wasn’t burnt out on games. Maybe I was just burnt out on the kinds of games I’d been choosing.

So I tested that idea.

Instead of relying on reviews and scores, I went back to how I picked what game I play back in the day, so I started watching trailers and forming my own opinion about whether a game actually looked fun to me. Not “content-rich” not “worth the grind” just fun.

That’s how I landed on High on Life.

On my first play, I went for four uninterrupted hours.

That might not sound impressive, but for me, that’s huge. Four hours without checking the time. Four hours without feeling guilty. Four hours without that nagging sense that I should be doing something more “productive.”

And when I stopped playing, I didn’t feel like I’d wasted my time.

So now I’m left with a burning question.

Is it just me, or have a lot of modern games become either souls like pits that require time and dedication just to master one move, or carefully engineered money machines designed to drip-feed dopamine? Games that don’t respect your time unless you give them your wallet too?

So great games are still out there, and I’ve just been looking in all the wrong places.

What game(s) have you been playing lately that was just an absolute blast?

My First game - Comms Under Fire

Shaquille Niekerk — Thu, 11 Dec 2025 14:57:28 +0000

A game set in an alternate world where two nations are locked in a brutal war. You’ve been assigned to man the comms, where you’ll find yourself drafting Propaganda to keep your fellow citizens calm, hacking into enemy communication channels to leak sensitive state secrets, and planting destabilizing messages to push the enemy’s civilians into panic.

All of this while staying alive during active invasions, relaying time-sensitive comms from the frontline to HQ, and doing whatever it takes to help win this war.

The Comms Under Fire mini-demo has just gone live, and you can play-test it right now. It’s the tiniest snippet of the full idea — a small taste of what the final game will become. I’ll be releasing the full version on Steam once I’ve got the proper tools to build it out.

For now, enjoy the free online mini-demo. Updates will be rolling in, so keep an eye out!