En del är naturligtvis helt med på tåget och följer utvecklingen dagligen. Andra har kanske börjat använda AI för att skriva texter, sammanfatta dokument eller ställa frågor, men har inte riktigt förstått hur långt tekniken redan har kommit. Och det är väl inte så konstigt egentligen. Det händer så mycket att det som var imponerande för några månader sedan redan kan kännas gammalt.
Men en sak är jag helt övertygad om.
Vi befinner oss mitt i en revolution.
Och då menar jag inte bara att vi har fått ett nytt praktiskt verktyg som gör vissa arbetsuppgifter lite enklare. Jag menar en förändring av hur vi arbetar, utvecklar, skapar, organiserar och förhåller oss till teknik överhuvudtaget.
Vi pratar mycket om AI, artificiell intelligens, men också allt mer om AGI, artificiell generell intelligens, och ASI, artificiell superintelligens. Exakt när och hur vi når de senare nivåerna kan man naturligtvis diskutera. Men för mig är det egentligen inte det mest intressanta just nu.
Det intressanta är vad vi redan kan göra idag och vad det innebär för morgondagen.
Från ett ganska begränsat hjälpmedel till något helt annat
Jag började använda AI som stöd i programmering och utveckling redan under 2023. På den tiden var det ganska begränsat. Visst kunde man få hjälp med mindre kodsnuttar, felsökning och en del enklare funktioner, men det var långt ifrån något man kunde förlita sig på för större utvecklingsarbeten.
Det blev ofta fel, man fick rätta mycket själv och det krävdes en hel del tålamod. Men jag såg ändå möjligheterna redan då.
Sedan dess har utvecklingen varit närmast absurd.
Under 2024 och 2025 blev verktygen successivt bättre, men framför allt från slutet av 2025 och under 2026 har jag upplevt en förändring som är svår att jämföra med något annat jag varit med om inom IT och utveckling.
Det handlar inte längre bara om att få hjälp med att skriva kod. Nu kan man arbeta tillsammans med AI-agenter som kan planera, utveckla, felsöka, testa, granska, dokumentera och förbättra hela system. Flera agenter kan dessutom arbeta med olika delar av samma projekt.
Man kan beskriva ett behov, resonera kring olika lösningar, få något utvecklat, testa resultatet och sedan fortsätta förbättra. Allt i en sammanhängande process.
Det som tidigare kunde ta dagar eller veckor kan i vissa fall göras på timmar. Ibland ännu snabbare.
Naturligtvis beror det på vad man utvecklar, hur komplicerat det är och vilka krav som finns. Men skillnaden är ändå enorm.
Och utvecklingen verkar snarare accelerera än bromsa in.
Människans roll förändras
Det här tycker jag är en av de mest intressanta delarna av revolutionen.
Tidigare har mycket av kompetensen inom programvaruutveckling handlat om att faktiskt kunna skriva kod. Att behärska programmeringsspråk, ramverk, databaser och tekniska lösningar.
Den kunskapen är fortfarande värdefull. Jag tycker absolut att man har nytta av en grundläggande förståelse för hur system fungerar, hur programvara är uppbyggd och inte minst informationssäkerhet och cybersäkerhet.
Men tyngdpunkten håller på att förskjutas.
Det blir allt viktigare att förstå vad som behöver utvecklas än att själv kunna skriva varje rad kod.
Att kunna identifiera ett behov, analysera det, se möjligheter, formulera krav och kommunicera vad man faktiskt vill åstadkomma blir centrala kompetenser.
Det gäller också att kunna föra en bra dialog med AI. Att resonera, ifrågasätta, förtydliga och styra arbetet mot rätt resultat.
Jag brukar tänka att man allt mer får rollen som beställare, arkitekt, projektledare och kvalitetsansvarig på samma gång.
Man behöver inte nödvändigtvis kunna utföra varje tekniskt moment själv, men man behöver förstå vad man försöker åstadkomma och kunna bedöma om resultatet motsvarar behovet.
Och när man utvecklar för andra, vilket jag också gör, blir verksamhetsförståelsen minst lika viktig.
Att kunna prata med människor, förstå deras vardag, arbetsprocesser, problem och önskemål. Att kunna ställa rätt frågor och ibland upptäcka behov som beställaren själv inte riktigt har formulerat.
Det är ju egentligen det som borde ha varit i centrum hela tiden.
Nu frigör tekniken betydligt mer tid för just detta.
Men behöver man verkligen kunna programmera längre?
Det är en intressant fråga.
För enklare applikationer, mindre verktyg och det som ibland kallas vibe coding, där man beskriver vad man vill ha och låter AI sköta programmeringen, behöver man i praktiken inte kunna skriva särskilt mycket kod alls längre.
Man kan få fram fullt användbara program genom att beskriva funktioner, testa och återkoppla.
När det gäller större system, särskilt sådana som hanterar känsliga uppgifter eller är verksamhetskritiska, behöver man däremot fortfarande ha ordentlig kontroll över kvalitet, säkerhet, arkitektur, beroenden och förvaltning.
AI kan redan idag hjälpa till med mycket av granskningen genom särskilda gransknings- och felsökningsagenter. Men man behöver fortfarande säkerställa att resultatet verkligen håller.
Att ett system fungerar i en demonstration betyder inte automatiskt att det är lämpligt för skarp drift.
Samtidigt går utvecklingen även inom testning och kvalitetssäkring väldigt snabbt. Hur mycket av den traditionella manuella kodgranskningen som kommer att behövas om ett eller ett par år återstår att se.
Jag skulle inte bli förvånad om även det förändras radikalt.
Däremot tror jag att människans ansvar för att förstå behov, konsekvenser och vad som faktiskt är ett bra resultat kommer att vara viktigt under lång tid.
När en vecka kändes väldigt snabbt
Det här får mig att tänka tillbaka på åren 2006 till 2008, när jag arbetade inom den privata sektorn.
Jag hade då bland annat rollen som projektledare och Scrum Master, och vi ville hitta sätt att snabba upp utvecklingen och få bättre flyt i arbetet.
Vi arbetade med någon slags egen häxbrygd av Scrum och andra agila idéer. Vi plockade helt enkelt de delar vi tyckte fungerade och anpassade dem efter våra behov.
Det var ganska mycket gamla hederliga post-it-lappar på väggen, korta möten och nära samarbete mellan utvecklare och övriga inblandade.
Vi kortade ner våra sprintar till en vecka, vilket kändes väldigt snabbt på den tiden.
På måndagsmorgonen hade vi ett kort stående möte för planering och beslut. På onsdagsmorgonen följde vi upp och justerade vid behov. På fredagsmorgonen hade vi demonstration, redovisning och möjlighet att fatta lite större beslut.
Sedan försökte vi göra resten av fredagen till en lite roligare avslutning på veckan, med spontana hackathons, experiment eller andra trevligheter.
Det fungerade faktiskt väldigt bra.
Vi fick kortare ledtider, snabbare återkoppling och kunde anpassa utvecklingen betydligt oftare än tidigare. Jag minns det som en väldigt positiv och innovativ period.
Och det var det nog också, utifrån förutsättningarna då.
Men tänk vilken skillnad mot idag.
Då var en veckas sprint snabbt.
Nu kan man i vissa projekt genomföra flera utvecklingscykler under samma dag.
Agilt arbete på steroider
Jag har alltid gillat grundtanken med agil utveckling. Att arbeta stegvis, ha nära kontakt med beställaren, testa tidigt och kontinuerligt förbättra.
Men med dagens AI-verktyg går det att ta det arbetssättet till en helt annan nivå.
Man kan börja med ett behov på morgonen, ha en första fungerande lösning senare samma dag och sedan låta beställaren testa och komma med synpunkter.
Efter en kort dialog kan förändringarna genomföras och en ny version vara tillgänglig.
Och sedan fortsätter man.
Utveckla, testa, utvärdera, förbättra.
Om och om igen.
I vissa fall flera gånger om dagen.
Det betyder att beställaren får en helt annan möjlighet att faktiskt påverka slutresultatet. Man behöver inte försöka förutse precis allt i en omfattande kravspecifikation innan utvecklingen ens har börjat.
Man kan naturligtvis fortfarande behöva dokumentera krav och fatta formella beslut, särskilt i större organisationer. Men själva utvecklingsprocessen behöver inte längre vara så tungrodd.
Jag tycker att detta är närmast revolutionerande.
Det förutsätter förstås att även organisationen och beställaren är beredda att arbeta på det sättet. Om tekniken kan leverera en förändring på en timme men beslutsprocessen tar tre månader har man inte riktigt tagit tillvara möjligheterna.
Det är alltså inte bara utvecklarna som behöver förändra sitt arbetssätt.
Hela organisationen behöver förstå vad som blivit möjligt.
Och här tror jag att många fortfarande tänker alldeles för mycket utifrån hur det fungerade tidigare.
Varför köpa något som inte riktigt passar?
En annan sak jag funderat mycket över, framför allt sedan slutet av 2025, är hur vi kommer att se på traditionella programvaror och verksamhetssystem framöver.
Historiskt har vi ofta varit hänvisade till att köpa färdiga produkter.
Man identifierar ett behov, undersöker marknaden, skriver kravspecifikationer, jämför leverantörer, upphandlar eller köper in ett system och försöker sedan anpassa verksamheten och produkten till varandra.
Ibland fungerar det väldigt bra.
Men ganska ofta får man kompromissa.
Systemet kanske innehåller mängder av funktioner som ingen använder, samtidigt som det saknar något som verksamheten verkligen behöver. Anpassningar kan vara dyra, ta lång tid eller helt enkelt inte vara möjliga.
Sedan tillkommer licenser, underhåll, konsultkostnader, integrationer och beroenden till leverantören.
Det här har vi mer eller mindre accepterat som en naturlig del av IT-världen.
Men varför ska det nödvändigtvis fortsätta vara så?
Vad händer när man istället kan bygga exakt det man behöver, anpassat efter sin egen verksamhet, på en bråkdel av den tid det tidigare tog?
Det är här jag tycker att det börjar bli riktigt intressant.
Jag tror att vi kommer att se en stor förändring i hur organisationer tänker kring att köpa eller utveckla system.
Det betyder inte att alla stora verksamhetssystem plötsligt kan ersättas över en natt. Det finns fortfarande frågor om lagkrav, informationssäkerhet, integrationer, drift, support, tillgänglighet och långsiktig förvaltning.
Och att utveckla något snabbt är inte samma sak som att förvalta det säkert under många år.
Men för väldigt många behov, särskilt avgränsade verksamhetsstöd och interna verktyg, har förutsättningarna redan förändrats dramatiskt.
Jag tror att det kommer bli allt svårare att motivera stora kostnader för produkter som inte riktigt motsvarar behoven, när alternativet är att utveckla något eget som passar betydligt bättre.
Förutsatt att man har rätt kompetens och en genomtänkt strategi.
PLAN-B, ett exempel från min egen vardag
Jag kan ta ett konkret exempel.
I mitt nuvarande arbete har jag bland annat en roll inom beredskap och systematisk kontinuitetshantering.
Det handlar förenklat om att identifiera vilka aktiviteter som är kritiska för en verksamhet, vilka resurser och beroenden som krävs för att de ska fungera, vad som kan hända vid störningar och hur verksamheten ska kunna fortsätta även när något allvarligt inträffar.
Man arbetar med analyser, prioriteringar, kontinuitetsplaner, reservrutiner, övningar och förbättringar.
Det är ett viktigt arbete, men det kan också bli ganska omfattande och administrativt.
Förra vintern började jag fundera på varför det inte verkade finnas något riktigt bra, sammanhållet och användarvänligt system för hela den processen.
Åtminstone hade jag inte hittat något som motsvarade det jag själv ville ha.
Så jag började bygga ett.
På fritiden, lite då och då, under några veckor.
Jag kallade systemet PLAN-B.
Tanken var att skapa ett komplett stöd för systematisk kontinuitetshantering och beredskapsarbete. Från att identifiera kritiska aktiviteter och kartlägga beroenden till att analysera konsekvenser, planera åtgärder och ta fram användbara kontinuitetsplaner.
Men också stöd för övningar, uppföljning och förbättringar.
En viktig del var att systemet skulle kunna installeras lokalt och användas utan internetuppkoppling. Det känns ganska självklart för ett system som bland annat ska stödja arbete vid allvarliga störningar.
Jag ville också att det skulle vara lätt att förstå och använda. Inte bara ett avancerat verktyg för specialister, utan något som faktiskt hjälper verksamheter att arbeta strukturerat genom hela processen.
Resultatet blev en fungerande webbapplikation med ganska omfattande funktionalitet.
Jag visade prototypen för några personer som själva arbetar inom området och fick väldigt positiv återkoppling. Några tyckte till och med att jag borde försöka sälja systemet.
Men det var aldrig riktigt min tanke.
För mig var det i första hand ett hobbyprojekt och ett sätt att utforska vad som gick att åstadkomma. Jag har faktiskt också använt delar av det i mitt eget arbete.
Och det som slog mig var hur lite faktisk utvecklingstid det hade tagit.
Ett system av den omfattningen hade jag aldrig kunnat bygga själv på motsvarande tid för bara några år sedan.
Nu kunde jag göra det på relativt få timmar, utspridda över några veckor.
Jag funderar faktiskt på att bygga om PLAN-B från grunden inom kort. Inte för att den första versionen var dålig, utan för att både tekniken och mina egna erfarenheter har utvecklats så mycket sedan dess.
Det säger också en del om hur snabbt allting förändras.
Från måndag eftermiddag till torsdag eftermiddag
PLAN-B är inte det enda exemplet.
Jag har sedan dess utvecklat flera andra system och applikationer, både privat och med koppling till verksamhetsbehov. Några av dem används nu i pilotverksamhet inom Uddevalla kommun.
Ett av dessa projekt tycker jag illustrerar den nya verkligheten ganska väl.
Det började en måndag eftermiddag med ett konkret behov från verksamheten.
Vi hade några korta möten via Teams och en del dialog i Teamschatten. Jag försökte förstå vad man ville uppnå, hur arbetet fungerade och vilka funktioner som faktiskt behövdes.
Sedan utvecklade jag en lösning utifrån detta.
På torsdag eftermiddag samma vecka fanns en fungerande prototyp i demoläge.
Den var enligt min egen bedömning både snygg, användarvänlig och funktionell, med de centrala delarna av verksamhetens önskemål på plats.
Den sammanlagda tiden jag faktiskt lade på utvecklingen var bara några timmar, fördelade över de här dagarna.
Några justeringar gjordes efter demonstrationen och systemet går nu i pilot, där det kan utvärderas och vidareutvecklas utifrån hur det fungerar i praktiken.
Det är just detta jag tycker är så fantastiskt.
Från ett behov som någon beskriver till en konkret, fungerande lösning på några dagar.
Inte månader av förstudier och långa utvecklingsprojekt innan någon ens får se hur det skulle kunna fungera.
Och när verksamheten vill ändra något kan man ofta göra det väldigt snabbt.
Självklart krävs ytterligare arbete med säkerhet, teknisk kvalitet, dokumentation och förvaltning innan ett sådant system kan betraktas som färdigt för bredare användning.
Men själva möjligheten att så snabbt omsätta verksamhetsbehov till något konkret förändrar väldigt mycket.
Det gör också dialogen bättre. Det är ofta lättare för människor att beskriva vad de vill förändra när de faktiskt kan se och prova en lösning, istället för att bara diskutera en tänkt funktion.
Det här är precis den typen av utveckling jag tror vi kommer att få se mycket mer av.
Den stora möjligheten till effektivisering och besparingar
Om man lyfter blicken lite från de enskilda projekten blir konsekvenserna ganska stora.
Det handlar inte bara om att utveckling blir billigare eller snabbare.
Det handlar också om att vi kan få system som bättre motsvarar de faktiska behoven.
Mindre onödig administration, färre omvägar, bättre arbetsflöden och funktioner som är anpassade efter hur människor faktiskt arbetar.
Det finns en enorm potential till effektivisering och det som ofta kallas effekthemtagning, alltså att de förbättringar man vill uppnå verkligen ger nytta i verksamheten.
Och naturligtvis även ekonomiska besparingar.
Men jag tycker inte att man bara ska stirra sig blind på pengar.
Att medarbetare får bättre verktyg, slipper onödigt krångel och kan lägga mer tid på sina egentliga arbetsuppgifter är minst lika viktigt.
Samtidigt behöver man tänka långsiktigt.
Att kunna utveckla ett system snabbt betyder inte att drift och förvaltning blir gratis. Någon behöver fortfarande ta ansvar för säkerhetsuppdateringar, dokumentation, incidenter, användarstöd och vidareutveckling.
Det finns också en risk att man skapar mängder av små system utan någon gemensam struktur, om alla börjar utveckla precis vad som helst.
Därför tror jag att organisationer behöver kombinera den nya utvecklingsförmågan med bra arkitektur, informationssäkerhet och tydligt ansvar.
Men det är ju inget argument för att låta bli.
Tvärtom.
Det handlar om att använda de nya möjligheterna på ett klokt sätt.
Open source förändrar också spelplanen
En annan del av detta som jag tycker är väldigt intressant är open source, alltså programvara med öppen källkod.
Det är naturligtvis inget nytt. Öppen källkod har funnits länge och jag har själv använt Linux och olika öppna programvaror under många år.
Men tillsammans med AI blir möjligheterna ännu större.
Man kan utveckla ett system, dela källkoden med andra och låta fler bidra med förbättringar. Andra kan i sin tur anpassa lösningen efter sina egna behov, förutsatt att licensen tillåter det.
Det betyder att organisationer inte alltid behöver börja från noll.
Man kan samarbeta, återanvända och vidareutveckla.
Jag tycker att det här är en väldigt tilltalande tanke, inte minst inom offentlig verksamhet.
Om en kommun utvecklar ett riktigt bra stöd för ett visst behov, varför ska då hundra andra kommuner behöva köpa eller utveckla hundra separata lösningar för ungefär samma sak?
Det borde finnas betydligt större möjligheter att dela, samarbeta och anpassa.
Naturligtvis behöver det finnas någon form av struktur för ansvar, kvalitet och förvaltning även här.
Men möjligheterna är enorma.
Och AI gör det mycket lättare att både förstå och vidareutveckla befintlig öppen källkod.
Behöver vi verkligen alla de gamla programvarorna?
Under 2026 har jag också följt och testat en hel del nyutvecklade programvaror som försöker erbjuda alternativ till etablerade kommersiella produkter.
Det handlar bland annat om program för bildredigering, grafik, dokument, presentationer och andra vanliga arbetsuppgifter.
Flera är utvecklade med omfattande hjälp av AI och en del är dessutom helt öppna projekt.
Och vet ni vad?
En hel del av det är faktiskt riktigt bra.
Inte bara någon halvdålig demonstration som ser imponerande ut på en skärmbild men knappt fungerar i praktiken.
Det finns naturligtvis gott om sådant också.
Begreppet AI slop används ofta om lågkvalitativt, massproducerat AI-genererat innehåll som saknar verkligt värde. Det kan vara allt från bilder och texter till programvara som mest ser färdig ut på ytan.
Men att något har utvecklats med AI betyder inte automatiskt att det är dåligt.
Precis som traditionellt utvecklad programvara kan vara både fantastisk och fullständigt värdelös.
Det avgörande är resultatet, kvaliteten och om produkten faktiskt löser ett behov.
När jag ser hur snabbt nya alternativ till exempelvis Adobe-program och Microsoft Office-liknande program utvecklas börjar jag fundera över hur marknaden kommer att se ut om några år.
Vem kommer egentligen att vilja betala stora licenskostnader för funktioner som man kanske bara använder en bråkdel av?
Visst finns det fortfarande goda skäl att köpa etablerade produkter. Kompatibilitet, avancerade funktioner, samarbete, support och integrationer är viktiga för många användare och organisationer.
Men alternativen blir fler.
Och framför allt behöver man inte längre automatiskt utgå från att man måste köpa ett färdigt program för att få tillgång till en viss funktion.
Man kan faktiskt bygga sitt eget.
Det hade låtit ganska orimligt för bara några år sedan.
Nu görs det hela tiden.
Jag har börjat ersätta mina egna program
För min egen del har det här redan förändrat ganska mycket.
Under 2025 och framför allt under 2026 har jag successivt börjat ersätta stora delar av de program jag använder privat med egenutvecklade alternativ.
Inte för att det nödvändigtvis saknas bra program på marknaden.
Utan för att jag numera kan skapa precis det jag själv vill ha.
Jag använder idag egna programvaror för bland annat dokumentredigering, presentationer, projektarbete, anteckningar, uppgifter och påminnelser, programmering, filhantering, musik, radio och annan media.
Och en hel del annat.
Flera av dessa använder jag dagligen.
Jag har utvecklat dem med hjälp av AI, utifrån mina egna önskemål om funktionalitet, utseende och arbetssätt.
Det är en ganska speciell känsla att använda program som fungerar precis som man själv vill ha dem.
Jag gillar exempelvis mörka, minimalistiska gränssnitt. Gärna lite noir-känsla, avskalat och utan en massa visuellt brus.
Jag vill ha tydliga funktioner, snabb respons och så lite onödigt krångel som möjligt.
Då bygger jag det så.
Det handlar mycket om det som brukar kallas UX, User Experience, alltså användarupplevelsen. Hur det känns att använda ett program, hur lätt det är att förstå, navigera och få saker gjorda.
Jag tycker att UX är minst lika viktigt som själva funktionerna.
Ett program kan ha hundratals avancerade funktioner, men om det är krångligt att använda eller om jag bara behöver tio av dem så är det inte säkert att det är rätt program för mig.
När jag utvecklar själv kan jag välja bort allt det där.
Jag kan bygga något som gör exakt det jag behöver, på det sätt jag vill arbeta.
Och när jag kommer på något som kan förbättras är det bara att fortsätta utveckla.
Ibland kan jag sitta på kvällen och komma på en funktion jag saknar, beskriva den för en AI-agent, resonera kring lösningen och testa en fungerande version en stund senare.
Det är ganska fantastiskt egentligen.
Jag har också börjat tänka mer modulärt kring mina program. Att de ska vara resurssnåla, fungera i de Linuxmiljöer jag använder och inte vara beroende av en massa onödiga komponenter.
Många av projekten har jag lagt upp på GitHub, dels för att ha ordning på utvecklingen och versionshanteringen, dels för att andra ska kunna ta del av det jag gör.
Det är fortfarande hobbyprojekt och en del är under ständig utveckling. Men det är också en stor del av nöjet.
Jag kan experimentera, lära mig nya saker och hela tiden förbättra.
Och jag behöver inte vänta på att någon annan ska prioritera en funktion eller släppa nästa stora uppdatering.
Det handlar inte bara om tekniken
Något jag tror är viktigt att förstå är att den här förändringen inte enbart handlar om hur bra AI-modellerna blir.
Det handlar minst lika mycket om hur vi människor lär oss att använda dem.
Man kan ha tillgång till världens bästa AI-verktyg och ändå få ganska begränsad nytta av det om man fortsätter arbeta precis som tidigare.
Jag tror att nyfikenhet, förmågan att se möjligheter och viljan att lära sig nya arbetssätt kommer att bli väldigt viktiga egenskaper.
Man behöver inte vara expert på allt.
Men man behöver vara beredd att ompröva sådant som tidigare har känts självklart.
Varför gör vi på det här sättet?
Måste det verkligen ta så lång tid?
Behöver vi köpa den här produkten?
Skulle vi kunna lösa problemet på ett helt annat sätt?
Och kanske framför allt: Vad är det vi egentligen försöker åstadkomma?
Det är frågor jag tycker att man borde ställa sig betydligt oftare.
För mig är det också viktigt att inte fastna i tekniken för teknikens egen skull.
Det är lätt att bli imponerad av vad AI kan producera, men det betyder ju inte att allt som går att bygga också behöver byggas.
Ibland är den bästa lösningen att förenkla något som redan finns.
Ibland är det att ta bort ett onödigt arbetsmoment.
Och ibland är det faktiskt att inte utveckla något alls.
Den verkliga kompetensen ligger i att förstå skillnaden.
Vad händer med den traditionella utvecklarrollen?
Jag tror att vi kommer att få se ganska stora förändringar inom hela IT-branschen.
Det betyder inte att programmerare och utvecklare plötsligt blir överflödiga. Men jag tror att själva yrkesrollen kommer att förändras mycket.
Den som framför allt ser sitt värde i att manuellt producera kod kommer sannolikt att få det svårare att konkurrera med någon som kan kombinera teknisk förståelse, verksamhetskunskap och effektiv användning av AI.
Samtidigt tror jag att riktigt duktiga utvecklare kan bli ännu mer produktiva än tidigare.
De kan lägga mindre tid på rutinmässig kodning och mer tid på arkitektur, problemlösning, kvalitet och sådant som faktiskt kräver djup förståelse.
Men även de delarna kommer naturligtvis att påverkas av AI.
Det är just därför jag tycker att det är så svårt att säga exakt hur framtidens utvecklarroll kommer att se ut.
Vi försöker beskriva morgondagen med utgångspunkt i dagens teknik, samtidigt som förutsättningarna förändras nästan hela tiden.
Det enda jag känner mig ganska säker på är att vi inte kommer att fortsätta arbeta på samma sätt som tidigare.
Den gamla modellen med långa utvecklingsprojekt, omfattande manuellt kodarbete och långsamma leveranser kommer att få allt svårare att hävda sig där det finns möjlighet att arbeta snabbare.
Det betyder inte att allt ska gå fort till varje pris.
Men om man kan uppnå samma eller bättre kvalitet på betydligt kortare tid, varför skulle man då välja det långsammare alternativet?
Att hänga med utan att behöva förstå precis allt
En annan tanke är hur svårt det faktiskt har blivit att hålla sig uppdaterad.
Det kommer nya modeller, nya agentverktyg, nya utvecklingsmiljöer och nya arbetssätt i en takt som jag aldrig tidigare har upplevt.
Ibland kan något man lärde sig för några månader sedan redan ha ersatts av något betydligt bättre.
Det kan naturligtvis kännas lite överväldigande.
Men jag tycker framför allt att det är roligt.
Jag har alltid haft ett stort intresse för teknik, utveckling och att hitta bättre sätt att göra saker. Och just nu känns det som att möjligheterna är nästan obegränsade.
Jag försöker följa utvecklingen, testa nya verktyg och framför allt använda dem i praktiken.
För det är först när man faktiskt börjar arbeta med tekniken som man på allvar förstår vad den kan göra.
Att läsa om nya AI-modeller är en sak.
Att själv utveckla ett fungerande system på några timmar, som tidigare hade krävt ett helt utvecklingsteam under betydligt längre tid, är något helt annat.
Då blir förändringen väldigt konkret.
Samtidigt tror jag inte att man behöver springa efter precis varje nyhet. Det viktiga är att förstå riktningen och vara beredd att förändra sitt arbetssätt när det finns goda skäl.
Det gäller att vara nyfiken, men också kritisk.
Allt nytt är inte automatiskt bättre.
Och AI kan fortfarande göra fel, ibland på ett väldigt övertygande sätt.
Därför behöver man fortsätta tänka själv.
Vi har egentligen bara börjat
Det är lätt att tänka att AI-revolutionen är något som kommer att hända i framtiden.
Att vi om fem eller tio år kommer att få se stora förändringar i arbetslivet och samhället.
Men jag tycker att det är ett märkligt sätt att se på det.
För förändringen pågår ju redan.
Jag ser den i mitt eget arbete, i mina hobbyprojekt och i hur snabbt det numera går att omsätta en idé till något fungerande.
Det som tidigare hade krävt stora resurser kan idag i vissa fall genomföras av en enda person med rätt kunskap och verktyg.
Och då är vi fortfarande bara i början av utvecklingen.
Tänk vad det innebär när AI-agenter blir ännu bättre på att arbeta självständigt, samarbeta, testa sina egna resultat och hantera allt mer komplicerade uppgifter.
När man kan beskriva ett verksamhetsbehov och få hjälp inte bara med utvecklingen, utan även med analys, arkitektur, dokumentation, säkerhetsgranskning och långsiktig förvaltning.
Mycket av detta är redan möjligt i varierande grad.
Och det kommer sannolikt att bli betydligt bättre.
Jag tror att organisationer som tidigt förstår detta och bygger upp rätt kompetens kommer att ha stora möjligheter att förbättra sina verksamheter.
Inte bara genom att spara pengar, utan genom att skapa bättre lösningar, kortare ledtider och större möjlighet att anpassa sig när behoven förändras.
De som däremot fortsätter att tänka och arbeta precis som tidigare riskerar att hamna långt efter.
Inte för att de nödvändigtvis gör ett dåligt arbete, utan för att spelplanen förändras.
Och den förändras snabbt.
En ny tid, som egentligen började igår
När jag tänker tillbaka på hur jag arbetade med utveckling för tjugo år sedan, eller bara för tre år sedan, är skillnaden nästan svår att ta in.
Det som kändes innovativt och snabbt 2007 framstår idag som ganska långsamt.
Och det som känns avancerat idag kanske framstår som primitivt redan nästa år.
Jag tycker att det är fascinerande.
För egen del vill jag fortsätta utforska möjligheterna, utveckla mina egna kunskaper och använda tekniken till att skapa sådant som faktiskt gör nytta.
Både för mig själv och för andra.
Jag gillar kombinationen av teknik, kreativitet, verksamhetsförståelse och problemlösning. Att kunna gå från en tanke eller ett behov till något konkret, användbart och genomarbetat.
Och att sedan fortsätta förbättra.
Det har alltid varit en drivkraft för mig, men aldrig tidigare har möjligheterna varit så stora som nu.
Jag tror också att vi behöver börja värdera vissa kompetenser annorlunda.
Att förstå människor och deras behov, kunna kommunicera, se sammanhang, tänka kritiskt och omsätta idéer till fungerande lösningar kommer att vara oerhört värdefullt.
Att bara kunna utföra ett visst tekniskt moment räcker inte på samma sätt längre, när tekniken själv blir allt bättre på att utföra det.
Det här innebär naturligtvis också utmaningar. För arbetsmarknaden, utbildningssystemet, organisationer och samhället i stort.
Alla förändringar kommer inte att vara positiva och det finns mycket vi behöver fundera över när det gäller ansvar, säkerhet, beroenden och hur tekniken används.
Men jag väljer att framför allt se möjligheterna.
För det finns något väldigt tilltalande i tanken att fler människor kan få möjlighet att förverkliga sina idéer utan att begränsas av samma tekniska och ekonomiska hinder som tidigare.
Att en person med en bra idé, förståelse för ett problem och förmågan att använda rätt verktyg kan skapa något som tidigare hade krävt betydligt större resurser.
Det förändrar förutsättningarna för väldigt mycket.
Och det är väl egentligen det som är kärnan i allt jag försökt resonera mig fram till här denna tidiga söndagsmorgon.
Vi behöver inte vänta på framtiden för att börja arbeta på ett nytt sätt.
Den är redan här.
Vi är i en revolution.
Och jag tänker definitivt inte sitta kvar i baksätet och titta på.