Promotion Simulator
The Only Honest Answer Was a Simulation
The Setup
A colleague asked: "What percentage of team members would reasonably be up for promotion at any given cycle?" The question came with 5 assumptions (competent team, invested leader, twice-yearly cycles, 1/3 step sizes) -- but Brian understood that with the vast complexity of this space it was not so simple as fixing a few variables and guessing. A rich set of variables could be explored with a simulation, and that's something relatively simple to build, and something his customers might find interesting.
Brian framed both the original question and his own analysis of each assumption, then declared the intent: "I want to make a minimalist static site reactjs calculator, but we have to explore the model first." A single average or formula would be dishonest. The only real answer was Monte Carlo -- model the variables, run 10,000 teams, show the distribution.
All three sessions happened on a single day (Feb 6), interleaved with other projects -- 61 project switches that day.
Session 1: Pure Planning — Feb 6, 07:47-08:30 | 45 min | 5 prompts | Model exploration, zero code
Zero Code, All Thinking
The entire session was model exploration. Not a single line of code was written.
Brian instructed Claude to create a CLAUDE.md file and set governance boundaries before any code: "I want really good tests co-located with the math. Once tests work, we don't touch them without discussing the reasons with me and getting permission from me."
Multiple plan rejections followed -- Brian used plan mode as a collaborative design space, not a rubber stamp. Session output: a shared mental model and the scaffolding for a detailed plan. No lines of code.
Session 2: The Big Build — Feb 6, 08:44-10:15 | 1.5 hours | 14 prompts | Full implementation, model interrogation, deepening
The Plan Drop
Brian arrived with a detailed implementation plan he'd written between sessions, covering: simulation model (agent skill matrices, 6 skill dimensions, growth formula, demonstration mechanics, promotion evaluation, attrition), Monte Carlo structure (10k teams), sensitivity analysis (tornado chart, 9 parameters), UX design (4 visualizations, presets, web worker), architecture (pure math/UI split), tech stack (Vite + React 18 + Tailwind + Recharts), and an 18-step build order.
He opened the session with: "Implement the following plan."
Claude executed the entire pipeline in one long run: types, constants, RNG, skill matrices, agents, teams, aggregation, simulation, sensitivity analysis, web worker, React hooks, all UI components, and presets. 40+ files created. Tests ran at each step.
While Claude executed the full 18-step build, Brian was working on other projects. He'd fire off the plan, switch away, and come back when Claude was done. When he returned at 09:21, the dev server was running and 75 tests were passing.
Model Interrogation
He caught leaked framing in the UI: "Don't write 'original question', remove the fact this was a question, map the case onto something generic sounding where it wasn't 'someone asked you'." Spotted a counterintuitive result: "Kind of odd, if I move cycles per year to 1 instead of 3, the % rate decreases, I thought it would increase."
Model Deepening
Brian requested variable skill growth rates: "different people grow at different speeds at different times, each person has a different pace and each month has a different modifier." Caught a copy detail: "Don't use emdashes in copy anywhere."
Claude proposed a Team Inspector feature for drilling into individual career progressions -- by preserving the random seed used in the simulation, any arbitrary team could be deterministically re-computed on-the-fly, avoiding the need to store 10k teams in memory. Brian: "yeah that's a cool idea actually. Build that." Per-agent per-cycle skill snapshots, progression tables, wired through the web worker.
Manager Modeling Escalation
Layered on bimodal attrition ("People who are looked over when promotion ready increases their chances of leaving multiple times") and lost-talent tracking. Session ended with Claude in plan mode, Brian rejecting the final edit -- he would write the plan himself between sessions.
Session 3: Manager Implementation and Validation — Feb 6, 10:16-12:39 | 2.5 hours | 7 prompts | Coaching strategies, calibration, deploy
Another Plan Drop
Brian arrived with another detailed implementation plan for manager modeling, bimodal attrition, and lost-talent tracking. Covered: 4 new parameters (managerDevelopment, managerAdvocacy, coachingStrategy, frustrationScale), 8 implementation steps, file change summary, verification checklist. Again opened with the plan as the prompt.
Claude implemented all steps: expanded constants/types, created coaching.js with 5 coaching strategies, wired manager effects into skill matrix / agent / team modules, added lost-talent aggregation, enriched the team inspector with attrition data, created ManagerControls UI, updated results displays and model assumptions, added 21 new tests. All 112 tests passed.
Model Validation
Brian shifted from building to validation: "I want to think through the quality of the model. Inspect it for logical correctness. When I open the page I see average promotion rate per cycle is 0.7%, I didn't do any thinking in any direction, is it reasonable for the defaults we have?"
Claude ran diagnostic scripts tracing numbers through the pipeline. Found: 0.7% is too low, median is 0.0%, bottleneck is baseGrowthRate=0.08 being too slow for Technical Execution skill thresholds. Also identified weak test assertions that would pass regardless of model correctness. Brian approved the fix: baseGrowthRate adjusted from 0.08 to 0.15, sensitivity parameters updated, weak test assertions tightened.
Deploy and Polish
Meta tags, OG image via Puppeteer screenshot. Brian asked Claude to check his Forgejo deploy script.
Final fix: "use Puppeteer. Something is wrong with the tornado rendering logic. Bars are not really centered. Let's fix that." -- Claude used Puppeteer for multiple rounds of screenshot-edit-verify to fix the centering.
What This Shows
Session 1 was 100% planning, 0% code. Brian wrote detailed implementation plans between sessions and delivered them as prompts. The plans were not vague specs -- they included file structures, build order, verification criteria, and parameter definitions. Brian's planning happened in focused bursts between context switches. The plan emerged from a ~45-minute dialogue, then Brian switched to other projects. When he came back, he provided the plan and immediately switched away again while Claude built everything.
Brian's first instinct on receiving a question was not "build a calculator" but "explore the model." He rejected Claude's simplifications ("too over-simplified") and demanded deeper modeling before any code existed. The product grew richer because Brian kept discovering new modeling dimensions while reviewing results -- manager coaching strategies, bimodal attrition, lost-talent tracking were not in the original plan.
"Once tests work, we don't touch them without discussing the reasons with me and getting permission from me" -- set before any code was written. Tests were locked governance boundaries, not just regression checks. When validation revealed weak assertions, that was treated as a model quality issue, not just a testing gap.
Model theory: "I think it is itself too over-simplified." Simulation logic: "is 0.7% reasonable for the defaults we have?" UI copy: "Don't write 'original question'." Typography: "Don't use emdashes in copy anywhere." Visual rendering: tornado chart bar centering via Puppeteer. Infrastructure: "nope none of that is a bug, it's actually what works."