The Third Week

Kai built Cragmoor's waitlist with an agent in one afternoon: about 1,400 lines, a demo that worked and tests that passed. In the third week a single freed place in a full class was offered to two climbers at once. Both accepted. Nobody on the team could say which code had sent which offer.

This page follows the feature week by week, not to find the bug, which Chapter 10 does properly, but to show exactly what was missing on the day it arrived. Kai is a capable engineer. Every decision he made that afternoon was reasonable on its own, and that is what makes the story worth telling.

Week One: Green

The request was clear enough. When a full class of 16 loses a booking, offer the place to the first person on the waitlist, hold it for 15 minutes, and pass it to the next person if the offer is not accepted. Kai described it to the agent in a few paragraphs and accepted its changes as they came. The agent created the module, wired it into booking, wrote 30-odd tests and ran them, and summarised what it had built in a tidy list.

Kai clicked through the demo: a full class of 16, a cancellation, an offer arriving for the first climber on the list, an acceptance, the class full again. He tried an expired offer passing to the second climber, and that worked too. The tests were green and the demo was convincing. The pull request went in before the end of the day.

Nobody had read the 1,400 lines, and that includes the tests. Kai had read the agent's summary, which was accurate as far as it went, and the pull request described the demo. A reviewer facing 1,400 lines on a Friday afternoon, from an author who says it works and shows that it does, is being asked to do the reading the author skipped, and nobody did it.

Week one+1,400 lines, green

→

Week twotwo patches, unread

→

Week threeone place, two offers

→

Ines's questionsno answers

Week Two: Patches on Patches

Two small requests followed. The front desk wanted climbers reminded when five minutes of the 15-minute hold were left. The business wanted the waitlist to skip members whose membership had lapsed. Kai gave each to the agent in a fresh session, with a sentence or two of description, and each worked first time.

Each also touched the code that hands an offer to the next person. The reminder needed to know when a hold started; the lapsed-member check needed to run before an offer went out. Each change landed on code nobody understood, made by a session that had never seen the earlier one and had only the code to go on. Each was accepted because the demo still worked. By the end of the week the offer path had been written by three sessions, each reading what the last had left without knowing why it was there.

	Lines changed	Tests added	Read by a person
Week one: the waitlist	about 1,400	30-odd	Nobody; the summary was read
Week two: five-minute reminder	about 300	3	Nobody; the demo was rerun
Week two: skip lapsed members	about 340	2	Nobody; the demo was rerun
Week three: the double offer	Found by a customer, not by any of the above

Week Three: The Double Offer

On a Tuesday evening a climber cancelled her place in a full class. Two climbers on the waitlist received the offer for that one place at the same time, and both believed it was theirs. The front desk found out when the second of them complained, with the offer still on her phone.

The tests were green, and stayed green after the report came in. None of them had two things happening at once. Each tested one cancellation, one offer, one acceptance, in order, the way the demo had. Whatever produced the second offer needed two events close together, and no test, demo or patch had ever put two events close together.

Nobody Can Trace It

Kai cannot say how offers are sent, because he never read that code. The agent cannot say why the code is the way it is, because every session started empty and nothing it decided was written down; a new session asked to explain the module will reconstruct an explanation from the code, which is a description, not a memory. The history is three large commits, all called "waitlist", so there is no small step to compare against, and a search through history could at best point at one of three large diffs.

Ines asks three questions. Which code sends an offer? What stops two offers going out for the same place? Which test covers that? None of the three has an answer. Not a wrong answer, which could be corrected, but no answer at all, from anyone, because the knowledge was never in a person's head and never in a file.

Kai does what most people would do next, and asks an agent to find the bug. In ten minutes it proposes three fixes, each with a confident explanation of the cause, and each explanation is different. None of them can be checked, because nothing reproduces the double offer: the tests are green before the fix and green after it. Choosing between three plausible stories with no way to test any of them is not debugging. It is the same gamble that built the feature, taken a second time.

What Actually Failed

The agent wrote ordinary, plausible code with the kind of gap a hurried person also writes. Bugs of that kind are what review, tests and small steps exist to catch. What was missing in Kai's three weeks was every one of those stages.

A specification that included the two-at-once case would have put it in front of the agent before any code existed. A reading of the diff would have raised the question Ines asked three weeks too late. A test written from the domain, two attempts to offer the same freed place in the same second, rather than from the code the agent had just produced, would have failed the day the bug went in. Commits small enough to search would have let the team find the step that introduced the behaviour. The cause itself is found in Chapter 10, starting where every debugging session in this book starts: with a failing test that shows the double offer.