July 20, 2026 · 9 min read
A practical workflow based on the creation of GitHits Agent Runner.
AI coding tools can turn an idea into a working prototype surprisingly fast. They cannot decide what deserves to exist, whether an interaction communicates the right idea, or when output needs a human hand. The useful skill is orchestration: reducing the idea, giving each tool the right context, grounding important decisions, testing the result, and applying manual craft where it matters.
GitHits Agent Runner is one example. It turns a common problem in AI-assisted development into an arcade mechanic: an agent runs while its token budget drains. Context coins the burn, hallucinations cause confusion, loops send the player backwards, and rate limits stop progress.
The workflow was hybrid — ChatGPT, Claude Chat, Claude Code, image generation, Illustrator, Photoshop, and GitHits. The first playable version took less than half an hour. Shipping the experience took several weeks. This guide explains the pattern behind that difference.
1. Reduce the idea to one clear promise #
Creative ideas usually begin larger than they need to be. Agent Runner started at 2:09 a.m. as a sprawling prompt: an 8-bit platformer, pick an agent, a draining token meter instead of a rising score, magenta coins that the burn, GitHits tools as rewards, a “loop hole” back to the start, and one control — jump.
Before any code, ChatGPT helped strip the platforming complexity that didn’t support the message. The useful reference was Google’s Dino game: one input and an immediately understandable loop.
The product idea became one sentence:
Better context helps coding agents waste fewer tokens and fewer runs.
That sentence translated into mechanics:
| Product concept | Game mechanic |
|---|---|
| Token consumption | A counter that constantly drains |
| Better context | Coins and tools that preserve tokens |
| Hallucinations | The character loses direction |
| Repeated loops | The player is sent backwards |
| Rate limits | Progress stops while tokens keep draining |
Define the promise before the feature list. If a prototype can’t express it with one core interaction, more features only make it harder to understand.
2. Give the prototype a boundary #
The first build had a one-day kill rule: if it was neither fun nor clear by the end of the day, it could be archived without guilt.
The implementation prompt was written like a small pull request. It stated the purpose — validate the core loop and the “better context = fewer wasted tokens” metaphor, kept extremely small, in hours not days — then the allowed scope and the exclusions:
ONLY IMPLEMENT:
1. Endless horizontal auto-run
2. Spacebar jump
3. Token meter draining over time
4. Magenta context coins
5. Three obstacle types
6. Game over
7. Restart flow
8. Minimal HUD
DO NOT ADD:
- menus
- character selection
- powerups
- achievements
- mobile support
- analytics
- sound
- particles
- settings
- leaderboards
- backend
Negative constraints stop a coding agent from building plausible features that miss the creative question.
ChatGPT suggested Vite, TypeScript, and Phaser 3. That recommendation was not passed directly into implementation: Claude Code first reviewed the plan and used GitHits to ground the stack against real projects and the repository’s constraints. Only then did the build begin.
Claude Code received the brief at 2:22 p.m. The prototype was playable at 2:45 p.m., and the first pull request was open at 3:52 p.m. Speed made the idea cheap to test. It did not make the result finished.
3. Direct the experience, not every line of code #
Once the prototype was running, feedback described what the player should see, understand, or feel: freeze the world so the hallucination can be read, make every obstacle jumpable, show tokens saved through context, make the loop look like a portal rather than a generic block.
The coding agent decided how; the creator stayed responsible for the behavior and meaning of the game.
The same holds beyond games: say what outcome is wrong before prescribing the fix, then inspect the result in its real environment. A compiling app is not a working experience.
Creative checkpoint: the prototype was ignored
The first gray-box version was shared internally with a short explanation. Nobody replied — no green light, no interest, no constructive rejection. It was completely ignored.
That silence almost ended the project. After nearly three weeks, the creator chose to continue it as a side project, without blocking product work or asking the team to invest.
The lesson is not to ignore feedback, but to know what was actually tested. The mechanic worked; the unfinished presentation still asked everyone to imagine the characters, world, tone, and connection to GitHits. Silence toward an incomplete expression of an idea is not always a verdict on the idea — sometimes the next useful test is a version that asks less of the audience’s imagination.
4. Create a grounded orchestration loop #
As the project grew, one prompt plus continuous implementation became too fragile. Agent Runner moved to a repeatable loop:
- Let the coding agent summarize the current repository and constraints.
- Use a conversational model to challenge the next feature and write a brief.
- Ask the coding agent to review the repository and ground the plan with GitHits.
- Revise the plan when real implementations reveal a better approach.
- Implement, test, and visually inspect the result.
- Play or use it, then direct the next iteration.
The recurring grounding instruction was deliberately simple:
Review the repo, but ground the planning with GitHits.
A chat model can propose a coherent architecture and a coding agent can implement it fast, but neither proves the plan matches the framework, package, browser, or repository in front of it. Grounding against real open-source implementations closes that gap — a checkpoint before consequential changes, not a rescue step.
Use it for unfamiliar packages, framework integration, browser constraints, or changes that are expensive to reverse — not for minor copy and spacing.
5. Combine generation with manual craft #
The art split across tools: generation for exploration, manual craft for production. ChatGPT and Gemini explored characters, portraits, and the logo; Illustrator and Photoshop produced the final sprites; Claude Code supplied technical constraints and integrated each asset.
The sprite sheets were not generated deliverables. They were drawn and refined by hand, using Mega Man sprites as references for pose, proportion, and movement. Run cycles, silhouettes, palettes, coins, and obstacles all got a manual production pass.
Before that work began, the coding agent returned an asset spec — frame sizes, hitboxes, tolerances — that went straight onto the artboard. Each finished asset was integrated by Claude Code and tested in-game before the next. Craft stayed at the center while AI reduced uncertainty around exploration, specs, and integration.
The process also made room for rejection. A synthwave perspective grid was built twice, then cut — it fought the sideways movement and competed with gameplay. Parallax mountains worked better. Generated output is a proposal, not a debt: delete it when it weakens the idea, even if it technically worked.
6. Ground the decisions that can quietly break the product #
GitHits was used again at several critical stages:
| Decision | Why grounding mattered |
|---|---|
| Character speed | Real speed differences required distance-based spawning, not time-based spawning |
| Astro integration | Phaser needed reliable mounting, cleanup, and navigation inside a static site |
| Social cards | The server-side image pipeline needed patterns that worked with the production architecture |
| Mobile support | Responsive sizing and touch input had to preserve reaction time and score comparability |
| Escape navigation bug | Grounding confirmed the Phaser keyboard pattern and helped eliminate the wrong hypothesis |
The Escape bug shows why. Pressing Escape destroyed the game but left the browser on an empty route. GitHits confirmed the Phaser keyboard approach was valid, narrowing the search to browser behavior: Escape can invoke “stop ” and cancel navigation fired in the same event. The fix prevented the default and deferred navigation. Grounding ruled out a false path and gave the agent better evidence to reason from.
7. Treat publication as a separate product phase #
A good prototype proves the central interaction. A public release has to survive everything around it: production art, music, tests, mobile input, responsive layout, analytics, reliable teardown, sharing, and a result screen that connects the score back to GitHits.
The result screen used three performance tiers and broke down tokens saved through context coins, Code Navigation, and Package Intelligence. A good run ended with “TOKENS WELL SPENT” and a real next step:
npx githits@latest init
Social sharing used a dynamic Open Graph scorecard. Because the Astro site was static, an Azure Function generated it with Satori and resvg — an approach grounded with GitHits first. Mobile required more than a touch handler: a narrower canvas cut reaction time, so the fix used a slight zoom-out, earlier obstacle warnings, and semantic actions such as JUMP
, START
, and EXIT
, also grounded with GitHits.
When the polished version was shared internally again, it drew an immediate response. The mechanics had improved, but the larger difference was legibility: nobody had to imagine the intended experience anymore.
8. Measure whether the idea travels #
Agent Runner was published at githits.com/agent-runner and shared with relevant communities.
On June 23 and 24, GitHits recorded its two highest daily unique visitor counts yet — 175 and 222 — driven mainly by new-audience Reddit traffic landing on the game. The numbers did not prove every visitor understood GitHits, but they showed a playable metaphor could carry the product idea beyond the usual explanation.
A reusable workflow for creative builders #
The Agent Runner process reduces to a practical set of rules:
- Define the idea in one sentence before defining features.
- Build the smallest version that can disprove the idea.
- Write prompts with purpose, scope, constraints, and exclusions.
- Direct outcomes and experiences instead of micromanaging code.
- Ground consequential plans with real implementations before building.
- Give generation, code, and manual craft different jobs.
- Inspect the result in its real environment and reject weak output quickly.
- Separate prototype success from production readiness.
Calling the result “AI-generated” would miss the point. Each system did a different job — coding agent, chat models, GitHits, generative tools, manual craft — and the creator’s job is to hold the intent across all of it.
AI tools make building faster. Grounded orchestration makes that speed useful.
Play GitHits Agent Runner and keep your own coding agent out of loops:
npx githits@latest init