Verificatiekosten zijn de werkelijke kosten van AI-coderen

Vroeger stelde ik één vraag bij het kiezen van een AI-model voor coderen.

Welk model is sterk genoeg voor deze taak?

Die vraag is prima. Maar het is niet langer mijn eerste vraag.

De betere vraag is: Hoe snel kan ik de output verifiëren?

Deze mindset verandert hoe je goedkope modellen gebruikt. Zie ze niet als zwakke versies van grote modellen. Zie ze als werknemers voor taken met korte verificatiepaden.

Sommige taken zijn goedkoop om te beoordelen omdat je de resultaten direct kunt zien.

• README-opschoning • Gebruiksvoorbeelden • Codecommentaren • Changelog-notities • Kleine formateringsscripts • Issue-templates

Als een model een slechte README-paragraaf schrijft, zie je dat meteen. Je verwijdert het slechte deel. De fout is irritant, maar het kost je bijna niets. Dit is de beste manier om goedkope modellen te gebruiken.

De volgende categorie is testbaar werk.

Als je het verwachte gedrag kunt definiëren en een testsuite kunt draaien, gebruik dan een goedkoper model voor de eerste versie. Je moet het model duidelijke kaders geven.

Zeg niet: Voeg tests toe voor deze helper.

Zeg wel: Voeg tests toe voor lege input, null-input, dubbele waarden, ongeldige configuratie, standaardconfiguratie en normale input. Verander de runtime-code niet.

Dit dwingt het model om binnen een verificatiekader te werken.

Sommige taken hebben geen geautomatiseerde tests, maar laten wel duidelijke handmatige controles toe.

• CLI-outputformattering • Configuratievoorbeelden • Notities voor een migratie-dry-run • Kleine scripts voor gegevensconversie

Vraag het model bij deze taken om het volgende op te nemen:

  • Hoe de code te draaien
  • Welke input te gebruiken
  • Welke output te verwachten
  • Welke edge cases te controleren

Als een model niet kan uitleggen hoe het zijn eigen werk kan verifiëren, vertrouw dan de code niet.

Kleine refactors zijn gevaarlijk. Een diff ziet er misschien kort en schoon uit, maar het gedrag kan veranderen in een verborgen pad, een standaardwaarde of een controle van de toegangsrechten.

Verhoog je risiconiveau wanneer een taak het volgende raakt:

  • Fallbacks
  • Standaardwaarden
  • Routing
  • Rechten
  • Facturering
  • Rate limits
  • Migraties
  • Achterwaartse compatibiliteit

Deze fouten zijn moeilijk te zien in een standaard code review. Ze vereisen diepe context.

Verdeel je werk op basis van verificatiekosten:

  • Lage verificatiekosten: Gebruik een goedkoop model voor een concept.
  • Gemiddelde verificatiekosten: Gebruik een goedkoop model, gevolgd door menselijke bewerkingen.
  • Hoge verificatiekosten: Gebruik een sterk model met tests en menselijke controle.

Grootte maakt niet uit. Een kleine taak is duur als deze moeilijk te verifi