AI för att koda – bygger vi snabbt eller bygger vi rätt?

Att bygga med AI går snabbt – men vad händer sen? Jag byggde nyligen en applikation utan hjälp av en enda utvecklare. Det gick snabbt. Ovanligt snabbt. Men det väckte en viktig fråga: Vad händer med kvalitet, ansvar och långsiktig hållbarhet när AI bygger?

Jag skulle bygga ett system för att mäta och främja AI-användning. För att testa på, men också för att få till något som funkar.

Först och främst: AI fungerar bra när riktningen är tydlig. När den inte är det fungerar det inte fullt lika bra.

Onödigt komplext – när riktningen inte är tydlig

Orutinerat definierade jag inte vad “främja” faktiskt innebär. Det är inte likt mig, men jag skyller på att jag blev omtumlad av upplevelsen att för första gången ”själv” kunna skapa något. När jag inte hade definierat främja fick jag diverse funktioner som hade kunnat främja, men som inte behövdes. Jag fick bl a AI-genererade tips om hur man kan använda AI i viss uppdragsroll, som ingen vill ha, en möjlighet att chatta med en AI om hur jag kan nyttja AI för X, vilket var helt överflödigt att lägga datorkraft på, det finns så många lösningar för det utanför mitt lilla ”system”. Jag fick även kreativa förslag kring personliga rekommendationer med mera.

Det såg bra ut, men det skapade inget värde.

Det räckte med ett bibliotek där människor delar tips med varandra om hur de skapar värde med AI i sina olika uppdragsroller.

Utvecklare gör mer än att skriva kod

Utvecklarens roll är mycket större än att skriva kod. Utvecklare:

• ifrågasätter behov och krav
• identifierar risk
• skyddar arkitektur och kvalitet
• och – inte minst –vad som kommer sen

Den sista punkten är avgörande. För det är där skalbarhet, förvaltning och vidareutveckling säkras. AI ställer inte de frågorna.

Kort sikt optimeras – lång sikt lämnas öppen

När något “fungerar” är det lätt att gå vidare. En erfaren utvecklare stannar och frågar:

• Hur ska detta vidareutvecklas?
• Hur ska det skalas?
• Vilka beroenden skapar vi?

AI optimerar att lösa uppgiften här och nu. Inte att lösningen ska fungera över tid.

Validering är fortfarande ett mänskligt ansvar

Ett konkret exempel:

En dashboard visade att konsulter sparade “tre timmar per vecka”. Det fanns dock ingen sådan fråga i enkäten.

Ett annat exempel:

En bugg identifierades och åtgärdades lokalt – men utan analys av om samma problem fanns på andra ställen.

Detta illustrerar en viktig skillnad: AI levererar svar – men tar inte ansvar för helheten.

Transparens och teknisk skuld blir en risk

Systemet fungerar. Men centrala frågor kvarstår:

• Hur ser lösningen ut under ytan?
• Hur mycket teknisk skuld byggs upp?
• Är arkitekturen hållbar?
• Går lösningen att vidareutveckla?

Här uppstår en ny typ av risk: Vi kan bygga fungerande lösningar som vi inte fullt ut förstår eller kan förvalta.

AI kräver mer styrning – inte mindre

Det är lätt att tro att AI minskar behovet av struktur och styrning. I praktiken är det tvärtom.

För att lyckas med AI i systemutveckling krävs:

• tydlig målbild
• explicita avgränsningar
• aktiv validering av resultat
• fokus på arkitektur och teknisk hållbarhet

Från att bygga snabbt till att bygga hållbart

Diskussionen om AI handlar ofta om hastighet.

Men den viktigaste frågan är en annan:

Hur säkerställer vi att det vi bygger går att förstå, vidareutveckla och förvalta över tid?

Vad innebär det i praktiken?

För organisationer som vill använda AI i utveckling innebär det att:

• definiera vad som inte ska byggas
• säkerställa att lösningar går att bygga vidare på
• arbeta aktivt med teknisk skuld
• behålla kompetens för arkitektur och kvalitet

Avslutning

AI förändrar hur vi bygger system. Men det förändrar inte ansvaret.

Ansvar för riktning, kvalitet och långsiktighet kan inte delegeras till AI.