A Flag Once Taken: A Free, Multiplayer Create-Your-Own-Room Capture the Flag Game

FOREWORD: THIS AIN'T YOUR VIBECODED APP

I'm building a multiplayer web appl exclusively through LLM.

CHAPTER 1: IT WAS A BRIGHT AND SUNNY DAY

I've created A Flag Once Taken as a proof of concept generated almost completely through iterative use of language models to add/update/modify/remove code. Over the past twenty years (more, really, but I'd date myself), I've crafted web and mobile applications aplenty. Dozens, small and giant. Along the way, I shifted from writing code to lead wonderful teams of product and engineering professionals who themselves create the code. Now, it's my responsibility to understand how to support their growth as we work together to build a better world.

All was well and happy until... wump! LLMs entered the scene. You know that story.

Will LLMs truly steal tech jobs? How will our roles, as leaders and team contributors, shift?

I set out to find out-by pushing LLMs to do the impossible: replicate what we as humans do, across the domains of product design, management and ownership, and engineering of all flavors. I wanted to create and release a production-ready, robust product far beyond the relatively simple applications produced through vibe coding.

CHAPTER 2: AND SO

And so! Here we have a fully-operational node/Typescript application with separate frontend and backend architectures. The LLM has refined our node-based package configs, resolved application runtime mismatches, resolved security weaknesses and resolved configuration issues across the deployment pipeline (for which we utilize Render).

It has taken hundreds of discrete commits, small and substantial, to produce a production-ready application. Time? Maybe 2-5 hours per week over four months. This was built through my daily 5 - 6 AM 'do something create' routine, a habit I picked up from SCWBI authors.

In two instances, I had to back the codebase to essential modules and rebuild entire feature/functions to accommodate architectural expansions. Yes, that meant "almost from scratch." I also shifted LLMs (ChatGPT to Anthropic) and strategies (from using the agent UI to using Cline, and then back to using a combination of both) to perfect the most efficient expansion approach.

Is anything left of the oldest codebase - the first prompt to ChatGPT to produce a game of tag? Likely no, though the terrain generation module is the most original code within the codebase.

CHAPTER 3: LEARNING

What have I learned? This will be the subject of a presentation, but in general:

• It's possible!
• This is a process that can only be understood by truly doing it. Reading a post about how I did it won't help you deeply understand how LLMs will, or won't, shift roles within the Product & Engineering sphere.
• LLMs lack architectural imagination, even if they can produce some robust product documentation.
• Product Managers? Helpful, and not. I may be old and stodgy, but please don't use an LLM to generate your product documentation from the get-go. It'll lack the flair and flavor you bring to the table as a thoughtful, inventive human. You have a unique language, a unique style and, of course, a unique imagination. The LLM dilutes you.
• Product Managers? Do use it to fully vet your documentation, particularly if feeding into an LLM. If so, the product documentation should be written in Markdown, and very, very perfect. Errors in the documentation, which act as a touchstone, only throw the LLM off later.
• The lack of architectural imagination is profoundly important when generating anything greater than a prototype. That is - at some point, because of the contained nature in which LLMs consider code, even Anthropic fails to understand the architectural flexibility needed to grow the codebase. The result becomes known when feature extensions require extensive reworking for classes and methods to accommodate.
• Engineers? Better get flexible with both frontend and backend methodologies. LLMs can traverse both with ease, though once again, your architectural knowledge is keenly important.
• Engineers? Your job isn't disappearing. Without applying an Engineering understanding at the architectural and code levels, this would simply not be an operating application.
• Engineers, yet again? Learn about computational efficiency and secure code. Learn about quality architectural styling. Learn to use testing tools. Learn to debug. Even with prompting, the most powerful LLMs today (for ex., Claude Opus) are not generating code that applies these principles deeply. With prompting, it can, but one needs to know what to look for.
• Reading for code quality and security is important. The LLM-generated code is... alright. But it takes a human, paired with an LLM, to probe for actual weaknesses. What are the weaknesses? More than a bullet's worth!

CHAPTER 4: WHAT'S NEXT?

My friendly pet LLM and I still have a giant backlog to push. Thereafter, perhaps a second test-project is on the table?