Hvis du ikke forstår hva du leverer til kundene, er du ferdig

Johannes Berggren hadde nylig en artikkel på Shifter med overskriften «Hvis du ikke bruker AI-agenter til å kode, er du ferdig». Han er ikke alene om å tenke i de baner, men jeg ønsker å utfordre påstanden. I Ensō sier vi heller Det er en selvfølge at dyktige fagpersoner bruker riktige verktøy, og dette handler om mer enn bare AI vs ikke-AI. Nå er det på tide å løfte diskusjonen videre.

I en tid der teknologien løper av gårde, er det lett å la seg rive med. AI-verktøy loves å øke produktiviteten, redusere repetitivt arbeid og kanskje til og med skrive koden for oss. Men mens enkelte roper at «hvis du ikke bruker AI til å kode, er du ferdig», stiller vi i Ensō et annet spørsmål: Hva skjer hvis du bare bruker AI til å kode? Svaret er kanskje at du blir ferdig – men ikke med det du tror.

Koding som håndverk, ikke samlebåndsarbeid

I Slow Productivity beskriver Cal Newport hvordan Henry Fords samlebånd revolusjonerte bilindustrien. Tidligere hadde dyktige håndverkere bygget hele biler, med stolthet i å forstå og mestre helheten. Med samlebåndet ble hver arbeider redusert til én spesialisert og repeterende oppgave. For å kompensere for den dalende trivselen, økte Ford lønningene dramatisk – men kvaliteten og stoltheten forsvant. Newport peker på hvordan dette ikke bare reduserte arbeidet til mekaniske oppgaver, men også tappet ingeniører og arbeidere for mening.

I dag ser vi en lignende fristelse i programvareutvikling. AI-agenter og generative verktøy kan automatisere stadig mer. Men hvis vi reduserer koding til samlebåndsoppgaver – å bare sette sammen puslespillbrikker av andres forslag – mister vi forståelsen for systemet, evnen til å feilsøke og, til syvende og sist, kvaliteten og stoltheten i arbeidet. Vi risikerer at koden blir ferdig, men at ingen forstår den – ikke engang vi selv.

Kunnskapsarbeid kan ikke måles i antall linjer kode

I all slags kunnskapsarbeid – enten det gjelder utvikling, design, strategi eller forskning – er det vanskelig å måle produktivitet. Hva er egentlig et godt mål? Antall linjer med kode? Antall deploys i uken? Neppe. Det som teller er kvaliteten på tankearbeidet, dybdeforståelsen, og holdbarheten i løsningene vi lager.

Når vi måler utvikleres produktivitet med overfladiske tall – som antall commits, linjer kode eller «features per sprint» – risikerer vi å undergrave det som virkelig gir verdi: evnen til å forstå komplekse problemer, gjøre kloke valg og bygge systemer som varer. Dette er ikke produktivitet som enkelt lar seg telle, men den er desto viktigere.

AI som verktøy, ikke salgsargument

Dette betyr ikke at vi i Ensō er teknologipessimister. Tvert imot – vi tar i bruk AI der det gir oss reell verdi: til å generere forslag, automatisere repeterende oppgaver eller til og med inspirere til nye løsninger. Mange av oss bruker slike verktøy daglig. Det har skjedd en rask endring: fra å eksperimentere med dem, til at de nå er en naturlig del av arbeidsflyten. Det er nå en selvfølge at dyktige fagpersoner tar AI i bruk der det gir mening – men også at de står inne for det som leveres.

Jeg holdt nylig et internt foredrag om Cursor AI med undertittelen "Automate the boring parts". Poenget mitt var (og er) tydelig: Bruk AI til det repetitive, det du skulle ønske du hadde en middels oppegående assistent til å ta seg av – men aldri til å outsource sjela i det vi holder på med. La oss være hodet, ikke halen. Det er i refleksjonen, forståelsen og mestringen vi bygger kvalitet. (Dette har jeg skrevet mer om i Coding as Craft og Claude Code: Game Changer or Hype?)

Levere kode raskt?

Å bli ferdig handler ikke bare om å få koden levert raskest mulig. Det handler om å bygge noe som holder – noe vi kan være stolte av, og som er lett å forstå og vedlikeholde. Det handler om å bygge løsninger som vi forstår dypt nok til at vi kan stå inne for dem, selv når AI-en er skrudd av.

Det er mangt å mene om Uncle Bob, men her var han på sporet av noe: > It is more important for code to be changeable than that it work. Code that does not work, but that is easy to change, can be made to work with minimum effort. Code that works but that is hard to change will soon not work and be hard to get working again.

Hos Ensō tror vi på å kombinere det beste fra moderne teknologi og klassisk håndverk. Vi tror at slow productivity – det å ta seg tid til å forstå og bygge skikkelig – ikke er et hinder, men en forutsetning for kvalitet.

Så før vi hopper på neste AI-hype, la oss spørre oss selv: Vil vi virkelig være ferdige på samlebåndsmåten – eller vil vi være ferdige fordi vi har gjort jobben skikkelig?