Innhold Vis
Linux-kjernen har fått sitt første offisielle regelsett for AI-assistert koding. Dokumentet coding-assistants.rst ble lagt til i Linus Torvalds’ kodebase i april 2026, etter måneder med debatt blant kjerneutviklere. Det er kort, pragmatisk, og setter én ting krystallklart: du eier alt koden AI skriver for deg.
Dette er ikke et forbud mot AI. Det er heller ikke et grønt lys for å dumpe Claude- eller Copilot-output rett inn i kernel-patches. Det er noe mer interessant – en formell anerkjennelse av at AI-verktøy er en del av moderne utvikling, kombinert med en tydelig ansvarsfordeling som gjør det umulig å gjemme seg bak «men AI-en sa det».
Med 499 Hacker News-poeng og 381 kommentarer er dette tydeligvis noe utviklermiljøet har meninger om. La meg grave litt i hva dokumentet faktisk sier, og hva det betyr for AI-assistert utvikling generelt.
Hva sier det nye Linux-dokumentet om AI?
Kjernen i coding-assistants.rst er egentlig veldig enkel. AI-verktøy er tillatt som hjelpemidler, men de kan aldri stå ansvarlig. Tre krav skiller seg ut:
1. AI MUST NOT legge til Signed-off-by. Bare mennesker kan juridisk bekrefte Developer Certificate of Origin (DCO). Det er den formelle erklæringen om at du har rett til å bidra med koden, at den er lisensiert riktig, og at du tar ansvar for den. En AI-agent kan ikke signere dette – og forsøk på å la den gjøre det er direkte brudd på kernel-prosessen.
2. Assisted-by-tag for transparens. Når AI har hjulpet med kode, skal commit-meldingen inkludere en Assisted-by-tag på formatet:
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]For eksempel: Assisted-by: Claude:claude-3-opus coccinelle sparse. Grunnleggende verktøy som git, gcc og make skal IKKE listes – bare AI-spesifikke verktøy og statiske analysatorer.
3. All kode følger GPL-2.0-only. Ingen spesialregler for AI-generert kode. Alt som landes i kjernen må ha kompatibel lisens med korrekte SPDX-identifikatorer, uavhengig av om en AI eller et menneske skrev det.
Hva mener Linus Torvalds om AI i kjernen?
Torvalds er ikke spesielt begeistret for at dette ble et eget dokument. I uttalelser gjengitt av Phoronix argumenterte han for at «dokumentasjon ikke vil løse AI slop-problemet» – de som sender inn dårlig AI-generert kode vil ikke bry seg om retningslinjene uansett. Dårlige aktører leser ikke contributing-guider.
Poenget hans er presist: dette dokumentet henvender seg til de gode aktørene. De som allerede bryr seg om kodekvalitet og prosess. For dem er det nyttig å ha tydelige regler. For de som spammer AI-slop inn i patch-køen – de stopper ikke av et .rst-dokument.
Torvalds foretrekker at AI behandles som «bare et verktøy» heller enn at kernel-dokumentasjonen tar politisk stilling i AI-debatten. Og det er akkurat det dette dokumentet gjør. Det er verktøy-nøytralt. Det sier ikke «bruk Copilot» eller «unngå ChatGPT». Det sier: uansett hva du bruker – du eier resultatet.
Hvorfor er ansvarslinjen det viktigste?
Det mest interessante med Linux-tilnærmingen er ikke hva som er forbudt, men hvem som tar ansvaret. Som implicator.ai peker på: Linux godkjente ikke AI-kode, de gjorde den menneskelige bidragsyteren til sikringen.
Det er en smart løsning på et reelt problem. Kjernen har ikke mulighet til å detektere AI-generert kode teknisk. Det er umulig å verifisere om en patch ble skrevet av et menneske eller en modell. I stedet for å prøve på det umulige, ankrer de ansvar fast til mennesket som trykker på send.
Konsekvensene er tydelige. Hvis du sender inn AI-generert kode som inneholder en feil, en sikkerhetssårbarhet, eller et lisensproblem – er det ditt problem. Du signerte Signed-off-by. Du er ansvarlig. AI-en er ikke en medforfatter med egne rettigheter eller plikter.
Det er faktisk ikke ulikt hvordan open source har håndtert kode-gjennopplasting fra andre prosjekter i årevis. Du kan hente inspirasjon fra Stack Overflow, en kollega, en bok – men du validerer det, du forstår det, og du signerer for det.
Hva er AI egentlig nyttig til i kernel-utvikling?
Dokumentet nevner eksplisitt noen bruksområder der AI faktisk hjelper. Test case-generering er et godt eksempel – det er tidkrevende manuelt arbeid der AI kan spare mye tid uten at det er katastrofalt hvis outputen trenger gjennomgang. Dokumentasjon er et annet område. Og «initial drafts of straightforward code» – altså ikke den kritiske concurrency-logikken, men boilerplate og struktur.
Det er en ærlig vurdering. Torvalds sa selv i et intervju at AI-verktøy «clearly are getting better» men at de er farlige for alt som involverer concurrency, minnehåndtering og hardware-interaksjon. Det er kjernen av kernel-programmering. Der er menneskelig ekspertise fortsatt nødvendig.
Tenk på det slik: AI kan hjelpe deg å skrive stillas, tester, kommentarer, og enkle hjelpefunksjoner. Men den kritiske interrupt-handleren eller spinlock-implementasjonen der en subtil feil kan krasje millioner av systemer? Der er det kanskje bedre å skrive den selv, forstå hvert ord, og så ta et lite nap etterpå.
Hva betyr dette for resten av open source?
Linux er ikke alene om å tenke på dette. Men de er det første store prosjektet med en formell, versjonskontrollert AI-policy direkte i kodebasen. Det er interessant fordi retningslinjene nå følger kodebasen – alle som kloner repoet har tilgang til dem, de kan vises i pull request-workflows, og de kan oppdateres med vanlige commit-prosesser.
Andre store open source-prosjekter vil sannsynligvis følge etter. AI finner allerede sikkerhetssårbarheter i produksjonskode – men det er én ting å bruke AI som sikkerhetsanalysator, og noe annet å la AI skrive produksjonskode i kritisk infrastruktur uten menneskelig gjennomgang.
Det som skjer i Linux-kjernen er egentlig en mikrokosmos av noe større: samfunnet finner ut hvordan AI-verktøy passer inn i eksisterende ansvarsstrukturer. Ikke ved å forby dem, ikke ved å gi dem frie tøyler, men ved å definere nøyaktig hva menneskets rolle er når AI er involvert.
Svaret Linux gir er: mennesket er alltid ansvarlig. AI er et verktøy. Og et verktøy kan ikke signere sin egen DCO.
Hva tenker du – er dette en fornuftig tilnærming, eller burde de ha vært mer restriktive? Interessert i å høre fra folk som faktisk bidrar til open source-prosjekter.
