We gave the infinite monkeys GPUs, and one of them wrote `assertEquals(true, true)`. The test passed. Naturally, we asked the monkey to review its own work.

When the code, tests, and review can all inherit the same wrong assumption, a second opinion is an expensive way to agree with yourself. Somebody has to establish what correct means before the agent starts explaining why it has achieved it.

We'll challenge the specification before deriving tests from it. Once we've agreed on the assertions, we'll lock them and try to get broken code through by changing its exam. You'll see which checks catch that attempt and where we still depend on a human understanding the requirement.

That agreement also has to survive the trip to production. At the release gate, we'll check who approved the change and whether the passing CI run belongs to the revision we're about to ship. A green run for yesterday's code won't do. If the specification changes, we'll send it back for a decision before treating the new tests as the agreed exam.

"The monkey seemed confident" remains a terrible acceptance criterion.

This session attacks a verification chain by trying to change the tests that judge the generated code. Developers see how to keep the agreed requirement intact through implementation and check that approval and passing CI belong to the revision being released. The release checks are new material.