Most game playtesting ends with a list of grievances. Players run into frustration, someone writes a report or logs a bug, and the notes sit in a backlog waiting for a developer to figure out what numbers to tweak. While building Agency Lab, my advertising-agency simulator, I wanted to see if that loop could move faster: letting simulated personas turn their own critiques into concrete design proposals, write the code changes, and test the game again.
From complaint to proposal
In an earlier post, I wrote about turning Steam reviews of comparable games into player personas—like an optimizer chasing efficiency or a casual player easily overwhelmed by micromanagement. Running these personas through scripted simulations gives me measurable trajectories: cash reserves over thirty turns, employee turnover, client retention, and where runs run out of momentum.
The interesting step is moving from measurement to a design proposal. Instead of simply logging that a run failed, an evaluator evaluates the run against the persona's priorities. If an optimizer persona repeatedly stalls in the mid-game because hiring costs spike unpredictably, the evaluator formulates a structured change: clarify the hiring fee breakdown, add a runway forecast, or adjust how lead channels scale. Because the proposal is grounded in a recorded trajectory rather than a vague impression, it arrives with a clear hypothesis to test.
Carrying proposals into code
Once a proposal is shaped, it moves into an automated implementation loop. I review the proposal to decide whether the design direction makes sense. If approved, it is handed to a coding agent that creates a branch, implements the mechanics, writes regression tests, and opens a pull request.
In practice, this loop has already produced real changes in the simulator. When personas struggled with unpredictable project margins, the pipeline proposed and built timesheet playbooks to let agencies set clear billing rules. When late-game agency growth lost dramatic tension, the pipeline proposed steerable lead flows and transparent pitch odds so players could take calculated risks rather than wait out a timer.
Having a coding agent draft the implementation changes the feel of development. Instead of spending an afternoon hunting down balance formulas in spreadsheets and wiring up UI panels by hand, the proposed mechanics arrive ready for inspection. The critical boundary remains: the agent never merges its own work. I review the pull request, check the code and tests, and decide whether the change belongs in the game.
Verifying the fix
The loop is only meaningful if it can check its own work. After a pull request is prepared, the same persona playtests run again across the same random seeds to compare the before-and-after trajectories.
This second pass is often where the real learning happens. Sometimes a change solves the optimizer's complaint but introduces a new failure mode for casual players, or turns a tense financial crunch into a boring surplus. Seeing the comparative replay makes those trade-offs visible immediately, long before real players ever see the build.
Where it leaves me
What excites me about this experiment is how it changes my role as a designer. I spend less time manually tweaking isolated variables in code, and more time defining the player personas, evaluating proposals, and judging whether the game feels right. Closing the loop doesn't remove human judgment from game development—it gives that judgment better evidence to work with.