Hur jag använder AI-assisterad kodning

Jag tror inte att mjukvaruutveckling är löst. Däremot har kod blivit mycket billigare att producera.

När jag kan beskriva en ändring tydligt, ge agenten rätt kontext och kontrollera resultatet kan den ofta skriva en användbar första version. Min grova uppskattning är att modellen klarar nio uppgifter av tio. Det beror på domänen, ändringens storlek och hur väl jag har beskrivit problemet. Det finns fortfarande områden där modellen saknar rätt träning eller missar ett edge case.

Det betyder inte att ingenjören blivit överflödig. Någon måste välja angreppssätt, ge rätt kontext, läsa resultatet och avgöra om ändringen hör hemma i kodbasen. När jag låter agenten gissa blir resultatet snabbt sämre. Det är där slop kommer ifrån.

AI-assisterad kodning skiljer sig från vibe coding.

Andrej Karpathy introducerade begreppet i en tweet från 2025. Jag tolkar vibe coding som att acceptera genererade ändringar utan att läsa dem. Ett fel uppstår, felmeddelandet klistras in i nästa prompt och loopen fortsätter tills programmet verkar fungera. Kodbasen kan då växa snabbare än personens förståelse för den.

Min variant är mindre automatisk. Jag läser diffen. Jag kör tester. Jag ger agenten projektets konventioner och lokala exempel, och korrigerar den när den går åt fel håll. Modellen kan skriva mycket av koden, men jag äger fortfarande gränserna och resultatet.

Hastigheten kortar avståndet mellan en idé och en version som går att testa. Jag kan be om en del av en datapipeline, köra den mot riktig data och använda den sparade tiden till att kontrollera datakvalitet och edge cases i produktion. Det är mer användbart än att skriva den första Airflow-DAG:en helt för hand.

Poängen är inte att skriva mer kod. Poängen är att nå ett användbart resultat med mindre repetitivt arbete. Då blir det billigare att prova en liten idé, behålla den om den fungerar och kasta den om den inte gör det.

Vanliga verktyg är Cursor, Claude Code, OpenAI Codex och GitHub Copilot. Jag började med Cursor, gick vidare till Claude Code och föredrar nu Codex. Verktyget spelar mindre roll än att lära sig formulera en tydlig uppgift och ge agenten ett sätt att kontrollera sitt arbete.

Agentverktyg och AI-plattformar är olika produkter. En agent arbetar i en befintlig kodbas och följer de begränsningar jag ger den. En plattform som Lovable eller Replit försöker skapa mer av applikationen utifrån en beskrivning på naturligt språk, ofta genom att kombinera utveckling, runtime och deployment. Båda kan vara användbara, men de löser olika problem.

Jag skulle börja med sådant som är lätt att kontrollera: unit tests, repetitiva refaktoreringar, små migreringar och boilerplate. Produktens viktigaste beslut och ändringar med hög risk behöver fortfarande granskas noggrant.

Modellen känner inte till privata konventioner, gamla beslut eller relationen mellan moduler om jag inte berättar det. Jag sparar sådan information i filer som AGENTS.md och CLAUDE.md och pekar agenten mot de filer som hör till uppgiften.

Dokumenten behöver vara fokuserade. Byggkommandon, testregler, namnkonventioner och projektspecifika fakta är användbara. Ett långt arkiv över varje gammalt beslut är det inte. Varje extra stycke konkurrerar om modellens uppmärksamhet, så jag tar bort kontext som inte längre påverkar arbetet.

Jag promptar nästan aldrig en agent utan att bifoga en fil eller ange exakt vilken del av kodbasen den ska undersöka. En vag uppgift ger en vag ändring.

Jag föredrar små iterationer. Be om en funktion, skriv eller uppdatera ett fokuserat test, kör det och läs diffen innan nästa ändring. Jag låter agenten föreslå assertions och fixtures, men jag bestämmer vilket beteende testet ska skydda.

Täta commits gör det lättare att backa. Om agenten tar fel väg är kostnaden för att rulla tillbaka liten.

Jag har några återkommande prompts för sådant jag gör ofta: committa ändringar, onboarda en uppgift och göra om undersökningen till en task-lista. Onboarding-prompten ber agenten undersöka repot, dokumentera relevanta filer och begränsningar och markera osäkerheter innan den ändrar något. Task-listan delar sedan upp kontexten i små steg.

Jag lånade grundidén till onboarding från McKay Wrigley, men det viktiga är vanan, inte den exakta formuleringen. Agenten ska lämna efter sig en handoff som går att använda, inte tvinga nästa session att upptäcka repot på nytt.

Arbetet har förändrats. Jag skriver färre rader, men lägger mer tid på att välja gränser, läsa diffar och avgöra om resultatet hör hemma i kodbasen. Det är fortfarande ingenjörsarbete.