--- title: "The Anatomy of Shipping Software to Perfection: How Code Review Caught What Tests Couldn't" excerpt: 'Across the GeekBye v2 series, the same thing keeps happening: a fix passes every test on the developer''s machine, and then code review proves it would have failed for almost everyone. This is the workflow behind nine releases — the review gate, the fix-first catches, and the test-before-ship discipline that turns "it works for me" into "it works."' date: '2026-07-06' author: 'Steven' authorAvatar: '/images/blog/authors/steven.jpg' coverImage: '/images/blog/covers/anatomy-of-perfection.svg' tags: ['Engineering', 'Process', 'Code Review', 'GeekBye Releases'] keywords: - 'code review catches bugs tests miss' - 'why it works on my machine fails for users' - 'engineering review gate workflow' - 'test driven development notarized release' - 'shipping fixes fast without breaking things' - 'how a small team ships reliable software' lastModified: '2026-07-06' tldr: 'This is the hub for the GeekBye v2 release series and the story of the workflow behind it. The recurring pattern across nine releases: a fix passed every local test, and an adversarial code-review step proved it would have failed in production — an anchor that resolved to the wrong screen for most users, an error code that hid a feature from itself, an activity stamp one refactor away from silently breaking. The gate is review that reasons about why code works, not that it runs; tests that pin the exact failure; and a notarized build verified before ship.' keyTakeaways: - 'The through-line of the whole series is one pattern: a fix that passed local tests, caught by review before it reached users' - 'Review that reasons about why code works catches what a green test suite cannot — a fix can pass on one machine and fail on every other' - 'Every behavior fix shipped with a regression test that pins the exact failure, so the bug cannot silently return' - 'Fixes went from diagnosis to a signed, notarized release within a day — speed and rigor are not opposites when the gate is disciplined' - 'This page links all nine v2 articles in order, each a self-contained case study in one release' --- Over a couple of weeks, GeekBye shipped nine releases — v2.0.0 through v2.0.11 — and this series told the story of each one. Read them together and a pattern jumps out that's more interesting than any single bug: **again and again, a fix passed every test on the developer's machine, and code review proved it would have failed for almost everyone else.** That gap — between "it works for me" and "it works" — is where reliability actually lives. This is the workflow that closes it, and the index to every release it produced. ## The pattern: green tests, wrong answer Here are three of the clearest cases from the series, because they make the abstract concrete. - In [the multi-monitor capture fix](/blog/screen-recording-wrong-monitor-multi-display) (v2.0.10), the first implementation anchored screen capture on the app's overlay window. It passed testing — on a single-monitor dev machine. Review reasoned about where that overlay actually lives (the primary display, always, unless you physically drag it) and proved the "fix" would have resolved right back to the wrong monitor for nearly every real user. The correct anchor — the cursor — came out of that argument, not out of a test run. - In [the WebSocket-fallback release](/blog/live-transcription-when-firewall-blocks-websockets) (v2.0.8), review found that the exact `403` a blocking proxy returns was classified as a _fatal auth error_ — so the fallback the feature existed to trigger could never fire. The feature would have shipped, passed its happy-path tests, and done nothing for its actual audience. - In [the idle-timeout fix](/blog/why-ai-notetaker-stops-recording-mid-meeting) (v2.0.9), the first version stamped the "still alive" clock inside a code path that a subset of transcripts legitimately skip — the other speaker's. Review caught that a future change could silently reintroduce the exact bug being fixed, and the stamp was moved somewhere unconditional, with a test to keep it there. None of these were caught by running the code. All of them were caught by a reviewer reasoning about _why_ the code works — and finding a case where it doesn't. ## The three parts of the gate The workflow behind the series is not elaborate. It's three habits applied without exception. **1. Review reasons about correctness, not just runs the code.** A passing test proves the code works for the case you thought of. Review is a second, adversarial model of the system asking _what case did you not think of?_ — the second monitor, the corporate proxy, the transcript that skips the branch, the client that's one version behind. The review step in this series was frequently an independent agent reviewer prompted to _refute_ the fix, not bless it. That framing is the whole point: a reviewer trying to break your reasoning finds the hole a reviewer trying to approve it skims past. **2. Every behavior fix ships with a test that pins the exact failure.** Not a test that the feature works — a test that _this specific bug_ is dead. The blocked-proxy `403` must fall through to the fallback; a real auth `403` must not. The activity clock must stamp on a transcript that skips attribution. These tests exist so the bug can't quietly return in six months when someone refactors nearby — the failure is nailed to the floor. **3. The build is notarized and verified before it ships.** Several of these fixes went from diagnosis to a signed, notarized, auto-updating release _within a day_. That speed is only safe because the gate is disciplined: the diagnostic proves the root cause ([the microphone-permission release](/blog/app-missing-from-macos-microphone-settings) shipped its diagnostic _first_), the test pins the fix, review refutes the reasoning, and only then does a real notarized build go out. Rigor is what makes speed safe, not what trades against it. ## Why this matters more for an AI app There's a reason this discipline is non-negotiable for a tool like GeekBye specifically. Several of the nastiest bugs in the series were **silent-wrong**, not crash-loud: a screenshot that fed the _wrong monitor_ to the AI ([v2.0.10](/blog/screen-recording-wrong-monitor-multi-display)), a transcription biased toward junk terms so "speak" came out as a name ([v2.0.11](/blog/why-ai-transcription-mishears-technical-terms)), an assistant answering in the wrong mode with no way to see it ([v2.0.3 + v2.0.5](/blog/why-your-app-should-tell-you-what-mode-its-in)). When your app feeds context to a model, a wrong input produces a confidently wrong output and _no error anywhere._ You can't test your way out of failures that don't throw. You have to reason your way out — which is exactly what the review gate is for. ## The series, in order Each of these is a self-contained case study in one release. Read start to finish, they're the anatomy of taking a product from "works" to "trustworthy." 1. **[What a version 2 actually takes: 206 commits of honest states](/blog/what-a-version-2-actually-takes-206-commits)** — v2.0.0. The foundation: never show a state that isn't true. 2. **[The day our app DDoSed itself](/blog/the-day-our-app-ddosed-itself)** — v2.0.1 + v2.0.4. A startup upload backlog stampeding our own backend, and the liveness ladder it forced. 3. **[Calm software: the flicker fix and the answer-mode chip](/blog/why-your-app-should-tell-you-what-mode-its-in)** — v2.0.3 + v2.0.5. No-feature releases that bought trust one detail at a time. 4. **[Your Mac app forgets microphone access every launch](/blog/app-missing-from-macos-microphone-settings)** — v2.0.6. macOS App Translocation, and shipping the diagnostic before the fix. 5. **[One CSS variable, five review rounds, and a Swift toolchain that lied](/blog/overlay-translucency-and-the-swift-toolchain-that-lied)** — v2.0.7. Uniform translucency, and a binary that changed size because the docs disagreed with the enforcement script. 6. **[Live transcription when the firewall blocks WebSockets](/blog/live-transcription-when-firewall-blocks-websockets)** — v2.0.8. A pure-HTTPS fallback, and the `403` that would have hidden it from itself. 7. **[Why your AI notetaker stops recording mid-meeting](/blog/why-ai-notetaker-stops-recording-mid-meeting)** — v2.0.9. An idle timer that could only hear you, and a crash that could lock your desktop. 8. **[Why screen recording captures the wrong monitor](/blog/screen-recording-wrong-monitor-multi-display)** — v2.0.10. The wrong-display bug, and the fix that passed on one monitor and would have failed on two. 9. **[Why AI transcription mishears technical terms](/blog/why-ai-transcription-mishears-technical-terms)** — v2.0.11. Biasing speech toward your vocabulary — and the regression that made it worse before it made it better. ## The takeaway Perfection isn't a state you reach; it's a gate you keep. Nine releases, and the same three questions at every one: _what case did you not think of, is the exact failure pinned by a test, and did a real signed build actually go out?_ None of it is glamorous. All of it is why GeekBye v2 feels calm. If you build software — AI or otherwise — the transferable part isn't any single fix. It's the habit of treating a green test suite as the _start_ of the argument, not the end of it. Every release above is live via auto-update — a feature that was itself one of the hardest things we ever shipped, told in [the safety check that made our app impossible to quit](/blog/the-auto-update-that-made-our-app-unkillable) (the v1 era that led here). For the product these fixes add up to, see [what's new in GeekBye v2](/blog/v2-whats-new).