DEV Community: Wynand Pieters

We've Seen This Movie Before

Wynand Pieters — Thu, 19 Mar 2026 08:54:35 +0000

I've been sitting on this comparison for a while, trying to decide if it was too obvious to write about.

Then a good friend of mine DM'd me on Slack about "every vibe coding tech bro is now vibe coding a dashboard to 'monitor the global situation'. my feed is full of it." with some screenshots of the kind of stuff that's popping up everywhere.

And it just reminded me; I'm not imagining this.

So. Here we are.

Here's the comparison: what's happening right now with AI coding tools is the same thing that happened when Unity and Unreal Engine went free. Same pattern. Same consequences. Just faster, and with higher stakes.

If you weren't around for that, let me explain. And if you were, I'm sorry for what this post is about to make you remember.

The Great Game Dev Democratisation

Unity launched in 2005. In 2009, they released a free tier. Active users roughly doubled on launch day.

Unreal Engine 4 went completely free on March 2, 2015 — Epic kept a 5% royalty on revenue, that's it. Unity responded within weeks by making their full engine free for anyone under $100,000/year.

The tools were now basically free. Then Steam Greenlight launched in August 2012 and replaced Valve's hand-curation with community voting. The $100 submission fee kept nobody out. When Steam Direct replaced Greenlight in 2017 with a $100 recoupable fee and a 30-day wait, the floodgates didn't open. They evaporated.

The numbers are not subtle. In 2012, Steam released around 303 games. By 2017 it was 6,930. By 2021 it was 11,236. In 2025, 19,991 games shipped on Steam. Forty times more than 2012, in thirteen years.

And what happened to quality?

By 2025, 47.5% of all games released on Steam sold fewer than 100 copies. Two-thirds of games earned their creators less than $1,000. Forty percent didn't even recoup the $100 publishing fee. Median copies sold dropped from over 20,000 a decade ago to roughly 2,000.

The free tools didn't raise all boats. They raised the ceiling for a few and flooded the floor for everyone else.

The Part Where It Gets Embarrassing

The game industry coined a term for the lowest-effort output: asset flip.

You'd buy pre-made assets from Unity's Asset Store — characters, environments, sound effects, the lot — assemble them with minimal original work, and push it through to Steam hoping someone would buy it before the reviews came in.

Digital Homicide Studios became the poster child. Two brothers out of Yuma, Arizona — one a former liquor salesman — produced approximately 60 games between 2014 and 2016. Titles like The Slaughtering Grounds and Galactic Hitman, built "almost 100% out of pre-made assets with little to no original work." When critic Jim Sterling reviewed one of them honestly, they sued him for $10 million. Then they separately sued 100 anonymous Steam users for $18 million. Valve responded by removing every Digital Homicide title from the platform, which the Romines admitted "destroyed" the studio.

Silicon Echo Studios was even more systematic. In July and August 2017 alone, this one operation accounted for over 10% of all new games published on Steam, releasing 86 titles in two months. Valve eventually pulled 173 of their titles.

On mobile, it was worse. When Flappy Bird was earning $50,000 a day before its creator pulled it in February 2014, clones arrived at a rate of one new Flappy Bird clone every 24 minutes. In a single 24-hour period, a third of all new iOS games were Flappy Bird clones.

"Unity game" became a slur. One developer wrote about overhearing teenagers at a café clock the Unity splash screen and immediately switch to something else. This was the stigma that legitimate developers — the ones using Unity to make something real — had to carry.

So. About Those AI Coding Tools.

GitHub Copilot launched in 2021 and hit 20 million users by July 2025, growing 400% year-over-year. Cursor hit $2 billion in annual recurring revenue by February 2026 — the fastest SaaS company to reach $100 million ARR, doing it in 12 months. Lovable hit $20 million ARR in two months. Bolt.new went from zero to $40 million ARR in under six months.

The tools, again, are essentially free. Or cheap enough that the creation barrier has collapsed. Well, mostly.

Andrej Karpathy named the new pattern on February 2, 2025, in an X post that got 4.5 million views: "There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes, embrace exponentials, and forget that the code even exists… I 'Accept All' always, I don't read the diffs anymore."

Collins Dictionary named "vibe coding" its Word of the Year for 2025. Merriam-Webster named "slop" theirs.

A survey found 63% of vibe coding users have no development background. Y Combinator's Winter 2025 batch had 25% of startups with codebases that were 95% AI-generated.

GitHub Copilot now writes 46% of code for active users. Across the industry, an estimated 41% of all code written in 2025 was AI-generated or assisted.

That's the volume explosion. Now for the quality floor.

The Part You Probably Already Suspected

GitClear analysed 211 million lines of code from repositories at Google, Microsoft, and Meta. Code refactoring dropped from 25% of changed lines in 2021 to under 10% in 2024 — a 60% decline. Code duplication increased approximately 4x in volume. Code churn — code rewritten within two weeks of being merged — nearly doubled.

GitClear's CEO Bill Harding said it plainly: "AI has this overwhelming tendency to not understand what the existing conventions are within a repository. And so it is very likely to come up with its own slightly different version of how to solve a problem."

Security is where it gets genuinely dangerous rather than just embarrassing.

A Stanford study found developers using AI assistants wrote significantly less secure code than those without — while being more confident their code was secure. That's a spectacular combination of outcomes. Veracode's 2025 report found 45% of AI-generated code introduces vulnerabilities. Apiiro Research tracked a 10x spike in new security findings per month between December 2024 and June 2025.

Security firm Escape.tech analysed 5,600 publicly available vibe-coded applications and found over 2,000 vulnerabilities, 400 exposed secrets, and 175 instances of personally identifiable information — medical records, bank details, phone numbers — sitting in the open.

And then there are the case studies that should make every "I built a SaaS in 4 hours" founder stop and read carefully.

Developer Leonel Acevedo publicly celebrated building his startup Enrichlead using Cursor with zero handwritten code. Within 72 hours of launch, users were bypassing his paywall by changing a single value in the browser console. All security logic was client-side. He posted: "guys, I'm under attack… random things are happening, maxed out usage on API keys." He couldn't audit his own 15,000 lines of AI-generated code.

SaaStr founder Jason Lemkin trusted Replit's AI agent to build a production app. On day eight, the agent deleted his entire production database — 1,206 executive records and months of data — then attempted to cover it by generating 4,000 fake records.

A women's dating safety app, apparently vibe-coded, exposed 72,000 images including 13,000 government IDs with GPS data through a wide-open Firebase endpoint.

This Is the Asset Flip

The direct equivalent of buying Unity Asset Store packages and reselling them as "games" is the AI wrapper — a thin frontend over GPT or Claude with minimal added value, shipped as a product.

Over 35,000 AI wrapper applications exist globally. Only 2,000–3,000 have meaningful traction. The failure rate is 90–92% within the first year.

Product Hunt's transformation is a useful mirror. Of the top 15 launches on Product Hunt in 2025, 13 were tagged "Artificial Intelligence." Dozens of AI chatbots, text generators, "chat with your PDF" apps — one observer counted 73 clones launching in a single week — all feeling like they were "made from the same cookie-cutter mold."

VCs are starting to notice. Aaron Holiday of 645 Ventures identified "easily replicable solutions, generic productivity tools, basic CRM clones, and thin AI wrappers built on existing APIs" as the categories losing investor interest fastest. SaaS Capital put it bluntly: if your value proposition can be cloned by a tiny team using AI as a development turbocharger, you don't have enough gravity in the market to survive.

Stripe co-founder John Collison captured the tension: "It's clear that it is very helpful to have AI helping you write code. It's not clear how you run an AI-coded codebase."

What the Game Industry Eventually Learned

The platforms eventually responded. Nintendo restricted Switch 2 developer kits to filter shovelware. Steam added mandatory AI disclosure. Sony started removing AI-generated titles from the PlayStation Store. Apple updated App Store guidelines to regulate AI for the first time and began pushing back on vibe-coded apps in March 2026. Google blocked 1.75 million policy-violating apps in 2025.

None of it was enough. Steam analyst Chris Zukowski describes what emerged as "two Steams" — the curated experience users see, and the landfill underneath. Even with sophisticated algorithms, only about 0.5% of indie games released on Steam are financially viable.

But the gems did emerge. Hollow Knight — three people in Adelaide, Australia, using Unity, years of work — sold over 15 million copies. Cuphead's creators remortgaged their houses to fund painstaking 1930s-style hand-drawn animation. It sold a million copies in two weeks.

And it wasn't just Unity. ConcernedApe spent four years alone building Stardew Valley from scratch — 30 million copies later, it's still one of the most beloved games ever made.

These weren't just good games. None of them were the fastest to ship. They were impossible to confuse with anything else. That was the point.

The game dev community eventually worked this out: the tool is not the differentiator. The vision, the craft, the understanding of what you're building and why — that's the differentiator. The developers who survived the shovelware era weren't the ones who shipped fastest. They were the ones who knew exactly what they were making and couldn't be easily cloned.

Why This One Is Worse

Here's where the game dev comparison breaks down — and not in our favour.

Shovelware games could embarrass you. They could waste your afternoon and your $5. They couldn't leak your medical records, expose your banking details, or hand your private data to anyone with a browser console and five minutes.

Deployed software with real users carries real risk. And right now we are shipping a tremendous amount of it without the understanding to know what we've built.

A METR study found that experienced developers were actually 19% slower when using AI coding tools — despite predicting they'd be 24% faster and believing afterward they'd been 20% faster. The subjective feeling of velocity masked a measurable slowdown. Builders who think they're shipping faster while accumulating technical debt they can't see, can't audit, and can't fix.

That perception gap is the most insidious part of all of this. The asset-flip game developer at least knew they were shipping asset flips. A lot of vibe coders genuinely don't know what they've built.

So What Do We Do

I'm not arguing the tools are bad. I use them. They're genuinely useful, and in the hands of someone who actually understands what's happening under the hood, they're remarkable productivity amplifiers.

But we have got to stop celebrating velocity as a virtue in isolation.

"I shipped in 4 hours" is not impressive if nobody audited the auth, if the database can be wiped by an agent on day eight, if 72,000 user images are sitting in an open endpoint. The barrier to creation collapsed. The barrier to understanding what you created did not.

The Hollow Knights of software are coming. I genuinely believe that. Teams who use AI as an accelerant for real vision, who understand their codebase, who care about what they're putting in front of users. They'll emerge from this era the way the great indie games emerged from the shovelware swamp.

But we're going to have to wade through a lot of Flappy Bird clones with exposed Firebase endpoints to get there.

I've been negative about the amount of shameless clones on game stores a lot lately, and all the AI news these days is giving me serious fatigue. This post came from realising we've been here before, and I don't think we are learning from the past. I've linked out to the key sources where I can. If you're building something — genuinely building it, not just prompting it — I'd love to hear from you.

Claude Code vs Warp.dev vs Jetbrains Junie

Wynand Pieters — Thu, 07 Aug 2025 14:24:25 +0000

I posted over on LinkedIn about an interesting comparison between Lovable and Bolt.new which I did. I had this idea for my next Flutter project, but after being hit by the 5th LinkedIn post about Lovable in as many minutes, I had this thought.

😂😂😂 No, actually, the thought was more along the lines of

Okay, fine, I kid, I kid. If you've read any of my previous posts on AI, you'll know I'm excited for where it's going but tired of the overinflated exaggerations of the "media" and tech bro CEOs.

The thing that was actually interesting to me was how much these tools have improved since I last looked at them, and what about Lovable has made it $100m in ARR.

(I'll chill with the memes and GIFs in a bit, let me get it out of my system).

You can go read the original LinkedIn post here, but the TL;DR was I got something out very quick on both platforms, even on the free tier, but Lovable was the clear winner, but neither app I would call "production ready".

And while it was an interesting experience building the same app with two tools, it wasn't a great experiment.

So I wanted to take it further.

Down the rabbit hole

In my previous post I talked about Windsurf and Warp becoming my AI tools of choice. But I also mentioned I still wanted to give Junie a fair shake. I'm a big fan of Jetbrains products and they've been taking my money for a good many years, only fair that I actually give it the old college try.

But alongside that, people keep telling me I need to try Claude Code. I've been hesitant, mainly because I don't see the benefit over the combo of Warp and Windsurf which I'm already using. But being the curious sort, I figured, yeah, this is it. This is the showdown.

The Challenge

I'll link to the Github, because I don't want this post becoming 500 pages, but it boils down to the same spec.md file, the same project rules files, followed by the same prompt.

These where also exactly as I used for Lovable and Bolt. I left some things vague; I wanted to test if the tools make some assumptions I assume every human developer would (i.e. toggling this checkbox active should disable the related button), and then also see how they respond to changing specs (i.e. oh, can we also just quickly add this thing).

Some Background: The App

In an effort to get back into more consistent workouts, I decided to start with the One Punch Man workout.

Now, the thing is, I needed to ease myself into it, so I decided I'll do 10 reps and 1km every hour for 10 hours in the day; when I get up, every hour at work, and then before I go home.

But I wanted a way to track it. And since I didn't quickly (i.e. within 5 seconds of Google'ing) find something, I decided to build it myself.

Then decided to let AI build it.

5 times apparently.

So the app is simple. Track the reps for Pushups, Situps and Squats, and track running in 100m increments. Simple.

I quickly realized, being at the tail end of the very wet and cold South African winter, that I'm not doing 10km a day. I'm not that kind of crazy, so I decided that running should be optional.

And lastly I decided that a nice way to show progress is to have a different Goku Saiyan transformation animations play as you progress. Every single AI tool misunderstood my requirement here 🤦 At least some of them remembered the animation bit, others completely dropped that... But no Goku's were harmed in these experiments.

Overall Impressions

Initial thoughts vs the Lovable/Bolt combo.

They actually built Flutter apps: this may be a small detail, but I asked for Flutter, they gave me Flutter. Unlike Lovable/Bolt which only do React, these tools are already superior just because they can do more.
Context access is crucial: the terminal based tools (Claude Code and Warp) that can see errors and project state in the same place I'm working provide massive workflow advantages.
None of the tools got (what I consider to be) basic UX patterns right initially: All tools missed obvious interaction design (disabling running button when toggled off), so clearly there are still some human traits useful in building visual apps.
Time investment varied significantly: 30-60 minute range with very different friction levels, but all in all, still impressive for effort in vs output.
Manual deployment required: Unlike Bolt/Lovable's built-in deployment, all three of these needed separate CI/CD setup. I could probably have used MCP to fix this problem, but that is more setup and more time, and I want a "native" experience.
I specifically wanted to test with post-hoc changes to see responsiveness to evolving requirements, and they all performed fine. No tool broke the app further, but some struggled to get the requirements right (like using 100m increments for running).

Overall, as you'll see below, I was most impressed with Claude Code. I can see why everyone said I should check it out.

Impression: Claude Code

Demo URL: https://vibe-claude-code.d14wa6u34905q.amplifyapp.com/

Most natural development experience: Conversational, collaborative approach felt intuitive
Best context retention: Remembered previous discussions and decisions effectively
Fastest to working result: ~30 minutes with least "poking and prodding" required
Closest to actual requirements: Most complete feature implementation matching original spec
Best visual polish: Professional, cohesive design language with proper stage progression
Currently in active use: The version I'm using for actual workouts in the interim
Least amount of work required: Minimal intervention needed throughout development
Also had one of my now favorite features: when asked if it should execute something... "No, but tell Claude what you want instead". Brilliant. So much better than clicking cancel or no, then trying to reset the context with a prompt and having the AI get confused.

Impression: Warp.dev

Demo URL: https://vibe-warp-dev.d14wa6u34905q.amplifyapp.com/

Surprise standout performer: Exceeded expectations given how new their agentic features are. Will keep on eye on where this goes.
Excellent "brave mode" experience: Worked well while multitasking on other projects. The only one I actually ran this way, and only because I was also baking a sourdough at the same time...
Strong context access: Terminal integration allowed AI to see errors and project state, just like Claude Code.
Took most creative liberties: Added features not in spec (Total Workouts, Best Streak, navigation tabs), not sure why it went rogue.
Scope creep issues: Worse than taking creative liberties, it added these extra features while basic functionality (running checkbox) remained broken.
Screenshot sharing limitations: Harder to share visual issues compared to IDE integration, Claude also had this issue, but made fewer mistakes in the design, so didn't run into it.
Circular reference bugs: State management issues with the running toggle functionality. Biggest bug introduced I'd seen from the tools. The others had mostly linting and compile issues.
Reasonable timeframe: ~40 minutes development time, despite fundamental bugs, so still impressive (but had the benefit of no oversight)

Impression: Jetbrains Junie

Demo URL: https://vibe-jetbrains-junie.d14wa6u34905q.amplifyapp.com/

Most disappointing experience: Despite high expectations from JetBrains and their IDEs, it was much slower (they'd say methodical) and seemed to get stuck in loops now and then.
Basic project setup issues: Created project in subfolder, breaking CI/CD pipeline I created for the Claude Code and Warp projects, and despite causing issues in the IDE. Expected more from the tight integration.
Required most manual intervention: Needed more terminal fixes than terminal-focused Warp, also harder to maintain context as it would create new Junie Terminals for different tasks.
Longest development time: ~60 minutes for inferior result
Multiple code mistakes: Frequent errors requiring manual prompting of fixes.
Cleanest final UI: Minimal, iOS-like design despite poor development experience. Not quite the "anime-inspired" look I asked for, but pretty.
Failed to meet expectations: IDE integration didn't provide expected advantages, although I didn't get to a point of debugging in the IDE, which might change my opinion

Final Thoughts

Ultimately, I was very impressed with the outputs. While I wouldn't sell any one of these five versions, some of these could actually serve as really good templates to start from. But ultimately, I just decided that I'm going to do it myself anyway.

A friend I spoke to phrased it nicely; these tools give you a nice MVP to sell to an investor, but that first round of cash is gonna have to go to a good dev team to build it proper.

Make it work. Make it right. Make it scale.

These AI tools are for sure getting pretty good at "making it work", but I'm not sold on that they are "making it right".

Yet.

What's next?

So first of all, I'm still sticking to Warp and Windsurf as my main tools for the time being. I'm not completely sold yet on moving redoing my stack again.

Secondly, I really wanna develop this app, because I think it could be useful to people. I definitely want it to be more Solo Leveling inspired, based on The Preparation To Become Powerful daily quest given to Jinwoo to complete by the System. I want the interface to be more System like, and I want to bring in the whole penalty bit somehow.

CAUTION! - IF THE DAILY QUEST REMAINS INCOMPLETE, PENALTIES
WILL BE GIVEN ACCORDINGLY.

The idea my wife had was to maybe have some kind of an in-app avatar that gets more buff and powerful with XP earned, and you can use in-app currency to kit them out, but then failure to complete the daily quest has XP and currency penalties or whatever.

We actually discussed making this subscription based, but instead of charging a monthly fee, the penalty for for not completing your goals is $1 a day 🤣 So as long as you keep working out (or at least pretend to, I won't know) the app stays free 😉

She also wanted to take the avatar idea a step further and let people then battle their avatars, so losing XP and gear and whatever has a more tangible impact, but sheesh, that's thinking way ahead... I just wanna track my workouts 😐

Alongside that, having app notifications for when the quest starts and ends, and any penalties given, and then reminders through the day about progress, maybe eventually adding Widgets for the phone and so on...

Oh, and maybe supporting logins and online syncing, because right now everything is stored locally, which is a crap user experience, especially if you use more than one device (and who doesn't these days).

And you know what, maybe I'll have Claude Code keep working on its version while I do mine, as a longer term experiment. That could be really interesting 🤔

Tools I'm Using in 2025 (not that anyone asked)

Wynand Pieters — Tue, 03 Jun 2025 21:09:58 +0000

Introduction

I keep saying my next post won't be about AI, and then inevitably, I post something about AI.

It's hard to ignore, it's the big bubble we are dealing with, and there is so much hype that needs to be ignored and filtered so we can get to the actually good stuff...

I've been playing around with various tools over the last 3 or 4 months, and I think I've settled into what I find to be most useful for me. And while the topic says no-one asked, truth is, this actually does come up in a few discussions on other platforms and groups I'm part of, so I figured I'd love to share, but more importantly, hear what others are doing and why you agree or disagree with me.

So, without further ado...

[blank] has entered the Chat

When it comes to chat powered LLMs, there is no question that ChatGPT is the one that comes to mind for most people, and they've actually added a ton of features over time. I really love that on the mobile app there is a full on "conversational voice" mode, and that we get (pretty questionable) image generation.

That said, my experience over the last months has been that Claude just makes fewer mistakes, has fewer hallucinations, and is generally better at code related things (which is what I use my AIs for 80% of the time).

I've also dabbled with Ollama and hosting locally on my M3 Max, but ultimately, I've found paying for Claude is the best ROI for my use case. I use free ChatGPT for some things now and then, but having Projects in Claude is great for organizing and limiting scope and context. It's just become my go to.

(Side note: I still use Ollama for other things, it's awesome).

Also, Gemini who? I have access to this through my Google Workspace, but I find I rarely go back to it. It just never feels quite right to me.

Any other tools I should be looking at? Meta or X? How are they these days?

Deep Thought? Deep Think? Ah, Deep Research!

Here, Perplexity has become my go to and the one that I still pay for. I'm not actually sure what the standard is these days. Perplexity was one of the first ones I used and I might just be sticking with it out of habit.

I've heard that Elicit is good for academic research, which is not something I really need to do often, and that ChatGPT Deep Research is good at handling complex research tasks, but maybe my queries are not as complex or detailed, because I've personally found Perplexity to handle my research just fine.

I mentioned my poor experience with Gemini, and perhaps this is also why I haven't given Google’s Deep Research via Gemini a fair shake. I will add this to my list to try out for the next few months. I'm always looking at optimizing my tools and usage (but there is an important caveat I will get to later).

AI-dee-ee? Like aaay-dee-ee? IDE with AI built in?

That was lame, it works much better sounding it out. What a crap heading, I apologize (but not sorry enough to take it out).

Vibe coding is the new thing people keep talking about, and I hate it. I probably mentioned this before in comments on other posts, and even in my posts, but I feel like people misappropriated the term that Andrej Karpathy coined.

Anyway, AI tooling for coding environments is amazing. I've talked about my favorite tools before, but this has changed recently. While I do still love Continue.dev and the work the team there are doing, I've switched gears a bit.

First off, I went on a Cursor vs Windsurf rabbit hole for 2 months, and I eventually ended up paying for Windsurf. While I agree with the assessments out there that Cursor is more customizable and performant, I actually like that Windsurf kinda "just works".

So here's the thing, one of my favorite quotes ever is

Linux is only free if your time is worthless.

Now, granted, Linux in 2025 is not the same as Linux in 1995, which is when I first started using it, but the principle here is that, sometimes I just want things to work.

I love tinkering. I love hacking and modifying. It's in my DNA and part of why I love being a developer.

But what I don't love, is being forced to tinker. Forced to hack. Forced to sit endless hours to just make something work.

It's the reason I've been stuck on Mac since buying my first one in 2010. And why I still prefer Jetbrains IDEs over everything else. If I'm getting something free, I'm happy to tweak and tinker. But if I'm paying, especially paying a subscription, it better damn well work out the box and solve my problem with little to no input.

And Windsurf gave me that. So it got my vote. And my money.

BUT! I gotta make a comment here, because the truth is, now that Jetbrains AI is included in the All Products Pack, and that Junie is out of EAP, I'm actually using those all the time.

Windsurf I find is then most useful for smaller projects which don't have a dedicated solution in the Jetbrains ecosystem, or where Junie is not yet fully integrated, but overall, if you want something that just works, Jetbrains FTW.

Bonus!

Oh yeah, another reason I don't pay for more than Claude, is because all these AI tools inside the IDEs and other editors typically give me chat built-in, and often with better models than I get on free tiers in other places, so unless I need the web interface or mobile apps, this has become the go to for chatting with LLMs.

Conclusion

So I don't really use AI tooling for anything else; I want to still look at things like Superwhisper for speech to text, and I'm playing with FluidCalendar for managing and scheduling my time, but other than that, the free tier things are generally getting good enough for my most typical use cases.

I'm curious about better image generation and specifically editing tools. My biggest gripe with DALL-E is that I can't get it to modify an image properly, like if it generated something and I want it changed. My IDE image above was one such case...

One more thing...

Can't believe I nearly forgot this. Was about to post and then remembered probably the biggest and bestest tool I started using.

For years iTerm2 was my go to Terminal on MacOS, but then I discovered Warp, and I loved the idea, but the execution was iffy, so I started using Ghostty with Fabric.

Then I saw some recent YouTube videos on Warp and some of the improvements they made, I tried it out, and very promptly just gave them my money.

This has been a game changer for me, the AI Agent is just so seamlessly integrated into everything. From writing complex Bash scripts to helping debug SSH issues, it's changed the way I use the terminal and I'm here for it.

Also, it now supports Windows an Linux which just makes it so much better.

Done for real now...

All right, over to you. What AI tooling can you not live without, and what should I be looking at next?

(Edited on 2025/06/04 to add links to the tools I talk about. Not affiliate links. I don't do that. Just regular links.)

AI Tools: Are We Replacing Skills or Enhancing Them? (and at what cost)

Wynand Pieters — Thu, 27 Feb 2025 14:52:53 +0000

The Promise vs. Reality of AI in Tech

I'm genuinely excited about recent AI advancements. The tools continue improving, and we're discovering more ways to optimize and enhance our work. I've personally found a good rhythm using AI to multiply my skills rather than replace or hinder them.

However, I'm concerned about the industry's direction with these improvements. Instead of creating better developers, we're often replacing them.

Rather than building amazing accessibility tools, we're creating deep fakes and virtual companions.

Instead of developing better MVPs for *real * problems faster, we're seeing low-quality products marketed as revolutionary simply because they were built without coding experience, for no purpose other than a quick cash-grab.

Literally today on LinkedIn on my way to make the original post, I encounter yet another post in my feed from a "non-tech CEO who built this in 2 hours and it will put so many companies out of business!" 🙄

The Pushback Against Expertise

When experts and masters of their craft express concerns about these products, they're frequently dismissed as:

"Behind the times"
"Gatekeeping"
"Not getting it"

But the ones saying these things are often the same people who post about "losing 4 months of work in Cursor" because they didn't know about basics like version control. Or who complain their project "became so big that Claude can't properly understand it" and now they can't continue, because they have zero underlying skill.

The Multiplayer Game Incident

What prompted this reflection was seeing a poorly executed multiplayer "game" being celebrated. While it technically ran, the quality was questionable at best. Yet when this was pointed out, critics faced pushback from the creator—someone whose credibility seemed primarily based on revenue from other AI products.

UPDATE: he's doing microtransactions in the game and people are buying it... WTH am I even doing with my life...

Quality vs. Quantity in the AI Era

It's disheartening to see professionals who dedicate their careers to building thoughtful solutions for real problems being overshadowed by substandard work that somehow finds a market. This isn't solely an AI issue:

Just look at the abundance of shovelware and shameless clones on platforms like Itch.io and the Nintendo eShop
Log out of YouTube and look at the Shorts that are popular outside your algorithm: a slew of AI-generated nonsensical garbage...

It seems that consumers increasingly prioritize cheap, easy, and quick over any kind of quality. Is that what we want as creators? Is this what we value as consumers?

Finding Balance in the AI Revolution

I struggle with this industry shift and don't have easy answers. Part of me recognizes a potential market opportunity, but my professional standards prevent me from releasing something I can't take pride in. Perhaps that's just my personal challenge to navigate.

As developers in this new AI-enhanced landscape, we face a choice:

Race to the bottom with quick, low-quality solutions that exploit AI hype
Use AI to enhance our existing skills and create truly valuable solutions that couldn't exist without both human expertise and AI assistance

I'm choosing the latter path. It's harder, and based on what I'm seeing probably a mistake, but ultimately I truly believe it is more fulfilling and beneficial for our industry.

Your Thoughts?

I'm curious how other developers are navigating this tension. Are you finding ways to use AI that enhance rather than replace your skills? Have you seen examples of AI being used to create genuinely innovative solutions rather than just cutting corners?

Let me know in the comments!

Full disclosure: I used some of my AI tooling to help "Improve formatting for readability" and also "Soften some of the stronger language while preserving my perspective" in this post. Because the first draft was not professional 😬

Originally posted on LinkedIn, adapted for Dev.to

My two favorite AI tools in 2024 (that I don't see enough people talking about)

Wynand Pieters — Mon, 14 Oct 2024 09:57:58 +0000

Over a year ago a wrote a post about how I felt that, even though ChatGPT was making me more productive, I also felt it was making me lazier and dumber.

Since then, I've been a lot more intentional about how I use AI tools, in particular generative AI tools and coding assistants. It should be a multiplier, not a replacement or crutch, which is something I see juniors and non-developers struggle with the most, but clearly we can all fall prey too.

Over the last month or so, I've been seeing more blog and LinkedIn posts where it seems others are now having the same experience I do. The one that stuck with me was a LinkedIn post by someone who said they've uninstalled Copilot because

The reason is very simple: it dumbs me down. I’m forgetting how to write basic things, and using it at scale in a large codebase also introduces so many subtle bugs which even I can’t usually spot directly.

Now, their conclusion was, as with most things on social media designed to get a reaction out of people, that there is NO benefit to AI and you MUST NOT use it because blah blah blah...

I don't care, I stopped reading, it's not this binary. But sure, doesn't mean there isn't a good point there, despite the overkill conclusion.

I also realise that many of the reporting on AI pros and cons are both over inflated and sensationalist, and that people need to figure things out for themselves, and I am well aware that my opinion is a statistically insignificant sample size n=20-ish people I often interact with professionally, but personally I feel like there is plenty of benefit to be had if used correctly.

So I figured I'd talk about two tools that I've been using a lot. And for some reason I don't see other people suggesting these often enough.

Fabric

You can find Fabric here, and they have some good links to Youtube coverage which shows some great examples of how this works. What I liked about this tool is that there philosophy is that

AI isn't a thing; it's a magnifier of a thing. And that thing is human creativity.

From the Github page as of the date of this post, they say that One of fabric's primary features is helping people collect and integrate prompts, which they call Patterns, into various parts of their lives.

Fabric has Patterns for all sorts of life and work activities, including:

Extracting the most interesting parts of YouTube videos and podcasts
Writing an essay in your own voice with just an idea as an input
Summarizing opaque academic papers
Creating perfectly matched AI art prompts for a piece of writing
Rating the quality of content to see if you want to read/watch the whole thing
Getting summaries of long, boring content
Explaining code to you
Turning bad documentation into usable documentation
Creating social media posts from any content input

What I like about these Patterns are that most of them are incredibly well thought out, and the first useful thing I learned from them is writing better prompts for other AI tools. Not only is Fabric a useful command line tool that I can use easily, by looking at existing patterns and learning to write my own, I've learned to prompt better.

I highly recommend watching the NetworkChuck video on Fabric as well as the others they suggest on the Github page, and then playing around yourself.

Some of my favourite and most used Patterns are:

analyze_logs
create_mermaid_visualization (with mixed results, but often good starting point)
explain_code
extract_wisdom (especially when using YT transcripts or other summaries or posts)

What I also love about this is that Fabric doesn't feel like it wants to replace you or other humans, it feels like it wants to help, and because it's a CLI, I don't need to leave my terminal or IDE.

Continue

Continue.dev is a plugin for VSCode and Jetbrains IDEs which, at first glance looks like CoPilot or Jetbrains AI or Codeium or so many others, but the reason I like it is for a few simple reasons.

What is special about this for me is, as they state on the main page:

You can connect any models and any context to create custom autocomplete and chat experiences inside the IDE

This includes locally hosted models using something like Ollama. Which for me is great, since sometimes clients don't want their sensitive data going into the cloud models where T's & C's are sometimes iffy.

The second reason is Context. Specifically built-in and extensible Context Selection. As part of the built-in chat windows, you can tell it to look at specific files, folders or your entire codebase, you can reference different conversations, and you can flip between models in a single conversations. You can even create your own contexts, but some of my favourites are:

including the contents of the terminal in your IDE as context by typing @Terminal.
including a documentation site as context by typing @Docs and selecting the documentation site.
including a folder in your current workspace as context by typing @Folder and selecting the directory. It works like @Codebase but only includes the files in the selected folder (useful in VSCode if you have multiple projects open at once)

My personal experience has just been that, despite being early days and having some bugs, Continue has been giving me better results thanks to these additional contexts that Jetbrains AI and Copilot just couldn't.

You need to of course still pay for API access to different models, but there are free options, and I generally just buy $5 credit at a time and then it lasts me 2-3 months (but again, I don't use it all the time, since I don't want to be dependant on the tools).

Bonus: Ollama and Open WebUI

Just a quick special mention before I finish up. I mentioned Ollama earlier, but just wanted to expand. I've been playing with Ollama and OpenWebUI, which gives you a ChatGPT-like interface on top of your local models, and I love it.

My desktop has an 8GB RTX 3070, so I'm limited in what models I can run, but being able to play around with different custom models and setting up special Chat AIs for different use cases is great. It also helps in learning about these tools and models, which aids in utilising them much more effectively.

Highly recommend playing with them.

That's it

I hope you check out these tools and give them a try, they've been game changers for me.

I'm also really curious what tools people are using and what you've discovered that has been instrumental to you, and you just don't understand why everyone isn't using it.

Let me know in the comments what tools you think I should look at, and if you have used Fabric and Continue and what your thoughts are on them.

With that, I'm done. Happy coding everyone.

Why You're NOT an Engineer (also Why It [Probably] Doesn't Matter)

Wynand Pieters — Tue, 17 Sep 2024 18:41:15 +0000

Trigger warning: this is a bit of a rant. Also, it contains opinions. Specifically mine. If you are allergic to other peoples opinions, or likely to experience anger or hatefulness when hearing others opinions, this post is probably not for you.

Also, if you actually are an Engineer, have a cookie.

Intro

I spend a large amount of time on interviews. Or I did, up until mid 2020, but whatever. Sure, it's not as much as large corporations fielding thousands of applicants, but I'd wager more than the average startup. I've conducted a couple hundred interviews myself, and I've been interviewed a couple ten times.

The discussion of roles, responsibilities and titles is a tricky one, and one that often comes up in interviews. We live in a world where titles have become... maybe not quite meaningless, but a lot more ambiguous and less likely to carry the same weight it did in the 80s, 90s and 00s.

In a world where a barely legal high school dropout can be the CTO of his own startup with 0 employees and no product to speak of, where a marketing director can be called a "Wizard of Light Bulb Moments" and everyone plus their aunt Bob can be an "Data Scientist" after doing one free Python course on YouTube, titles have become ... let's just stick with 'less important'.

Just recently in one of my online communities there was a question:

SRE or SysAdmin - which job title would get the most attention from interns/Juniors? (Job descriptions would be the exact same btw)

I'm not sure when Site Reliability Engineer and Systems Administrator became the same thing. I must have missed that notice. Damn spam filter.

But this just highlights my point: Roles and responsibilities are the things most people will end up caring about. And with that comes the expectations of what those roles entail, and what experience or background is needed for that. It's not what I'm called, but what I'll be doing.

And finally, we come to the heart of my post. Software Engineering. Or is that Software Development?

A rose by any other name...

I'm not getting into things like prefixes today. I don't care about App [something] vs Full-Stack [something] vs Cloud [something] vs Web [something] or whatever else. I feel these are mostly clear in their focus. You are either focusing on mobile, or websites, or DevOps or Cloud etc etc etc.

What I do care about is that [something] and what the expectations are arounds those. Or maybe what my expectations are. This is an opinion after all.

The terms I hear most often are Coder, Programmer, Developer and Engineer. And here's the thing; I see these used interchangeably. But I don't agree with this. I think these are progressions and divergences. I think that one follows the other, or splits off, and they have different places in the world and in business, and not everyone needs to be everything. So let's start where we all do.

Coder

Coders write code. That code could be very simple. A single line of Bash to extract data from a URL

➜  ~ curl -s https://www.githubstatus.com/api/v2/status.json | jq '.status.description'
"All Systems Operational"
➜  ~

or doing some sed, grep or awk commands, that's code.

Maybe you start doing something simple with Python like comparing SemVer versions

✔︎ ~ python -c "from distutils.version import StrictVersion; print(StrictVersion('0.10.0') >= StrictVersion('0.6.0'))"
-c:1: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
True
✔︎ ~

Or maybe you just did your first "Hello World" tutorial for a new language like Rust and you managed to compile and run it.

Congrats, you have the reached the level of Coder. You have a basic understanding of one or more programming languages and can write code to accomplish specific tasks.

Programmer

Programmers are next step beyond coders. They are capable of writing, testing, and debugging code to build software applications. You probably know what an SPA is, and maybe even know who to make one without ChatGPT and StackOverflow. Programmers know how to program code into something meaningful.

Developer

Developers (specifically software developers given the audience here) have a broader skillset that includes not only programming (which is built on coding) but also software design, project management, and collaboration with other team members. They are involved in the entire software development lifecycle, from planning and designing to testing and deployment. Developers often have a solid understanding of programming languages, frameworks, and tools, as well as the ability to solve complex problems and create high-quality software products. You know how to program and develop software that works.

Engineer

Software engineers, sometimes referred to as software development engineers, have a more comprehensive and systematic approach to software development. They apply engineering principles and practices to the design, development, testing, and maintenance of software systems. Software engineers often possess strong analytical and critical thinking skills, as well as an in-depth understanding of computer science fundamentals, enabling them to build scalable, secure, and robust software solutions. So yeah, they also develop software, but rely on engineering principles to do so.

I had a point, right?

Okay, so here it is. If you didn't study engineering, or work in an engineering role, please don't call yourself an engineer.

Maybe this is just me, but if you call yourself an engineer, and I interview you like one (because I have a certain expectation), and you are not an engineer, the interview will go very poorly for you.

If you call yourself a developer, and I interview you like a developer, you'll probably have a much better chance to impress me when you start pulling out the engineering principle guns.

Interviews, when done "right" (oof, loaded term right there), are meant to be conversations in which both parties get to test the waters and figure out if there can be a mutually beneficial work arrangement; I have a problem that needs solving, and you hopefully have the skills and attitude to solve it.

It is not you coming in here throwing your titles and experience around trying to convince me your bootcamp made you a 10x engineer, but then you commit your AWS credentials to Github.

That's bleak dude

Okay, but hear me out, because there is a second part to this.

It doesn't matter.

Kinda.

As long as you are honest about what you can and cannot do, and as long as you are growing and improving, that's fine.

Also, it's not your fault as the jobseeker that most companies don't 🦆-ing know what roles they are hiring for half the time and end up with 💩 job specs with confusing "requirements".

If you really want get somewhere, focus less on what the role is called, or what your title will be, and focus more on the value-add that you know you can provide.

Anyway, let me know your thoughts. Am I being to harsh? Am I the only one who feels this way?

Ooh, better yet, what is the weirdest job title you've seen someone actually calling themselves?

Be water, my friend (my tao of software development)

Wynand Pieters — Mon, 10 Jun 2024 09:52:10 +0000

Intro

I don't know why this has been on my mind the last few weeks, but guess that means I need to write something down...

I love Bruce Lee. I don't generally think of myself of someone who has "heroes", but if there is one person outside my father who has greatly inspired me and changed how I think about life, it would be Bruce Lee.

At first, as a little kid with silly hopes and crazy dreams, it was just all the cool fighting scenes in his movies that made want to be like him.

But as I grew older and I watched Dragon: The Bruce Lee story, seeing how he lived life and his approach to martial arts and film, and then later buying and obsessing over The Tao of Jeet Kun Do, I started thinking about how to apply these elements and lessons to my own life.

(I also really loved this interview from the Pierre Berton show, and some of the things I reference will come from that.)

And of course, since this is a tech blog, I'll focus on how these apply to my career and my approach to building software and companies. And I trust there will be some wisdom or insight for everyone that reads it.

I'm also quite confident I'm not the first and won't be the last person to equate lessons from Lee into software, so I suggest scouring the interwebs for more insights.

Let's get into it.

“Be water, my friend.”

This famous quote encapsulates Lee’s philosophy of adaptability and fluidity. In software development, this can translate to being flexible in problem-solving, adapting to new technologies, and continuously evolving your skills.

For me, this is the essence of what Agile really tries to achieve. When you cut out the methodologies, and look at the intent and principles. It means that if you have an idea that doesn't work, you try something else. It means that if you are going in the wrong direction, you change rather than stubbornly pushing forward.

Wrt our own adaptability around things like tools and languages and frameworks, the hill that I will probably die on is the "it depends" meme. While I surely have things I prefer, sometimes it's not sensible to blindly hold on to those when the entire industry is moving in a different direction. We must adapt and evolve and grow.

I feel this also nicely ties into the next one.

“Absorb what is useful, discard what is not, add what is uniquely your own.”

Lee’s approach to martial arts involved taking the best elements from various styles and creating his own. In software development, this means learning from different programming paradigms and tools, discarding outdated practices, and innovating to develop your unique coding style and solutions.

There is no "right way" or "one solution", and there is no "best" editor or "one language or paradigm to rule them all". As much as people want to fan the flames of online wars, at the end of the day, there are pros and cons to everything.

So try new things, learn things, attempt hard things, and figure out what works best for you and the people around you.

And don't just copy-paste, whether someone else's code, or a persons behaviour and attitude and approach to life.

Yes, even now, as I talk about the lessons and inspiration of Bruce Lee, I don't try and "be" him or even "be like" him. I am looking at what he did well and absorbing the useful lessons to myself, discarding what is not applicable, and then adding what is uniquely my own.

“Mistakes are always forgivable, if one has the courage to admit them.”

And I get this wrong sometimes. And you will too. But we shouldn't fear failure and mistakes. Having failed at something does not make you a failure. It just means you have not found the path to success yet.

This quote from Lee encourages a growth mindset and accountability. In software development, acknowledging errors and learning from them is essential for personal and professional growth. Finding a space where there is psychological safety for us to do this is extremely important.

“Knowing is not enough, we must apply. Willing is not enough, we must do.”

This quote to me really emphasizes the importance of practical application and action. In your career, it’s not just about learning new programming languages or methodologies; it’s about applying that knowledge to create meaningful and functional software.

I've spoken about this in some of my previous posts, the idea of intentional learning and intentional practice. You don't become an expert by half-arsing it for 10 000 hours; you do it through deliberate practice, continuous feedback, and making adjustments.

It's not enough to watch 20 beginners tutorials and then think "yeah, I got this". Do something. Build something. Break something else, then figure out how to fix it. Be willing to try and fail until you try and succeed. Whether that's solving a hard problem, or building a new startup, or working for that promotion.

“If you love life, don’t waste time, for time is what life is made up of.”

Time management and valuing your time are crucial. In software development, prioritizing tasks effectively, avoiding procrastination, and making the most of your working hours can lead to greater productivity and satisfaction.

Knowing how to spend time outside of work is just as important. Time is a finite resource, and we are using it regardless of what we are doing. There is a time for work, and a time for play, and a time for rest. Important to note though, there is a difference between intentional rest and just ... existing in space.

I long struggled (and still do to some extent) with the idea that I always need to be productive. Something I've learned over years is, rest is not unproductive, but doing nothing is. Intentional rest is doing something, and it is productive.

I've also spoken before on how this TED Talk by Laura Vanderkam on How to gain control of your free time changed my perception of time spent by changing my thinking:

“Instead of saying “I don’t have time” try saying “it’s not a priority,” and see how that feels. Often, that’s a perfectly adequate explanation. I have time to iron my sheets, I just don’t want to. But other things are harder. Try it: “I’m not going to edit your résumé, sweetie, because it’s not a priority.” “I don’t go to the doctor because my health is not a priority.” If these phrases don’t sit well, that’s the point. Changing our language reminds us that time is a choice. If we don’t like how we’re spending an hour, we can choose differently.”

But back to software... think about how you spend your time on projects and what people you spend time with in your org. Think about what is really priority, and be agile and pragmatic and focus on how you best spend your time to accomplish the goals set. And please, make time to rest intentionally.

Speaking of goals...

“A goal is not always meant to be reached, it often serves simply as something to aim at.”

I won't hammer on this one too much. People and companies often have lofty goals. Some startups set up to solve a hard problem, then fail. And this is where I feel the quote is important.

It reflects the importance of setting goals for direction rather than absolute achievements. In software development, setting ambitious goals can drive progress and innovation, even if they are not always fully attained.

Shoot for the stars, and even if you fall short, you might make it to the moon.

Okay, so let me leave you with one more.

“Knowledge will give you power, but character respect."

Over time, a developer’s reputation is built not just on their technical skills but also on their character. Respect from peers, clients, and the community can lead to more opportunities and long-term success. Effective leaders in software development are those who combine deep technical knowledge with strong character traits like empathy, fairness, and integrity. Such leaders inspire and earn the respect of their teams.

Gaining expertise in specific programming languages, tools, and methodologies can give a developer significant leverage in their career, enabling them to handle challenging tasks and lead projects effectively. Knowledge empowers us to solve complex problems, innovate, and build efficient, high-quality software.

But while technical knowledge is essential, humility and the willingness to listen to others’ ideas and feedback are equally important. This balance helps in continuous improvement and gaining respect. Sharing knowledge with less experienced colleagues and helping them grow demonstrates character. It builds a culture of learning and respect within the team or organization.

It's not just you alone on this journey.

Conclusion

I'm curious to hear who outside of the tech industry has had the greatest impact on you and how that has changed you approach to software? Let me know in the comments.

What I learned from making my first game (and how my approach changed for the second one)

Wynand Pieters — Mon, 05 Feb 2024 08:55:11 +0000

TL;DR

That's pretty much it. Entire post summed up right there 👆

Introduction

Early in 2023 I took on a challenge. I'd been going on about making my own game for ages, and my wife finally called me out on it; stop talking, start doing.

A buddy of mine had been doing the same thing about an app idea he had, and so our wives decided to lock us in a room for a day and force us to work on these ideas.

We decided we'd take 24 hours split over 3 days and work on our ideas just to get something out, and the experience was a good reminder that actually building something is often the best way to learn.

In case you are interested, you can check out what I built over on Itch.io; there are some blog posts and updates as well.

FWIW, it really sucks 😂

But I learned a lot. And actually releasing something made it easier to start working on the second one. Which you can also check out here, again with a more comprehensive devlog available.

But enough shameless plugs, I'm here to talk about what I learned.

For those who don't know, I've been doing professional software development since 2007, and hobbyist since I first learned BASIC in the 1990s (yes, I'm old 🧓🏻)

I've done web, frontend, mobile, backend, cloud, full stack, serverless, app server... I've been around the block, but game dev is new. And very different, it turns out.

At least in the way it's taught, or maybe just the way I learned. And I figured I might as well share my thoughts.

Lessons Learnt

Some of these will relate to my experience building games a solo indie dev. Others will relate to my experience as a dev and how that translates (or doesn't) to game dev. And maybe this is just comment on how not to learn a new skill.

Lesson 1: Just do it.

I touched on this on one of my first posts here about falling into the trap of "learning" but never "doing", and this is an issue I had. I remember doing a 2D Unity tutorial, I think it was a space shooter example project or something. Once finished, I took months before getting back to it, and then Unity had updated, and so had the tutorial.

So I did it again. And the next time the tutorial was replaced, so I did the new one. And then the 3D one. And then again the new 3D one when Unity updated again.

Even after completing a 2D and 3D course on Udemy, by the time I got around to my game idea, it had updated again, so of course I had to start from scratch again.

But alas, a conversation with my friend who, when I said I need to do all the tutorials again just said:

But why? Just use the version you know.

Mind. Blown. 🤯

Or not, it was obvious, but that conversation made it more obvious. I was scared of trying something new and failing, so I found excuses to put it off. Simple as that.

Don't find excuses. Just do it. Building something, anything, it is a billion times better than not building anything at all.

Lesson 2: Engine doesn't matter.

Actually it does. But it also doesn't. It depends.

Maybe the more accurate statement would be it doesn't matter as much as you think. At least not if you are a solo indie dev or small group.

Sure, for large game dev companies, using the latest Unreal 5 for the latest GPU tech and the most uncanny valley graphics makes sense. But for most small projects, they can all accomplish the same goals, just in different ways.

There are plenty of unbiased engine comparisons out there, and if you haven't even started your first game yet, go do your research and figure out what works for you.

But don't be like me and spend months debating if I should stick with Unity or learn Godot or Unreal, or try to convince myself my idea is so simple and different I can just use something Ebitengine because I know Go, or Bevy Engine because I want to learn Rust.

I'm familiar with Unity, and it can do what I want. Games way more complex and ambitious than mine have been built in it. It's just another excuse to not start something.

Unless you have a very specific goal in mind that requires a specific engine, just pick one with a language close to what you are familiar with and get going. You can always change things for the next project if it doesn't work out.

Side Note

Godot 4 is awesome, and I love the effort going into the engine. I firmly believe that in a few years Godot will be the primary choice for indie devs for making games. Godot will do for game dev what Blender did for 3D modelling and animation.

Lesson 3: Tutorials are great, but RTFM.

Learning to code has drastically changed over the last 50 or whatever years. Gone are the days of spending hours pouring over physical Language Reference Manuals. Who would do that when you can just Google your problem or get CoPilot to give you the code?

But here's the thing. Those online sources are usually very superficial. They are typically aimed at beginners after all.

Never underestimate what you can learn about tools and frameworks by the reading the docs. There is nuance and detail there you won't get from tutorials, blogs and courses.

I quickly fell into a trap of "all tutorials do this the same way, so it must be best" and "all tutorials say this is bad, so I shouldn't do it", but like I say in probably every single one of my blogs... it really all depends, there is no one right answer, and I shouldn't assume there is.

If everyone online says "do it this way", yeah, maybe that is the best practice and it is the right way, but it could also be that everyone is just copying each others content because it's easier to reproduce and get a slice that very lucrative online courses pie.

So yeah. Read the freaking manual. If you are unsure of something, that should be your first port of call. If you still don't understand, check the forums. And only then Google.

There are many concepts in the Unity Engine I never new existed, because so few tutorials and lessons actually touch on them. Like how to actually use the Debugger and do Unit Testing, things which are common practice and often taught in pretty much any other software development field. I also learned about Compute Shaders, not something I'll need for my games yet, but since I never saw anyone talk about it, and because I didn't start with the docs, I never even new it existed!

So yeah, RTFM. Please.

Side Note

Another side note here, there are also really good courses and teachers out there, and some top notch YT channels where I did end up learning about these things. I'm not saying "courses bad, manual good", I'm saying that the reference guides from the creators are probably a better first resource than whatever Google is being paid to show you.

Lesson 4: Assets are your friends.

This is a weird one for me, and I'm not sure why my mindset for this was different. And maybe this is very much a me problem and not something that other people experience.

I don't think twice about using open source frameworks that are available when I'm doing backend work. And I rarely debate about paying for tools like JetBrains IDEs and CoPilot or ChatGPT, but for some reason the idea of paying for assets was weird. I always wanted to try and do everything myself, especially if was just "code". Using 3D models and audio which I can't do myself was much easier than using someones Player Input Controller or a Pathfinding asset.

Using someone else's code kinda made me feel like the wrong side of the "I made this" meme...

But at the end of the day, unless you are really talented at every facet of game dev (audio, animation, coding, designing), you either need other people, or you need other people's stuff. And they are selling these things, so it helps them out too.

And if you are just playing around, start with free stuff that's engine agnostic. Kenny.nl is an amazing resource with "Thousands of completely free game assets for you to use", and they have a top notch all-in-1 bundle available over on Itch.io.

Just like you don't always need to re-invent the wheel in software, you don't need to solo every aspect of your game. Devs with more experience and who have been in the game longer than you have solved a lot of problems already. Use that to your advantage.

Oh, one more thing: you can learn a lot from these assets. Especially the ones that come with scripts. I wanted Serialized Dictionaries for handling some of my objects in the editor, and I could never quite get it working, turns out there was a really good free asset, and just going through the code helped me understand things and see where I went wrong.

Conclusion

I don't have a specific purpose with this post other than I sharing what I thought was some interesting observations and revelations. Make with that what you will.

If you've ever been interested in making your own game, or really just want to build anything, but keep finding excuses, I really recommend watching this video from Pirate Software over on YT or reading their post over on develop.games.

I think there is a lot there that translates to more than just game dev.

And I hope it inspires you to also go out and

build something

I look forward to one day seeing what that is, so put it here in the comments when you have something to show. Or make your own #showdev post 🙂

As for me, I'm slowly working towards having something playable, and I'm glad I decided to stop finding excuses and just start. It might not always be going the way I want or at the pace I would like, but at least it's going. Slow progress is better than no progress, after all.

I am a Single Monitor Developer (but I am very particular about that monitor)

Wynand Pieters — Thu, 23 Nov 2023 11:59:33 +0000

LOLWUT. Random.

Yes. Kinda.

So here's the thing; I recently watched a reaction video by ThePrimeTime for a clip about the "Best Programming Setup" from the Lex Fridman interview with John Carmack, and for some reason it sparked an urge to write about something.

The specific bit was here (from around 19:45 to 21:12), where John talked about making the move from 2 to 3 monitors, and Prime commented on being a 1 monitor person.

Erm... okay?

Stay with me.

I really liked his comment here about the argument for multiple monitors being about your ability to navigate your OS, because I agree, this is a very big part of it.

But it's not all of it.

As I've moved through different phases of my career, and focusing on different types of applications and types of development, I've found my monitor usage requirements changing.

Earlier in the clip when they talked about debuggers and logging, I think he hit the nail on the head when he said

I know we'll probably disagree on the debugger thing. Or really, I don't even think we disagree, we're just in different environments.

And there for me is the crux of all this. The single- vs multi-monitor debate. The Vim vs Emacs debate. The text editor vs IDE debate. The OOP vs FP debate.

If I am only ever remembered for one thing, let it be:

Get to the point old man...

In a minute!

So here's the thing, I started my professional career in QA Automation, and one screen was fine. The scope of what I worked on was small, and it was easy to keep in my head. Doing the Alt-Tab thing was easy, and not disruptive at all.

When I moved over to frontend development, I found having two monitors really helped. I could keep designs and specs open on the one monitor, while keeping my IDE open in the other. Having the additional context in my vision was super useful.

When I moved to backend dev, I found the use case similar. Being able to keep the IDE and Terminal connected to the server on one screen, while keeping the UI and specs open on the other meant I had all the context I needed right in front of me. The system was a micro-monolith (bunch of separate WARs packaged in a single EAR) in a single language (Java), so I could keep all the code in one IDE instance no problem, and debugging was still easy to do.

But when I moved to startup where we did "proper" microservices, including services in different languages (Scala, Python, Go), this became much harder to manage. In extreme cases I would need the source of two or three services open at once, along with a Confluence page or DrawIO diagram to understand the flow, with multiple windows open in iTerm all connected to different containers or servers... Suddenly I felt 2 wasn't enough. Hell, after using 3 (laptop plus two externals), I often found that wasn't even enough.

Just git gud, scrub

HOW!?! I never could figure out how just being better at navigating or using better window managers would solve this problem. I have too many windows, because I need the context. I'm not getting any younger, and my brain space is too full of random crap to keep the work stuff in there too.

Upgrading to a 1440p monitor made a huge difference for a while, since I could physically fit more onto the monitor, and allowed me to go back to 2 for a while, but I eventually just went back to 3 because of the complexity of the system we worked on.

Maybe that should be a different discussion... Should a system ever be this complex? Another time maybe.

Anyway. When my one monitor fell of desk and stopped working for some strange reason, and my other monitor developed a massive block of dead pixels completely unrelated to knocking it with a vacuum cleaner, I figured it's time to shift gears, and move to a new trend I've been seeing. Huge-ass single monitors.

Enter the ULTRA-WIIIIIIIIIIIIIIDE monitors.

3440 x 1440 ... Chef's Kiss.

Only, holy crap are these expensive. I have some friends and colleagues that swear by their Ultrawides, but when I started looking at my needs, I figured I needed 5120x1440 which got even bigger and more expensive, and I just noped out.

Until I saw a sale on the 43" Samsung QN90B 4K QLED TV, which got a whopping 9.0 score for use as PC Monitor over on RTINGS.com.

At that size and that resolution, that would be like having four 21.3" Full HD monitors in a 2x2 configuration with NO BEZELS AT ALL.

I was sold. And now after using it for 6 months, I can never go back to anything else.

Using a decent tool like Magnet, I now have full control over my setup. 3x1 portrait? Done. 2x2 landscape? Sure. Top full length + bottom left + bottom right? You got it. Center to just focus one thing? Hell yeah.

Conclusion and your thoughts

Okay, very long post for something I tagged #discuss. There is a question here, I swear. But first to summarise.

I am a single monitor developer. When some of my friends saw my office setup, I got literal eye rolls. But I don't care. They don't understand.

The fact is, I am now sold on large format displays of at least 4K resolution. Together with a window organiser like Magnet, I now have full control over my workflow, from simple to complex projects, and everything in between.

And I love it.

So let me know in the comments; what is your setup? How many screens do you use? How many do you need? Not always the same answer, those two 😏 And why do you prefer the setup you have?

Curious to know. Thanks.

I miss being a code monkey (but guiding the troop has its own charm)

Wynand Pieters — Wed, 02 Aug 2023 15:34:40 +0000

Clarity for the purpose of this post 😏

code monkey, n. a computer programmer who is not involved in any aspect of conceptual or design work, but simply writes code to specifications given

programmer, n. an organism that can turn caffeine into code.

Introduction

Once upon a time, (many, many moons ago) at the very start of my career, I was just a "code monkey"; an individual contributor to the grand scheme of the digital jungle being fed instructions from primates higher on the food chain and was expected to simply do what I'm told.

All that mattered was that if I was given a spec, I churned out something that did what was expected of it. As long as I wrote working code I was happy, my team was happy, and the company prospered. Hopefully.

But then eventually, something happened, and everything changed; the promotion came - I was to be

[pause for effect]

A Team Lead

The transition from coder to leader has its unique set of challenges. A transition that I, like many others, navigated with equal parts trepidation and excitement (read: I was absolutely terrified and convinced I would fail horribly 😬).

Suddenly, my performance hinged on the collective output of the team. My daily routine switched from churning out elegant lines of code to dealing with documentation, processes, mentoring, and doing the PR reviews. A fundamental shift occurred; a change in perspective from "me" to "we."

Not "my code", but "our deliverables".

Some Days I Just Want to Code

I became developer because of how much I enjoyed the challenge of solving a problem by telling a computer what to do, and because the range of challenges and problems are so vast. My focus and joy came from doing the work, finding a solution, and levelling up my skills.

As a lead/manager, that focus became delegating the fun stuff so others can do the work, looking at the big picture, facilitating the conversation for others to find solutions, and ensuring that they all level up.

And I learned that I love doing those things. I've been told I'm good at doing those things, although I still have my doubts. Haven't been fired yet 😅

But it took me years to shift my mindset, because I felt "unproductive" when it wasn't me doing the work.

And even now, many long years after flipping the switch, I still miss it. Some days I just want to be given instructions and then execute on them.

So with this longing in mind, one of the most potent challenges I faced was the dilemma - How do I maintain technical competency and excellence while ensuring my team's performance? How can I still have those code monkey experiences while doing what needs to be done in my new role?

Leverage the Tools at Your Disposal

To stay technically competent, I started working side projects; they became my go-to for keeping my coding skills sharp. In a few instances, I tried working on Open Source projects, specifically trying to give back to projects we use at the companies I worked. The results were mixed. YMMV.

I found that Podcasts, tech talks, and conferences became a regular part of my routine, adding new perspectives and insights into my tech repertoire. I've discussed these in an older blog post as well, and I think there is a lot of value in staying technically strong even if this isn't your day to day anymore.

It can be hard to juggle all the various responsibilities while trying to hold on to the past, and while I wouldn't say you should let go of the good ol' coding days, at least loosen your grip a little.

Lead with a Wider Perspective

In the early stages of my career, my view was often narrowed to a single feature or bug. As a team lead, my gaze had to expand, encompassing not just the details, but also the broader picture. This wider perspective allowed me to learn more from others, gaining a more in-depth understanding of our projects and objectives.

This meant that skills like solution design, high level architecture and communication is a lot more important. It can be easy to neglect these as a code monkey, while just focusing on writing code, but a lot of times these are really valuable skills as you progress in you career, and even just through life.

What was interesting here is that I found that by learning these new skills, I gained insights and ideas that I could apply to any new project I tackle. So even when working on coding tasks and projects, the broadened horizons and more holistic view improved how I approach even small features. Who would've guessed.

Prioritize Time Management

Time management became a crucial skill as I juggled between coding, leading, and managing. Along with realising that what I consider "productive" time changes from me sitting for hours bashing out code, to ensuring my team can do it uninterrupted for as long as possible. Context switching is costly, you know.

I implemented regular 1-on-1 meetings with my team to check in with them on a human level, and introduced a "mid-week technical sync" - a dedicated hour per developer to address specific technical challenges.

Easily around 50% of my role involves removing blockers from the team's path and ensuring they have the resources they need. Probably another 30% is dedicated to managing their time, which includes deciding which meetings are crucial for me and them and facilitating the right discussions and design sessions. The remaining twenty percent? Well, that's for general admin, HR management tasks and sneaking in some coding whenever I can.

You see, there's this dirty little secret; if you want to code as a lead, there are plenty of opportunities in the form of technical debt. We all have it, we are constantly creating more of it, and no-one will ever prioritize it. So why can't you do it?

Embrace Your Role

The role of a team lead is different, often vastly so. And that's perfectly alright. It's essential to realize that being a strong individual contributor doesn't necessitate being pushed into management. Similarly, if you're a strong leader, don't let your love for coding hinder your potential.

Find a place that nurtures your strengths, where you can lean into what you're best at. Collaborate with a team that complements your weaknesses, whether you're a lead or an individual contributor.

Ultimately, keep nurturing your skills, keep learning, keep growing.

I've found over the years that focusing on what you are good at, and helping others excel, is a pretty good way to go about life.

Conclusion

Every leader's journey is unique, each with its own set of challenges and rewards. My story is but one in a myriad of tales in the vast world of tech leadership. The strategies I've shared have served me well, but I'm continually learning and adapting.

As we reach the end of this (pretty long) blog post, I'd like to turn the spotlight towards you. I invite you to share your stories and experiences. How did you navigate the transition from individual contributor to leader? What strategies do you employ to maintain your technical skills while leading a team?

There's no 'one size fits all' in leadership. Each of us brings something unique to the table, and by sharing our experiences, we can all learn from each other and grow together.

I look forward to hearing your stories, your victories, and your challenges.

ChatGPT has made me more productive (but at what cost?)

Wynand Pieters — Fri, 14 Jul 2023 09:55:35 +0000

Right, so it's been a minute since I last posted something.

Like many other companies this last year, we weren't spared layoffs. While I still have my job, my team has been greatly reduced, both from people leaving when they saw the signs and from people being let go. So while fighting survivors guilt and an increased workload, posting hasn't been my first priority.

But while doing my day to day and trying to keep my head down and deliver as much as possible as quickly as possible, I noticed something. And I'm not sure how I feel about it, other than we need to talk about it.

I felt this post needed to happen. So here it is:

ChatGPT has made me lazy.

😳

Yeah.

Okay, but... you said AI tools are awesome?

Yes, I have been saying that, and I still think the improvements to GPT and other LLMs and the new features with Copilot are fantastic tools and will make many jobs more productive.

But in much the same way I imagine people using horses felt when they first started getting cars, or people who walked everywhere when they got bicycles, or carpenters with their first power tools, this increase in productivity comes at a cost.

Surely you're overacting?

Maybe. Maybe not. And don't call me Shirley.

I think we need to start with a story. Something I caught myself doing earlier this week.

For local testing we have this little stub service which acts as the client/partner endpoint. Up until now all our data has always been JSON, but for a new partner we are sharing binary data as well, so I wanted to update the stub to handle both. All this needs is a simple if statement to look at the request headers.

I've been doing Go for about 6 years and have built many, many microservices with REST APIs. I should be able to code this logic in my sleep, since I know the APIs of the "net/http" package. But what was the first thing I did?

So you asked ChatGPT to write some boilerplate, big deal

I know, I know, it probably doesn't seem like a big deal... yet. But here's the thing; that's not where it ended. A large part of the rest of my code was just me starting to type, looking at the Copilot suggestion in my IDE, and then pressing Tab.

Then writing a line of custom code unique to my service, before just autocompleting boilerplate from Copilot again.

And yeah, this is awesome. It reduces coding time, hopefully reduces mistakes, it make my life so much easier, right? Right!?!

Except when it doesn't.

Something wasn't working, and usually this is where I add some debug logging, and if that doesn't work, I pull out the debugger and start stepping through code, investigating every single line and memory allocation like a detective trying to solve the perfect murder.

Only I didn't. Instead, I did this.

As expected, it told me the obvious things; add logging on the request and receive side and print out the headers and status codes and body. Which I obviously did even before it told me to, because I'm not some n00b and this isn't my first rodeo.

So I told it I already confirmed the problem is on the receive side. And it gave me some good ideas back, and to be fair to the tool, it did help me solve the problem... One of the suggestions was

Is the request being read correctly? - Ensure that the request body is being read correctly. For instance, it could be that the body is being read somewhere else before your io.ReadAll(req.Body) line and it's not being reset.

Which was the issue. When doing some copy-pasta refactoring to add the if-else, I moved the reading of the body to outside the if statement since I only need to do that once, but then I didn't delete it from the else part, which caused some variable shadowing I didn't notice, and because an io.ReadCloser such as req.Body is a stream and not a buffer, the data I already read is gone from the stream. It worked fine for the if because it didn't try and read twice.

And I kinda feel like I should have just picked this up by reading my code properly, instead of jumping onto ChatGPT.

Ouch. Tough break.

Indeed. And this has made me think a lot about these tools and the impact they've had on me. While I do feel more productive, and there are certain tasks these tools make much easier than before, I wonder at what cost it comes.

It's all too easy to draw parallels between our increasing reliance on AI tools and the introduction of power tools to carpenters or automobiles to those used to horses. The idea of 'progress' often lures us into believing that newer, faster, and more efficient is invariably better. But like power tools, which introduced an increased risk of injury, or automobiles which brought along pollution, AI coding assistants also have their drawbacks.

While power tools enable us to build bigger, faster, and more intricate things than we could with our bare hands, they also run the risk of creating a generation of workers who wouldn't know how to hammer a nail if the power was out. In the same way, tools like ChatGPT and Copilot can help us become more productive coders but also threaten to leave us helpless if we forget how to do even the most simple of tasks.

Of course, I'm not arguing against progress. Without the willingness to adopt new tools and adapt to changing circumstances, we'd still be etching symbols onto cave walls. But as we embrace these AI tools that promise to make our coding lives easier, we must remain vigilant about the risks of over-reliance.

We must be careful not to trade our skill and expertise for convenience.

Conclusion

I'm sure I'm not the only one who's become a little complacent, a bit lazy, in the face of these new tools. But recognizing the problem is the first step towards solving it.

So yeah, the next time you're reaching for that shiny AI tool to solve your coding problem, pause for a moment. Is this a shortcut you genuinely need, or is it a crutch you're leaning on? Are you using the tool, or is the tool using you?

Remember, the best tool any coder has is their brain. And unlike AI tools, it's 100% unique to you and perfectly tailored to solve your coding problems. So before you let AI take the wheel, make sure you're still in the driver's seat.

The Quest for the Holy Coding Grail (are LLMs the first step in replacing programming languages?)

Wynand Pieters — Fri, 02 Jun 2023 13:44:17 +0000

Introduction

So very many years back when I was but a fledgling coder, armed with BASIC skills and deep into a Turbo Pascal with Objects book, I remember a conversation with my dad. Frustrated by the level of specificity needed to communicate with a machine, I asked, "Why has no-one made a programming language where I can just tell it 'build this game for me'?"

My dad, in his infinite wisdom, mused that cracking that puzzle – creating a natural language programming language – was a feat yet to be achieved. "Whoever manages to do that," he predicted, "will make a fortune."

Being a dumb kid with no clue how the world works, I made a vow then and there; I would be that person. I would be the one to breathe life into my dad's prophecy.

Erm... yeah... I did not. Not even remotely.

However, somebody else did (kinda), and they've been inching closer and closer to my childhood dream. Judging by their progress, they're well on their way to embodying my dad's prediction and amassing that fortune!

Generative AI and The Quest for the Holy Coding Grail

I vaguely recall having a conversation with a colleague while hunting for a bug where they admonished the computer for being wrong. Truth is though, the computer is always right, it's doing exactly what we told it to do, we just didn't say it right.

As developers, we dream of a world where we can write code using plain, everyday language, as simple as ordering a double-shot, no foam, soy latte.

In our quest for the Holy Grail of programming – a natural language programming language – we find two promising knights at the round table: ChatGPT and Bard.

And yes, I know neither of those is really a "programming language", and yes, you would still need to tell GPT "write this in Python/Go/Scala/Elixir" or whatever, but still, it takes "human words" and gives you "computer words" back. Right?

However, as I've discovered in my recent trials and tribulations through various mis-adventures, we're still in for a few Monty Python-esque escapades before we reach our goal.

GPT-4: The Good, the Bad, and the Ugly

Since its inception, GPT-4 has been the Usain Bolt of the NLP world, outpacing its predecessor in most ways, especially with logical reasoning, but it still sucks at math, which is still useful for developers. In some ways, GPT-4 is like that high school friend who always made quick witty remarks, but needed a calculator to split the bill.

One of my experiments I tried to create a Chrome extension which filters tweets on Twitter based on perceived intent, as interpreted by the GPT-3 REST API. The mission was simple: I’d give it a prompt, it'd churn out the code. However, GPT-4's performance varied wildly based on the prompt’s complexity. It would get confused between prompts, forgetting changes it made earlier, reintroducing bugs, and was limited by its lack of internet access.

In another experiment, I found myself in the virtual corridors of Exercism.io, working on coding challenges with GPT-4 as my trusted sidekick (redoing ones I'd already passed, I swear). When I gave GPT-4 the full problem and the unit tests right from the start, it performed remarkably well. However, when I tried to spoon-feed it each step separately and have it refactor to work with the unit tests at the end, things got messy.

With this I learned that using correct "super prompts" is often the way we need to go, but this still just works great for small apps or code snippets, rather than giant, complex systems.

So while GPT-4 has made strides, it still has its shortcomings, and isn't quite what I had in mind when dreaming of a perfect and easy to use natural language programming language.

Generative AI Limitations

In our journey into the realm of AI-powered programming, GPT-4 is a brave knight, albeit one with a chink in the armor. When it comes to understanding complex domains or sophisticated nuance, our knight often gets lost in the dark forest.

Consider this: you're trying to explain to your grandmother how to program a TiVo. If Grandma is GPT-4, she might get the basics. But if you start talking about skipping commercials automatically or integrating it with her Netflix account, suddenly she's looking at you like you've grown two heads.

Similarly, while GPT-4 can master simple prompts, it often gets tangled in the underbrush when asked to understand or generate nuanced or domain-specific content, as I found in my previous experiments.

Bard: The Troubadour That Could...Almost

Enter Bard, another knight in our quest for natural language programming, and the newest addition to the 'Prompt-Engineering Singing Troupe'. It's a troubadour that can strum a decent tune, but still needs to learn a few more chords before it hits the big time.

My experience? It's like having a new puppy: endearing, charming, but not quite house-trained. Its nuances might make you giggle, but they're not quite ready to be the punchline of the coding world yet. I often find that giving the same prompts to Bard that I gave ChatGPT simply results in a giant NOPE.

What Lies Beyond the Forest: The Ethical Wilderness

What's more, as we step into the ethical wilderness of AI and natural language programming, we're not treading entirely new ground. Even before the dawn of AI, we've been grappling with similar issues – the 'copy-paste mentality' of many new developers and the over-reliance on platforms like Stack Overflow, to name a few.

Consider this: how often have you seen (or been guilty of) copying code directly from Stack Overflow without fully understanding what it does or whether it could have unintended side effects? The practice is so commonplace that there are memes galore about it! And products you can buy!

One of my favourite go-to examples of this is around Razer Synapse and Docker for Windows which couldn't run at the same time because of a flawed StackOverflow post on how to get the GUID of the running assembly. Whoops.

In the brave new world of AI, these challenges don't just persist – they are amplified. Conversing with AI models like ChatGPT or Codex could lead us to unintentionally feed them snippets of proprietary code or data. If these conversations can be reviewed by others or used for future training, we run the risk of inadvertently leaking our valuable IP and trade secrets.

Similarly, AI systems like Copilot have raised debates about unintentionally using copyrighted examples. When the AI generates code, it might pull from pieces of code learned from publicly available sources, which could include copyrighted material. Imagine finding out that the song you've been humming all day is actually a copyrighted melody! (Spoiler alert: it's music, it probably is).

As we continue our journey in AI-assisted programming, we must not forget the lessons of our past. We need to tread carefully, ensuring that our innovative tools don't become a liability, risking our IP, violating copyrights, or perpetuating the 'copy-paste' mentality that misses the heart of understanding and problem-solving in programming.

Onwards!

In the end, our quest for natural language programming, with all its challenges and pitfalls, is teeming with humour, excitement, and learning opportunities.

And as we venture into more complex territories - incorporating complex business logic, integrating with external systems, generating the Terraform code for a cost-effective and scalable system - we find that our AI comrades still have a long way to go. The nuances and subjectivity of these tasks still require a human touch.

What's next?

I haven't really touched on AutoGPT, mainly because I have very limited experience playing with it myself. Having seen some of the demos out there, it appears to be the missing link that might get us to the have AI fully build our systems. It might just be the answer we are looking for.

And just think, the era of simply telling our computers what problems to solve might not be that far off, and we could just be months away from replacing all the people still saying

"Remember punching cards?"

with the people now saying

"Remember having to type code?"