New applications

In the last few months, I have been working on a bunch of new applications.
Feeling the itch to use all the AI credits I had available and to squeeze out the budget before it reset, I spent almost all of my spare time in April and May working on new projects or project ideas that had been lingering in my head for a while.

Now, in June, I decided to take a step back and slow things down for a bit after my wife complained that I was in my office non-stop. First home office, a short family time during dinner, putting our youngest kid to bed, and then back into the office to work on projects until late at night.

Anyway, that phase was very productive. Now I have one game in the stores, one game stuck at ~70%, another promising game at 80%, and a new process explorer.

I used these projects to experiment with different AI providers, compare their outputs, and analyze the strengths and weaknesses of each to get a better understanding of the current state of AI and how to best use it in different situations (also at work).

One goal was to provide the infrastructure for the applications, define guardrails and basic rules for the AI, and then try to let the AI do as much of the work as possible. I still reviewed the code at a high level (architectural violations and such) and did the commits / PRs manually.

This worked quite well. I took the infrastructure bits from Mirroly (custom DI solution, logging approach, architecture, and abstraction levels), and the first task for the AI was to copy that code and adapt it to the new project.
I think the result was pretty good and helped a lot to get the project up and running quickly.

I feel like this approach also made it really easy for me to detect when the AI was taking a suspicious turn, as just looking at the code areas touched was already a super strong signal. I could then review the code and give feedback to steer it back on track. Basically, I treated the AI as a junior developer and tried to provide guardrails through the code architecture and basic design rules.

But now let me briefly talk about the released projects:

VØID Arc

I started with a game called VØID Arc. The idea was to create a simple game that leans heavily on skill but still has the potential to be played casually.

It is a very simple game in which you control a small dot (the ship) orbiting a circle (representing a planet). You tap the screen, and the ship exits the orbit in the direction of the current tangent. The goal is to hit the next planet.

That’s all.

The goal is to go as far as possible. As the “level” increases, the planets get smaller and more distant, and the speed at which the ship flies increases.

I used Flutter and Flame for this one, simply because I was already familiar with Flutter and had wanted to try Flame for a while. As it is a 2D game with simple graphics and mechanics, this was a very good fit.

To spice things up a bit, I decided to also add a backend component to that one. I was somewhat hesitant to jump directly to an easy but expensive solution or to self-host something, so I decided to use a middle-ground solution: Supabase.
The game is still on the free tier, and I don’t expect this to change anytime soon. I just hope that supporter purchases and ads will cover the costs if it gets some traction 🤞.

More games

Inspired by the VØID Arc experience, I then started to work on more games. I quickly realized that if the game mechanics are even a little bit more complex than what VØID Arc has, then the role of the “Product Owner” to define all the nitty-gritty details of game mechanics, how they interact, and how they play with thresholds to make the game really fun becomes super important.

AI can’t help you with that.

It will produce something, but if you are not able to describe exactly what you want, the output will be mediocre at best.

That’s why I now have a bunch of half-finished games in various stages of completion that lack “something” I can’t quite put my finger on. So, I decided to put them aside for now and maybe come back to them later once I have more concrete ideas on where I actually want to go with them.

Yggdrasil Explorer

This is the latest (yesterday) addition to my family of applications. I was looking for an Activity Monitor replacement for a while. The Activity Monitor on macOS is really not that good. It takes forever to start, and if you want to find out which process is currently running (for example, in a tree view because I want to see if OpenCode running in Warp is still executing the Dart tests), it is really cumbersome to navigate.

Items jump around, and the CPU usage numbers are not very helpful.

These are the two main complaints I had, so I decided to build my own process explorer.

I could have tried to build it with Flutter and make it cross-platform (maybe I will do this one day), but on Linux and Windows there are already really good solutions, so I decided to go all-in on macOS for this one.

As I’m also currently experimenting with Rust, I wanted to:

• use Swift for the UI
• use Rust for the backend (fetching process information, CPU usage, etc.) and communicate with the Swift UI via FFI.

I know that directly opposes by previous blog post about “Why most applications should be cross-platform”, but as stated in that blog post: there are always exceptions to that rule and if an application heavily leans into platform-specific functionalities or features, it can totally make sense to build a native applcation.
And I wanted to build something with Swift and Rust, OK? 🤣

For this project, it was more about me trying to make sense of what the AI had built, as I’m not deeply familiar with either technology. I can read them and comprehend what is going on, but I lack the experience that would immediately help me see if something is bad code or if the junior AI dev is making the wrong design decisions.

The project turned out to work quite well, though, and I’m already using it. You can, too, if you want to give it a try: Yggdrasil Explorer.

It already contains the basics one (at least I) would expect from a process explorer and contains things like a Sparkle based update mechanism, dark mode support and a nice macOS-native UI.

Summary

That’s a wrap. I can’t tell you any more details about the half-finished games, but there is one physics-based game that could be really fun, and that’s the one I will most likely come back to at some point.

AI coding is really great for getting projects off the ground that would have been too big of a task to even start in my free time, but I really need to be careful not to burn myself out that way.
It’s good to have a family that keeps me grounded and reminds me to take breaks and spend time with them.