KI-verktøyene har gått fra autocomplete til å skrive hele systemer. Det interessante er ikke at det går fortere. Det interessante er hva hastigheten avslører.
Du blir ikke bedre i matematikk av å få en kalkulator. Du blir ikke en bedre arkitekt av å få en KI som skriver kode raskere enn deg.
Oppgaver som før tok uker, tar nå timer. En idé som måtte diskuteres i møte etter møte, kan bygges og testes på en ettermiddag. Men en fungerende prototyp er ikke en løsning. Et problem har alltid mange løsninger, det vanskelige er å finne den som fortsatt fungerer om fem år. Fokuserer du bare på å få noe til å virke raskest mulig, har du signert systemets dødsattest. Det er ikke noe nytt. Med KI går det bare mye fortere.
Fire ganger raskere
Vi er midt i en modernisering for en stor norsk teknologiaktør. Vi brukte de første månedene av prosjektet på å designe tjenester, abstraksjoner og arkitektur. Prosjektet er ikke ferdig, men første leveranse er i produksjon, og tallene så langt er tydelige.
Systemet vi arvet, hadde 13 , 150 databasetabeller, 60 API-endepunkter og noen hundre spredte tester. Det vi har levert så langt, har ett repo, 9 databasetabeller, 13 endepunkter og fem ganger så mange tester. Etter at vi tok i bruk KI i kodingen, leverte vi tilsvarende funksjonalitet fire ganger raskere enn i prosjektets første måneder. Det nye systemet har lavere kompleksitet enn det vi arvet, og 98 prosent av kodebasen har syklomatisk kompleksitet under 5.
Vi har ikke opplevd at KI-generert kode har endt opp i uhåndterlig kompleksitet eller spaghettikode. Grunnen er enkel: Agentene koder, de designer ikke. Vi brukte tid på å forstå hva vi skulle bygge, og ga agentene klare, avgrensede oppgaver innenfor den strukturen. Resultatet er et enklere system med tilsvarende funksjonalitet, ikke til tross for at vi brukte KI, men fordi vi visste hva vi ville bygge før vi ba den bygge det. Vi kjører ofte flere agenter i parallell. Det fungerer bare hvis tjenestene er riktig dekomponert, ellers tråkker de på hverandre.
Men det er ikke gratis.
Flaskehalsene
Det som tidligere var en teknisk flaskehals, blir nå en kognitiv og organisatorisk flaskehals. Når én utvikler kan bevege seg gjennom hele stacken – fra database til API til frontend – med støtte fra KI-verktøy, øker også kravet til å forstå helheten. Det holder ikke å vite hvordan noe implementeres; man må vite hvorfor det finnes og hvordan det påvirker resten av systemet.
Dette merkes særlig i det som ikke fungerer.
Hvis datamodellen er uklar, blir uklarheten implementert raskere. Hvis grensesnittene er dårlig definert, må de rettes opp på flere steder samtidig. Hvis ingen har eierskap til strukturen, vil systemet fungere til det møter en situasjon som ikke er eksplisitt håndtert. Tempoet forsterker konsekvensene av disse svakhetene.
Samtidig gir det et nytt handlingsrom. Det er mulig å refaktorere på systemnivå, ikke bare på funksjonsnivå. Det er mulig å konsolidere tjenester, fjerne historiske lag og stramme inn grensesnitt uten å starte på nytt. Det er mulig å jobbe mer eksplorativt og samtidig ende opp med enklere systemer.
For utviklere betyr dette at faget forskyves, men ikke forenkles. Full-stack betyr i større grad faktisk full-stack. KI-stacken – modeller, kodegeneratorer, testverktøy og deploy-pipelines – blir en del av den daglige arbeidsflaten. Mindre tid går til det mekaniske, mer til vurderingene.
Den nye begrensningen blir evnen til å forstå hva man bygger – og å ta gode valg mens man bygger det. Her kommer det et stort klasseskille mellom programmerere som forstår og utnytter denne utviklingen, og de som tviholder på en utdatert arbeidsmåte. Bedrifter vil oppleve det samme.
Menneskelig kontroll av KI – en farlig sovepute?
