I build my game with coding agents. The scarce resource is the decisions I still have to make.
A solo developer is building an AI-driven life simulation game where AI agents write the code, and the developer focuses on product direction and technical decisions. The project currently involves approximately 168k lines of backend Python, 108k lines in frontend source files, and 95k lines in backend tests. This approach helps manage the growing repository, with the developer emphasizing that the scarce resource is the decisions they still need to make.
Time & source
- Published
- 09/08, 17:27 UTC+0
- Ingested
- 09/09, 17:00 UTC+0
- Source type
- Dev community
- Tier
- Community
- Source status
- Healthy
Tier is a per-source editorial setting, not a per-item score.
Discussion trend
The percentage is based on collected discussion signal, not new comments or independent people. The curve only compares the same topic across time.
I'm a solo developer building an AI-driven life simulation game. AI writes the code; I decide the product direction and make the technical calls. The part I want to share is how I keep that arrangement manageable as the repository grows.
For scale, my current checkout has about 168k lines of backend Python, 108k lines in the selected frontend source files, and another 95k in backend tests. Those are text-line counts including comments and blanks, not SLOC or a productivity benchmark. More code can also mean more maintenance.
My biggest constraint is how many decisions stay in my head after a task ends. Here are the concrete conventions I use:
Route context by the task. The root AGENTS.md is a map of responsibilities and reading requirements. Changing the simulation loop points to its runtime contract; changing UI points to frontend conventions. Local instructions live beside their modules. I don't ask every task to digest every historical document.
Separate decisions from implementation. I keep a document of product and collaboration decisions, including rejected directions. Code and schemas describe what exists. Active contract documents describe what should be true. If they disagree, the agent has to show the conflict; silently declaring either one obsolete is not a resolution.
Make repeated corrections executable where possible. My frontend has checks for design tokens and UI structure, plus generated protocol checks. The benefit is that the next task can discover a violation from tooling instead of requiring me to remember the last conversation. These checks don't decide whether the design is good.
Define completion beyond the diff. Behavior-changing work needs an expected outcome, a data source and time window, a pass criterion, and a follow-up schedule. A merged change and a verified effect are separate claims. A check that was skipped remains skipped.
One less comfortable rule: when a mechanism needs a second layer of patches, pause and ask whether it should still exist. AI can keep making a local solution more elaborate while leaving me with a system I no longer understand.
Compared with keeping instructions only in chat, the tradeoff is maintaining these repo contracts. They can become stale too. I don't have a controlled before/after measurement of time saved, so I'm sharing the workflow rather than a speedup claim.
For people maintaining larger projects with coding agents: which repeated human correction have you successfully moved into a check, and which still needs your judgment?
Disclosure: AI-assisted writing, based on my actual repository and development decisions.