DEV Community: Tony Costanzo

I Billed Myself for 6.7 Billion Tokens and the Total Came Out to $35.85

Tony Costanzo — Wed, 08 Jul 2026 11:30:08 +0000

This one originally went up on my blog.

My Model Got Called Illiterate

My friends spent the weekend trash-talking the new coding model on my rig. By the time I finished defending its honor, I had priced every token my GPUs have ever produced and drafted a passive-aggressive invoice to the cloud.

Quick context for the new folks: I run a four-GPU homelab rig that serves coding models to a handful of people over LiteLLM. Last week I swapped the coder from Qwen3.6-35B-A3B to Ornith-1.0-35B, a DeepReinforce fine-tune built for agentic coding that benches a couple points higher on SWE-Bench (75.6 vs ~73.4). Getting it to boot took a vLLM upgrade and five sequential startup failures, which is a war story for another post.

The defendant's residence. Four 3090s on a mining frame, and yes, the RGB is load-bearing.

The point is, the community was raving about this model. Then my users started filing complaints:

"this model misspells shit a lot"
"spent about 10 minutes deleting a file and recreating it, forgot what its original task was"
"big habit of deleting the whole file it's working on and trying to rewrite it all even though it's just missing imports"

So either every reviewer on the internet was wrong, or something about my serving setup was making a good model act like it had a concussion. I had a suspect. It was me.

Subpoenaing My Own Request Logs

Here's a thing I didn't fully appreciate until this week: LiteLLM stores the raw request body of every call in its spend logs. Every parameter every client ever sent. It's a full forensic record, sitting in Postgres, waiting for someone to have a bad enough week to read it.

I pulled every Ornith-era request for the heaviest user's key. 2,706 requests. 2,703 of them sent no temperature at all.

When the client doesn't send a temperature, vLLM falls back to whatever the model's generation config says. This quant's default: 1.0. Combined with the top_p of 1.0 the client did send, my users were generating production code at near-maximum randomness. The misspellings weren't a model problem.. they were a dice-rolling problem.

Yikes.

And that was just the first charge. The logs kept talking:

The contexts were enormous. Average prompt: 105,394 tokens. The biggest: 230,071, damn near the model's 262K ceiling. Roughly a third of all requests came in over 140K.
My fp8 KV cache was quietly taxing those deep contexts. Squeezing the cache to 8-bit is how I bought headroom, but at 100K+ tokens the precision loss is real. That's your "forgot what its original task was."
Thinking was disabled globally. I'd turned it off for my other workloads. For a model whose entire party trick is reasoning through a plan before acting, that explains the "rewrite the whole file to fix one import" behavior.

The control group sealed it: completions in the 44K to 56K range were clean, articulate, multi-step debugging. The model was fine. The config was drunk.

The Fix Cost Nothing (My Favorite Price)

Two things I learned fixing this, and both were free:

Sampling params ride along per request. One loaded model can behave completely differently per consumer. I made a second LiteLLM model entry, ornith-thinking, pointing at the same backend with temperature: 0.2 and thinking enabled baked in. The coding folks switch one config line. My other consumers (a security camera captioner, my knowledge base, a chat UI) keep their fast no-thinking behavior and never notice.
This model's KV cache is comically small. Ornith uses aggressive GQA with only 2 KV heads, so I checked whether I even needed fp8 anymore. Turns out fp16 still fits the entire 262K context with room for ~3 fully-maxed concurrent requests, and about 8 at my users' average context size. Peak concurrency ever observed on this box: 4. I was paying a precision tax to buy concurrency nobody was using.

So the deep-context degradation fix was literally removing a flag. I love it when the answer is deleting something.

The Rabbit Hole Under the Spend Tables

Now, while I was elbow-deep in LiteLLM's spend tables gathering evidence, something kept bugging me. Every local request had a spend of $0.00. Which is adorable, but wrong. These tokens aren't free.. I pay for them in electricity, and I had all the data to compute exactly how much.

My Prometheus setup already scrapes per-GPU power draw and vLLM throughput. The math is one line:

Energy per token = watts / (tokens per second)
The two coder GPUs pull ~700W under load (power-capped 3090s)
Decode runs ~130 tok/s, so each output token costs 5.4 joules
Prefill chews ~6,000 tok/s, so each input token costs 0.12 joules

At my rate of $0.1395/kWh, that lands here:

	$ per 1M tokens
Input (prefill)	$0.0045
Output (decode)	$0.21

Prefill is ~46x cheaper per token than decode because it batches, which matters enormously when your workload is agents stuffing entire repos into every prompt.

Honesty corner, because I hate cost posts that hide the asterisks: this is marginal cost. It excludes idle power, cooling, and hardware amortization. And the prefill throughput is estimated, not measured, so the input rate is the softest number in this post. Sanity check though: it prices my last 7 days of usage at about $6.90, call it $30/month of coder electricity, which matches what the rig actually pulls. The math holds.

The Part Where the Cloud Should Blush

I set those per-token prices on the local models and backfilled every request LiteLLM has ever logged. All-time damage across every local coding model since April: 6.67 billion input tokens, 27.8 million output tokens, $35.85 in electricity.

Then I priced the identical token volume at OpenRouter's rate for Qwen3.6-35B-A3B, the exact architecture Ornith is fine-tuned from, at $0.14/M in and $1.00/M out. Same tokens, their bill: ~$961.

That's ~27x cheaper on marginal cost, and OpenRouter's open-model pricing is already the cheap option. Input tokens are the absurd part: 31x cheaper locally, on the exact token type my agentic workload mainlines.

Before anyone yells at me (again), yes, the comparison is electricity vs fully-loaded cloud. So let's load it: the rig cost about $6k, which amortizes to ~$167/month over three years. The coder workload alone has been producing $320 to $480/month of cloud-equivalent value. It pays the rig's mortgage two or three times over before counting anything else the box does (image gen, voice, embeddings.. you name it).

Where 6.7 Billion Tokens Actually Went

Backfilling spend meant I could finally answer a question I'd never thought to ask: what is actually eating my rig? I mapped every API key to its workload and grouped all-time usage.

The results broke my mental model of my own homelab:

The always-on assistant dominates everything. Hermes, my 24/7 messaging agent, has quietly pushed 4.75 billion tokens.. 71% of all local inference ever. Total electricity: about $26. A billion tokens a month of ambient assistant costs less than a pizza.
Coding is the heavyweight per request, not per volume. 28% of the tokens from just 12% of the requests, averaging ~97K tokens per request. Agentic coding tools shove the whole repo into every single turn.
The "second brain" is a rounding error. My knowledge base and memory agents, the thing people assume is the token hog, used 13.6 million tokens all-time. Twenty-two cents. The chat agent out-consumed it 350x, purely by never shutting up.
Vision is cheap and bursty. The security cameras fire thousands of tiny ~1.9K-token requests. 5% of requests, 0.23% of tokens.

Three Traps I Sprung So You Don't Have To

If you want to do this backfill on your own LiteLLM box, learn from my bruises:

/model/update silently drops custom cost fields. input_cost_per_token and output_cost_per_token only stick if you delete the model and recreate it via /model/new. No error, no warning. The API just quietly disagrees with you.
Spend lives in three places, and the UI reads the one you'd guess last. Per-request spend logs, per-key running totals, and daily aggregate tables. The usage dashboard reads the daily tables, so backfilling only the request logs changes nothing on screen. Ask me how long that took me to figure out.
Reconcile key totals additively, never from scratch. Old spend logs get pruned while key counters persist. Two of my keys held $42 of real recorded spend with zero surviving log rows. A naive spend = sum(logs) would have erased history, and bumping totals can also trip keys with budgets, so guard for that too.

LiteLLM has strong opinions about its spend tables. Now I have strong opinions about its opinions.

Case Closed

So the model was never drunk. My config was rolling dice at temperature 1.0, compressing memories at 200K context, and lobotomizing a reasoning model's ability to reason. Ornith is owed a formal apology from at least three people, and I've sent mine.

The real souvenir is that number though. Every token my coding stack has ever produced, 6.7 billion of them, cost me less than a family dinner. The cloud wanted a grand for the same work.

My friends are back to happily burning 97K tokens per request like it's nothing. Because at $0.0045 per million, it basically is.

Go bill yourself. It's weirdly satisfying.

I Run AI Agents Around the Clock and My Best Productivity Tool This Year Has No Battery

Tony Costanzo — Thu, 18 Jun 2026 10:32:20 +0000

This one originally went up on my blog.

The Most Analog Thing I've Done in Years

I have a four-GPU AI rig humming in my house. I've got a homelab agent that pings my Telegram the second something breaks. I've automated chunks of my life that most people don't know can be automated.

And the single best productivity change I made this year was buying a notebook and a pen.

I know how that sounds. Believe me, I know. The guy who writes blog posts about vLLM quantization and self-hosted inference is here to tell you about.. journaling. Stay with me, because the irony is kind of the whole point.

It Started, Like Most of My Bad Decisions, at the Mall

Last year I was wandering The Galleria in Houston and walked into the Mont Blanc store. My dad always had a Mont Blanc when I was growing up, so the name had a pull on me I didn't fully understand at the time. I wasn't going to buy anything, I just wanted to look.

So of course I tested one. And it was genuinely lovely.. right up until I saw my own handwriting on the page. Mine is terrible. Always has been. Dropping Mont Blanc money to make my chicken scratch more expensive felt like buying a Ferrari to sit in traffic, so I capped the pen, set it down, and walked out.

That should have been the end of it. Then about a month ago a YouTube video about fountain pens landed in my feed and dragged the whole itch right back out. Like Betty from that video, I had no idea something so simple had so much depth. She pointed me at a Lamy Safari, which runs about half of what a Mont Blanc costs in sales tax. Sold.

Once I actually had a pen I liked, the pen stopped being the point. The writing did. I'd spent the first half of this year building out a personal "knowledge base" to finally get organized, and the idea of doing some of that thinking by hand wouldn't leave me alone.

Turns Out There's a Method to the Madness

Down the research rabbit hole I went, and I found the Bullet Journal method. It's a stupidly simple system for categorizing quick notes, and it clicked instantly because it reads like markdown for paper.

Naturally, I couldn't leave it alone. I tweaked the key until it matched the way my brain already works:

• a task
x task done
/ task started
> task I'm pushing to tomorrow
< task I canceled
- a quick note
* an important note (admittedly subjective)
○ an event

If you've ever written a markdown checklist, this is the same muscle. I'm not parsing it with a tokenizer, I'm parsing it with my eyeballs at 4 in the morning, but the instinct is identical.

One Brain, Six Boxes

Once the key felt right, I built a weekly layout. Two pages, each split into three, so six boxes total: one for every workday and a big one for the weekend.

On Sunday I sit down and rough out the week at a high level. The decision that actually changed things was refusing to separate my domains. Work, side projects, life.. all of it goes in the same six boxes. One centralized brain dump, which is sort of the entire point.

So a single week's spread might hold:

Work: database cleanups, the weekly migration, UAT acceptance.. the usual EPC data gremlins
Thundoria: rework the inventory system, balance some enemy NPCs, build a changelog
Life: Kid's sporting events, important dates, the works

This sounds insultingly basic. Plan your week, write it down. And yet, looking back, I genuinely don't know how I functioned before.

Actually, I do know. I was a "vibe coder" before AI was commercialized. I executed work based on vibes and how I felt that day, hour, minute. If I woke up and felt like pivoting my fourth million-dollar SaaS idea in a completely new direction, cool, sounds fun, let's go. No plan, just vibes and caffeine.

Putting Pen to Paper (Literally)

The game changer wasn't the clever key or the six little boxes. It came down to one stupidly old phrase: putting pen to paper.

Journaling, the bullet method, the custom symbols.. none of that is the magic. They're just outlets. The actual shift was stopping, taking a breath, and thinking about what I was about to do before I did it.

That's embarrassingly hard now. We're drowning in pings. Social media notifications, Telegram messages from my homelab agent, Reddit alerts about cheap GPUs I absolutely do not need more of. Every one of those is a tiny hand reaching out to yank my attention somewhere else.

Putting the phone down and picking the pen up broke the loop. No notes app, no task manager, no productivity suite synced across six devices. Just a page that can't notify me about anything.

My 4 AM Half-Page

I get to work early. 4 to 4:30 in the morning. The first 15 minutes now belong to the notebook, and the routine is always the same half page:

A sentence or two on me: how I slept, how I'm feeling, what the day's got waiting
Three to five tasks I actually want to finish today, cross-checked against Sunday's weekly plan
A quote of the day, which I get by asking Claude for something that'll resonate with me (yes, the AI guy uses the AI for his analog journal, the hypocrisy is noted)

Then I set the notebook right next to my keyboard, a glance away, and I get to work. As the day throws things at me, I log them in real time:

Joe Shmoe needs earned value data pulled for the past week
Jane Doe wants a UX feature added to one of the apps
Wife called, grab bread on the way home

Little things. The exact little things that used to evaporate the second a Teams message landed on top of them.

The Part Where I Take Off the Apple Watch

This is the bit I keep coming back to, because it's where it stopped being about a notebook and started being about something bigger.

I'm 33. I've made peace with the fact that I'm scatterbrained. I do it to myself, juggling something like 48 projects at once, and I'm not proud of it.. but I genuinely work well in chaos. The notebook didn't fix that. It just gave the chaos structure.

So I kept pulling threads. I stopped opening my phone "real quick" only to surface 40 minutes later on TikTok with no memory of why I unlocked it. I took off the Apple Watch that buzzed my wrist every ten seconds and put my old analog watch back on. A watch that tells time. That's the whole feature list.

I'm an avid tech guy who looked at his own setup and decided to de-digitize parts of it. Not all of it. Just the parts that were quietly running me instead of the other way around.

Controlled Chaos

I'm not going to pretend a notebook turned me into a calm, organized person. It didn't. I'm still juggling 48 projects, still up before the sun, still one good benchmark away from buying another GPU I don't need (don't tell my wife).

The difference is that now it's controlled chaos. Same mess, but I'm holding the leash instead of getting dragged behind it.

Funny how that worked out. I spent years and a small fortune building systems to manage my brain, and the thing that finally did it was a thirty-dollar Lamy and a notebook.. no firmware, no notifications, a battery life measured in ink.

My handwriting has only gotten marginally better, for the record. But I fill that notebook every single morning now, which is more than any app on my phone can say. So maybe one of these days, once I've actually earned it, I'll walk back into that Mont Blanc store and buy the thing my dad always carried.

I Spent 22 Years Programming Just to Fail at Making a Skeleton Swing a Sword

Tony Costanzo — Fri, 29 Aug 2025 15:43:11 +0000

Originally published at techhivelabs.net

Why I'm Building an MMORPG (By Learning How NOT to Build One First)

Every Game Developer Tells Us The Same Thing...

"Don't build an MMO."

It's literally the first rule of indie game devs. Right up there with "start small" and "your first 10 games will suck." And you know what? After 22 years of programming and two months of trying to build one, can confirm: they're absolutely right.

The thing is.. I'm still going to build my MMORPG. I'm just taking a massive detour through a completely different game first. Let me explain why building my dream game meant stepping the hell away from it.

From RuneScape Private Servers to Full-Stack Development

My programming journey started when I was 11, doing what any reasonable (totally not degenerate) pre-teen would do in 2004: hacking together RuneScape private servers so I could spawn max cash stacks and party hats. Those early days of tearing apart poorly-written Java codebases by other degenerates taught me one thing exceptionally well: how to duct-tape other people's code together until it (mostly) worked.

Over the years, I graduated from game server shenanigans to real backend development. I built RESTful APIs, managed millions of rows of data for EPC contractors, and became what I'd call a "real programmer." Java, Kotlin, Python, TypeScript, PostgreSQL, microservices.. you name it, I could architect it.

But deep down? I never stopped scoping out game ideas in markdown files. Mountains of them.

Enter Thundoria: My Beautiful, Overscoped Monster

Earlier this year, I finally said "screw it" and started building Thundoria, a browser-based multiplayer roguelike bullet-hell with:

Procedurally generated dungeons
Real-time multiplayer combat
RPG progression systems (because why not?)
Crafting, fishing, mining (who doesn't love scope creep)
Social features like guilds and parties
And yes... it's an MMO

[Want to watch this trainwreck unfold? Join the mailing list at thundoria.com!]

The Technical Flex That Nobody Asked For

In two months of near-daily work, I built some fairly impressive infra:

NuxtJS Frontend:

Supabase auth with JWT passthrough to the game client
Embedded game frame with seamless auth

Kotlin Service Layer:

RESTful API for game server orchestration
Dynamic instance balancing
Procedural map generation
HTTP map data serving to both client and server

Nakama Game Server (Go):

Multi-character system per account
Server-authoritative collision detection using map data from Kotlin
Real-time multiplayer synchronization
Full inventory and stats persistence

Godot Client:

Fully integrated with the entire stack
Complete UI with MMO-style panels
Character creation with class selection
Multiple polished scenes

I was crushing it. Architecture? Check. Data flow? Nailed it. Scalability? Ready for millions of players that would definitely (never) come.

Here's some posts where I talked about progress:
// Detect dark theme var iframe = document.getElementById('tweet-1954976218299895986-866'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1954976218299895986&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1953539709730205787-148'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1953539709730205787&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1952172653894148553-46'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1952172653894148553&theme=dark" }

The Brutal Realization

Then I tried to implement combat.
And NPCs.
And enemy AI.
And suddenly, it hit me like a wave attack from a boss I needed to design: I had no idea how to actually design game systems.

Twenty-two years of programming experience, and I was paralyzed by questions like:

Should enemies attack on a timer or use complex behavior trees?
What percentage of loot should be rare vs common?
How do you make death punishing but not ragequit inducing?
Why does every design decision have 47 interdependent systems?

I knew HOW to make an enemy attack. I knew HOW to implement a loot table. Shit, I could build you a distributed loot service with Redis caching. But WHAT should that enemy's attack pattern teach the player? WHAT loot distribution keeps players engaged without breaking the economy?

I was an architect and never built a house.

The YouTube Immersion Therapy

When I started this journey a few months ago, my entire YouTube feed became game development content. I immersed myself in design philosophy while coding, listening to creators like:

Thomas Brush (indie success stories and reality checks)
Jonas Tyroller (the science of game feel)
Aarimous (roguelike design deep dives)
Jackie Codes (Godot-specific wisdom)
DevWorm (practical indie dev insights)

Not tutorials, mind you. Working with the Fireship YouTube channel has taught me that tutorial hell is real, and most developers just need concepts, not code-alongs, something he does a great job at. I needed to understand how game designers THINK, not how they type.

Everyone kept saying the same damn thing: "Start small. Build Pong. Make a platformer."

But telling a seasoned developer to make Pong is like telling Gordon Ramsay to make a ham sandwhich. Sure, I could do it, but what would I actually learn?

Dungeon Supply Co: My "Small" Game That's Actually Perfect

Instead of abandoning everything like so many times in the past, I started designing a new game specifically to teach me what I didn't know: Dungeon Supply Co.

The premise?
We've all crawled our fair share of dungeons, right? We grind and grind for gear, pots, and food for hours before finally attempting the dungeon. How the hell do the dungeon NPCs always have everything that they need??
You're enslaved by an asshole orc who forces you to run a factory that supplies dungeons with everything—swords for skeletons, potions for bosses, and yes, all those ceramic pots that heroes compulsively smash.

It's automation meets subtle dark humor and a bit of irony.

More importantly, it's designed to force me to learn:

State Management: Hundreds of items on conveyor belts without melting CPUs
Game Feel: Making automation satisfying (that sweet, sweet production line dopamine)
Art Pipeline: Expanding on Mwaayk's excellent 16x16 automation pack with my own sprites
Scope Control: 4-8 week timeline, not 4-8 years of development hell
Player Psychology: What makes "just one more production line" addictive

Why This Actually Works

Building an automation game teaches fundamental game development skills without the complexity of combat, multiplayer networking, or making sure your netcode doesn't let players phase through walls like interdimensional ghosts.

The technical challenges are real (managing thousands of moving items at 60 FPS), but bounded. The design space is constrained but meaningful. Most importantly, it's a game I'd actually want to play while procrastinating on building my actual dream game.

The Developer's Paradox: Failing Up

Here's what nobody tells you: As programmers, we're trained to build incrementally. We start with "Hello World," not "Let's rebuild Google from scratch." But the moment passion enters the equation, we immediately try to build our own GSuite replacement for enterprise customers.

My MMORPG isn't dead. In fact, working on Dungeon Supply Co. has made me MORE excited about Thundoria, not less. Every system I implement teaches me something I'll need. Every optimization technique, every player feedback loop, every scene implementation, it's all training for the main event.

The Real Lesson: Your Dream Game Needs Practice Games

If you're a developer sitting on your own "dream game" idea, here's my advice: Don't abandon it. Orbit it.

Build smaller games that teach you specific skills you'll need. Want to make an RPG? Build an inventory system game first. Dream of a shooter? Start with a wave defense game.
Think of it as building your own curriculum where every assignment directly contributes to your final project, except nobody's grading you and you can drink while doing it.

Join Me on This Beautiful Disaster

I'm documenting everything—the successes, failures, and the times I spent 6 hours debugging only to realize I spelled "strength" wrong. Thundoria is still happening, and I'm trying to build it in public because apparently I'm a masochist.

The game design is stupidly ambitious:

Roguelike extraction mechanics where you gamble progression like a degenerate
Bullet-hell combat that scales from "tutorial grandmother" to "what the fuck is happening"
"Just one more floor" addiction that ruins friendships
No pay-to-win BS, just honest "give me money for cosmetics" capitalism

Meanwhile, Dungeon Supply Co. is teaching me how to actually deliver on that vision without having a complete mental breakdown.

Want to watch this slow-motion catastrophe?

Sign up for development updates at thundoria.com
Watch me learn game dev fundamentals the hardest way possible
Get early access to both games (whenever the hell they're ready)

The Bottom Line

Every game developer is right: don't build an MMO as your first game. But also, don't let your dreams die in a folder called "maybe_someday_projects_final_v2_actual_final."
Instead, be strategic. Build towards your dream, not away from it. Learn in public. Fail spectacularly. And remember—even the creators of World of Warcraft probably started by spawning themselves max cash stacks in someone else's terrible code.

Although... how can I expect you to listen to me? I didn't listen, and honestly, I don't really expect anyone else to either. I'm just a guy with a dream and a tendency to overcomplicate things.

Now if you'll excuse me, I have some conveyor belts to optimize. These skeletons won't arm themselves, and my orc overlord is getting bitchy.

Links

Are you also building a game way above your skill level? Learning game development after years of "real" programming? Let's suffer together!
Follow the journey at thundoria.com and let's fail upward as a community.

I post about my progressions sometimes on Bluesky and X / Twitter as well.

I Let Amazon's AI Build My Game for 3 Days. Here's What Happened

Tony Costanzo — Tue, 17 Jun 2025 17:08:56 +0000

Originally published at techhivelabs.net

TL;DR: Built a working roguelike with Amazon Q in hours. It was amazing until it wasn't. Enemy projectiles broke me. AI coding is powerful but not ready to fly solo yet.

🎮 Try the Game | 💻 GitHub Repo

The Setup

When Amazon threw down the gauntlet with their AI coding challenge, I couldn't resist. The mission? Build a browser-based game using their new AI assistant, Q. As someone who's been curious about the current state of AI-powered development, this seemed like the perfect opportunity to push the boundaries and see just how far we could go with "vibe coding" - that magical state where you describe what you want and the AI makes it happen.

My weapon of choice? A fresh Nuxt.js project, my go-to framework for web development. I fired up Tabby and was pleasantly surprised to see Q integrate seamlessly with it - I'd half expected it to only work with the built-in terminal. While I noticed Q only offered Claude models (no complaints there, it's my LLM of choice anyway), I was ready to embark on this adventure.

First Contact: Setting Expectations

I started by spitballing a rough idea for a roguelike game:

The initial response was... well, exactly what you'd expect from an eager AI assistant - way too affirmative. I don't need a yes-man; I need honest feedback and alternative suggestions!

After some gentle encouragement (okay, I may have talked some shit to the LLM), I finally got the honest feedback I was looking for. Be careful what you wish for, though - the reality check was humbling!

Finding the Perfect Assets

Before diving deeper, I needed some visual assets. I stumbled upon an absolutely gorgeous asset pack on itch.io by Trevor Pupkin - affordable, high-quality, and perfect for the cyberpunk roguelike vibe I was going for. I dropped it in the root directory and asked Q for its honest opinion about our game design and timeline.

Okay check out the asset pack in q-roguelike/TechDungeonAssets I really like this and think we could build a simple roguelike.. We can just do projectile combat, no building.. we can have upgrades like speed, multi projectile (adds +1 at a slight angle each time), health, fire speed, exploding bullets, etc.. We can keep it simple enough I suppose. What do you think about game engine with this design? is it doable in our timeframe? again dont just reaffirm, give honest feedback

Q suggested we should just yeet a 2d canvas and start building on that. I was certainly hesitant about that considering all of the helpers libraries like Phaser or PixiJS gives us..

The First Attempt: A Comedy of Errors

The "actual" first attempt was... let's call it educational. The code was non-functioning, mixing Vue 2 Options API inside a Vue 3 Composition API script block. But hey, I was being intentionally vague with my requirements, so I can't blame Claude or Q entirely. One prompt later pointing out the issue, and we had our first error-free pass.

Well... it was something:

I'm still not entirely sure what I was looking at, but asking an LLM to parse multiple spritesheets and properly set up sprites with animations is admittedly a tall order.

Before diving into fixing the sprite issues, I noticed Q had done something quite thoughtful - it had taken all the assets I'd dumped in the root directory and organized them nicely in the public folder. Small wins!

The TexturePacker Breakthrough

Then I thought of a way to give more image context.. the TexturePacker app outputs JSON data alongside its spritesheets. If I gave each image and animation a descriptive name, Q should be able to parse and use them correctly... right?

RIGHT!

Suddenly, we had a working run animation and projectiles firing in the direction of my mouse! Sure, my character wasn't facing the right direction and the projectiles were angled incorrectly, but this was genuine progress. This was the point where I thought I'd need to take over completely, but I was curious to see how far Q could go.

Building the Core Game Loop

Instead of getting bogged down in perfectionism, I asked Q to outline the next steps:

Q provided a solid roadmap:

## Priority Order:

1. Collision & Combat System
• Projectile-enemy collision detection
• Enemy health and death
• Basic enemy AI (move toward player)

2. Wave System
• Spawn enemies in waves
• Wave progression with increasing difficulty
• Wave completion detection

3. Roguelike Upgrades
• Upgrade selection screen between waves
• Core upgrades: damage, fire rate, health, speed, multi-shot
• Persistent upgrade effects

4. Game State Management
• Health system for player
• Game over/restart
• Score tracking

Implementing Combat

Starting with collision and combat systems, I prompted: Okay let's go in order! We can go ahead and implement the projectile hits, enemies chasing, health system, and death animations!

The first attempt introduced some bugs - I couldn't shoot and spawned with 0 HP. By the time I died, my health was between -5 and -10. Classic game development!

One clarifying prompt later: I'm ready to move on but we do have some issues. I'm not able to shoot but I think it may be because I spawn with 0hp and by the time I die, my hp is -5 - -10.. I think we need some delay between death and restarting so that the death animation can play as well. Finally I see a lot of warnings in the console from the animation manager stating that our animation keys already exist.. Are we reinitializing these unnecessarily?

And just like that, we had a functioning combat system! Complete with health management, incremental damage, immunity periods, and even a score system:

Code Quality Check

At this point, I hadn't really examined the code beyond fixing that initial Vue 2/3 issue. I was expecting a thousand lines of spaghetti. To my surprise, we had only ~450 lines of surprisingly clean code. All in a single component (not ideal, but workable), including ~20 lines of CSS and 10 lines of templating. The JavaScript was well-structured, without duplicated logic, and documented concisely - not in that typical verbose AI fashion. Color me impressed!

The Wave System

Next up: the wave system. One prompt. Just one prompt, and boom:

I was genuinely impressed at this point. We had a working wave system with progressive difficulty in a single iteration.

Hitting the Wall: Context Limits and Collision Detection

The next challenge - implementing the upgrade system and tilemap collision - is where things got rocky. Q struggled. Hard. My codebase ballooned from ~500 lines to about 1,000 lines. Despite having all the tilemap data in JSON format, Q couldn't get the collision layers working properly.

It loaded the map and registered all the layers correctly, but when it came to setting up collision detection, we went in circles. Q eventually decided that Phaser's built-in collision system was broken (spoiler: it wasn't) and attempted to write its own per-tile collision system. Yikes.

I tried to guide it back to using Phaser's built-in features, but we'd hit the classic AI coding limitation: context window exhaustion. Under 1,000 lines of code and we were already having fundamental issues. Q started creating basic TypeScript errors that prevented the page from running entirely.

Recognizing the signs, I asked Q to strip out all the collision work so I could handle it myself. I created a git commit (should have done this earlier!) and prompted Q to create documentation to maintain high-level context.

Taking Back Control

I performed a major refactor, splitting the monolithic component into separate TypeScript files and Phaser scenes. With the help of Ourcade TV's excellent YouTube tutorials, I implemented proper collision detection myself.

This created a new problem: the basic straight-line enemy AI couldn't navigate around walls. Time to see how Q handled pathfinding:

Well... the enemies were certainly moving, just not in any useful direction. When I clarified that I needed proper pathfinding, Q implemented A* pathfinding with heuristic functions for 8-directional movement. The first attempt was too precise, causing enemies to overshoot waypoints and backtrack:

But third time's the charm! In just three prompts, Q had implemented fairly sophisticated pathfinding:

Pushing Forward and Finding the Limits

At this point, we'd essentially completed the original goal, but I was feeling inspired. I've had this concept for a browser-based MMO/roguelike hybrid brewing for a while, and this seemed like the perfect opportunity to explore it further.

I took more control from here, using Q as a coding assistant rather than the primary developer. We added more enemy types, complex wave patterns, tiered upgrades, and other roguelike elements. But the final straw? Enemy projectiles.

Getting enemy projectiles to move correctly, deal damage, and not freeze the entire game took over 10 prompts. I never successfully got Q to implement this feature without game-breaking bugs.

The Verdict: Impressive but Not Ready for Prime Time

Let me be clear: I was genuinely impressed with how quickly Q created a functioning game that felt like a real project worth iterating on. The initial results had me excited about the possibilities of AI-assisted development.

But here's the bottom line: I ended up with a pile of unfamiliar, difficult-to-maintain code with a clunky development pattern that I didn't want to continue building on.

As a reasonably experienced developer, I had to guide Q toward correct solutions fairly early in the process. I'm not confident that less experienced developers would be able to provide the same guidance when things go sideways.

This isn't really a criticism of Q specifically - it's more about the current state of AI coding assistants in general. Language models will undoubtedly improve, but will we ever be able to go completely hands-free on larger projects? I doubt it. Context windows need to expand dramatically, and tools like Q need more sophisticated agentic processes to prevent the accumulation of "AI slop."

Final Thoughts

I'm glad Amazon put this challenge out there. It gave me a valuable opportunity to assess the current state of AI coding assistants in a real-world scenario. The technology is impressive and shows tremendous promise, but for now, I'll stick with using LLMs through web interfaces and copilot-style IDE extensions for specific tasks rather than full project development.

I'm not quite ready to hand over the reins completely - but I'm excited to see where this technology goes. The future of AI-assisted development is bright, even if we're not quite there yet. Who knows? Maybe in a year or two, I'll be writing a follow-up post about how I built an entire MMO using just voice commands and interpretive dance.

Until then, happy coding - whether you're doing it with AI assistance or good old-fashioned keyboard mashing!