Last time I wrote here, I had taken the enterprise AI SDLC I build at work, shrunk it down to one repo and two slash commands, and used it to ship Colors Grid. The conclusion was that the pipeline scales down, and that the discipline is worth the tokens.
So this time I ran the opposite experiment.
What happens if I use no process at all? No PRD. No specs. No review chain. No planning phase worth the name. Just me and a prompt, changing my mind whenever I felt like it, for as long as it took. I wanted to know how far pure prompting gets you on something genuinely big, and what the bill looks like at the end.
The thing I built is Jazz Paws: a lofi cat band that walks a hundred places drawn from real Southern California, fifty cats each with a skill nobody else has, three parts of story across 390 levels, and thirteen machines to get past.
I did almost no planning. I had a feeling I wanted (chilled, cute, easy to pick up, with somewhere to go if you want to get good) and basically nothing else pinned down. No design doc. No scope. I would decide what the game was while building it, and I would change my mind constantly, because that is the honest version of how a person builds something they have not fully imagined yet.
I expected that to be expensive. It was.
The development cycle was long. Much longer than Colors Grid, and not because Jazz Paws is four times the game, though it is. It was long because I kept rebuilding things I had already built.
Every time I changed my mind about how a place should work, or what a cat should do, or how the party should be arranged on screen, that decision rippled through code that had been written under the old assumption. With a PRD and a spec, that ripple gets caught on paper, where changing it is free. With pure prompting, it gets caught in the code, where it is not.
And the tokens. A lot of tokens, on work that got thrown away. That was the predicted cost and I paid it in full. If you want a number that matters more than the token count: entire features were built, lived for a week, and were deleted because I had moved on. That is what no planning phase buys you.
None of that surprised me. Here is what did.
I assumed the hard part would be getting a hundred places and fifty cats to exist. It was not. Getting things to exist is the thing prompting is genuinely great at. Give it a clear enough description of a new place and it will build you one.
The hard part was everything after that. Once the game existed roughly the way I wanted it, I spent what felt like the majority of the project on the part nobody sees in a feature list: making it feel good.
Making the moment-to-moment feel sharp is a stream of tiny adjustments, and there is no prompt for "make this fun." How far a dash carries you. Whether it stops dead or settles. How long a crouch holds you before you can stand out of it, and whether standing needs a swipe or should also accept a plain tap. Every one of those is a five-minute change and a twenty-minute argument with yourself about whether it is actually better.
You cannot outsource that judgment, and you cannot batch it. You play, you notice something is off, you nudge it, you play again. Multiply that by every verb in the game.
A hundred places, each one supposed to look like somewhere real and feel different to walk through. This is where AI struggled most, and where I spent the most back-and-forth by a wide margin.
Describing a place in words is not enough to get a place that looks right. "Chinatown at night" gets you something generic. What actually worked was going and finding reference images of the real street, feeding those in, and then iterating on the result over and over: this roofline is wrong, these buildings are too uniform, the far plane is too bright, this reads as a wall instead of a street you can walk into. Dozens of rounds per place, on some of them.
The lesson underneath it is that visual judgment does not transfer through a text prompt. You have to look at the thing, decide what is wrong, and say so specifically. Repeat until it stops being wrong.
The thirteen machines were their own problem. A machine has to be legible at a glance, has to telegraph what it is about to do, and has to look like it belongs to the place it appears in. Getting one to read clearly on a phone screen, in motion, is a very different task from getting it to exist.
And then the readability work underneath everything: making sure hazards are visible against a busy backdrop, that obstacles do not disappear into the art, and that the player gets enough visual feedback to know what just happened to them. A game where you lose a heart and cannot tell why is not a hard game, it is a broken one. A lot of the late project was spent making the game explain itself.
Two examples of what unplanned building actually leaves behind, both of which I only found by looking at the screen.
The first: a call that builds a colour gradient with the wrong number of colours. It type checks. The analyzer says nothing. But it throws at render time, and because it threw inside a layer that draws below the cast, everything above it silently stopped drawing. Obstacles, hazards, mounts, the cats themselves. The game kept running and the interface stayed live, so it did not read as a crash. It read as the band vanishing. That shipped through two transitions before anyone traced it.
The second: five different vehicles where the cat riding them was not actually on them. A cat fifteen pixels below its own pedals. A shopping cart being pushed by a cat standing in the road. The cause was the same each time: instead of asking the vehicle where its seat is, the code re-derived the position from two public constants. Which type checks, and which the analyzer is perfectly happy with.
Both of those are exactly the class of mistake a spec-and-review pass catches for free, and exactly the class that pure prompting will happily produce all day. I ended up writing two narrow checks that grep for the specific wrong shape, because that was cheaper than being careful forever.
The experiment answered its question. You can build something genuinely large with nothing but prompting. It works. It also takes far longer than it should and wastes a great deal of work, and the failure mode is not that the code does not run. It is that the code runs and looks wrong, and only your eyes can tell.
So the next project gets planned properly. Not a heavyweight process for its own sake, just an actual think about what the thing is before I start asking for it. And once that planning is done, it goes straight back through the SDLC, because everything I learned shrinking that pipeline for Colors Grid still holds: for scoped work where I know what I want, the pipeline pays for itself every time.
The honest summary is that prompting is a superb tool for building and a poor one for deciding. Jazz Paws is the proof of both halves.
You can play it at techtiger.tech/jazz-paws-home.
