The models get muscle

Things have been moving fast. SpaceXAI dropped Grok 4.5 and OpenAI released GPT-5.6 Sol, Terra, and Luna. For me the real surprise was Grok. I’d been using it mostly for research and had never reached for it on coding work — Claude Sonnet had been my default for that. My quick-and-dirty way of checking whether a model was actually useful was a one-shot prompt that asked it to build a browser-based clone of the 1979 vector Asteroids game.

I picked that old game for a few reasons that still hold up. It touches on a lot of what makes games interesting: graphics, basic physics, sound, scoring, projectiles, collisions, and even a little destruction effect when the ship blows up. At the same time it’s simple enough to describe without locking the model into every last detail, so you can see what it decides on its own for the ship, rocks, and UFO. JavaScript is one of the languages these models have seen the most of, and the whole thing runs in any browser with zero install.

Back in March 2026 I ran Grok 4.1 through that same prompt and it was pretty rough. Asteroids came out warped, the ship thrust sideways instead of forward, you’d hear the shot sound but nothing actually appeared on screen. It was one of the weaker results I got at the time.

Around then I started putting together a multi-agent setup — an orchestrator that would hand work to a planner, then a coder, then an auditor, and so on — so the models could build a small game feature by feature.

Before I had the whole thing tuned the way I wanted, the newer models (Grok 4.6 and GPT-5.5 among them) got noticeably better at just working through things on their own. They could plan, implement, test, and even come up with the next feature without constant hand-holding. I ended up shelving the orchestrated pipeline for a while.

The other big jump has been in vision. These models are now decent at looking at a screenshot of the game and checking whether what they think is happening actually matches what’s on screen. That self-verification step removes a lot of the back-and-forth that used to require a human in the loop.

To keep testing meaningful I put together a tougher prompt. On top of just building Asteroids, the new version asks the model to:

Follow SOLID and KISS/YAGNI principles where they make sense.
Use test-driven development for the pieces where it’s practical.
Avoid the usual LLM shortcuts when it comes to testing.
Wire up Playwright so it can actually verify graphics, physics, and on-screen behavior.
Support custom game modes (single-step mode has been especially useful for debugging).
Come up with 25 new features that feel fun and replayable, then plan, build, test, and commit each one to git in sequence.

Some of the games available on the game examples web page, generated by LLMs.

I’ve put the playable game results from the latest runs here, in a game examples web page:

https://rgm-llm-asteroids-arcade.netlify.app.

‘c’ and ‘1’ to insert coin and start the game.

‘left arrow’ and ‘right arrow’ to turn

‘forward arrow’ to thrust

‘space’ to fire

‘h’ to hyperspace

Example of a game designed, generated, and tested by an LLM

Every game is a full browser version of Asteroids with 25 new features the model designed itself. I’ve also included two earlier builds (the ones with the gold background) that only had 20 features. I liked the feel of those two enough that I wanted to show what was possible with this single prompt pipeline.

Lastly, I’ve included the prompt used to make these games at the bottom of the game examples web page. Feel free to use it as inspiration for your own prompts.

One practical note: running these long agentic loops eats tokens, especially once the context grows. Grok 4.5 and GPT-5.6 Terra Medium were both quick — around 15-20 minutes per game — and Grok barely touched my monthly token budget. Claude Sonnet 5 took an hour and forty minutes and ran up $112 in tokens. Opus 4.8 and Fable sat in the middle at about 45 minutes and roughly $60 each.

The frontier models have reached the point where they can keep iterating on a messy, ambiguous problem until it’s done. The older and smaller models still tend to stop after the first pass and wait for you to say “go do the next feature.” I’m planning to run a side-by-side on the single-agent approach versus the older orchestrator setup to see how they compare on speed, cost, and context size.

Giving the model a way to look at its own output visually has been one of the bigger practical wins. The more ways you can let it check its own work, the fewer obvious mistakes make it into the final build. The long-term interesting question is whether these models can eventually judge whether a feature or a whole game actually fun. That’s going to take more experimentation.

Testing Claude Sonnet 5 as an autonomous game development agent

I was able to test Anthropic’s newest welterweight class model, Sonnet 5, on the one-shot “make me a game” agentic prompt I had developed in my last post. I’ll go into more detail about the prompt after the Independence Day holiday,.

Briefly, the prompt instructs a single agent in a single context to create a basic Asteroids game, then come up with 20 fun new features all on its own, and iterate on them one by one, using Playwright autonomously to take screen captures of the game to validate the graphics.

The full prompt is here, and includes guidance to the LLM on code architecture, testing, and choosing new features : https://github.com/rgmarquez/devrep20-claude-sonnet-5/blob/main/notes/prompt.md

I’ll analyze the pros and cons of the one-shot prompt versus the much more structured feature orchestrator agentic pipeline I had been using before the (on again, off again) release of Claude Fable. I’ll also discuss some interesting observations and challenges I noted while watching Sonnet 5 iterate on the features, including intuitions on what fully agentic LLM pipelines may struggle with in the future, and the high token and money costs of fully agentic flows such as this one.

But for now, I present you Claude Sonnet 5’s solution.

The game can be played in a web browser here : https://rgmarquez.github.io/devrep20-claude-sonnet-5/

The actual GitHub repository can be found here : https://github.com/rgmarquez/devrep20-claude-sonnet-5

The Rise and Mild Panic of AI Autonomous Game Development

We’ve all heard that AI is going to eliminate our jobs, especially those in “knowledge work”, and more specifically those of us in software engineering.

I got to thinking, how real is the possibility? I only started to use LLMs for coding projects in November 2025, seven scant months ago. In that time, I’ve seen LLM based coding tools go from barely able to one-shot code an old 1979 arcade game (Asteroids ’79) to being able to pair code (with myself) sophisticated tools, back-ends, and game clients.

Still, I wondered, how close are we to having LLM based tools design, code, and test a simple, yet fun game all on its own; a completely autonomous game generation system.

I’ve spent the past 3 months of my off-work time working on such a system.

It is glorious. I have fully autonomous agentic pipelines, complete with a state machine “orchestrator”, orchestrating development agents such as a “planner”, a “coder”, and adversarial “code auditor” and “test auditor” agents. These separate agents minimize common LLM coding mistakes, emphasize DRY, SOLID, and YAGNI, and TDD principles, and minimize well-known LLM test cheating patterns.

I also enforce rigid policies on context separation, in order to keep each agent working on clear and concise tasks to minimize task drift. The system uses successive development, having the orchestrator task out each feature in sequence, so that the agents can implement each feature as a step-wise addition to the previous features, in the hopes of keeping the agents focused one feature at a time.

There are also a lot more blah blah blah principles and features of the pipeline, rooted in LLM research and simple blood and sweat of trial and error.

In a word, it is quite fabulous. And it works.

To a point.

I still have to generate the feature specs “offline” and paste them into the pipeline, by prompting a web based chatbot of the LLM model, as feature generation wasn’t implemented in my pipeline. And each “run” of a feature, including the planning->coding->auditing flow often gets stuck in a loop, with the auditors screaming that “just one more thing” needs to be fixed, with the coder dutifully implementing each revision, burning token after token. And sometimes the agents “drift” or even go completely off the rails, examining each other’s configuration files, and even each other’s prompts, in order to be “helpful” despite prompts telling them not to.

A reminder, a paraphrase of Captain Barbosa from “Pirates of the Caribbean” : “Prompts are more, what you’d call ‘guidelines’ than actual rules. Welcome aboard the Black Pearl Miss turner.”

Life is good, and although I still have a way to go to get Github Copilot, Claude Code, or OpenAI Codex to design, build, and test a simple game from beginning to end, I’ve learned a lot about designing, implementing, and testing these fully autonomous agentic pipelines.

However…

An interesting thing happened during the past month or two.

The LLM harnesses got better. And the LLM models got more capable. Much more capable. Actually, much MUCH more capable.

I saw it first with GPT 5.5, with its ability to code, stay on task, and use its multi-modal ‘vision’ capabilities. All of a sudden, I had a model that wouldn’t often drift off task, that was really good at coding, and that could be tasked with checking its work VISUALLY. I started having the agents use Playwright (for web based games) and AppGhost (my own custom app for Mac and Windows games) to have the agent visually verify what was on the screen; no more arguments with the agent about if the spaceship was oriented on the screen correctly, or why the entire terrain mesh was outside the 3D rendering area.

With the later versions of Opus and now Fable, I also noticed that the agents could now iterate on their own; no longer did “one shot” equate to “make it all at once”…it could now mean “do these operations once for each feature for these ten features”, and reasonably expect the agent to stay on task until the last feature was planned, coded, and tested fully.

In other words, they could now, on their own, manage the whole pipeline I had spent months architecting and verifying, in one prompt, in one messy but somehow effective context…and in a way that produced a better game implementation, in far less times, with far fewer tokens.

My characterization of “better game implementation” is based on several runs of my old pipeline using various GPT and Claude models (mostly Claude Sonnet and earlier versions of Opus), and one run of the “one-shot” pipeline using Fable, before it was taken off-line.

As far as “far less time”, I’m talking 1-2 hours for the old pipeline, vs. 20 or so minutes for the 1 shot pipeline…and the 1-shot pipeline also includes having the LLM come up with new features and the feature specs each and every run.

I’m not sure about the token counts of each pipeline; my claim about “far fewer tokens” is based on the fact that the “rigid” pipeline generated many artifacts (coding plans, testing plans, auditing reports, etc.) that seemed to take quite a while to generate (reasoning tokens), tokens that maybe, just maybe, didn’t contribute to the end product as much as I would have liked.

I’ll be experimenting with the new “pipeline”, refining the testing requirements, etc. and examining the output (code, architecture, tests) vs. what was produced by my old pipeline.

Honestly, besides the models and harnesses becoming more capable, the biggest change towards fully autonomous game generation has been giving the agent “vision”, so that it can verify on screen what it thinks it “knows” about the game.

Lastly, one of the insights I’ve learned is that one of the biggest hurdles to a fully autonomous game generation system is something that I’ll call “aesthetics”. Not necessarily what is beautiful, although “aesthetics” can encompass that. By “aesthetics” I mean the emotional aspects of art in general and games in particular; what makes a game exciting, frustrating, boring, interesting to look at? Is the story engaging, are characters relatable? Does the story have irony, pathos, love, heroism, duty, sacrifice? An LLM can be prompted to approximate many of these qualities, but humans seem to be far better at creating and judging (gating) these aspects of a game, as they have been trained on these qualities literally all of their lives.

If you are interested in this project, I have a GitHub repo that you can check out here : https://github.com/rgmarquez/claude-code-fable-game

It includes the actual prompt that I used with Fable to generate the game : https://raw.githubusercontent.com/rgmarquez/claude-code-fable-game/refs/heads/main/.notes/initial-prompt.md

A playable version (in your web browser) of the game is located here : https://rgmarquez.github.io/claude-code-fable-game/

Chronicling the Singularity

It’s been almost 2 years since I last posted to this blog. Since then, related to the world of software development, two things have changed:

I’ve been working at a large game company as a Senior Software Engineer on one of the technology teams; it’s nothing short of a total blast working with the people on my team.
The dawn of agentic coding has arrived on the software scene, and knowledge work in general.

It’s terrifying and exciting times to be a software developer. I hope to document each step along the way.

(Skip to the bottom if you just want the ‘fun stuff’ 😀)

I started using coding assistants only recently. In November 2025, a coworker demonstrated GitHub Copilot in Visual Studio Code to team members. He was amazed at how quickly he could get working prototypes up and running. At first, I found it interesting, but as his demonstration continued, I too was amazed.

Over November and December, the team independently started experimenting with coding assistants to see what they could do, what mistakes they would make, and what best practices we could devise for using them in production code.

In December, we shipped our first AI-assisted project, weeks ahead of schedule and with better documentation than in many prior projects.

By January and February 2026, we were routinely using AI to explore and document older codebases, as well as to assist with maintenance and modernization efforts. We even began investigating ways to use AI for reducing accumulated technical debt…ironically, since one common complaint about AI agents is that they add to a codebase’s technical debt.

As of March 1, 2026, all team members use coding AI as an efficiency tool at work on a daily basis. All of us are also pursuing side projects after hours, experimenting with AI coding agents to push their limits, identify where they fail, and determine where they add value. Several of us have created functional web apps that solve problems we had long intended to address through traditional development but never found the time for. And all of us are working on passion projects—mostly game-related—that would traditionally require several programmers and artists weeks to prototype, but which can now be prototyped in several nights by one software engineer.

In the coming weeks, I will present some of these passion projects. I will also provide posts on the best ways to fully and deeply understand—or “grok”—Large Language Models and agentic AI, so that you do not have to treat them as black boxes and can more fully grasp their problems and usefulness in software development.

Additionally, I will blog about the societal implications of the rapid rise of AI in general, with thoughts on how to not only survive but thrive, and what to teach your children to do the same.

For now, I will present a one-off project that I created on a whim last night. A coworker was investigating realistic gem rendering on screen. He considered existing game engines, including Godot and Unity, to give him a head start. He used AI to assist, but he was not getting the results he wanted in Godot, so he switched to Unity. He reported decent results—this was Friday, two days ago—but I suggested he look into web-based technologies, as they would provide cross-platform availability out of the box.

That night, I wondered how easy it would be to create a web-based gem renderer. While half-watching TV with my wife and daughter, I decided to have Claude Opus and Claude Sonnet help me develop one. I wrote a detailed software specification, omitting the rendering technologies so that the AI could recommend them. I then had Claude Opus create the plan and Claude Sonnet execute it.

The result is a web app, using three.js, that renders gemstones in real time:

Example (screenshot from live gem animation)

The live website has the gem autorotating in real time, and you can use the mouse and mouse button to see different orientations of the gem. You can also switch gems (Diamond, Sapphire, Emerald, Citrine) and change some of the render parameters using on screen sliders.

It’s important to note; without human intervention, the concept of “aesthetics” often eludes the current LLMs, especially in a coding context. They are getting better at it, but often developers will have to coach the LLM, “move it more to the left so that it is inline with the text above”, or “the spaceship looks like a rectangle, it was supposed to be a chevron”, or even “that gem looks like *ss, lets brainstorm ways to fix it.”

This is where I believe that humans will always be needed. We may get to a point where AI can render a movie for a consumer ‘on the fly’, but will it be good? Coherent? Watchable for more than 5 minutes?

This came into focus when I tried to work with an LLM to convert the web based gem renderer to Vulkan, to run natively on MacOS and Windows. The first attempt looked like *ss. And, after several hours of re-prompting and coaching, it still looked like *ss. However, I have a plan on how to get the LLM agent to convert the renderer to Vulkan in a way that exactly replicates the WebGL renderer. Stay tuned.

If you are interested in trying out and seeing the web version of the gem renderer, try out the live website here : https://rgmarquez.github.io/gem-render/

The GitHub repo is here : https://github.com/rgmarquez/gem-render

Speaking of Priorities

I love doing fun things. Don’t we all?

And, all else being equal, I like doing the “more funner” things more than the “just plain fun” things.

However, sometimes priorities dictate doing the “just plain fun” things first. This is one of those times.

For the next few days I’ll be putting my React learning on hold, and dig up my Java programming knowledge from back in my Amazon Prime days. You see, I have an interview coming up with a Java-based shop, and I’ve been told that their coding challenges and questions are strictly Java based.

I’m currently reviewing some of my old Java code (an example of which can be found here : https://github.com/rgmarquez/redis2-codechallenge) to revive the Java side of my brain. I need to be reminded of the the syntax, coding conventions, and concurrency best practices that I used to have in the forefront of my mind, before C#, C, and JavaScript pushed it all to the back.

My next post will most likely be my thoughts on going back to Java after the joys (non-sarcastically) of C# and JavaScript async/await programming. I do remember that with Java SOA, we tended to use dependency injection a lot more than I’ve see in C# or JavaScript. I also remember that DI was particularly useful for decoupling dependencies, and for test mocking with little to no change to the target system.

Hmmm, maybe I should do a future blog post describing Dependency Injection, to what extent each developer community (Java, C#, JavaScript) seems to use the DI paradigm, and why.

But for now, on to refreshing my knowledge of Java syntax, memory model, concurrency, automated tests, and best practices…

The pragmatics of priorities

In looking at my list of projects, it occurs to me that in order to make a dent in most of them, I really should step up to the plate and learn the front-end Javascript framework “React”. I’m choosing to learn React over something newer (like Svelte) as a great deal of companies use React, and I’m trying to make myself more marketable as well as learning front end coding for my projects. A two birds with one stone kind of thing.

I actually know a bit of front-end coding with both straight HTML/CSS/JavaScript and with Angular.js, but again, I believe that React knowledge will get me farther with prospective employers, while allowing me to create professional quality front-ends for my projects.

I’ll be using Mosh Hamedani’s “Code with Mosh” videos to learn React. In theory, his videos will be building my knowledge up to coding a “production grade app for discovering video games”, and I like the idea of learning enough about React to be able to code such an app:

If you are interested in Mosh’s coding courses, they can be found here: https://codewithmosh.com

Which one, which one…

There are so many development topics I want to cover, it’s hard to know where to start. I want to talk about projects I’ve worked on in the past (there have been a LOT of them), but I also want to talk about new projects that I am curently starting.

I’m currently unemployed right now (and looking for work!), but in my now expanded spare time, I’m trying to learn some new technologies, while bolstering my knowledge of some things I’ve done in the past.

So perhaps I’ll start off with my list of current projects that I’m starting, in no particular order:

All of these projects will be hosted on GitHub (actually, some already are), and as I work through development, I’ll be making sure to update the source code and supporting files there.

Here : https://github.com/rgmarquez?tab=repositories

Incidentally, I do tend to keep a lot of notes and lists, from lists of projects I’m working on, to lists of features (specs?), to lists of bugs that I’d like to fix, to cool features that I’d like to add. When I’m working professionally, Iuse Atlasian’s Jira (https://www.atlassian.com/software/jira) to keep track of projects, features, and bugs. However, for my simple experimental projects, I tend to use simpler tools like Apple’s “Notes” app when I’m working strictly on my Mac Laptop, or Evernote when I will be switching between my Mac laptop and my Windows laptop.

For example, the “spec” for my gift/wishlist app looks like this:

It should be noted that I like to develop my own apps in stages, starting with a “minimal viable product”, or even a “prototype”; I don’t want to start with every feature that can be imagined, I want to start with something that will be useful, while uncovering issues that I may not have thought about when starting a project (the “unknown unknowns”). Additionally, I like to start small to make sure that the product is something useful, to make sure that I am “building the right product” as well as “building the product right”.

For now, one of the main goals for these projects is learning new things, and reinforcing old skills, so for many of them, “usefulness” (other than as an example for others) may not be a major concern. 😉

Embark on a Coding Journey: From Embedded Systems to Blockchain and Beyond

Greetings to anyone reading this! This blog was a long time coming; I had originally created this blog back in May of 2015, with the intent of creating an interactive discussion, spanning the wide range of software development projects I have been involved with in my many years design and programming.

My career so far has been nothing short of crazy; I’ve written applications ranging from one of the original “map/tile editors” used in games for the original Sega Genesis and SNES, to mobile (iOS and Android) applications that wirelessly communicated with fitness equipment to optimize your work-out, to tools, game engines and games for MANY platforms (MS-DOS, Windows 95, Amiga, Playstation, 3DO), to back-end services and game systems for Amazon Prime and Scopely, to front-end applications for configuring Live-Ops game events, to embedded system programming in assembly language (Sega Genesis) and C (Intellivision Amico Controller), to blockchain/smart contract code for in-game items, to data analytics pipelines/ETLs for graphing game events.

Most of my career has been involved with games or computer entertainment in some capacity, with the exceptions of periods with the Amazon Prime team and San Luis Aviation.

The point being is this: I am a generalist. I have experience with a whole lot of practices, methodologies, and bad habits from multiple software disciplines, which hopefully means I can bring some cross-domain insight into software development based on my experience.

It also means that I can do a little bit of everything, including creating crazy cross domain projects; imagine a project integrating games, AI, blockchain, analytics, and front-end tools all in one, hopefully simple to understand project. There is a lot to be learned from cross-domain projects, and I hope to make this blog a chronicle of my ongoing learning.

So if you are game for this journey, welcome aboard; and if you have any expertise in any of the things I will be chronicling, definitely feel free to speak up and set me straight. It is hard to bruise my ego, and I’d rather learn together than pretend I am always right.

Welcome!

Getting started…

“No fear. No distractions. The ability to let that which does not matter truly slide.” – Fight Club