– Vi må bli mer disiplinerte

KI i utvikling – det er ikke lenger et spørsmål om vi skal bruke det. Det gjør vi allerede, og bruken kommer bare til å øke.

Derfor er heller ikke den mest interessante diskusjonen – om KI-generert kode er «bra» eller «dårlig». KI kan skrive kode som er ryddig, lesbar og fullt mulig å vedlikeholde.

Det interessante er hva som skjer når kostnaden ved å produsere kode blir dramatisk lavere.

Fra timer til minutter 

Det som tidligere tok timer, kan nå ta minutter. 

Nye klasser, tester, abstraksjoner, integrasjoner og konfigurasjon kan genereres – nesten uten friksjon.

Det er en fordel, men det har også en bakside. 

Det blir lettere å bygge mer enn vi egentlig trenger – som kan føre til over-engineering – noe som for øvrig ikke er nytt. Utviklere har alltid hatt en tendens til å lage løsninger som er litt mer generelle, fleksible og «fremtidssikre» enn problemet krever.

Men det er et ekstra interface, en factory og et nytt lag. Forskjellen nå er at KI gjør denne kompleksiteten billigere å produsere.

Som har en generisk struktur som kanskje blir nyttig senere.

Over-engineering

Tidligere kostet det mer å over-engineere. Du måtte skrive klassene selv, koble dem sammen og kjenne på tyngden av løsningen mens du bygde den.

Den friksjonen hadde en verdi. Den tvang oss av og til å stoppe opp og spørre oss selv:

Trenger vi egentlig dette?

Men med KI forsvinner mye av den friksjonen. 

På få sekunder kan man få en løsning som ser ryddig og profesjonell ut. Den kan ha gode navn, tydelig struktur, tester og dokumentasjon.

Alt kan se riktig ut.

Men spørsmålet er ikke bare om løsningen fungerer?

Men om den i det hele tatt før finnes?

Laget for å være hjelpsomme

KI-verktøy er laget for å være hjelpsomme. De gir ofte et mer komplett svar enn man har bedt om.

Ber man om enkel validering, kan man få et lite valideringsrammeverk. Ber man om en integrasjon, så kan man få wrapper-klasser, egne exceptions, retry-logikk og konfigurasjon.

Noen ganger er det riktig. Andre ganger får man mer arkitektur før man har nok kunnskap.

Det er ofte der overengineering starter: Det er ikke med dårlige intensjoner, men med for tidlig generalisering.

Ser ut som kvalitet

Det vanskelige er at overengineering ofte ser ut som kvalitet i starten.

Koden er pen. Strukturen virker fornuftig. Løsningen er fleksibel og «klar for fremtiden».

Men fremtiden kommer sjelden akkurat slik vi forestilte oss.

Grensesnittet får aldri en alternativ implementasjon. Factoryen oppretter konsekvent det samme objektet, så den ekstra fleksibiliteten blir aldri utnyttet.

Og man sitter igjen med en kode som ser profesjonell ut, men som er tyngre å forstå og vanskeligere å endre.

Raskere enn vi kan lese

Derfor flytter KI noe av utviklerrollen.

Flaskehalsen er ikke lenger bare å skrive kode. Den ligger mer i å vurdere kode.

Forstår vi løsningen? Løser den riktig problem? Er fleksibiliteten verdt prisen? Kan noen andre endre dette om seks måneder?

KI kan produsere kode raskere enn vi kan lese den.

Derfor blir dømmekraft viktigere. Vi må bli bedre til å stoppe opp, forenkle og noen ganger slette. Det betyr ikke at vi skal bruke mindre KI.

Tvert imot.

Men vi bør bruke KI mer bevisst. Ikke bare be KI-boten om å iverksette noe, men også be den finne den enkleste løsningen som kan fungere. 

Hva er unødvendig her og hvilken kompleksitet introduserer denne løsningen?

På den måten blir KI mer enn en kodegenerator. Den blir en sparringspartner.

Så til hovedpoenget: 

KI gjør ikke overengineering til et nytt problem. Det gjør problemet raskere, billigere og mer fristende.

30 sekunder

Det tar kanskje 30 sekunder å generere en løsning.

Men det kan ta timer å forstå den, måneder å oppdage at abstraksjonen er feil, og år før noen tør å slette den.

De beste utviklerne og teamene fremover blir neppe de som bruker KI mest ukritisk. Det blir de som bruker KI mest bevisst.

For kanskje er ikke den viktigste ferdigheten i KI-alderen å skrive kode raskere.

Kanskje det er å se på en ferdig generert løsning og å si:

Dette fungerer, men det er kanskje mer enn vi trenger?