Flytande mjukvara

Det finns en känsla jag inte blir av med just nu: att mjukvara håller på att bli… flytande.

Som att den inte längre är något man bygger sten för sten, utan något man tappar upp. Du vrider på kranen, beskriver vad du vill ha, och så rinner det ut kod, komponenter, API-anrop, tester, UI – ibland nästan färdigt.

Och om jag ska vara ärlig: första impulsen är rätt dystopisk.

Om kod är det jag gör hela dagarna, och kod plötsligt blir “billig” eller nästan gratis – vad är jag då? Vad händer med hantverket? Med stoltheten i att kunna ett språk, en stack, en arkitektur? Är det bara att tacka för sig när Lovable, Cursor, Claude Code och allt vad de heter blir bättre än mig på att spotta ur sig fungerande lösningar?

Det är lätt att hamna där.

Men när jag landar lite i det så ser jag en annan bild. Inte att utvecklarrollen försvinner – utan att den byter tyngdpunkt. Och det är kanske där det blir intressant på riktigt.

Kod var aldrig målet

Vi har i åratal låtsats (lite) att kod är produkten. I verkligheten har kod alltid varit ett medel.

Det vi egentligen försöker göra är något så här:

• förstå ett problem
• välja vad som är viktigt
• hitta en lösning som funkar i verkligheten
• få den att hålla över tid

Kod är bara det material vi råkat använda för att förverkliga det.

När mjukvara blir “på tapp” blir kod mer som… byggskum. Användbart, snabbt, ibland magiskt. Men fortfarande bara material.

Och då blir det tydligare vad som faktiskt är svårt.

Om AI nu tar de “kreativa” jobben?

Det sägs ofta att AI kommer ta kreativa jobb. Jag köper inte den bilden, åtminstone inte så som “kreativitet” brukar fungera i praktiken.

Det AI vi använder idag är extremt bra på att transformera:

• text → text
• krav → kod
• kod → bättre kod
• mockup → UI
• buggrapport → fix

Det är en slags probabilistisk remixmaskin. En väldigt kraftfull sådan, absolut. Men den skapar nästan alltid genom att fortsätta i spåret av något som redan är bekant.

Det är inte samma sak som att vilja något. Eller att känna av de där subtila behoven som inte riktigt går att skriva ner i en prompt:

• “den här knappen känns fel, men jag vet inte varför”
• “vi behöver fart, men inte på bekostnad av förtroende”
• “det här måste funka för någon som är stressad, trött och lite irriterad”
• “vi behöver inte fler funktioner – vi behöver färre, men rätt”

Sånt där är inte en transformation. Det är förståelse, prioritering och omdöme.

Och det är där jag tror att människans värde snarare ökar än minskar.

Så vad återstår när kodandet blir billigt?

Om vi tänker att mjukvara blir mer som att “tappa upp” lösningar, då flyttar våra färdigheter upp ett steg. Jag ser några saker som blir mer relevanta:

1) Problemformulering som superkraft

Att kunna säga: “Det här är det egentliga problemet.”

Inte “vi behöver en app”, utan:

• vem har ont?
• varför gör det ont?
• när gör det ont?
• vad har de försökt?
• vad betyder “fungerar” i deras värld?

Det här är svårt idag. Det blir inte mindre svårt av att vi får fler verktyg.

2) Att översätta behov till en tydlig modell

När någon säger “vi vill ha ett enkelt flöde”, menar de vad då?

Ett flöde är en serie beslut. Data. Tillstånd. Gränser. Undantag. Säkerhet. Integritet. Ansvar. Och en massa “vad händer om…?”.

AI kan hjälpa oss implementera. Men någon måste fortfarande skapa en formulerad lösning: en modell som går att bygga, testa och förbättra.

3) Omdöme: vad ska vi inte bygga?

När det blir billigt att bygga blir det dyrt att välja.

Billig kod leder lätt till:

• fler features
• fler beroenden
• fler edge cases
• mer underhåll
• mer förvirring

Den som kan säga “nej” på rätt sätt blir ovärderlig. Inte som gatekeeper, utan som någon som håller riktningen.

4) Smak och helhet

Det finns något jag bara kan beskriva som “produktkänsla”: att kunna se helheten.

Att förstå att tekniken inte är produkten – upplevelsen är produkten. Och att upplevelse är en kombination av hundra små beslut.

AI kan ge fem förslag. Men vem väljer vilket som passar sammanhanget, varumärket, människorna och framtiden?

5) Ansvar och förtroende

När mjukvara rinner ut ur kranen blir frågan: vem står för den?

Vem tar ansvar för:

• säkerhet
• data
• fel som får konsekvenser
• att systemet beter sig “rimligt” i gråzoner

Det blir mer mänskligt, inte mindre. För ansvaret går inte att prompta bort.

En ny roll: från kodare till regissör

Jag tror att utvecklare mer och mer blir regissörer.

Vi kommer fortfarande förstå teknik – kanske mer än någonsin. Men fokus flyttar från att sitta och skriva varje rad till att:

• skapa rätt ramar
• ställa rätt frågor
• specificera på rätt nivå
• iterera snabbt
• kvalitetssäkra
• hålla ihop helheten

Och ja: ibland kommer vi fortfarande behöva gå ner på “rå kod”-nivån. Precis som en bra regissör ibland tar kameran själv. Men det är inte där värdet sitter längre.

Den optimistiska versionen

Här är visionen jag faktiskt blir pepp av:

När mjukvara blir flytande kan fler människor lösa fler problem. Små idéer kan bli riktiga verktyg utan att kräva ett helt team, en budget och ett halvår.

Det betyder att:

• fler kan bygga hjälpmedel för sina egna vardagsproblem
• nischade behov kan få lösningar
• vi kan testa idéer snabbare
• vi kan lägga mer tid på att förstå, mindre på att traggla

Och för oss som gillar att bygga saker? Det är ju egentligen drömmen.

Vi tappar inte hantverket. Vi byter hantverk.

Från att “skriva kod” till att forma lösningar.

Och när jag tänker på det så känns det inte som slutet på utveckling.

Det känns mer som att vi precis har börjat vrida på kranen.