Sessies isoleren voor reviews

Pijplijnen hebben geen terminal waarin je kunt typen, dus Claude Code moet in de niet-interactieve modus (afdrukmodus) worden uitgevoerd. Gebruik -p (of --print) om één prompt door te geven, één resultaat terug te krijgen en vervolgens af te sluiten.

Dit vormt de basis voor een geïsoleerde beoordelingsstap: elke aanroep is een nieuw proces met een eigen schone context, volledig gescheiden van een eventuele eerdere generatiestap.

Een CI-stap heeft door machines leesbare resultaten nodig, geen proza. Voeg --output-format json toe, zodat de pijplijn bevindingen kan parseren en kan beslissen of de build slaagt of mislukt.

Door JSON-uitvoer met een schema te combineren, wordt het resultaat deterministisch te verwerken: je poortscript leest gestructureerde velden in plaats van in vrije tekst te zoeken naar woorden als "LGTM" of "done" — wat een antipatroon is.

Het schoonste isolatiepatroon in CI/CD is het splitsen van generatie en beoordeling in twee afzonderlijke aanroepen van Claude Code. De generatietaak schrijft code; een latere, onafhankelijke taak met -p beoordeelt deze.

Omdat elke aanroep een eigen proces is, neemt de beoordelaar nooit de conversatiegeschiedenis van de generator over. Dit weerspiegelt de multi-agentregel uit het examen: subagenten nemen de geschiedenis van een coördinator niet over — context moet expliciet worden doorgegeven en mag nooit worden verondersteld.

Het is verleidelijk om de generatiesessie te --resume en te vragen het eigen werk te beoordelen. Doe dat niet. Een hervatte sessie brengt de oorspronkelijke redenering weer in de context — precies de vertekening bij zelfbeoordeling die je wilt vermijden.

Er is nog een risico: resultaten van hervatte tools kunnen verouderd zijn als de codebase is gewijzigd sinds ze zijn vastgelegd. Soms is een nieuwe sessie met een gestructureerde samenvatting beter dan een sessie met een naam rechtstreeks hervatten.

Kies voor een onbevooroordeelde beoordeling standaard altijd een nieuwe sessie.

Een geïsoleerde beoordelaar moet een compacte, relevante lading ontvangen: de diff die moet worden geïnspecteerd plus de toe te passen standaarden. Beperk uitgebreide tooluitvoer tot de relevante velden — een overvolle context veroorzaakt het effect lost-in-the-middle, waarbij het model veel meer aandacht heeft voor het begin en einde dan voor het midden.

Houd de beoordelingscriteria dicht bij het begin of einde van de prompt, zodat ze niet midden in de context begraven raken.

Een geïsoleerde sessie heeft geen gedeelde aannames waarop ze kan terugvallen, dus de criteria moeten expliciet zijn. Precieze regels verminderen valse positieven drastisch.

• Vaag: "be more precise" — levert luidruchtige, inconsistente signaleringen op.
• Expliciet: "flag a comment only when it contradicts the code it describes" — levert bruikbare bevindingen op.

Voor CI-beoordelingen is het doel specifiek om valse positieven te minimaliseren — een beoordelaar die steeds vals alarm slaat, wordt genegeerd en tast het vertrouwen in de controlepoort aan.

Voeg 2-4 gerichte few-shotvoorbeelden toe die de dubbelzinnige gevallen afdekken, zodat een geïsoleerde beoordelaar zich in verschillende uitvoeringen consistent gedraagt. Het model generaliseert daaruit — het herhaalt ze niet simpelweg.

Few-shot is het juiste hulpmiddel voor consistentie, randgevallen, de uitvoerindeling en het verminderen van verzonnen bevindingen. Een paar goed gekozen voorbeelden van flag / do-not-flag stemmen het oordeel van de beoordelaar af op de norm van je team.

Dwing de beoordelaar om via een tool en JSON Schema een gestructureerd oordeel te geven. Stel tool_choice in op "any", zodat het model verplicht een tool moet aanroepen — zo garandeer je gestructureerde uitvoer in plaats van vrije tekst.

Markeer een veld alleen als required wanneer het altijd aanwezig is. Vereis nooit een veld dat mogelijk ontbreekt, anders verzint het model een waarde. Gebruik een enum met een optie "other" plus een vrij tekstveld voor details, zodat nieuwe typen bevindingen toch kunnen worden weergegeven.

Wanneer een pull request wordt bijgewerkt en de beoordeling opnieuw wordt uitgevoerd, zou een nieuwe sessie alles opnieuw signaleren — ook items die al zijn erkend. Dat veroorzaakt ruis.

Het patroon voor de toets: neem bij een nieuwe uitvoering de eerdere resultaten op en rapporteer alleen nieuwe of nog niet opgeloste problemen. Zo behoud je sessie-isolatie — het blijft een schone beoordelaar — terwijl je de eerdere bevindingen expliciet als invoer meegeeft. De context wordt bewust overgedragen en niet overgenomen uit een hervatte generatiesessie.

Belangrijkste punten voor sessiegeïsoleerde beoordelingen in CI/CD:

• Een nieuwe instantie is beter dan zelfbeoordeling — de auteur verdedigt zijn eigen werk; een buitenstaander doet dat niet.
• Afzonderlijke processen — beoordeel met een afzonderlijke aanroep van claude -p; hervat nooit de generatiesessie met --resume voor een beoordeling.
• Niet-interactief + JSON — -p met --output-format json levert een schone context en parseerbare resultaten; zoek nooit in tekst naar signalen dat de uitvoering is voltooid.
• Expliciete criteria + 2-4 few-shotvoorbeelden minimaliseren valse positieven en houden oordelen consistent.
• tool_choice "any" dwingt gestructureerde uitvoer af; vereis alleen velden die altijd aanwezig zijn.
• Bij nieuwe uitvoeringen geef je eerdere bevindingen expliciet mee en rapporteer je alleen nieuwe of niet-opgeloste problemen.
• Nooit blokkerende beoordelingen vóór het samenvoegen via de Batch API laten lopen.