Hobbykodare stänger av Copilot för att få tillbaka känslan

I forum för operativsystemsutveckling, emulatorbyggen och demoscen är LLM-genererad kod ofta oönskad och skälet handlar sällan om kodkvalitet. Det handlar om att hobbykodning har processen som mål. När en modell levererar lösningen försvinner själva aktiviteten som deltagarna kom dit för. Under 2026 har det fått ett namn i communityn: analog coding, att medvetet plocka bort AI-assistenten ur sin editor.

Motståndet är alltså inte teknikfientlighet. Det är en gränsdragning mellan två helt olika sätt att använda samma verktyg. Fenomenet beskrivs bland annat i Born Against, en genomgång av varför hobbyprogrammeringsmiljöer motsätter sig LLM-användning.

Fem faser i ett kodprojekt och tinkerern bryr sig om tre av dem

Ett hobbyprojekt går att dela upp i fem steg: identifiera problemet, hitta lösningsmetoden, implementera den, se den fungera och till sist släppa den. Skillnaden mellan en entreprenör och en hobbyist är vilka faser som räknas som värde och vilka som räknas som friktion.

Läser du tabellen radvis blir konflikten uppenbar. Samma verktyg som halverar tiden i fas 2 till 4 är en produktivitetsvinst för den ena och en förlust av hela aktiviteten för den andra. En hobbyist som ber en modell skriva sin schackmotor har fått en schackmotor men inte gjort något. Ungefär som att ta liften upp till toppen och sedan fundera på varför utsikten inte gav något.

Off-by-one klockan halv tolv är belöningen, inte hindret

Den som suttit en hel kväll med ett logikfel och till slut upptäckt att loopens index var ett steg fel känner igen känslan. Frustrationen byggs upp i timmar och släpper på en sekund. Det är den kicken hobbykodare beskriver som anledningen till att de över huvud taget sitter uppe och kodar en tisdagkväll.

En LLM tar bort både frustrationen och kicken. Den som får felet påpekat efter fyra sekunder har visserligen ett fungerande program men har handlat bort det enda som skiljde kvällen från att titta på tv. Jämförelsen med sudoku återkommer i diskussionerna: ingen köper ett sudokuhäfte med facit ifyllt.

Skillnaden mellan att förstå kod och att ha kod

Det andra argumentet är hårdare och gäller även yrkesverksamma. En modell kan producera kod som fungerar utan att den som beställde den kan förklara varför. Det spelar mindre roll i ett litet skript.

Det spelar desto större roll i ett emulatorprojekt där varje cykel ska stämma mot original­hårdvaran eller i en OS-kärna där ett felaktigt antagande om minneshantering visar sig först under last. Kunskapen om varför något fungerar byggs i just de timmar som AI-assistenten kortar bort. En som byggt en 6502-emulator för hand har en modell av processorn i huvudet. En som fått den genererad har en katalog över filer.

Det finns dessutom ett praktiskt problem som kodare oftare pratar om än förespråkarna: att granska främmande kod är ofta jobbigare än att skriva den själv. Genererad kod flyttar arbetet från skrivande till läsande och läsandet är den tråkigare halvan.

OSDev och EmuDev kallar det fusk, Rust-forum kallar det underhållsproblem

I OSDev, EmuDev, demoscenen och bland code golfers ses LLM-hjälp ofta som fusk snarare än effektivitet. Logiken är samma som i motorsport med förarhjälpmedel eller schack med dator vid bordet: respekten i gruppen bygger på svårighetsgraden, inte på resultatet. Tar man bort svårigheten är resultatet ointressant.

Rust-communityn och forum kring Home Assistant har liknande diskussioner, fast med en annan grund. Där handlar det mer om underhåll: vem svarar på frågor om koden när den ursprungliga författaren aldrig förstod den?

Motståndet är inte enhälligt. Många projekt landar i stället i transparenskrav, alltså att den som skickar in en pull request talar om vad som är genererat. Det löser inte den filosofiska frågan men gör granskningen ärlig.

Två risker som är större än enskilda projekt

Den ena gäller nykomlingar. En nybörjare som fastnar i tio minuter och sedan frågar en modell lär sig hitta svar snabbt men bygger aldrig upp den felsökningsvana som behövs när problemet är för specifikt för att någon modell ska ha sett det förut. Det är just den vanan som gör skillnad mellan att kunna programmering som färdighet och att kunna beställa kod.

Den andra gäller communityn själv. Öppen källkod har alltid drivits av att människor svarar på varandras frågor. Om fler frågar en chatt i stället för ett forum sinar just det engagemanget, samtidigt som lågenergiprojekt som ingen underhåller blir billigare att publicera. Nettoeffekten kan bli färre svar och fler övergivna repon. Både KTH:s AI-forskning och RISE pekar på öppen källkod som central för AI-utvecklingen, vilket gör frågan om vem som orkar underhålla den mindre teoretisk än den låter.

Var gränsen faktiskt går

Slow code-rörelsen är inte ett förbud, den är ett val av kontext. Samma person kan använda en kodagent på jobbet på måndag och stänga av allt i sitt eget projekt på lördag, utan att vara inkonsekvent. Målen skiljer sig åt.

Den praktiska frågan att ställa sig innan man slår på autocomplete är enkel: kodar jag för att bli klar eller för att koda? Är svaret det första är generativ AI ett rimligt verktyg. Är svaret det andra köper man bort sin egen kväll.

FAQ

Är det förbjudet att använda AI i öppen källkod-projekt?

Nej, det finns ingen generell regel. Enskilda projekt sätter sina egna riktlinjer och den vanligaste varianten är krav på att bidragsgivaren uppger om koden är genererad snarare än totalförbud.

Blir man sämre programmerare av att använda Copilot?

Det beror på när i lärandet man börjar. Den som redan kan felsöka på egen hand förlorar lite på att autocompleta rutinkod. Den som aldrig byggt den vanan riskerar att fastna på en nivå där man kan producera fungerande kod men inte reparera den när något oväntat händer, eftersom just den förmågan tränas i timmarna man annars hoppar över.

Varför är emulator- och OS-utveckling extra känsligt för det här?

Båda kräver att man håller en detaljerad modell av hårdvaran i huvudet och den modellen byggs genom att man själv gräver i specifikationer och felsöker mot verkligt beteende. Genererad kod kan se korrekt ut och ändå bygga på fel antagande och det upptäcks ofta först långt senare.