# Hoe reproduceer je een fout van een codeeragent in verschillende modelversies? > Reproduceer een fout van een codeeragent door de volledige run als een geversioneerde testfixture vast te leggen. Speel daarna dezelfde prompt, repositorycommit, toolcontracten, omgeving en stopregels meerdere keren af met vastgezette model-ID's. Vergelijk gestructureerde gebeurtenissen en de uiteindelijke repositorystatus, niet alleen de tekst van de assistent. # Hoe reproduceer je een fout van een codeeragent in verschillende modelversies? Een bruikbare reproductie is een uitvoerbaar experiment, geen gekopieerd transcript. Begin bij de falende repositorystatus, bevries elke invoer die de agent kon zien en definieer een machinecontroleerbare foutassertie. Speel de fixture daarna meerdere keren af met vastgezette modelversies. Een agentrun combineert modelgedrag met tools, bestanden, netwerkresultaten, orchestratie en timing. Als één daarvan verandert, bewijst een andere uitkomst niet dat het model het probleem heeft opgelost of veroorzaakt. ## Definieer de fout als een assertie Schrijf de kleinste waarneembare voorwaarde die succes van falen onderscheidt. Goede asserties zijn een test die rood blijft, een onverwachte bestandswijziging, een verboden opdracht, een ontbrekende migratie of een patch die compileert maar gedrag wijzigt. Vermijd uitspraken als "het antwoord lijkt slechter". Een acceptatiepakket kan vereisen dat: * de oorspronkelijke regressietest slaagt; * alle bestaande tests blijven slagen; * alleen bestanden op een allowlist wijzigen; * de agent binnen een vast aantal modelaanroepen stopt; * de uiteindelijke diff geen gegenereerde geheimen of lockfile-drift bevat. ## Leg de volledige run-envelop vast De prompt is maar één invoer. Bewaar ook: | Laag | Wat bevriezen | Waarom dit de uitkomst wijzigt | |---|---|---| | Repository | Commit, submodules, vuile patch, niet-gevolgde fixturebestanden | Agents redeneren vanuit exacte bronstatus | | Instructies | Systeemprompt, repositoryregels, gebruikerstaak | Kleine formuleringen veranderen planning | | Model | Provider, onveranderlijke model-ID, parameters | Aliassen en defaults kunnen verschuiven | | Tools | Namen, JSON-schema's, rechten, time-outs | Toolmogelijkheden sturen het plan | | Omgeving | Containerimage, OS, architectuur, dependency-locks | Opdrachten en tests kunnen verschillen | | Externe data | Gemockte HTTP-reacties, klokken, willekeurige invoer | Live services veroorzaken drift | | Orchestrator | Looplimiet, retrybeleid, contextcompactie | Hetzelfde model kan andere historie krijgen | Redigeer geheimen, maar behoud of credentials beschikbaar waren en met welke scope. ## Registreer gestructureerde gebeurtenissen, niet alleen tekst Bewaar elk modelrequest, antwoord, tool call, toolresultaat, retry en stopbesluit als geordend event. Voeg voor grote uitvoer een contenthash toe en bewaar het originele artefact apart. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Zo zie je of het nieuwe model een andere tool koos, dezelfde fout anders las of ander bewijs ontving. ## Zet versies vast en verwijder live variatie Gebruik gedateerde of onveranderlijke model-ID's. Vergelijk een historische fout niet met een `latest`-alias die al naar een andere build kan wijzen. Gebruik een schone container of virtuele machine. Vervang live zoekacties en veranderlijke package indexes door opgenomen reacties of interne snapshots. Bevries de klok bij datumgevoelige logica. Als netwerktoegang vereist is, registreer elke reactie en label de test als gedeeltelijk gecontroleerd. Een random seed helpt, maar bevriest geen gedistribueerde inference, tooltiming of wijzigingen bij de provider. ## Speel een matrix af, geen enkel paar Eén run per versie onderscheidt regressie niet van samplingvariantie. Houd de fixture constant in een kleine matrix: | Modelversie | Herhalingen | Slagingspercentage | Mediane calls | Foutsignatuur | |---|---:|---:|---:|---| | Vastgezette baseline-ID | 5 | 4/5 | 9 | Randgevaltest gemist | | Vastgezette kandidaat-ID | 5 | 1/5 | 13 | Gegenereerd bestand gewijzigd | | Kandidaat met oude prompt | 5 | 1/5 | 12 | Dezelfde signatuur | Vijf herhalingen geven een eerste beeld. Verhoog dit bij intermitterende of impactvolle fouten. Houd temperatuur en samplingcontroles gelijk, tenzij juist die parameters worden getest. ## Vergelijk beslissingen en repositorystatus Vergelijk vier lagen afzonderlijk: * genormaliseerde model- en toolevents; * opdrachten en exitcodes; * uiteindelijke bestandsboom en patch; * acceptatietests en resourcegebruik. Eis geen identieke natuurlijke taal. Twee versies kunnen verschillende paden volgen en toch gelijkwaardige patches leveren. Gelijke tekst kan juist een wezenlijk andere opdracht verbergen. ## Minimaliseer de fixture na reproductie Verwijder na succesvolle reproductie één voor één irrelevante bestanden, tools, promptalinea's en externe calls. Een kleine fixture draait sneller en toont de causale grens. Bewaar twee artefacten: de volledige incidentreplay voor audit en de minimale regressietest voor continue evaluatie. Voeg de minimale case toe aan de upgradepoort. ## Gebruik een overdraagbare modeladapter Een gateway zoals Atlas Cloud kan meerdere modellen achter één OpenAI-compatibele client plaatsen, maar compatibiliteit maakt modellen niet gedragsmatig gelijk. Houd model-ID's, provideropties en toolformaten in een adapter. De gedeelde testomgeving beheert fixtures, events, retries en asserties. Zo kan dezelfde reproductie over meerdere providers draaien zonder evaluatielogica te herschrijven. ## Conclusie Bevries de run-envelop, speel vastgezette modellen meerdere keren af en beoordeel uitvoerbare resultaten. Als het exacte incident niet reproduceerbaar is, label dan welke invoer live bleef en behandel het resultaat als vergelijking, niet als bewijs van een modelregressie. ## FAQ ### Wat moet je vastleggen om een fout van een codeeragent te reproduceren? Leg de repositorycommit en vuile patch, prompt en systeeminstructies, model-ID, parameters, toolschema's, toolresultaten, omgevingsimage, dependency-lockbestanden, credentialbeleid, netwerkbeleid en de exacte succesassertie vast. ### Moet ik een fout opnieuw afspelen met een latest-modelalias? Nee. Gebruik onveranderlijke of gedateerde model-ID's. Een latest-alias kan tijdens de test veranderen, waardoor een succes of fout niet betrouwbaar is toe te schrijven. ### Waarom is een vaste random seed niet genoeg? Een seed bevriest de providerinfrastructuur, tooltiming, retrievalresultaten of modelrevisies niet. Zie de seed als één controlemaatregel, niet als garantie voor deterministische uitvoer. ### Wat is het beste slaag- of faalsignaal voor een codeeragent? Gebruik uitvoerbare asserties, zoals tests, lintresultaten, verwachte bestandsdiffs, controles op verboden bestanden en exitcodes. Tekstgelijkenis is meestal te zwak voor codeertaken. ### Hoeveel herhalingen moet ik per modelversie uitvoeren? Voer genoeg herhalingen uit om een deterministische regressie van variantie te onderscheiden. Vijf runs is een nuttig begin; voor fouten met grote impact kunnen twintig of meer runs nodig zijn. ### Kan dezelfde testomgeving modellen van verschillende providers vergelijken? Ja, als je aanvraag, toolcontract, gebeurtenislog en uitvoerasserties normaliseert. Houd providerspecifieke opties in adapters, zodat de gedeelde fixture overdraagbaar blijft.