My Game Said a Training Run Would Take Eleven Days. It Took One.

My game told the player a training run would take eleven days. It took one. Both numbers came out of my own code.

Scaling Laws has a model creator. You pick scale, data, compute budget, and the screen quotes you a training time before you commit money to it. That quote is entire basis for the decision, because the calendar is the resource the game is actually about.

Here is how the projection computed days:

days = petaflop_days / throughput

where throughput included a precision multiplier. FP32 is slower than FP8, so the multiplier matters.

Here is how the daily tick computed progress:

progress += base_rate * founder_skill * team_utilisation

Notice what is missing. Tick never multiplied by precision. And it applied two bonuses the projection had never heard of.

Two formulas producing one quantity. Nothing in the codebase compared them. For weeks.

The lesson is structural

Lesson is not "I made an arithmetic mistake". Its structural: if the same quantity is calculated in two places, that is not duplication. It is a future disagreement with a date on it.

So I pulled both sides into one function, TrainingThroughputMultiplier(), and both callers now ask it. Not because it is tidier. Because now they cannot drift.

And then the fix broke the game

With training time finally telling the truth, FP32 precision started to actually cost calendar days. A company with no research was training at 0.55 throughput inside an economy balanced for 1.0. A permanent forty-five percent penalty that nobody had decided to apply.

I found out within a minute, from a test I wrote weeks earlier. It plays a full fourteen-year campaign on every seed, and it went red with an assertion message I had written myself months ago:

"That is not difficulty, it is an unwinnable game."

Fixing the lie required re-anchoring the entire precision ladder so that what a player gets for free sits at exactly 1.0.

Three things I would hand to anyone building a simulation

• One. A test that plays the whole campaign is worth every second it costs. It is the only thing that catches "correct code, broken game".
• Two. Whatever the player has before doing anything must be your baseline. Not what is typical, not what is default. What is free.
• Three. Fixing a real bug can break your balance, and that is normal. What is not normal is learning about it from a player.

I have made this exact class of mistake three times now. Three times a test caught it in under a minute. That ratio is the only reason I can move this fast on my own.

What is the longest two parts of your code disagreed about the same number without either of them crashing?