Vad som händer efter att koden genererats
AI har förändrat vad en utvecklingsbudget räcker till. När en första implementation kan genereras på minuter kan mer av ett uppdrag läggas på funktionalitet, integrationer och förbättringar som tidigare hamnade utanför omfattningen.
Förändringen är inte jämnt fördelad. Googles DORA-undersökning för 2025 ser AI-användning kopplad till både högre leveranstakt och lägre leveransstabilitet samtidigt. Mer kommer ut, och mer går sönder. Vilken av de två som dominerar avgörs till stor del efter att koden genererats.
Det väcker en rimlig fråga inför rekryteringen: hur mycket seniort utvecklingskunnande behöver ni fortfarande?
Från att skriva varje rad till att styra implementationen
Svaret börjar i det som händer efter att koden genererats. Någon måste fastställa att den löser rätt problem, fungerar under verkliga förhållanden och passar in i en lösning verksamheten kan fortsätta bygga vidare på. Det ansvaret blir en allt större del av en senior utvecklares arbetsdag.
I mitt eget arbete har förskjutningen gått från att skriva kod för hand, till att löpande granska AI-genererad kod, till att styra större förändringar och kontrollera hur de fungerar tillsammans.
AI producerar kod snabbare än jag hinner skriva den. Det flyttar min tid: att reda ut krav, ge implementationen riktning, granska beslut, testa beteende och se till att förändringar hamnar i rätt del av lösningen.
Arkitektur och test har alltid varit seniora ansvarsområden. Det som ändrats är balansen i arbetet. När mindre tid går åt till att producera välbekant kod kan mer uppmärksamhet läggas på de beslut som avgör om en funktion förblir användbar och förvaltningsbar.
Dit hör att säga nej till en fungerande implementation när den skapar onödiga beroenden, dubblerar befintlig logik eller gör nästa ändring svårare.
Att funktionen fungerar är bara första provet
Ta ett registreringsflöde för kunder som är kopplat till ett CRM.
AI genererar formuläret, valideringen och integrationen snabbt. I en demonstration fyller kunden i sina uppgifter och en post dyker upp i CRM-systemet. Funktionen fungerar.
Men vad händer om CRM-systemet inte svarar? Om kunden skickar in två gånger? Om ytterligare en applikation behöver samma registreringsprocess nästa månad?
De frågorna påverkar både beteende och arkitektur. Affärsreglerna behöver en tydlig hemvist. Integrationen behöver vettig felhantering. Delad logik ska gå att återanvända utan att kopieras in på ytterligare en sida.
En implementation som förbigår de besluten kan mycket väl klara sin första demonstration. Kostnaden kommer senare, när en liten ändring kräver redigeringar på flera ställen eller när nästa utvecklare måste reda ut den ursprungliga lösningen innan något nytt kan läggas till.
Seniort omdöme bidrar till att dagens leveranshastighet inte blir morgondagens förvaltningskostnad. Det håller också lösningen rimlig i omfattning: en okomplicerad funktion ska inte bli ett utbyggt ramverk för hypotetiska krav.
Vad samma budget räcker till
När implementationen tar kortare tid och resultatet håller kan samma budget täcka mer levererad omfattning.
Det kan betyda att koppla på ytterligare ett verksamhetssystem, förbättra en kundresa eller bli klar med ett internt verktyg som tidigare stannade vid en prototyp. Det kan också betyda att en funktion blir produktionsfärdig inom en budget som tidigare räckte till grundfunktionaliteten.
Vinsterna beror på arbetet och miljön, och de kommer inte av sig själva. Det är vad stabilitetshalvan av DORA-resultatet beskriver: rapportens egen slutsats pekar på ingenjörspraxisen runt verktygen – test, återkoppling och arkitektur – snarare än på verktygen i sig.
Det finns dessutom ett mätproblem värt att känna till. I en randomiserad studie som METR publicerade i juli 2025 arbetade 16 erfarna utvecklare igenom 246 verkliga ärenden i kodbaser de kände väl. Med AI-verktyg tillåtna tog det 19% längre tid – och efteråt trodde de fortfarande att de varit 20% snabbare. Författarna är tydliga med att resultatet inte kan generaliseras till allt utvecklingsarbete. Vad det visar är att en upplevelse av hastighet inte är en mätning.
För den som rekryterar gör det måttet till tillförlitlig funktionalitet levererad inom budget, inklusive arbetet med att förvalta den. Kodvolym och självskattad hastighet berättar bara en del.
Det kommersiella värdet av en erfaren utvecklare är att föra samman krav, implementation och verifiering så att snabbare produktion blir ett användbart resultat.
Vad ni bör titta efter vid rekrytering
Det här förändrar hur jag själv skulle bedöma utvecklingskapacitet.
Be en kandidat gå igenom en genererad implementation och förklara vad hen skulle behålla, ändra eller förkasta. Kan hen koppla sina beslut till verksamhetskravet? Känna igen befintlig funktionalitet som borde återanvändas? Förklara hur resultatet skulle testas?
Titta efter bredd också. En funktion kan beröra gränssnitt, applikationslogik, databas, integration och driftkonfiguration. Den som tar ägarskap behöver förstå sambanden och märka när specialistkunskap krävs.
Slutligen: titta efter ansvar hela vägen till leverans. Att granska kod är en del av arbetet. Det är också att reda ut oklara krav, korrigera implementationen och få den säkert i produktion.
En sak förändras inte: det är fortfarande värt att rekrytera juniora utvecklare. Men juniorer som arbetar med AI behöver mer granskningskapacitet per person, inte mindre, och den kapaciteten tas ur samma seniora personer. Planera för det i stället för att upptäcka det.
Det här är praktiska sätt att bedöma om någon kan omsätta AI-stödd utveckling i pålitliga framsteg.
Ett skäl att ta upp projektet ni sköt upp
Om en integration, kundportal eller ett internt verktyg tidigare kändes för dyrt kan det förtjäna en ny titt.
Börja med ett tydligt verksamhetsproblem och en avgränsad första release. Seniort deltagande i det skedet hjälper till att sätta de ansvarsgränser och konventioner som senare utveckling följer. De besluten är enklare att fatta innan funktioner hunnit samlas runt dem.
AI kan bidra till att snabba upp implementationen, medan en erfaren utvecklare håller omfattningen realistisk och grunden redo för nästa användbara tillägg.
Sätt kapaciteten i arbete
Jag har arbetat med .NET sedan 2008 och med Umbraco sedan 2013, med en bakgrund nära marknad, försäljning och verksamhetens beslutsfattare.
För företag kan jag ta ett krav från första samtal genom implementation, release och löpande förbättring. För byråer bidrar jag med senior leveranskapacitet och tekniskt ägarskap vid sidan av ert befintliga team. För produktteam kan jag ta ansvar för utvecklingsarbetet med blick för både den aktuella releasen och det som kommer sedan.
Har ni ett projekt i tankarna eller en backlogg som behöver röra sig: hör av er med verksamhetsmålet, vilket stöd ni behöver och när ni helst vill starta. Så pratar vi om en praktisk omfattning och min tillgänglighet.
För nya Umbraco-projekt kan min plattform dessutom ge en färdig utgångspunkt, så att mer av budgeten går till det som är specifikt för er verksamhet.
Siffrorna kontrollerade mot primärkällorna den 15 september 2026: Googles DORA-rapport State of AI-assisted Software Development 2025 och METR:s randomiserade studie från juli 2025. Båda är värda att läsa i sin helhet, inklusive de begränsningar författarna själva anger.