Legendarisk FreeBSD-udvikler om AI-kode i open source: certificering, ikke forbud

Poul-Henning Kamp, en af de mest profilerede udviklere bag FreeBSD og caching-serveren Varnish, har skrevet et længere holdningsindlæg på Version2 om et spørgsmål, mange open source-projekter kæmper med lige nu: hvordan skal man håndtere AI-genereret kode?

Kamp starter med en personlig anekdote om "Øjvinds far", en dygtig fører af en rendegraver på landet, og bruger den som grundlæggende billede på sit argument: En kompetent og ansvarlig maskinfører med en rendegraver sparer tyve mand for farligt, udmattende arbejde, mens en rendegraver styret af en tåbe udgør en umiddelbar og uacceptabel fare for liv, lemmer, ejendom og anden infrastruktur. Pointen er, at værktøjet — AI'en, rendegraveren — ikke i sig selv er problemet. Det er operatørens kompetence og ansvarlighed, der afgør udfaldet.

Copyright og kodekvalitet

Kamp peger på to konkrete problemer. Det første er ophavsret: Han har selv oplevet sin egen kode — renset for licensoplysninger — blive gengivet af sprogmodeller, og flere retssager involverer modeller, der genererer ophavsretsbeskyttede billeder og andet beskyttet materiale. Open source-projekter står derfor over for et svært valg: forbyde brugen af sprogmodeller helt, sætte en "de minimis"-grænse, eller omfavne teknologien ukritisk.

Det andet problem er kodekvalitet. Kamp beskriver AI-genererede pull requests som "tonedøve" i forhold til projektets kodestil, designmønstre og arkitektoniske principper. Som konkret eksempel nævner han Varnish-komponenten Vinyls "latched error model", der tillader fejlfri, strømlinet kode gennem tidlig assertion og en endelig verificering — et mønster AI-patches ofte misforstår fundamentalt, blandt andet ved fejlagtigt at konvertere void-returtyper til int og geninføre unødvendig fejltjek-kode.

Forslaget: hverken forbud eller fri adgang

I stedet for et blankt forbud eller fri adgang foreslår Kamp et trinvist certificeringssystem for FreeBSD (med forbehold for, at det mindre Vinyl-projekt kræver en simplere tilgang):

• Automatisk godkendelse under en copyright-tærskel eller fra certificerede committere
• Et review-udvalg på tre tilfældigt udvalgte certificerede medlemmer vurderer tvivlsomme bidrag
• Udvalget kan eskalere og anbefale fuld certificering til core@

Review-udfaldet kan være commit (eventuelt med mindre ændringer), anmodning om revision, afvisning, eller afvisning kombineret med et midlertidigt forbud mod fremtidige bidrag fra den pågældende bidragyder.

Fordelen ved modellen er ifølge Kamp, at den skaber en vej for både simple og komplekse AI-assisterede patches, samtidig med at reviewbyrden koncentreres hos de mest erfarne udviklere, der er bedst i stand til at vurdere sprogmodellers output. Han erkender dog også ulemperne: risiko for "scope creep", mulig regulatory capture, en ny separat klasse af committere, og at FreeBSD's decentrale styringsform komplicerer implementeringen.

Hverken dogmatisk eller ukritisk

Kamp understreger, at hans holdning ikke er dogmatisk — han kræver ikke, at kode "skal skrives i hånden, helst på hulkort". I stedet søger han en mellemvej, der anerkender AI'ens reelle nytteværdi uden at gå på kompromis med projektets integritet. Han peger desuden på, at manglende dokumentation er en del af problemet: Når et projekts konventioner kun findes implicit i koden i stedet for eksplicit i vejledninger, kæmper både mennesker og AI lige meget med at følge dem.

Indlægget rejser desuden en række åbne spørgsmål: Kan AI'ens stilistiske problemer løses alene gennem bedre prompting, eller afspejler de grundlæggende begrænsninger i modellerne? Taler sprogmodeller forskellige "dialekter" — med Python-output der følger PEP8, og C-output der afspejler Linux-konventioner? Og bør projekter investere i særlige "markup"-systemer til at guide modellerne, eller er det en uøkonomisk indsats?