Korsmodell-kodgranskning: be en AI rätta en annan

Det finns ett tyst mönster som växer fram på seniora dev-team som jag inte sett dokumenterat ännu. Det är värt att namnge eftersom det är effektivt, billigt och inte uppenbart förrän någon visar dig det.

En senior utvecklare jag arbetade med hade just byggt klart ett komplext audit-loggsystem. Han hade använt Claude med en developer-skill - multi-thread, försiktigt, strukturerat. Han körde Claudes inbyggda självgranskning två gånger. Båda passerade rent. Enligt hans egen bedömning var han 90% säker på koden.

Sedan öppnade han en annan tråd, med Codex den här gången, och bad den granska vad Claude hade skrivit.

Codex hittade tre verkliga problem.

Ett var en retry-logik-bugg - implementationen skulle misslyckas tyst efter den första batchen i vissa kö-konfigurationer. Ett var en åtkomstkontroll-lucka som de ursprungliga kraven implicit antagit men aldrig gjort explicit. Ett var ett edge case i idempotency där två events som anlände i samma millisekund kunde producera duplicerade poster.

Alla tre var verkliga. Alla tre skulle ha shippats. Alla tre missades av Claude som granskade Claude.

Mönstret har ett namn nu: korsmodell-kodgranskning.

Varför det fungerar

Intuitionen är okomplicerad: modeller tränade på olika data med olika fine-tuning-mål har olika blinda fläckar. När en modell granskar sin egen output kollar den mot mönster den tränats att betrakta som korrekta. Den letar på de platser den vet att leta.

En modell tränad på olika data letar på olika platser.

Retry-buggen i exemplet ovan var något Claude hade skrivit med självförtroende eftersom mönstret matchade något den sett i träning. Självgranskning flaggade inte det eftersom mönstret såg rätt ut enligt Claudes standarder. Codex, som utvärderade det mot andra träningsmönster, märkte att denna specifika implementation avvek från konventionerna den absorberat för kö-hantering.

Ingen av modellerna är "bättre". De är olika kalibrerade. Den skillnaden är hävstången.

Hur det skiljer sig från ensemble eller röstning

Detta är inte ensemble-röstning där flera modeller producerar kandidater och du väljer det mest överenskomna svaret. Det är inte heller reflexion-loopen där en modell kritiserar sin egen output (även om den har värde också).

Korsmodell-kodgranskning är adversariell:

• Granskar-modellen ges produktions-modellens output som ett fait accompli.
• Den ombeds hitta vad som är fel, inte föreslå förbättringar.
• Granskaren försöker inte skriva om - bara flagga.
• Utvecklaren bestämmer vilka flaggor som är verkliga.

Det är samma form som en kodgranskning mellan två mänskliga ingenjörer, förutom att ingenjörerna är två olika AI-system med olika träningsdistributioner.

Hur arbetsflödet ser ut

Den seniora utvecklarens faktiska process:

1. Bygg i en tråd. Claude med developer-skill. Spec är laddad som indata. Kod produceras inkrementellt med granskningsbara diffar.
2. Självgranska i samma tråd. Kör developer-skillens code-review-prompt två gånger. Fixa vad som ytar. Kom till ett självförtroendetillstånd.
3. Öppna en ny tråd med en annan modell. Codex i detta fall. Ny kontext. Färsk start.
4. Lämna över koden och be om granskning. Inte "förbättra denna kod." Specifikt: "hitta problem."
5. Visa problem i en lista. Varje problem ska vara specifikt: vad är fel, var, varför.
6. Utvecklaren triagerar. Vissa flaggor är verkliga. Vissa är stilistiska skillnader mellan modellernas träning. Vissa är out-of-scope. Utvecklaren bestämmer.
7. Fixa de verkliga i bygg-tråden, eller öppna en ny bygg-tråd för att adressera dem.

Kostnad: ungefär 30 minuters extra arbete per signifikant komponent. Träffrate: 2-4 verkliga problem per granskning i exemplen jag sett.

När det tillför mest värde

• Kod som är svår att testa eller granska genom att köra. Om du inte enkelt kan simulera felmoden (race conditions, felhantering, retry-logik, integrationskod) är korsmodell-granskning ett av få praktiska sätt att yta problem före produktion.
• Kod vid scope-gränser. Var som helst en komponent möter omvärlden - API:er, databaser, köer, tredjepartstjänster - skiljer sig konventionerna mellan modellernas träning. Korsmodell-granskning ytlägger dessa mismatcher.
• Säkerhetsrelevant kod. Olika modeller har olika känsligheter kring säkerhetsmönster. Använd denna asymmetri medvetet.
• Lång-kontext-output. När produktions-modellen byggt något över många turer arbetar dess självgranskning på samma potentiellt-driftande kontext. En granskare i en färsk tråd ser artefakten, inte konversationen.

När det inte hjälper

• Slit-och-släng-kod. Om koden ska raderas inom en vecka, granska den inte.
• Kod du kan helt testa genom att köra. Tester fångar vad korsmodell-granskning skulle ha flaggat, och du får test-artefakter som bonus.
• Kod i en djupt bekant domän. Ibland vet utvecklaren mer än båda modellerna. Korsmodell-granskning kan producera falska positiver där utvecklarens domänkunskap korrekt åsidosätter båda modellerna.
• Kod som redan passerat en grundlig mänsklig granskning. Två AI-granskningar ovanpå en mänsklig granskning tillför vanligtvis inte mycket.

Det djupare mönstret

Korsmodell-kodgranskning är del av ett bredare mönster jag har kallat två-trådsmönstret. Olika modeller har olika styrkor, sekvenserade i separata trådar, med medvetna överlämningar mellan dem.

I två-trådsmönstret är sekvensen: spec-modell -> bygg-modell. Korsmodell-granskning utvidgar det: spec-modell -> bygg-modell -> granskar-modell. Tre trådar, tre artefakter (spec, bygge, granskningsnoter), tre modeller med komplementära styrkor.

Kostnaden är liten. Värdet, på senior produktionskod, är verkligt och repeterbart.

Hur du börjar

Om du arbetar med Claude regelbundet, prova detta på din nästa icke-triviala färdigställning:

1. Avsluta vad du normalt skulle anse vara klart.
2. Öppna en Codex-tråd. Klistra in relevanta filer. Fråga: "Granska denna kod. Hitta vad som är fel. Var specifik."
3. Läs svaret. Sortera flaggorna i "verkligt", "stilistiskt" och "out of scope."
4. Fixa de verkliga.

Om du arbetar med Codex regelbundet, gör det omvänt: be Claude granska.

Första gången du gör det, förvänta dig att bli förvånad över vad du hittar. Andra gången, förvänta dig att börja designa ditt arbete kring det. Vid femte gången är det en vana.

---

Baserat på observationer från ett nyligt Mindtastic Sprint-engagemang, maj 2026. Mönstret utvecklades oberoende av en senior utvecklare som rapporterade att han använde det som standardpraxis för produktionskod. Kundidentitet ej angiven.