Spec-Driven Develop­ment: «Kan snu opp ned på bransjen vår»

– Spec-Driven Development tvinger frem en nødvendig og etterlengtet endring i forretningsmodellen for programvare, skriver Egil Fujikawa Nes om KI-fremtiden.

Egil Fujikawa Ness, i midten mot venstre, inviterte teknologiledere for å diskutere veien videre med KI-drevet utvikling.
Publisert

✍ leserinnlegg

Dette er et leserinnlegg fra en ekstern skribent, som betyr at innholdet ikke nødvendigvis speiler kode24s meninger. Vil du også bidra? Send oss en epost på [email protected], eller les mer her!

Spec-Driven Development (SDD) kan snu opp ned på bransjen vår, men veien dit er full av menneskelige, tekniske og kommersielle hindre. Det ble tydelig da vi nylig samlet bransjen til diskusjon.

For løftet om kunstig intelligens i programvareutvikling er i ferd med å bevege seg forbi enkel kodeassistanse mot et dypere, systemisk skifte. 

Jeg er nysgjerrig på erfaringer – det er lett å føle at mann famler litt i blinde eller lever i sin egen boble – derfor inviterte jeg på vegne av 99x nylig inn til en “rundebordskonferanse” for å diskutere temaet. 

Spec-Driven Development snur den tradisjonelle utviklingsprosessen på hodet: i stedet for å kode først og skrive dokumentasjon senere, starter du med en spesifikasjon som blir sannheten for hvordan koden din skal oppføre seg. Denne spesifikasjonen fungerer som kunnskap for verktøyene og AI-agentene dine.

Konklusjonen fra en mangfoldig gruppe norske teknologiledere, partnere og kunder klar: Spec-Driven Development representerer en avgjørende og utfordrende evolusjon for bransjen. 

Diskusjonen ga oss en felles visjon for fremtiden, som fremhevet enorme muligheter for hastighet og innovasjon, men som også tvang oss til å se nøkternt på de betydelige utfordringene som ligger foran.

Kalana Wijesekara, 99x’s leder for utvikleropplevelse, startet samtalen med å gjøre det abstrakte konseptet SDD konkret ved å dele innsikt fra vår egen vellykkede implementering av metodikken for å bygge raske, høykvalitets MVP-er. Dette virkelighetsperspektivet fungerte som en katalysator for diskusjonen og startet en praktisk og fremtidsrettet debatt.

For oss handlet ikke samtalen om hvorvidt AI vil endre programvareutvikling, men om hvordan det vil endre verdi, roller og ansvar.

Muligheten: En fremtid med enestående hastighet og gjenbrukbarhet

Vi var alle enige om at den største fordelen med SDD er en dramatisk akselerasjon av utviklingssyklusen. Evnen til å generere funksjonelle Minimum Viable Products (MVPs) på dager i stedet for måneder, gir raskere validering av forretningsideer og hurtigere beslutningstaking.

Utover greenfield-prosjekter, så vi en klar vei for å modernisere legacy-systemer. 

Henrik Vikøren fra Gture delte sitt teams erfaring med å "reverse-engineere" spesifikasjoner fra eksisterende kodebaser. Ved å lage detaljerte specs for modne systemer, kunne de nå «bygge nye funksjoner mye raskere», noe som beviser at SDD kan gi nytt liv og smidighet til etablerte produkter.

Andreas Brustad fra Clave pekte på en sentral mulighet: å endelig løse den evige utfordringen med gjenbruk av kode. Han så for seg en fremtid der tekniske spesifikasjoner, for alt fra API connectors til komplekse architectural patterns, kan deles og gjenbrukes. Spesifikasjonen kan passe inn i et annet prosjekt selv om koden ikke gjør det. 

Dette antyder at SDK-er til slutt kan bli erstattet av velprøvde, gjenbrukbare specs som genererer skreddersydd kode for ethvert miljø. Dette ville være et ekte paradigmeskifte: fra gjenbruk av kode til gjenbruk av intensjon.

– Den ikke-deterministiske naturen til AI var en annen stor bekymring.

Risikoen: Tvetydighet, ansvar og en ny type gjeld

Men til tross for optimismen, var vi også pragmatiske og løftet frem flere kritiske bekymringer. 

Lana Vu, CTO i Netlife, satte ord på en primær risiko med konseptet «spec debt». Fordi naturlig språk er tvetydig, kan dårlig skrevne spesifikasjoner bli like uoversiktlige som dårlig skrevet kode. Vi var enige om at kvaliteten på den AI-genererte programvaren er helt avhengig av presisjonen i den menneskeskrevne spec-en.

Den ikke-deterministiske naturen til AI var en annen stor bekymring. Henrik Vikøren trakk en parallell til en tradisjonell compiler, som gir forutsigbart resultat, mens AI kan «gjøre fire forskjellige ting hvis du kjører spesifikasjonene fire forskjellige ganger». 

Kjetil Draugedalen fra Step Solutions stilte det kritiske spørsmålet: «Hvem har skylden når en AI introduserer en bug? Hvem klandrer du?»

Sverre Colbjørnsen fra USBL ga uttrykk for en frykt vi alle delte: at SDD kanskje ikke fjerner arbeid, men bare flytter det. «Jeg er bekymret for at det bare flytter ressurser fra koding over til testing og bug fixing», uttalte han, og pekte på faren for å skape mye «støyende» kode.

Det menneskelige elementet: Nye roller og omorganisering

Til syvende og sist var vår konklusjon at den største utfordringen ikke er teknisk, men menneskelig. 

Samtalen vendte gjentatte ganger tilbake til hvordan SDD vil påvirke oss og organisasjonsstrukturene våre.

  • Den nye kompetansen: Vi stilte spørsmål ved om utviklere, som drives av håndverket med å kode, vil finne tilfredsstillelse i å skrive detaljerte spesifikasjoner. Lana påpekte også at designere neppe vil omfavne spesifikasjonsoppgaven. Dette peker mot fremveksten av nye hybridroller: tekniske arkitekter som også er glimrende skribenter, og produkteiere som kan oversette forretningsbehov til maskinlesbar logikk.

  • Byrden på forretningssiden: Sverre Fønstelien fra Kollektiv Intelligens understreket et poeng vi alle kjente oss igjen i: forretningssiden vil trenge en fundamental endring i tankesett. «De vil bare fortelle hva de vil ha i én setning», observerte han. «De kommer aldri til å bruke 10 timer på å skrive en skikkelig spesifikasjon.»

  • Dilemmaet med juniorutviklere: En avgjørende bekymring vi diskuterte, var karriereveien for de ferske. Hvis AI automatiserer junior-oppgavene, hvor skal neste generasjon seniorarkitekter få erfaringen som trengs for å skrive fremragende spesifikasjoner? «Hva skal vi gjøre med dem?» spurte Kjetil.

En avgjørende bekymring vi diskuterte, var karriereveien for de ferske.

Konklusjon: Fra fakturerbare timer til en ny verdiforståelse

Vi forlot samtalen med en klar konklusjon: 

Spec-Driven Development tvinger frem en nødvendig og etterlengtet endring i forretningsmodellen for programvare.

Vårt verdiforslag kan ikke lenger baseres på kostnad per kodelinje eller antall arbeidstimer. I stedet vil verdien vår defineres av kvaliteten på strategisk tenkning, dybden av domenekunnskap og verktøyene vi bruker.

Fremtidens modell, slik en av oss foreslo, ligner mindre på et samlebånd og mer på et advokatfirma eller en «value shop», der kunder betaler for ekspertise og garantert kvalitet, ikke for tid brukt på manuelt arbeid. 

Å navigere denne overgangen blir den definerende utfordringen for oss som teknologiledere i årene som kommer.

Powered by Labrador CMS