Agentisk utveckling: så förändras arbetssättet när AI skriver koden

Agentisk utveckling betyder att utvecklare låter AI-agenter utföra större arbetsuppgifter självständigt — läsa kodbasen, göra ändringen, köra testerna och rätta sig själv — medan människan sätter riktningen och granskar resultatet. Det ökar tempot rejält, men flyttar samtidigt flaskhalsen: det som begränsar er blir inte längre hur snabbt kod skrivs, utan hur snabbt den kan verifieras.

• Uppgifter formuleras som mål och acceptanskriterier i stället för detaljerade instruktioner
• Granskning blir det viktigaste momentet, inte det sista innan lunch
• Tester och typkontroller går från trevligt att ha till förutsättning, eftersom de är agentens facit
• Mycket kod skrivs snabbt, vilket gör det billigare att kasta ett förslag och göra om
• Ansvaret för resultatet ligger kvar hos den som godkänner ändringen

En agent presterar ungefär som en ny utvecklare med perfekt minne men noll historik. Den blir bra i en kodbas där det går att kontrollera sig själv, och opålitlig i en där ingenting går att verifiera automatiskt.

• Tester som går att köra på en kommandorad och som säger något om verkligheten
• Linting och typkontroll som ger snabb, entydig återkoppling
• Ett sätt att starta systemet lokalt utan hemliga steg
• Kortfattad dokumentation av konventioner — hur ni namnger, var saker hör hemma
• Små, tydliga ändringar som går att granska på tio minuter

• Läs ändringen som en helhet först: löser den det som efterfrågades, och bara det?
• Var särskilt uppmärksam på det som ser rimligt ut men inte testas — felhantering, gränsfall, behörigheter
• Kräv att agenten visar hur den verifierat sitt arbete, inte bara att den säger att det fungerar
• Misstänk breda ändringar: många filer med små justeringar döljer ofta ett missförstånd
• Kontrollera att inget säkerhetssteg tagits bort för att få testerna gröna

Den största risken är inte att agenten skriver fel kod — det upptäcks av tester och granskning. Den är att teamet slutar förstå sitt eget system. När ingen längre kan förklara varför en lösning ser ut som den gör blir varje framtida ändring dyrare. Motmedlet är att kräva motiveringar i beslut och att hålla ändringarna små nog att någon faktiskt läser dem.

• Hemligheter och nycklar ska aldrig ligga där en agent läser dem av misstag
• Beroenden som föreslås automatiskt behöver kontrolleras innan de införs
• Produktionsdata ska inte användas som underlag i utvecklingsarbete
• Behörigheter för automatik ska vara egna och begränsade, inte en administratörs

Mät på flöde och kvalitet, inte på antal rader kod. Rimliga mått är tiden från påbörjad uppgift till driftsatt ändring, hur stor andel av ändringarna som behöver rättas i efterhand, och hur ofta något går sönder i produktion. Ökar tempot medan felen ligger stilla är arbetssättet en vinst. Ökar båda har ni bara flyttat arbetet framåt i tiden.