De anatomie van software tot in de perfectie uitbrengen: hoe code review ving wat tests niet konden vangen

In de loop van een paar weken bracht GeekBye negen releases uit — v2.0.0 tot en met v2.0.11 — en deze serie vertelde het verhaal van elk daarvan. Lees ze samen en er springt een patroon uit dat interessanter is dan welke afzonderlijke bug dan ook: keer op keer doorstond een fix elke test op de machine van de ontwikkelaar, en bewees code review dat hij voor bijna iedereen anders zou zijn mislukt.

Die kloof — tussen "het werkt bij mij" en "het werkt" — is waar betrouwbaarheid daadwerkelijk woont. Dit is de workflow die haar dicht, en de index van elke release die eruit voortkwam.

Het patroon: groene tests, verkeerd antwoord

Hier zijn drie van de duidelijkste gevallen uit de serie, omdat ze het abstracte concreet maken.

• In de multi-monitor-capturefix (v2.0.10) verankerde de eerste implementatie de schermopname op het overlayvenster van de app. Hij doorstond de tests — op een dev-machine met één monitor. Review redeneerde over waar dat overlayvenster eigenlijk leeft (altijd het hoofdscherm, tenzij je het fysiek versleept) en bewees dat de "fix" voor vrijwel elke echte gebruiker regelrecht terug naar de verkeerde monitor zou verwijzen. Het juiste anker — de cursor — kwam voort uit die redenering, niet uit een testrun.
• In de WebSocket-fallback-release (v2.0.8) ontdekte review dat precies de 403 die een blokkerende proxy teruggeeft, werd geclassificeerd als een fatale authenticatiefout — waardoor de fallback die de functie moest activeren nooit kon afgaan. De functie zou zijn uitgebracht, haar happy-path-tests hebben doorstaan en niets hebben gedaan voor haar werkelijke publiek.
• In de idle-timeout-fix (v2.0.9) zette de eerste versie de "nog-in-leven"-klok binnen een codepad dat een deel van de transcripten terecht overslaat — dat van de andere spreker. Review ving op dat een toekomstige wijziging stilletjes precies de bug die werd gerepareerd opnieuw kon introduceren, en de stempel werd naar een onvoorwaardelijke plek verplaatst, met een test om hem daar te houden.

Geen van deze werd gevangen door de code te draaien. Allemaal werden ze gevangen door een reviewer die redeneerde over waarom de code werkt — en een geval vond waarin dat niet zo is.

De drie onderdelen van de poort

De workflow achter de serie is niet ingewikkeld. Het zijn drie gewoontes die zonder uitzondering worden toegepast.

1. Review redeneert over correctheid, draait niet alleen de code. Een geslaagde test bewijst dat de code werkt voor het geval waar je aan dacht. Review is een tweede, adversarieel model van het systeem dat vraagt aan welk geval heb je niet gedacht? — de tweede monitor, de bedrijfsproxy, het transcript dat de branch overslaat, de client die één versie achterloopt. De reviewstap in deze serie was vaak een onafhankelijke agent-reviewer die de opdracht kreeg om de fix te weerleggen, niet om hem te zegenen. Precies daar draait het om: een reviewer die je redenering probeert te breken, vindt het gat waar een reviewer die hem wil goedkeuren overheen leest.

2. Elke gedragsfix wordt uitgebracht met een test die de exacte fout vastpint. Niet een test dat de functie werkt — een test dat deze specifieke bug dood is. De 403 van de geblokkeerde proxy moet doorvallen naar de fallback; een echte authenticatie-403 mag dat niet. De activiteitsklok moet stempelen op een transcript dat attributie overslaat. Deze tests bestaan zodat de bug niet stilletjes over zes maanden terugkeert wanneer iemand er vlakbij refactort — de fout is aan de vloer genageld.

3. De build wordt genotariseerd en geverifieerd voordat hij wordt uitgebracht. Verschillende van deze fixes gingen binnen een dag van diagnose naar een gesigneerde, genotariseerde, zichzelf-updatende release. Die snelheid is alleen veilig omdat de poort gedisciplineerd is: de diagnose bewijst de grondoorzaak (de microfoon-permissierelease bracht haar diagnose eerst uit), de test pint de fix vast, review weerlegt de redenering, en pas dán gaat er een echte genotariseerde build de deur uit. Degelijkheid is wat snelheid veilig maakt, niet iets wat ertegen inruilt.

Waarom dit meer uitmaakt voor een AI-app

Er is een reden waarom deze discipline juist voor een tool als GeekBye niet onderhandelbaar is. Verschillende van de vervelendste bugs in de serie waren stil-fout, niet luidruchtig-crashend: een screenshot dat de verkeerde monitor aan de AI voerde (v2.0.10), een transcriptie die naar rommelwoorden neigde zodat "speak" als een naam eruit kwam (v2.0.11), een assistent die in de verkeerde modus antwoordde zonder dat je het kon zien (v2.0.3 + v2.0.5). Wanneer je app context aan een model voert, produceert een verkeerde invoer een zelfverzekerd verkeerde uitvoer en nergens een foutmelding. Je kunt je niet uit fouten testen die geen exceptie gooien. Je moet je eruit redeneren — en daar is de review-poort precies voor.

De serie, op volgorde

Elk hiervan is een op zichzelf staande casestudy over één release. Van begin tot eind gelezen vormen ze de anatomie van een product van "werkt" naar "betrouwbaar" brengen.

1. Wat een versie 2 werkelijk vergt: 206 commits van eerlijke toestanden — v2.0.0. Het fundament: toon nooit een toestand die niet waar is.
2. De dag dat onze app zichzelf DDoS'te — v2.0.1 + v2.0.4. Een opstart-uploadachterstand die onze eigen backend onder de voet liep, en de liveness-ladder die dat afdwong.
3. Kalme software: de flikkerfix en de antwoordmodus-chip — v2.0.3 + v2.0.5. Releases zonder nieuwe functies die vertrouwen kochten, detail voor detail.
4. Je Mac-app vergeet bij elke start de microfoontoegang — v2.0.6. macOS App Translocation, en de diagnose uitbrengen vóór de fix.
5. Eén CSS-variabele, vijf reviewrondes en een Swift-toolchain die loog — v2.0.7. Uniforme doorschijnendheid, en een binary die van grootte veranderde omdat de documentatie het oneens was met het enforcement-script.
6. Live-transcriptie wanneer de firewall WebSockets blokkeert — v2.0.8. Een pure-HTTPS-fallback, en de 403 die hem voor zichzelf zou hebben verborgen.
7. Waarom je AI-notulist middenin een vergadering stopt met opnemen — v2.0.9. Een idle-timer die alleen jou kon horen, en een crash die je bureaublad kon vergrendelen.
8. Waarom schermopname de verkeerde monitor vastlegt — v2.0.10. De verkeerde-scherm-bug, en de fix die op één monitor slaagde en op twee zou zijn mislukt.
9. Waarom AI-transcriptie technische termen verkeerd verstaat — v2.0.11. Spraak naar jouw vocabulaire sturen — en de regressie die het eerst slechter maakte voordat het beter werd.

De conclusie

Perfectie is geen toestand die je bereikt; het is een poort die je bewaakt. Negen releases, en bij elke dezelfde drie vragen: aan welk geval heb je niet gedacht, is de exacte fout vastgepind door een test, en is er echt een gesigneerde build de deur uitgegaan? Niets ervan is glamoureus. Alles ervan is waarom GeekBye v2 kalm aanvoelt. Als je software bouwt — AI of anderszins — is het overdraagbare deel niet een afzonderlijke fix. Het is de gewoonte om een groene testsuite te behandelen als het begin van het argument, niet het einde ervan.

Elke release hierboven is live via auto-update. Voor het product waartoe deze fixes samen leiden, zie wat er nieuw is in GeekBye v2.