Spring til indhold

Indsigt

Sådan holder du kvaliteten, når AI skriver koden

Torn Studio6 min. læsning

Kort svar

Når AI skriver størstedelen af koden, flytter ansvaret for kvaliteten sig fra gennemsyn til automatiske porte. Typetjek i strikt tilstand, tests, lintregler der kodificerer arkitekturbeslutninger, og én enkelt verify-kommando, der skal være grøn før hvert commit, fanger tilsammen det, et menneske holder op med at se efter tredje fil.

Den mest almindelige indvending mod AI-skrevet kode handler om drift: at stil, struktur og beslutninger glider fra hinanden over måneder, indtil ingen længere kan sige, hvorfor noget ser ud, som det gør.

Gennemsyn skalerer dårligt

Et menneske, der gennemgår sin tredje AI-genererede fil på en time, læser med mindre skarphed. Det er en forudsigelig effekt af, hvordan opmærksomhed fungerer. Løsningen er at flytte så meget som muligt af bedømmelsen over på noget, der holder en jævn skarphed.

Portene der gør arbejdet

  • Typetjek i strikt tilstand, inklusive noUncheckedIndexedAccess
  • Lintregler der kodificerer arkitekturbeslutninger
  • Tests for det, der koster penge, hvis det går i stykker
  • Én kommando der kører det hele, og som skal være grøn før commit

Pointen med det sidste punkt er, at en port først tæller, når den faktisk køres. Kræver den fire kommandoer og en god hukommelse, bliver den sprunget over en fredag.

Ofte stillede spørgsmål

Bliver koden dårligere, når AI skriver den?
Kvaliteten følger portene. Er typetjek, tests og lintregler på plads, holder koden samme niveau, uanset hvem eller hvad der skrev den.
Hvilke tests er værd at skrive?
Dem, der dækker det, der koster penge, når det går i stykker: betalingsflows, rettigheder, dataintegritet og de regler, der er sværest at holde i hovedet. Fuld dækning af triviel kode giver mindre pr. time.
Hvor strikt bør typetjekket være?
Strikt tilstand slået til, inklusive tjek af indekserede opslag. Hvert hul, du lader stå åbent, er en klasse af fejl, et menneske skal fange i gennemsyn, og gennemsyn er præcis den del, der skalerer dårligst.
Kan lintregler erstatte kodegennemsyn?
De erstatter den kedelige halvdel. En lintregel fanger arkitekturafvigelser mekanisk, hvilket frigør gennemsynet til det, det er godt til: om løsningen løser det rigtige problem.
Hvad gør man, når en port bliver for langsom?
Deler den op. Hurtige tjek kører ved hver gemning, tungere ved commit og de tungeste i bygget. En port, der tager ti minutter, bliver omgået, og så fanger den ingenting.
Hvordan får man et team til faktisk at køre portene?
Gør det til én kommando. Kræver det fire kommandoer og en god hukommelse, bliver de sprunget over. Én verify, der skal være grøn, er den eneste udgave, der overlever mødet med en deadline.

Fortæl os, hvad du vil bygge

Tredive minutter, helt gratis, og en klar melding om, hvorvidt vi er det rette studio til opgaven.