Två-trådsmönstret: Codex för spec, Claude för bygge

Två seniora utvecklare i samma team, arbetande oberoende på samma uppgift, använde exakt samma AI-arbetsflöde. De hade aldrig diskuterat det. De hade aldrig sett det dokumenterat. De hade båda kommit fram till det genom egen iteration.

Arbetsflödet:

Öppna en tråd med en modell (Codex/GPT). Be den skriva en produktstilad specifikation.
Förfina specen genom dialog tills den fångar avsikten utan att specificera implementation.
Stäng den tråden. Öppna en ny tråd med en annan modell (Claude med en developer-skill).
Lämna över specen. Låt den andra modellen bygga från den.
Valfritt: lämna tillbaka resultatet till den första modellen för korsgranskning.

De kallade det olika saker. Mönstret är detsamma. Jag kallar det två-trådsmönstret.

Det är på väg att bli teamets de facto-standard.

Varför två trådar, inte en

Frestelsen när man arbetar med AI är att hålla hela konversationen på ett ställe. En tråd, en modell, en historik. Allt i kontext. Allt sammankopplat.

Detta misslyckas av tre skäl.

Kontextkorruption. Långa trådar ackumulerar drift. Modellen "minns" saker som inte riktigt hände - tidigare turer biaserar subtilt senare. Vid slutet av en 200-meddelandes konversation arbetar modellen på en delvis-fiktiv version av projektet. Konversationen känns koherent eftersom modellen är bra på att verka koherent. Men output-kvaliteten har försämrats mätbart från där den var vid meddelande 20.

Modellaffordans. Olika modeller är bra på olika saker. Codex/GPT har ett starkt produkttänk - den kan skriva en specifikation som läses som om den kom från en produktchef, vilket är användbart just för att produktchefer tänker på vad och varför innan de tänker på hur. Claude med en developer-skill är exceptionellt bra på att bygga från en välformad spec, ställa klargörande frågor när specen är tvetydig. Styrkorna är komplementära i sekvens, inte i parallell.

Att blanda leverantörer bryter metadata. Detta är den mest underuppskattade felfunktionen. Om du växlar från Codex till Claude (eller till Gemini) inom samma tråd, inkluderar kontextfönstret innehåll från en modell med olika metadata-förväntningar. Mottagande modell kan läsa innehållet, men kan inte läsa konversationsstrukturen rent. Edge cases utlöses. Citeringsförväntningar bryts. Tool-use-mönster blir förvirrade.

Två trådar - separata, sekvenserade, med en medveten överlämning - undviker alla tre.

Vad varje tråd gör

Spec-tråden, med Codex/GPT:

Börjar med kundbrief, teamets riktlinjer och relevanta kodexempel
Producerar en specifikation som medvetet är produkt-orienterad, inte implementations-orienterad
"Ge inte arkitekturalternativ. Ge inte implementations-tutorials. Specificera vad audit-loggen ska göra och vad den inte ska göra."
Itererar tills specen fångar avsikt utan att specificera mekanism
Valfritt: producerar en README, en definition-of-done och operations notes
Sparas till disk som en markdown-fil

Bygg-tråden, med Claude (vanligtvis med en developer-skill):

Börjar färsk, med specen från föregående tråd laddad som indata
Läser specen, ställer klargörande frågor, ber om tillstånd att börja
Bygger inkrementellt med granskningsbara diffar
Testar allteftersom
Hanterar tvetydighet genom att ytlägga den, inte genom att gissa

Arbetsloopen körs inom bygg-tråden. Spec-tråden är uppströms från arbetsloopen.

Korsgransknings-varianten

En av de seniora utvecklarna lade till ett steg som den andra inte hade:

Efter att Claude avslutat byggandet öppnade han en ny tråd med Codex och bad den granska vad Claude hade producerat.

Codex hittade tre problem som developer-skillens självgranskning hade missat. Ett var ett retry-after-first-batch-fel i kö-hanteringen. Ett var en åtkomstkontroll-lucka. Ett var ett konfigurations-edge-case.

Detta fungerar för att modeller tenderar att fånga varandras blinda fläckar bättre än sina egna. Retry-logiken var något Claude hade skrivit med självförtroende eftersom den följde Claudes träningsmönster; Codex evaluerade den mot olika mönster och märkte mismatchen.

Det här är inte ensemble-röstning. Det är adversariell granskning. Billigt, effektivt, och den mest novella arbetsflödes-tekniken jag sett i år.

Varför detta inte är ChatGPT 101

Två-trådsmönstret ser vardagligt ut. "Använd ett verktyg för en sak, ett annat för en annan." Det låter som råd från 2023.

Vad som är annorlunda:

Trådarna har en designad överlämning. Specen producerad i tråd ett är inte ett konversationsutdrag. Det är en medveten artefakt: en markdown-fil på disk, strukturerad som något en produktchef skulle skriva. Överlämningen är till filen, inte till modellen. Båda modellerna skulle kunna plocka upp den. Artefakten överlever konversationen.

Två-trådsstrukturen är uppströms från modellvalet. När du väl har mönstret kan du välja olika modeller per tråd beroende på uppgift. Codex är inte den enda produktstilade spec-modellen. Claude är inte den enda bra byggaren. Mönstret överlever förändringar i vilka specifika modeller du använder.

Det förbjuder explicit blandning inom en tråd. Detta är den del de flesta utvecklare inte internaliserat ännu. Folk försöker fortfarande "bara byta modell" mitt i konversationen när något inte fungerar. Det är inte byte - det är att tyst bryta kontexten. Vill du ha en annan modell, starta en annan tråd.

När mönstret inte gäller

Slit-och-släng-arbete. Ett 20-radersskript behöver ingen spec-fas. En tråd räcker.
Tungt explorativt arbete. Ibland vet du inte vad du vill ha förrän du försökt bygga det. Specen växer fram ur byggförsöket. I så fall, räkna med att slänga byggandet och skriva en spec från det du lärt dig.
Solo-arbete i din egen domän. Om du är djupt i en kodbas du känner intimt kan du komprimera båda faserna mentalt. Specen lever i ditt huvud; byggandet sker i en tråd.
När projektet är för litet för att motivera overhead. En spec-fas kostar ~30 minuter. Under en 4-timmars uppgift är det oftast inte värt det.

För riktigt produktionsarbete som spänner mer än några timmar betalar två-trådsmönstret sig själv nästan varje gång.

Hur du börjar använda det

Välj din nästa icke-triviala uppgift. Något med mer än ett arkitekturbeslut.
Öppna en tråd med Codex (eller en annan modell bra på strukturerade dokument). Ge den kundbrief, kod-kontext, riktlinjerna. Be den skriva en produktstilad specifikation.
Iterera på specen, inte på koden. Tryck tillbaka när den specificerar implementation. Be om klargörande när avsikt är otydlig.
Spara specen till disk. Markdown-fil. Committa den.
Stäng tråden. Återanvänd den inte.
Öppna en ny tråd med Claude (med en developer-skill om du har en). Ladda specen som indata. Låt Claude bygga.
När Claude är klar, öppna valfritt en Codex-tråd och be om en kodgranskning.

Du kommer känna skillnaden på två ställen. Byggfasen är snabbare för att specen ger modellen rätt kontext från början. Och granskningen ytlägger problem du skulle missat annars.

De seniora utvecklare jag ser använda detta mönster är 4-5x så produktiva som samma utvecklare var för sex månader sedan. En del är dem. En stor del är detta.

Två-trådsmönstret observerades oberoende komma fram till av två seniora utvecklare under ett nyligt Mindtastic Sprint-engagemang, maj 2026. Korsgransknings-varianten lades till av en av dem efter att ha läst forskning om cross-model evaluation. Kundidentitet ej angiven.

Var detta till nytta?