I set out to build a fifteen-minute countdown. The data source had stopped telling the truth six years earlier, and nothing in the response said so.

The idea was almost comically simple.

I was watching a WNBA game. Halftime started. I wanted to go do something and know exactly how long I had before the game came back.

The broadcast said Halftime. Google said Halftime. Neither told me the number I actually wanted: how much halftime is left?

WNBA halftime is fifteen minutes. So the product seemed obvious. Call it Halftime Clock. One number, large, in the middle of the screen. 12:43. That's basically the whole app.

The important constraint

I worked out the concept with ChatGPT and asked it to help me figure out whether the underlying data existed. It did. Or at least, it appeared to.

The NBA has live-data infrastructure with scoreboard, box-score, and play-by-play endpoints. The WNBA uses related infrastructure, and there was a straightforward-looking way to identify games and determine when the second quarter ended.

The build brief had one important rule: never estimate halftime from the scheduled tip time. If you know when Q2 actually ended, start the fifteen-minute countdown there. If you don't know, don't fake it. That constraint turned out to matter much more than I expected.

The build looked finished

I handed the spec to Claude Code. It built the app quickly: Next.js, server-side polling, normalized game states, a client-side clock that ticks every second, and states for upcoming, live, halftime, starting soon, and final.

It also wrote a tiny probe script whose only job was to hit the real endpoint and print what came back. Claude couldn't access the endpoint from its own sandbox, so it told me to run the probe locally and verify the actual response before trusting the implementation. That instruction was probably the most important part of the entire build.

So I ran it. 200 OK. Valid JSON. All the fields we expected were there. Game status. Period. Clock. Teams. Scores. The schema looked perfect. The game was Seattle Storm versus Las Vegas Aces. The date was October 6, 2020.

Everything worked except reality

The endpoint hadn't failed. It hadn't returned an error, or an empty response. It returned a completely valid description of a basketball game played almost six years earlier.

If I'd validated only the things developers usually validate, everything would have passed. Does the endpoint respond? Yes. Is it JSON? Yes. Does the schema match? Yes. Are the fields present? Yes.

The only thing that failed was the question that actually mattered: does this data describe what is happening now? Nothing in the response told us it didn't. No deprecation warning, no stale-data flag, no 410. Just 200 OK.

When I flagged the stale response, the first read on it was that it might be a cached placeholder shown when no WNBA game was live — a reasonable-sounding guess, with a mechanism and an obvious next step. It just happened to be wrong. ChatGPT had offered the plausible endpoint; Claude offered the plausible explanation for why it appeared stale; and it was the habit of verifying rather than trusting that caught both. That's more useful to me than a story about "AI hallucinating." It's about what it takes to work with agents through genuine uncertainty.

Then the architecture got simpler

We found ESPN's scoreboard instead: correct teams, correct scores, correct game state, and it exposed something more useful than what we'd designed around — a direct STATUS_HALFTIME field, no play-by-play inference required.