Når kode blir billig: hva skjer med leverandørene?

Når kode blir billig: hva skjer med leverandørene?

Alle som har sittet i et leverandørmøte kjenner svaret: «det ligger på veikartet.» I tjue år har det vært et ærlig svar. Å bygge en utstillermodul eller en integrasjon mot et regnskapssystem kostet faktisk uker med utviklertid, og en leverandør med tre hundre kunder måtte prioritere mellom dem.

Det koster ikke uker lenger. Det koster dager. Og det gjør veikartet til et dårligere svar enn det var i fjor, uten at så mange har begynt å behandle det sånn.

(Dette innlegget handler altså ikke om AI inne i systemet deres — agenter, forslag, automatisk tilbudsutkast. Vi har skrevet om det skillet et annet sted. Her er det snakk om AI i produksjonen av programvaren, altså hos leverandøren, før dere ser noe av den.)

Hvorfor de store likevel ikke løper

Jeg har sittet på begge sider av det bordet, først i mange år som den som kjøpte slike systemer, nå som den som lager et. Og det jeg trodde fra kjøpersiden var at leverandørene var trege fordi de var mette. Det stemmer av og til. Men det er ikke hovedforklaringen, og jeg tok feil om hvor kostnaden deres ligger.

Kostnaden til en etablert leverandør har aldri ligget i å skrive funksjoner. Den ligger i å ikke ødelegge de hundre­vis av installasjonene som alt kjører, hver med sin egen konfigurasjon, sine egne priskoder og sine egne særegenheter som noen la inn fordi en kunde insisterte i 2014 og ingen har turt å fjerne siden.

Tenk på hva en liten endring faktisk utløser hos dem. En justering i hvordan en linje prises må testes mot en sertifisert regnskapsintegrasjon, mot EHF-formatet, mot SAF-T-eksporten, mot en MVA-sats som endret seg i fjor og en som endrer seg neste år, og mot de hotellene som fortsatt kjører en versjon som er to år gammel fordi de aldri oppgraderte. Og det må gjøres uten at en resepsjonist et sted i landet står med en buss og førti mennesker klokka halv tolv på kvelden og ingenting som virker. AI skriver gjerne den endringen på et kvarter. Den tar ikke bort noe av testingen rundt den.

Så kommer det jeg synes er det virkelig kontraintuitive, og som går stikk i strid med hvordan dette selges: AI-assistanse hjelper minst der koden er eldst. Hypen sier at AI kan rydde i gammel kode. I praksis er flaskehalsen i et femten år gammelt system ikke skriving, det er å forstå hva som står der. Hva gjør denne funksjonen? Hvem kaller den? Hva faller ned i andre enden hvis jeg endrer den? En AI-assistent er god til å foreslå en endring og ganske dårlig til å kjenne konsekvensene i et system ingen har kartlagt. Leverandøren med mest gammel kode får altså minst igjen for verktøyet, selv om det er dem som trenger det mest.

Jeg er usikker på hvor lenge det varer. Verktøyene blir bedre på nettopp dette ganske raskt. Men det er der vi er nå.

Det som faktisk har blitt raskere

Integrasjoner, først og fremst. Å snakke med et API, mappe felter, håndtere feiltilstander — det er den mest mekaniske delen av arbeidet, og det er det AI er best på. «Vi støtter ikke det regnskapssystemet» holder dårligere som svar nå.

Det samme gjelder uttrekk av data. Verktøy for å få data ut har alltid vært underprioritert, av den enkle grunn at ingen leverandør tjener penger på dem. De er nå billige nok at pris ikke er en gyldig unnskyldning, noe som er verdt å huske neste gang dere spør om hva en eksport koster.

Og revisjon, som er den minst omtalte konsekvensen av alt dette. Hvis en maskin kan skrive en modul på en dag, kan den også lese gjennom et helt system og si hvor en sjekk mangler. Det betyr at «det ville tatt måneder med konsulenttimer å finne ut av» ikke er sant lenger. Dere kan be om en datert gjennomgang av én konkret ting og forvente et svar.

Kode som ser riktig ut

Her er risikoen ingen leverandør markedsfører, inkludert oss.

Den gamle feilen var kode som ikke virket. Den ble funnet, nettopp fordi den ikke virket. Den nye feilen er kode som virker helt fint i det tilfellet den ble skrevet for.

Et eksempel. En leverandør finner ut at en bruker kan se tall hun ikke skal se, i en bestemt rapport. Du ber en AI-assistent fikse det, og den legger inn en sjekk i nøyaktig den rapporten, raskt og pent. Problemet er at samme datauthenting også skjer i en eksport, i et API-endepunkt, i en e-post som går ut hver morgen, og i en nattjobb ingen har sett på siden den ble skrevet. Sjekken står på ett av fem steder. Fiksen ser ferdig ut og er det ikke, og den typen halvferdighet er vanskeligere å oppdage enn et rent krasj, fordi ingenting klager.

Dette rammer nye og gamle leverandører helt likt, og nettoeffekten på markedet er ganske forutsigbar: flere funksjoner, raskere, med dårligere dekning i kantene. Som kjøper betyr det at leveransetakt har sluttet å være et kvalitetssignal. Alle har den nå.

«Men dere sa vi ikke skulle bygge selv»

Det sa vi, og vi står ved det. Det er rimelig å spørre hvordan det henger sammen med at vi bruker de samme verktøyene selv, så la meg svare på det.

Poenget i den posten var aldri at hoteller ikke kan skrive kode. Det var at byggingen er omtrent tjue prosent av arbeidet over tid. De åtti som gjenstår er vedlikehold, regelverk som flytter seg, integrasjoner som knekker når motparten oppdaterer noe, og noen som tar telefonen på en lørdag. AI gjør noe med de tjue prosentene og omtrent ingenting med de åtti. Spørsmålet er derfor ikke hvem som skriver koden, men hvem som bærer resten, og om de bærer det som en virksomhet eller som en ekstraoppgave for en ildsjel i IT som en dag bytter jobb.

Det følger av dette at AI-assistert utvikling ikke gjør noen til en troverdig leverandør. Den senker terskelen for å bygge noe som ser komplett ut i en demo. Den senker ikke terskelen for å drifte det i fem år. Jeg vil tro vi får se en håndfull nye navn i dette markedet de neste par årene som er imponerende i mars og borte i oktober, og det er en ny variant av den konsolideringsrisikoen vi har skrevet om før.

Hva dere kan spørre om i stedet

Funksjonslister er i ferd med å bli dårlig beslutningsgrunnlag, rett og slett fordi de er billige å forlenge. Det som fortsatt koster noe er disiplinen rundt koden, og den kan dere faktisk spørre om uten å være tekniker.

Ta noe konkret og spør hvor det håndheves. For eksempel at en pris ikke kan settes utenfor en avtalt ramme: er det sjekket ett sted, eller på hvert sted det kan skje? «Det er validert i hele systemet» er ikke et svar på spørsmålet. «Det går gjennom én funksjon, og den har en test» er det.

Spør om tilbakerulling framfor leveransetakt. En leverandør som ruller ut hver uke uten å kunne rulle tilbake, er mer risikabel for dere enn en som ruller ut månedlig og kan angre.

Og spør hva de har fjernet det siste året. Dette er det spørsmålet jeg liker best, og samtidig det jeg er minst sikker på at fungerer, for de fleste selgere forstår det ikke og svarer forbi. Men hvis du får en utvikler i rommet og hun begynner å snakke om kode og dokumentasjon de har slettet fordi den ikke stemte lenger, har du lært noe ekte om leverandøren.

Forbeholdet

Vi er en ung leverandør som bygger med disse verktøyene, så vi har åpenbart interesse av å si at kode har blitt billig. Les det med det i bakhodet.

Det AI ikke har gitt oss er femten år med referanser, sertifiserte integrasjoner mot alt norsk regnskap, døgnbemannet support, eller den samlingen av kanttilfeller som bare oppstår når hundre hoteller har brukt noe i et tiår. De etablerte har alt det. Det er antakelig det tyngste argumentet mot oss i en anbudsprosess, og vi har ikke noe godt motsvar annet enn tid.

Det vi mener vi har er bredde tidlig, og en mulighet til å bevege oss raskere på eventproduksjon enn et programvarehus som må beskytte en stor installert base. Men bredde bygget fort er en påstand, ikke en egenskap, og den eneste ærlige måten å behandle en påstand er å la den bli testet. Derfor bruker vi minst like mye av disse verktøyene på å revidere det vi har bygget som på å bygge nytt. Det er den kjedelige halvparten av jobben.

Så hva gjør dere med dette

Ikke så mye, ærlig talt, før neste gang dere sitter i et leverandørmøte. Da er det to ting som har endret seg siden sist: veikartet er en svakere forklaring enn det var, og hastighet er ikke lenger noe å bli imponert av i seg selv. Det som fortsatt er verdt å vite er om noen har sjekket kantene, og om de kan si hva de fant uten å bytte tema.