Keeping the project out of vibe coding

Wreckwing is built almost entirely by Claude Code sessions. I design the game, direct the work and play it. I don’t read the code. On October 10 the game’s repository took more than 26,000 new lines in one day, and no one read them line by line.

Vibe coding usually means accepting what an AI writes without checking it by any means. By that definition this project isn’t vibe coding. Every piece of work starts as an issue with a stated condition for when it’s done, changes are judged by measurement, and when two fixes for enemies hitting walls made the numbers worse, we took them out. But speed makes it easy to drift. When the checking is done by tests and by play instead of by reading, anything the tests don’t measure goes unchecked. On October 11 I found out how much that could hide.

Recognizing the drift

Every enemy pilot in the game has a personality: how aggressive it is and how cautious. Personalities were drawn for every enemy and written to the logs. But only the experimental trained pilot read them, and the game flies the scripted one. For a week, every enemy in a level flew the same way, and nothing failed. We found it while measuring why enemies so rarely boosted or chased (Enemies weren’t using everything their ships can do). Code that nothing reads looks alive and isn’t.

That led to a review of the game’s sessions from September 29 to October 11. It found a pattern:

• About 15 issues had been closed as fixed and then seen again in play. Enemies spawning inside buildings had been closed three times. Floating rubble was closed with 8 pieces left, and a replay eight hours later held 72. The minimap closed on a test render that came out blank, then crashed on another Mac.
• Some problems took many rounds of fixes before they were solved or set aside: floating rubble 6, wall bumps 6, stalls in large cities 5, the water splash 4. Four stills the sessions had approved themselves turned out to be wrong.
• Of ten notes from a side session over three days, six were knock-on effects of a change that nobody had raised. Doubling ship toughness also halved what a falling building did to a ship, night arrived in one city in four with no way to turn it off, and cars skated across the new ponds.
• I was asked about 36 questions on one evening, and about 15 of them didn’t matter to me either way. On October 11, 33 issues sat waiting for me to play them.

None of that is accepting code without checking it. It is checking that had gaps, at a speed where the gaps added up.

What I had to change

These went into the game’s rules on October 11:

• Every feature gets a test that it changes behavior. The test runs the game with the feature and without it, or at two settings, and checks that what a player would see differs in the expected direction. A test that only shows the code runs doesn’t count. For the personalities, aggressive pilots now have to deal more than twice the damage cautious ones do. This rule came from an outside reviewer’s suggestion.
• A problem I report closes on my own case. My flight, my city or my scene is kept in the repository as a test that fails before the fix and passes after. Without it, the fix is called unconfirmed, the issue stays open with a “Needs play” label, and it goes on my play checklist.
• A smoke test before anything a player reaches is closed. A clean build of the game flies a run level, the sandbox with a wave of enemies and wave defense, with no one at the keyboard, and reports spawns, frame rates, the HUD and crashes.
• Two attempts, then measure. After two failed fixes for the same problem, the next step is a measurement that isolates the cause and a research pass, not a third fix. On visual work, a separate model that didn’t make the change compares the stills with reference photos.
• Check the consequences of shared numbers. A change to a default or a balance value is run with and without it first, and its effect on the rest of the game is counted.
• Fewer questions. At most five at a time, each with a recommendation. Anything waiting on my play goes on one checklist a session, where I mark each item and the sessions read my verdicts back.

How it’s working

• The night glow. Measuring the new neon city showed the same number of bright pixels by day and by night. Every glow had been clipped at the brightness of its own color, so the night lighting we had designed had never reached the screen. It was the same kind of failure as the personalities, found the same afternoon the rules went in. A test now checks it: a lit sign cabinet went from 2 bright pixels to 902.
• Enemies inside buildings. On October 14 I flew into a city where an enemy started inside a building. This had been closed as fixed three times. The two-attempts rule meant the next step was a measurement. The flight recordings showed 5 of the run’s 19 enemies starting at exactly 158.4 m from me, the distance the game’s unchecked fallback uses. Rebuilding my city without a screen found the cause: the elevated freeway counted as one box around the whole road, 502,000 m², and every spawn point not near me lay inside it. Now each piece of road has its own box. My city keeps 37 of 160 spawn points open, where it had none, and it is kept as the test. The smoke test had flagged the same problem in two other modes that night. Once those spawns worked, it caught a new one: a fighter warping in on top of a drone.
• The house windows. An issue about breakable house windows and doors stayed open because one part, a warehouse door, couldn’t be reproduced without a screen. Before, it would have been closed. It closed after I confirmed it in play.

The first play-through under the new rules was on October 14. I flew 31 items on the checklist, and 22 held up. Of the other nine, seven were design and tuning, such as more impact for ship deaths and a role for the Sniper. Enemies flying into walls was better but not gone, and lit windows that change as you approach a building were a new defect. Separately, one old fix came back: the spawns above, closed three times under the old rules.

Still unproven

This is one play-through against two weeks of history. The count that matters is how many fixes come back over the next several play-throughs, against about 15 in the first two weeks.

The rules also missed something. Two enemy kinds, the Bruiser and the Dozer, were built to fight up close. In my play they seemed to do nothing. A measurement found they did fight, but their guns did the least harm of any enemy. The balancing tests hadn’t flagged it. It was found two days after it was built, where the personalities took a week, but it was found by me in play, not by a test. The fix also went in without my flights kept as its case; a measurement stood in for them. Pitting a dodging test player against eight enemies has the numbers.

Some of these rules are enforced by scripts, such as the commit checks, the smoke test and the release gate. Most are followed by the sessions because they are written down, and nothing stops a session from skipping one. The checklist and the closing comments are how I see whether they did.

I’ll write again after more play, with the number of fixes that came back.