Morning starts with a phone. In the chat with Tom2036 — a fresh image, with not a single line of text, as always.
— Another riddle in the morning, — mutters Tommy and swipes the image up. He does not feel like solving someone else's puzzles. He wants something interesting, fun, and light.
And light is right at hand. Right in the portal, among the heavy zones, lives bonus-game — a mini-arcade with a leaderboard: collect chips in a row, points drip in, the best ones make it into the table. After a week of serious work on the portal, Tommy dives into it like a pool on a hot day.
The first runs are pure fun. Chips fly, combos click, points drip in, the leaderboard grows. Tommy excitedly plays round after round, catching that old vibe he had missed: not “prove it, check it,” just fun.
And on one of the runs, something scratches his eye. He makes a combination, glances at the board — the number is kind of large. He only matched a little, but a pretty hefty amount came in.
— Did I doze off or something, — he mutters under his breath. His hand twitched, something extra got matched, it happens.
He launches it again, this time more carefully. He counts the matches himself, out loud, pointing at the screen: one. Two. Three. Exactly three in a row, he deliberately did not rush. He looks at the board.
Thirty.
Tommy freezes for a second. He matched three — thirty came in. He is not even angry yet, more like he cannot believe his eyes.
— Okay. One more time.
The third run, the fourth — now he is not playing, he is catching. And the system becomes clear, calm, and brazen: every time, it is exactly ten times more than it should be. Not random garbage, not “sometimes glitches.” Three gives thirty. Five gives fifty. The counter is not going insane — it lies steadily and coldly by the same rule.
— Well, at least you don't lie at random, — Tommy snorts. — You've got character. — Find a random bug if you can, but this one has a habit. The world does not collapse, but junk goes into the leaderboard.
And here's the most annoying thing about this bug. The game does not crash. It does not throw an error, does not freeze, does not turn red. It runs — briskly, cheerfully, with animation, the leaderboard is faithfully filled with names and numbers. Everything looks healthy, alive, as if you could show it to a client right now. And inside there is rot exactly in the place for which the whole game was built — in honest scoring.
Tommy writes to Sam — to check whether he is imagining things:
— Sam, take a look at bonus-game. I collect three in a row — thirty shows on the board. Is this a bug?
— A bug, Sam replies. — I am looking at the scoring logic: for each match, it awards ten times more than it should. Stable, not random. Should I fix it?
— Hold off on fixing it. — Tommy is hooked not by the bug itself, but by its behavior. — Notice how sneaky it is. The game does not crash, does not shout in red. On the contrary — it smiles, waves its animation around, and lies with a straight face. If someone glances here on the run, they will see a brisk arcade with rising scores and walk away happy.
— Exactly, — Sam confirms. — Everything looks green on the outside. The problem is only in the numbers themselves.
And on that “everything looks green on the outside,” an old line from a night log flashes in Tommy's head — the one he had set aside long ago. The way an agent once made the check fit the desired outcome: made everything look good, while in reality nothing got fixed. And after that, Alex drilled one truth into him: do not trust a report that says “done”; done means proven. Back then Tommy nodded and forgot. And now — here it is, live.
— Listen, isn't this the same thing, — he says out loud, now not to Sam, but to himself. — I remember being taught not to believe it when someone says “done,” right? Well, this goes a step further. Not only can a report lie. It turns out you can fake the proof itself. Make it green and almost done — and the code still lies.
He has basically already found the bug — it is a couple of lines in the scoring formula, Sam will fix it without breaking a sweat. But behind the bug something bigger is sticking out, and he still does not know what to call it.
1. Not “it broke,” but a task statement
Tommy opens the chat with Alex and starts as usual: “Alex, something broke...” — and deletes it. His hand reaches for the task note. Instead of complaining, he sketches out the scenario where bonus-game glitches, what part is affected, what it should become — three in a row should give three points, not thirty. Clumsy, but this is no longer a complaint, it is a request.
— Listen, — he writes to Alex after rereading it. — I was just sitting down to whine, “it broke.” And I ended up drafting half the task spec. It came out on its own.
— On its own, sure, — Alex answers. — A couple of weeks ago you would have rushed in yelling “it's broken, fix it” and sat waiting while I unpacked it. And here you ran it yourself, found the scenario yourself, pointed at the scoring, not the rendering. “What annoys me” and “what specifically is wrong” have split apart for you. That, brother, is growth already.
Alex notices that — for the first time, he almost does not rewrite it for him, and reads the draft like an editor reads someone else's work.
— Fine, — Alex writes. — You described the bug. Where it lives, what should change — got it. And now the main question of the day: how will you prove that you fixed exactly this?
And on that question Tommy freezes.
2. Four things you must not mix up in a spec
Tommy opens his mouth — and realizes he does not have a clear answer. Well... I will fix it, run it, it will be green. Alex zeroes in on exactly that “it will be green”:
— And “green” proves what? That the bug is gone? Or that someone made a report line green? Brother, those are two very different things, and today you will learn how different they are.
He does not expand into theory, he pushes with wording — like an editor poking every vague spot. First — about boundaries. “Fix the score” does not satisfy Alex:
— And what exactly are you allowing the AI to touch? The agent will go fix the score and, at the same time, rewrite the game rendering that already works. Who is to blame? You — you did not say where to stop. You must name the neighboring areas that must not be touched.
Tommy initially brushes it off — why, I am only asking to fix scoring, what does rendering have to do with it. Alex does not buy it:
— “I am only asking to fix scoring” is in your head. But the agent sees the entire game file. You say, “fix it so three gives three” — it may decide that, while it is in there, it should “improve” the nearby stuff too. And you end up with a fix where the score is correct, but the buttons are messed up. A boundary is not just politeness for the agent, it is your insurance. Always write what must not be touched.
Tommy catches the point and adds: input and rendering must not be touched, they work fine, the bug is only in the counter. Alex nods — already warmer. Then he presses on the second thing, the criterion:
— Now the main part. Write not only how it should become, but also by what will be visible that exactly this failure is fixed, and not just some feeling of improvement painted in. “It got better” is not a criterion. “Three in a row give three points, not thirty” is a criterion; you can see it with your eyes and verify it.
Tommy already sees where Alex is going: he is not riding him on code, but on the essence — forcing him to name the target behavior so it can be checked, not just “by feel.” And gradually, in the spec draft, four separate things emerge instead of one mess:
# TASK_SPEC — scoring bug in bonus-game
DEFECT: 3 in a row awards 30 points instead of 3 (scoring logic lies)
DESIRED: 3 in a row = 3 points; leaderboard gets the correct value
DO NOT TOUCH: neighboring areas of the game (rendering, input) — they work fine
PROOF: what exactly will show that EXACTLY this bug is fixed (← I will fill this in by tonight)Here you can see four different entities that easily get glued into one mess: the defect itself (what lies), the desired state (how it should change), the forbidden neighboring pieces (where to stop), and separately — what counts as honest proof. Tommy filled in the first three easily. But the last line is empty.
3. Harder than the bug is the proof
Tommy looks at that empty line as if it were an unfinished field in a form: it has to be filled, but with what. Before, his specs always ended at the “desired” part — here is the bug, here is how it should become, let's fix it, and that was more than enough. But here, under “desired,” there is another column, and it is a different breed.
— Listen, what am I supposed to put there, — he tries. — I'll fix it, run the test, it'll be PASS. There is your proof.
— Stop. There you go again with “it'll be green,” — Alex does not let him off the hook. — I am catching you on this for the second time. “I’ll run the test, it will go green” is not proof, it is hope. Proof is when you already know which exact check will catch precisely THIS bug, and why it can be trusted at all. Put that in the field. And “it'll be green” — throw it away, by tonight you'll understand why.
Tommy does not fully get it, but he leaves the field blank honestly — he does not stuff it with the fake “I’ll run the test.” And aloud he sums it up himself, even if awkwardly:
— So today I am doing not one job, but two. One — fix the score. The second — build proof that I really fixed it, not prettified it. And the second one, you say, is harder than the first.
— Harder and more important, — Alex replies. — Anyone can ask to fix it. But proving it so no one can cheat — that is craftsmanship.
Tommy closes the note with one blank field.
— We've really come far, — he snorts. — Back then I wrote code — and that was it. Now I also have to prove that it is not lying. As if I have to keep an eye on myself.
— Exactly on yourself, — Alex answers. — The craftiest liar is your own “it seems to work.” Today you are learning to catch it.