TraceYield

Kwaliteit van AI-gegenereerde code beoordelen

Hoe je de geschiktheid van AI-gegenereerde wijzigingen beoordeelt voor bedoeld gedrag, eisen, risico’s en de bestaande softwareomgeving.

TY

TraceYield Inzichten

5 min leestijd · Bijgewerkt 8 oktober 2026

Kwaliteit hangt af van het beoogde gebruik

In dit artikel betekent kwaliteit: hoe geschikt een codewijziging is voor het bedoelde gedrag, de relevante eisen en risico’s en het gebruik binnen het bestaande systeem. Er bestaat geen enkel universeel kwaliteitssignaal dat elke wijziging samenvat.

Beoordeel relevante eigenschappen

Functionele geschiktheid gaat over het bedoelde gedrag. Betrouwbaarheid en robuustheid betreffen relevante fout- en randgevallen. Beveiliging telt waar risico en toepassing dat vragen. Onderhoudbaarheid, begrijpelijkheid, compatibiliteit en architecturale aansluiting kunnen voor de hostomgeving belangrijk zijn. Prestaties zijn relevant wanneer de eisen dat vragen; niet elke wijziging vraagt dezelfde beoordeling.

Gebruik eigenschappen als vragen die bij de taak passen, niet als universele checklist of samengestelde kwaliteitsscore.

Houd bewijsfasen uit elkaar

Een statische analyse of codepatroon is een signaal uit het artefact. Tests en review leveren verificatiebewijs voor onderzochte voorwaarden. Acceptatie of samenvoeging is een besluit over de wijziging onder teamcriteria. Productie- of onderhoudsgegevens kunnen later nieuw bewijs geven. Geen fase bewijst automatisch alle andere.

Gebruik metrics voor de vraag die ze beantwoorden

Leg eenheid, noemer en meetbereik vast. Testdekking beschrijft welke regels of condities zijn geraakt, niet of assertions de juiste eis uitdrukken. Complexiteit, duplicatie en statische bevindingen kunnen reviewvragen aanwijzen, maar zijn geen totaalscore. GitHub Copilot-metrics tellen gebruik of output; DORA’s change fail rate en deployment rework rate beschrijven delivery op deploymentniveau, niet de intrinsieke kwaliteit van één patch.

Testresultaat

Wat wordt waargenomen
Uitkomst van een benoemde testset in een vastgelegde omgeving.
Wat kan het ondersteunen
Dat de geteste gevallen zich tijdens die uitvoering gedroegen zoals verwacht.
Wat stelt het niet vast
Correctheid van niet-geteste gevallen, beveiliging of onderhoudbaarheid.
Benodigde context
Testnamen, assertions, omgeving en overgeslagen gevallen.

Dekking

Wat wordt waargenomen
Gemeten regels of voorwaarden die tests hebben uitgevoerd.
Wat kan het ondersteunen
Waar uitvoeringsbewijs ontbreekt.
Wat stelt het niet vast
Of assertions passend zijn of aan eisen is voldaan.
Benodigde context
Berekening van de dekking, testset en scope van de gewijzigde code.

Bevinding uit statische analyse

Wat wordt waargenomen
Een overeenkomst met een regel binnen het gescande bereik.
Wat kan het ondersteunen
Een patroon of mogelijke tekortkoming die aandacht verdient.
Wat stelt het niet vast
Een bevestigd defect, of dat er geen defecten zijn als er niets is gevonden.
Benodigde context
Versies van tool en regels, ernst, scanscope en triage.

Complexiteit of duplicatie

Wat wordt waargenomen
Paden of herhaalde blokken volgens de definitie van een tool.
Wat kan het ondersteunen
Een mogelijke plek voor gerichte review.
Wat stelt het niet vast
Een oordeel over onderhoudbaarheid.
Benodigde context
Taal, functie, referentiewaarde en lokale conventies.

Bevinding uit beveiligingsscan

Wat wordt waargenomen
Een mogelijk probleem dat een geconfigureerde controle heeft gevonden.
Wat kan het ondersteunen
Een aanleiding voor gerichte beveiligingsreview.
Wat stelt het niet vast
Een uitbuitbaar lek of algemene veiligheid zonder verdere controle.
Benodigde context
Dreigingsmodel, scancodekking, status van de bevinding en getroffen versie.

Reviewbevinding

Wat wordt waargenomen
Een vastgelegde observatie van een reviewer over een specifieke versie.
Wat kan het ondersteunen
Een vraag, correctie of voorwaarde voor acceptatie.
Wat stelt het niet vast
Een kwaliteitsscore op basis van alleen het aantal opmerkingen.
Benodigde context
Reviewcriteria, omvang van de wijziging en ernst van de bevinding.

Acceptatie door het team

Wat wordt waargenomen
Besluit om een versie onder bepaalde voorwaarden te behouden.
Wat kan het ondersteunen
Dat het team het werk op dat moment heeft geaccepteerd.
Wat stelt het niet vast
Universele correctheid of later succes.
Benodigde context
Geaccepteerde versie, criteria en verantwoordelijke reviewer.

Defect of incident

Wat wordt waargenomen
Een bevestigd voorval nadat de wijziging in gebruik is genomen.
Wat kan het ondersteunen
Een aanleiding om gedrag en oorzaak te onderzoeken.
Wat stelt het niet vast
Dat AI of deze wijziging het voorval op zichzelf heeft veroorzaakt.
Benodigde context
Ernst, blootstelling, tijdvenster, versie en toerekening.

Instabiliteit bij uitrol

Wat wordt waargenomen
Gedefinieerde mislukte wijzigingen of hersteluitrol na productie-incidenten.
Wat kan het ondersteunen
Onderzoek naar levering op serviceniveau.
Wat stelt het niet vast
De intrinsieke kwaliteit van één codewijziging.
Benodigde context
Noemer van uitrols, service, periode en gebeurtenisdefinitie.

Copilot-acceptatie of regels code

Wat wordt waargenomen
Geaccepteerde suggesties of toegevoegde/verwijderde regels volgens GitHubs definitie.
Wat kan het ondersteunen
Toolinteractie of uitvoervolume.
Wat stelt het niet vast
Codekwaliteit, productiviteit of bedrijfswaarde.
Benodigde context
Metriekdefinitie, gebruikte interface, scope en periode.

Voorbeeld: sessieverlenging en vervaldatum

Voorbeeld ter illustratie — geen klantgegevens, productie-incidenten of onderzoeksbewijs. Een AI-assistent stelt een wijziging voor aan sessieverlenging met een vaste absolute vervaldatum, een inactiviteitsverval en intrekking bij uitloggen. De regel is dat verlenging de inactiviteitstijd mag verlengen, maar de absolute vervaldatum nooit verschuift; uitloggen moet het sessietoken ongeldig maken.

Een test slaagt, maar de reviewer controleert of de test de exacte vervalgrens, verlenging vlak daarvoor en ingetrokken token na uitloggen dekt. Dekking laat mogelijk een niet-uitgevoerde tak zien, maar niet of de assertion de regel juist weergeeft. Review controleert ook aansluiting op het bestaande intrekkingspad en compatibiliteit met aanroepende code. Pas nadat de ontbrekende grenssituatie is getest accepteert het team een herziene versie. Een later supportprobleem vraagt nog steeds onderzoek naar versie, blootstelling en toerekening voordat het aan deze wijziging of AI wordt gekoppeld.

AI verandert de context van het bewijs

De relevante kwaliteitseigenschappen veranderen niet vanzelf doordat AI aan de patch heeft bijgedragen. Wel kunnen menselijke en gegenereerde wijzigingen gemengd zijn en kan een interactierecord de uiteindelijke repositorystaat niet volledig weergeven. Als dezelfde verkeerde interpretatie zowel code als tests stuurt, kan een geslaagde test die verkeerde interpretatie bevestigen. Dat is een verificatierisico om te controleren, geen claim dat gegenereerde tests meestal falen. Toets belangrijke assertions aan eisen of onafhankelijke review.

Waar TraceYield past

Waar records beschikbaar zijn, kan TraceYield context rond taak, interactie, koerswijzigingen en verificatie verbinden. De dekking hangt af van configuratie en beschikbare gegevens; een ontwikkeltraject is geen kwaliteitsbeoordeling. Het team bepaalt de kwaliteitsvraag, inspecteert het artefact en interpreteert controles. Voor de smallere beslissing na een melding dat de agent klaar is, zie Melding van de agent en voltooiing van het werk; voor vervolgwijzigingen, zie Herstel- en vervolgwerk. TraceYield berekent geen universele kwaliteitsscore, verifieert geen correctheid, voorspelt geen defecten en bewijst geen causaal kwaliteitseffect.

Referenties