Sessionsisolering til reviews

Arbejdsgange har ingen terminal, man kan skrive i, så Claude Code skal køre i ikke-interaktiv tilstand (udskrivningstilstand). Brug -p (eller --print) til at sende én prompt og få ét resultat tilbage, og afslut derefter.

Dette er grundlaget for et isoleret kontroltrin: Hver kørsel er en ny proces med sin egen rene kontekst, fuldstændig adskilt fra et eventuelt tidligere genereringstrin.

Et CI-trin har brug for maskinlæsbare resultater, ikke prosa. Tilføj --output-format json, så arbejdsgangen kan fortolke fund og afgøre, om bygningen skal bestå eller fejle.

Hvis JSON-output kombineres med et skema, bliver resultatet deterministisk at bruge: Dit kontrolscript læser strukturerede felter i stedet for at søge i fri tekst efter ord som "LGTM" eller "done" — hvilket er et antimønster.

Det reneste isoleringsmønster i CI/CD er at dele generering og kontrol op i to separate Claude Code-kørsler. Genereringsjobbet skriver kode; et senere, uafhængigt -p-job kontrollerer den.

Fordi hver kørsel er sin egen proces, overtager kontrolløren aldrig generatorens samtalehistorik. Det afspejler reglen om flere agenter fra prøven: Underagenter overtager ikke en koordinators historik — kontekst skal videregives eksplicit og må aldrig antages.

Det kan være fristende at bruge --resume til genereringssessionen og bede den om at gennemgå sit eget arbejde. Lad være. En genoptaget session bringer den oprindelige argumentation tilbage i konteksten — og det er netop den selvvurderingsbias, du vil undgå.

Der er endnu en risiko: resultater fra genoptagne værktøjskald kan være forældede, hvis kodebasen er ændret, siden de blev gemt. Nogle gange er en ny session, der startes med et struktureret resumé, bedre end at genoptage en navngiven session direkte.

For at få en uvildig gennemgang skal du som standard bruge en ny session hver gang.

En isoleret gennemgangsmodel skal modtage en kort og relevant datapakke: de ændringer, der skal undersøges, samt de standarder, der skal anvendes. Skær fyldige værktøjsresultater ned til de felter, der betyder noget — en overfyldt kontekst udløser «lost-in-the-middle»-effekten, hvor modellen i langt højere grad fokuserer på begyndelsen og slutningen end på midten.

Hold kriterierne for gennemgangen tæt på begyndelsen eller slutningen af prompten, så de ikke begraves midt i konteksten.

En isoleret session har ingen fælles antagelser at falde tilbage på, så kriterierne skal være udtrykkelige. Præcise regler reducerer antallet af falske positiver markant.

• Vagt: "be more precise" — giver støjende og inkonsekvente markeringer.
• Udtømmende: "flag a comment only when it contradicts the code it describes" — giver resultater, du kan handle på.

Ved CI-gennemgange er målet specifikt at minimere falske positiver — en gennemgangsmodel, der råber «ulv», bliver ignoreret og svækker tilliden til kontrollen.

Hvis en isoleret gennemgangsmodel skal opføre sig ensartet fra kørsel til kørsel, skal du tilføje 2-4 målrettede few-shot-eksempler, der dækker de tvetydige tilfælde. Modellen generaliserer ud fra dem — den gentager dem ikke bare.

Few-shot er det rigtige værktøj til ensartethed, randtilfælde, outputformat og reduktion af opdigtede resultater. Et par velvalgte eksempler på flag og do-not-flag får gennemgangsmodellens vurderinger til at stemme overens med jeres teams standard.

Tving gennemgangsmodellen til at afgive en struktureret afgørelse via et værktøj og JSON Schema. Sæt tool_choice til "any", så modellen skal kalde et værktøj — det garanterer struktureret output i stedet for fri tekst.

Markér kun et felt som required, når det altid er til stede. Gør aldrig et felt, der muligvis mangler, obligatorisk, ellers opfinder modellen en værdi. Brug en enum med valgmuligheden "other" samt et frit tekstfelt til detaljer, så nye typer af resultater stadig kan repræsenteres.

Når en pull request opdateres, og gennemgangen køres igen, vil en ny session markere alt igen fra bunden — også allerede anerkendte punkter. Det skaber støj.

Mønsteret er: Ved en ny kørsel skal du inkludere de tidligere resultater og kun rapportere nye eller stadig uløste problemer. Du bevarer sessionsisoleringen — det er stadig en ren gennemgang — samtidig med at du udtrykkeligt giver de tidligere resultater med som input. Konteksten overdrages bevidst i stedet for at blive arvet fra en genoptaget genereringssession.

Vigtige pointer om sessionsisolerede gennemgange i CI/CD:

• En ny instans er bedre end selvvurdering — forfatteren forsvarer sit eget arbejde; det gør en udenforstående ikke.
• Adskilte processer — gennemgå med et særskilt claude -p-kald; brug aldrig --resume på genereringssessionen til gennemgangen.
• Ikke-interaktivt + JSON — -p sammen med --output-format json giver ren kontekst og resultater, der kan fortolkes; søg aldrig i tekst med grep efter signaler om færdiggørelse.
• Udtømmende kriterier + 2-4 few-shot-eksempler minimerer falske positiver og holder afgørelser ensartede.
• tool_choice "any" tvinger struktureret output frem; gør kun felter, der altid er til stede, obligatoriske.
• Ved gentagne kørsler skal du udtrykkeligt videregive tidligere resultater og kun rapportere nye eller uløste problemer.
• Aldrig skal blokerende gennemgange før sammenlægning sendes gennem Batch API.