AI gjør det lett å starte turen. AI-vett avgjør om du kommer trygt frem.
Med verktøy som ChatGPT, Claude og Copilot kan man generere fungerende kode på minutter. Oppgaver som tidligere krevde utviklingsteam og lange prosjekter, kan nå løses av enkeltpersoner i løpet av en ettermiddag. Dette gir enorme muligheter, men får også konsekvenser! For selv om AI gjør det lettere å skrive kode, skal systemer leve videre lenge etter at koden ble skrevet.
Les artikkelen og sjekk ut våre AI-vettregler, enkle prinsipper inspirert av fjellvettreglene som hjelper organisasjoner å navigere trygt i en AI-drevet hverdag.
For første gang i historien kan nesten hvem som helst bygge programvare. Når flere løsninger utvikles raskt, øker samtidig kompleksiteten i organisasjonen. Flere små verktøy, automatiseringer, integrasjoner og systemer dukker opp, og det blir vanskeligere å holde oversikt.
De fleste organisasjoner har gode intensjoner:
-
"Hos oss følger folk policy."
-
"Vi har gode utviklingsprosesser."
-
"Vi forstår problemet før vi utvikler."
-
"Datakvaliteten vår er ganske bra."
-
"Det viktigste er dokumentert."
Dette er gode ambisjoner.
Men virkeligheten i de fleste organisasjoner er litt mer… menneskelig.
-
Folk finner snarveier
-
Kunnskap ligger i hodene til folk
-
Systemer vokser litt etter litt
-
Dokumentasjon kommer ofte i etterkant
Det er ikke nødvendigvis tegn på en «dårlig» organisasjon - det er bare slik organisasjoner ofte fungerer.
Så hva skjer med AI? AI gjør egentlig bare én ting:
Den skrur opp tempoet på alt dette.
Når flere mennesker kan bygge flere løsninger raskere enn før, blir konsekvensene av alle de små valgene større. Små verktøy kan plutselig bli kritiske systemer. Prototyper kan ende opp i produksjon. Integrasjoner kan bli vanskelig å fjerne.
Hva med noen enkle prinsipper å navigere etter?
AI-vettreglene
Noen enkle prinsipper for å bygge systemer i en AI-drevet verden
Som nevnt, senker AI terskelen for å bygge nye løsninger. Det gjør organisasjoner mer innovative, mer eksperimenterende og dette skjer ofte i langt raskere enn før. Men det betyr også at programvarelandskapet kan vokse raskere enn organisasjonen klarer å holde oversikt over.
Når terrenget blir mer komplekst, hjelper det å ha noen enkle regler.
Inspirert av fjellvettreglene har vi formulert noen AI-vettregler for virksomheter som utvikler systemer med AI. De er ikke ment som en fasit. Men de kan fungere som et kart – et sett med prinsipper som gjør det enklere å bygge løsninger som ikke bare fungerer i dag, men også tåler endringer, vekst og uforutsette hendelser.
1. Planlegg systemet, og fortell noen hva dere bygger
Ingen systemer bør eksistere uten at noen vet hvorfor de finnes, hvem som eier dem og hva de brukes til.
I dag oppstår mange løsninger som små initiativer: en automatisering, et script, en intern tjeneste eller en integrasjon mellom to systemer. De løser ofte et konkret problem der og da, men problemet er at slike løsninger ofte blir værende.
Det som startet som et lite verktøy kan etter hvert bli en viktig del av arbeidsflyten. Kanskje brukes det av flere team. Kanskje kobles det til nye systemer. Kanskje blir det kritisk for en prosess.
Derfor er det lurt å starte med en enkel plan:
-
Hva bygger vi?
-
Hvilket problem løser det?
-
Hvem eier løsningen?
-
Hvem har ansvar hvis noe slutter å virke?
2. Tilpass løsningen etter kompetanse, behov og forhold
Ikke alle problemer trenger et produksjonssystem. Noen ganger holder det med en prototype eller kanskje et enkelt skript eller et lavkode-verktøy være nok. Ved andre tilfeller kan imidlertid løsningen kreve mer: arkitektur inkludert sikkerhet og skalerbarhet, drift, overvåkning og tydelig eierskap.
Feilen mange gjør er å behandle alle løsninger likt. Enten blir alt overkonstruert, eller så blir kritiske systemer bygget som små eksperimenter. Derfor bør nivået på løsningen tilpasses etter bl.a. risiko og konsekvens:
-
Hvor kritisk er løsningen?
-
Hva skjer hvis den stopper?
-
Hvem påvirkes?
-
Hva er konsekvensen?
Gode systemer starter ofte med et enkelt spørsmål: Hvor robust må dette egentlig å være?
3. Sjekk data, definisjoner og forutsetninger før dere bygger
AI kan skrive kode raskt, men AI vet ikke hva begreper betyr i akkurat din organisasjon. Hva er egentlig en:
-
kunde?
-
ordre?
-
aktiv avtale?
I mange organisasjoner finnes det flere definisjoner samtidig. Det kan være med eller uten intensjon - ofte uten at man er helt klar over det. Foretrukne navn og definisjoner endres normalt også over tid.
Når systemer bygges på uklare begreper, blir resultatet uklare løsninger. Derfor bør man alltid starte med å forstå:
-
hvilke data systemet bruker
-
hva begrepene betyr
-
hvilke forutsetninger løsningen bygger på
Dette arbeidet virker kanskje mindre spennende enn å skrive kode, men det er ofte her kvaliteten på systemet avgjøres.
4. Vær forberedt på at systemer og integrasjoner kan endre seg raskt
Programvare lever i et økosystem som er i kontinuerlig endring. Her er noen eksempler:
-
API-er endres
-
Modeller oppdateres
-
Leverandører endrer tjenester
-
Integrasjoner får nye versjoner
I en AI-verden skjer dette enda raskere. Løsninger som skal leve over tid må derfor bygges med endring som premiss. Det betyr blant annet:
-
Løse koblinger mellom systemer
-
Tydelige grensesnitt
-
Fleksible integrasjoner
Systemer som er bygget for endring tåler utvikling bedre enn systemer som er bygget for stabilitet alene.
5. Ta med utstyr som gjør systemet forståelig og driftbart
Logging, overvåkning og eierskap er ikke ekstrautstyr - det er grunnutstyr. Når en løsning fungerer, er det lett å glemme dette, men før eller siden vil noe gå galt. Da er det avgjørende at noen kan se hva systemet faktisk gjør.
Gode systemer har derfor:
-
Logging som gjør hendelser synlige
-
Overvåkning som varsler når noe skjer
-
Tydelig eierskap når noe må fikses
Hvis ingen kan se hva systemet gjør, er det også vanskelig å vite når noe går galt og forstå årsaken.
6. Velg arkitektur og plattform som er trygg for forholdene
Det kan være fristende å bygge alt selv, spesielt når AI gjør det raskt. Husk at dette sjelden er nødvendig. Etablerte plattformer, standarder og arkitekturmønstre finnes av en grunn: de gjør systemer enklere å forstå, drifte og videreutvikle. Når man bygger på det som allerede finnes, slipper man også å løse de samme problemene på nytt.
Det betyr ikke at alt må være standardisert, men kunnskap om gode valg av plattform og arkitektur gir løsningen et bedre utgangspunkt for å leve over tid.
7. Bruk kart og kompass, og vit hvor systemene deres er
Mange organisasjoner har flere systemer enn de egentlig har oversikt over. Noen er nye. Noen er gamle. Noen er kritiske. Noen er nesten glemt. Når antallet systemer vokser, blir oversikt viktigere enn før. Organisasjonen bør derfor ha oversikt over blant annet:
-
Hvilke systemer som finnes
-
Hvordan de henger sammen
-
Hvor data flyter og hvordan de skal behandles
-
Hvem som eier hva
For å unngå at organisasjonen navigerer i tåke, er denne oversikten viktig for å forstå konsekvensene av endringer.
8. Det er ingen skam å snu dersom løsningen ikke fungerer
Det er lett å fortsette i samme retning bare fordi man allerede har investert tid og arbeid i en løsning, men noen ganger er det riktige å stoppe hvis løsningen ikke fungerer. Det kan være flere årsaker til å vurdere underveis:
-
Kanskje ble problemet misforstått
-
Kanskje finnes det en enklere løsning
-
Kanskje har behovet endret seg
-
Kanskje investeringer som kreves ikke står i forhold til effekten
Man må tørre å feile. Å justere kursen tidlig er som oftest billigere enn å fortsette i feil retning. Gode utviklingsmiljøer har derfor rom for å si: Dette fungerte ikke. La oss gjøre det annerledes!
9. Ta pauser og spar kapasitet i systemene underveis
Systemer som konstant går på maks, er sårbare når noe uventet skjer. I praksis betyr det at løsninger som kun er dimensjonert for å håndtere dagens behov, fort blir sårbare når belastningen øker eller avhengigheter svikter. Små avvik kan raskt utvikle seg til større problemer.
Robuste systemer tar høyde for at ting ikke alltid går som planlagt. Det betyr blant annet kapasitet til å håndtere topper, skalerbarhet og mekanismer for å håndtere feil underveis. Når alt er optimalisert til grensen, blir systemet skjørt. Marginer i systemene gir rom til å oppdage, forstå og håndtere det som skjer, og er ofte en forutsetning for stabilitet over tid.
10. Søk ly og bygg robusthet når forholdene krever det
Alle systemer møter virkeligheten før eller siden.
-
Integrasjoner bryter.
-
Bruksmønstre endres.
-
Data oppfører seg annerledes enn forventet.
Gode systemer er ikke perfekte, men de er robuste nok til å håndtere uventede hendelser. Det betyr at de evner å feile på en kontrollert måte, at de kan gjenopprette seg selv, og at mennesker kan forstå hva som skjedde når noe går galt.
(Artikkelen fortsetter under bildet)

Når AI gjør utvikling raskere, blir systemtenkning viktigere
AI gir organisasjoner en ny superkraft: evnen til å lage programvare mye raskere enn før. Men når utviklingstakten øker, blir også konsekvensene av arkitekturvalg, eierskap og systemforståelse større.
Organisasjoner som lykkes med AI er derfor ikke nødvendigvis de som skriver mest kode raskest, men de som klarer å kombinere tempo med systemtenkning.
Som i fjellet handler det ikke bare om hvor fort man kan gå, det handler om å komme trygt frem.
AI gjorde det lett å skrive kode. Nå må vi lære å bygge systemer som tåler både vær og vind.