Advarer mot KI-gjeld: – Utviklere må samarbeide mer

– Utviklere må støtte seg mer på andre faggrupper enn seg selv!

Det sier Anne Christine Knudsen til kode24. Hun er KI-rådgiver og foredragsholder, og har over 30 års erfaring fra digitaliseringsprosesser.

Nylig skrev kode24 at nesten halvparten av norske utviklere lar KI skrive alt eller mesteparten av koden sin. 

Det kan føre til at man vil sitte igjen med en enorm ryddejobb og store kostnader, er både KI-forkjempere og -skeptikere enige om: 

Norske KI-kodere kan vente stor ryddejobb, enda høyere regning

Det spår de fire ekspertene kode24 snakker med, om konsekvensene av at halvparten av norsk kode nå er KI-generert.

Mange utviklere kjenner til begrepet teknisk gjeld, som handler om å pådra seg ekstrakostnader i framtida dersom man nå velger noen lettvinte løsninger. 

Mindre kjent er det kanskje å snakke om KI-gjeld. For med med stadig mer bruk av kunstig intelligens er Knudsen opptatt av at folk må være obs på den store gjelden de opparbeider seg, mens de tror de moderniserer.

– KI-gjeld er ny teknisk og organisatorisk gjeld fra KI-bruk uten kontroll på data, prosesser, ansvar og gevinst, forklarer hun. 

Ulike typer KI-gjeld

Knudsen peker på fem andre typer KI-gjeld: 

1. Datagjeld: Mange ligger bakpå i å ta i bruk data i sine organisasjoner. Hvordan komme ajour? Og hvordan sikre kvaliteten? – Jo mer inkonsistente data du har, jo vanskeligere er det å stole på det. Kjør tilsyn med systemene som bruker KI, også agenter, sier Knudsen. 

2. Prosessgjeld: Hvilket forhold har vi til prosessen vår og hva gjør vi ved endringer? Her kan man lage KI-verktøy for å få oversikt og huske riktig rekkefølge på prosesser. 

3. Ansvarsgjeld: Hvem må i fengsel når en bankkonto tømmes? Det gjelder hvert system og agent. Noen må eie vurderingen, feilen eller konsekvensene.

4. Kompetansegjeld: Når ansatte tar i bruk KI-verktøy uten nok opplæring og dømmekraft. Hvilken kompetanse har man til å drive med KI-utvikling? Hvordan få til et opplæringsløp ut blant dem som jobber? Del erfaringer internt: hva er gjort bra og ikke?

5. Gevinstgjeld: Når KI brukes mye, men verdi, effekt eller risiko blir ikke målt. Blir vi faktisk bedre på å skape gevinst med KI? Når skal du begynne å måle en agent? – Måler du ikke noe, kan du heller ikke måle om agenten har noen nytte. Begynn å måle for å se en gevinst. 

Avklar data, kontroll og sikkerhet

For tida bistår Knudsen Bærum kommune i sin digitalisering og KI-bruk. 

– Retningslinjer om vibbekoding er ikke så lett å opprettholde i dagens tempo.  Hva skjer når vi bruker KI til å forsterke arbeidsprosesser vi egentlig ikke har forstått godt nok? 

Nylig fortalte hun IT-arkitekter om hva de kan gjøre for å oppdage KI-gjelden tidlig. Hun begynte foredraget på ARK ved Dataforeningen slik: 

– Jeg elsker KI! 

Hun peker på at alle starter med gode intensjoner, og så baller det på seg med KI-verktøy til alle, ansatte som bruker private KI-kontoer på jobb, fagmiljø som eksperimenterer i sine egne prosesser og utviklingsteam som automatiserer nye arbeidsflyter. 

– Før KI skaleres, må arkitekter avklare datakvalitet, menneskelig kontroll, sikkerhet, logging, eierskap og forvaltning, understreker Knudsen. 

Poenget er ikke å bremse bruken av KI, men lede bedre, understreker Knudsen.

– Utviklere har enormt utbytte av å bruke KI i utviklingen. De sier at effektiviteten går veldig opp, noe vi trenger.

– Hvordan kan utviklere lede seg selv bedre i KI-bruken så de unngår gjelden? 

– Det jeg tenker at utviklere må gjøre, er at de må støtte seg mer på andre faggrupper enn seg selv, fordi utviklere har vært veldig vant til å være hovedpersonen i rommet i veldig mange år nå, synes jeg, sier hun. 

1 av 2 norske utviklere genererer det meste eller alt med KI

Samtidig er 81 prosent bekymra for feil de aldri oppdager, viser kode24s tall. – For hvis så mye kode blir generert, har man da kontroll på det som kommer ut?

Utviklere må samarbeide mer

Knudsen peker på at team har blitt definert som å bestå av utvikler, designer og leder, og dermed kasta ut en del andre kompetanser.

–  Utviklere må samhandle i større grad med arkitekter, test og QA, som har andre perspektiver. Designerne har fått innpass, men nå må de andre inn igjen. Pendelen har gått altfor lang den andre veien, sier hun. 

Selv er hun begeistret for å kunne KI-kode sine egne systemer, etter lang tid i bransjen uten å kunne programmere. Nå slipper hun be andre gjøre det for seg.

– Men hvis jeg skal lage et system, må jeg ha ekstra agenter som er arkitekt, utvikler, tester og designer for å hjelpe meg i kodingen.

Knudsen understreker at utviklere kan være gode på å teste kode, men at de ikke tar for seg hele forretningsperspektivet. Videre er de ikke i utgangspunktet utdannet i drift, og ved sikkerhetstesting vet de ikke alltid hva OWASP er. 

– I så fall må de sette seg inn i det, og da blir de jo ikke så effektive som det de burde vært. Det er der team-tankegangen kommer inn. Den som kan kompetansen kan bidra. 

– Hva burde utviklere spørre seg selv om for å unngå gjeld? 

– Hvordan noe skal driftes, er et godt spørsmål. Hvordan er det sikkert? 

Kan ingenting om sikkerhet

Knudsen peker på at utviklere gjerne ender opp med å fikse opp i andres vibbekode-problemer og KI-gjeld. 

– Hvem er verst på å lage KI-gjeld? 

– Enhver i dette landet som vibbekoder. Mange gründervirksomheter lager nå ganske heavy løsninger, fordi det går an. Men sikkerheten i det, kan de ingenting om.

– Og så er det datakvaliteten, og de har ikke erfaring med systemutviklingsprosessen. 

– KI tvinger oss til å bli kvitt middelmådige utviklere

Det er stadig mer bruk for IT-arkitekter, mens utviklere må spisse kompetansen sin, mener grunnlegger av internasjonal arkitekt-organisasjon.