Video summary

My New AI Workflow

Main summary

Key takeaways

Technology

Overview

The video demonstrates a creator’s end-to-end workflow for using an LLM to develop and change game code while “walking it forward” in controlled steps—especially useful when traveling without reliable keyboard/service.

Core concept: “6 phase” (described as up to 7, with phase 0)

The speaker’s method is an LLM-assisted programming process with strict gating: the creator decides when the project can advance based on whether the generated artifacts look correct.

Phase 0: Research / plan

  • Do research
  • Produce a plan for phases 1–6

Phase 1: Create structure definitions

  • The LLM outputs data structure definitions first
  • Human reviews and provides corrections
    • This is doable even from a phone

Phase 2: Implement the project tile / API layer

  • The LLM generates the API/builds the skeleton interfaces/functions
  • The human constrains scope (e.g., “don’t add things we don’t need”)
  • Emphasizes incremental changes, one step at a time
  • Toolchain mention:
    • Cursor (noted as an iOS-only preview app / Cursor only on iOS)

Phase 3: Generate to-dos

  • The LLM produces a list of to-dos describing exactly where code must change
  • Human iteratively updates/removes incorrect to-dos while reviewing

Phase 4: Implement + test in “JSON mode,” then revert with diagnostics

  • The LLM implements changes based on the to-dos and data structures
  • Uses a custom “JSON mode” test/run method:
    • Runs the full game without rendering
    • Instead processes events/UI interactions via JSON
  • After running:
    • The LLM reports where it could not implement without deviating from the to-dos (“break path” points)
  • Then the workflow undos/reverts changes so the creator stays in control

Phase 5: Add invariance

  • The speaker notes LLMs are bad/hard at invariance in this context
  • They couldn’t get it to behave well

Phase 6/7: Finish and implement the final working game

Progression only happens when the human verifies:

  • data structures look right
  • interfaces look right
  • to-dos look right
  • implementation respects constraints

Key philosophy emphasized

  • The LLM should not do more than requested
  • Agents/automation can generate “horse crap” if left unconstrained
  • The human remains responsible for reviewing and approving each phase

Technical feature: “JSON mode” for deterministic game testing + replay

A major technical element is a custom testing harness that can run and validate game changes automatically.

How it works

  • Uses a CLI/workflow that runs:
    • odin.run ... JSON mode
  • In JSON mode, the game can:
    • accept mouse events / UI interactions encoded in JSON
    • run a complete simulation loop
    • record JSON output to a file for replay

Analogy given

  • The speaker compares it to a Playwright CLI for game dev:
    • drive the UI
    • simulate thousands of games
    • gather results (e.g., win rates / card usage)
    • inspect strategies

Why it matters

  • Used to verify LLM-made changes (especially in phase 4) by running the game automatically and checking behavior.

Example refactor: static enemy arrays (game-mechanics driven change)

The speaker provides a concrete gameplay-related refactor example.

Change made

  • Switched enemy storage from a dynamic array to a static array with a max enemy count
  • Instead of removing dead enemies:
    • enemies are marked with state (dead + timestamp)
    • enemies remain in the array for animation continuity

Rationale

  • Needed to keep enemies around for death animations
  • Removing breaks update continuity for animation/behavior

Resulting logic pattern

  • Game logic uses an enemy count and checks each slot:
    • whether the enemy is “finished/dead” vs still active
  • Similar approach for:
    • projectiles
    • towers

Product/workflow: “55” for quick-change iteration (git worktrees + “inspect”)

The speaker introduces a second system (named 55).

What “55” does

  • Manages a list of “projects”
  • Automates the planning/generation process for them

How changes are managed

  • Uses git worktrees to isolate in-progress changes
  • Runs a command like inspect, which:
    • takes git hunks
    • creates a quick fix list so the creator can review each generated change easily
  • Demonstrates handling conflicts and getting the game working after applying/refining generated changes (e.g., “damage to player when enemy gets to end”)

Release/loop improvement goal

  • Wants a more seamless loop:
    • work tree locally
    • potentially later “handoff to cloud” so work can continue on a phone

Testing / verification approach

  • Some targeted tests (e.g., layout/animation)
  • But relies heavily on:
    • JSON mode full-game runs
    • event replay + stepping
    • phase-based revert/diagnostics rather than large traditional test suites

Performance note

  • The JSON/game loop runs extremely fast locally
  • The speaker mentions absurdly high frame rates / very fast loop execution

Availability / release intent

  • Earlier public AI library: 99 (SNIPER-style gun naming theme)
  • 55 is not released publicly yet because the speaker is still deciding if it’s “the right choice.”

Names and sources mentioned

  • Adam C. Younis: credited as a pixel artist (used for artwork/assets; the speaker says they didn’t use AI for assets)
  • Cursor: mentioned for coding assistance, with iOS preview context
  • Speaker’s systems:
    • Odin
    • JSON mode
    • 55
    • earlier 99 library

Main speaker/source: the creator demonstrating their “6/7 phase” workflow and game/testing system.

Original video