Codekwaliteit | Blog

~/blog/series/code-quality

Codekwaliteit

Hoe je erachter komt of wat de agent schreef deugt, met instrumenten die hem niet vleien.

Waar deze reeks over gaat

Genereren werd goedkoop. Controleren niet, en de meeste instrumenten waar mensen naar grijpen zijn ontworpen voor code waar al iemand over had nagedacht.

Dat is de rode draad door deze stukken. Coverage vertelt je dat een regel is uitgevoerd. Of iemand het zou merken als hij stukging, blijft ongemeten. Een duplicatierapport geeft AI-code een goede score, want de matchers tellen tokens terwijl agents bijna-klonen produceren in plaats van kopieën. Complexiteit blijft ongeveer gelijk terwijl de vorm eronder verandert. Al die getallen kunnen omhoog gaan terwijl de codebase achteruit gaat, en elk stuk hier zoekt uit waar een bepaald instrument ophoudt de waarheid te vertellen.

Wat overeind blijft is weinig spectaculair. Mutation testing, omdat het de vraag stelt of een test überhaupt zou falen. Churn, omdat dat het enige signaal is dat zich meldt voordat iemand klaagt. Een bevroren takenset en een scorer zonder smaak, als de vraag is of een modelwissel iets heeft verslechterd. Een baseline in de repo die vastlegt wat er al staat en weigert wat de agent er net bij zette.

De volgorde loopt van diagnose naar behandeling. Wil je alleen het betoog waarom dit er überhaupt toe doet, dan staat dat in de gids over AI en codekwaliteit. Deze reeks is de werkende helft.

Waar dit naartoe gaat

Het gat dat ik nog wil dichten is meten over tijd in plaats van per pull request. Elk getal hier is eerlijk over één wijziging en onbetrouwbaar over één week, en de bruikbare versie van dit werk is een trendlijn die gewoon blijft lopen. Dat is het stuk dat ik hierna zou willen schrijven, en daar heb ik een langere reeks echte data voor nodig dan ik nu heb.