Hva det krever, og hva det gir

De vanskeligste feilene i dette prosjektet har én ting felles: de sa ikke fra.

• Kilder endrer seg uten varsel

  En kolonne bytter navn. En tabell får en ny dimensjon. Et dokument endrer oppsett. Ingen av delene gir feilmelding - hentingen går gjennom, og resultatet er tomt eller feil. Derfor kontrolleres resultatet, ikke bare om jobben kjørte ferdig.

• Det som virker lokalt, ryker i drift

  Ulike operativsystem behandler tegn og linjeskift ulikt. En verktøykjede som håndterer norske tegn på én maskin og ikke på en annen, bytter dem ut med erstatninger som ae, oe og aa - og gir fristelsen til å skrive dem slik med vilje for å slippe styret. Fella er ikke lesbarheten. Det er at erstatningen havner i det som publiseres.

• Publisering er sin egen disiplin

  Antakelser om hvordan utlegging fungerer, viste seg gjentatte ganger å være feil - og feil på måter som bare kunne oppdages ved å prøve. Innstillinger som ikke ligger i koden, er de vondeste: de er usynlige helt til noe ikke virker.

• Verktøykjeden må vedlikeholdes for å fortsette å spare tid

  Automatiseringen som sparer timer, koster timer. En jobb som slutter å virke i stillhet, er verre enn ingen jobb - fordi man tror den går.

Svaret på alle fire har vært det samme: gjør feilen umulig framfor å love å passe på. Det er grunnen til at prosjektet har 218 testfiler, og at flere av dem vokter en regel framfor å teste en beregning.

Med 230 datasett er det alltid noe som er i ferd med å bli gammelt. Det er ikke en feil i oppsettet - det er den naturlige tilstanden til en portal som viser tall fra mange kilder med hver sin publiseringstakt.

Det er lett å undervurdere hvor mye tid dette tar. Å bygge en ny side er en avgrenset jobb med en tydelig slutt. Å ha en side er en jobb uten slutt: lenker råtner, kilder legger om, tall som stemte i fjor stemmer ikke i år, og tekst som viser til et tall må kontrolleres når tallet endrer seg. Fordelingen av leveranser i forrige kapittel sier det tydelig: feilretting, infrastruktur, design og dokumentasjon er til sammen langt større enn nytt innhold.

Listen over hva som gjenstår, er selv et vedlikeholdsobjekt. Varsler om feil, rapporter fra nattlige kjøringer og oppfølgere fra kodegjennomgang opprettes av maskin, men bare et menneske kan avgjøre at noe er ferdig. Da fylles listen automatisk og tømmes for hånd, og den vokser skjevt. Ved en opprydding var rundt en av ni saker spor etter automatikken selv: meldinger om feil som for lengst var rettet, og rapporter fra kjøringer som var over for uker siden. Ingen av dem var arbeid. De så bare slik ut. I tillegg sto et titalls saker som var bevisst forkastet, fortsatt oppført som gjenstående, fordi tilstanden var satt opp feil ett sted. Samlet sett var rundt en av seks saker ikke reelt arbeid. Slikt finner man bare ved å telle.

Den vanskeligste avveiningen er ikke teknisk. Det er å velge mellom å legge til noe nytt og å holde ved like det som finnes. Det nye er synlig og gøy. Vedlikeholdet er usynlig helt til det ikke er gjort. En portal som lover ferske tall og viser gamle, har mistet det eneste den hadde.

Et prosjekt uten team har ingen å dele avgjørelsen med. Hver eneste vurdering - hvilken tabell som faktisk måler det den ser ut til å måle, om en formulering gir et sterkere inntrykk enn tallene bærer, om noe er godt nok til å publiseres - tas alene. Det finnes ingen å spørre om det bare er en selv som ser det slik.

Det er også mye å huske på. Hvorfor en bestemt løsning ble valgt for et halvår siden. Hvilke antakelser som ligger under et tall. Hvilke deler som er skjøre. Uten et team å fordele det på, er alternativet å skrive det ned - og selv da må man huske hvor man skrev det.

En AI-medarbeider hjelper her, men ikke slik man kanskje tror. Den husker ikke forrige uke. Den kan lese det som er skrevet ned, og det er hele poenget: den delen av prosessen som virker mest byråkratisk - å skrive ned regler, begrunnelser og antakelser - er det som gjør at både maskinen og mennesket kommer tilbake til en avgjørelse og forstår den.

Og så er det tempoet. Når kode kan produseres raskere enn man rekker å bestemme hva som skal produseres, er det lett å bygge for mye. Køsystemet og kravet om plan før kode er like mye en brems som en effektivisering.

Dette er den erfaringen som er minst omtalt og mest merkbar i praksis: den samme oppgaven, stilt to ganger, gir ikke det samme svaret. Ikke feil svar - bare ulike. Det gjelder kodestil, ordvalg, hvilke grensetilfeller som blir tenkt på, og hvor grundig noe blir gjort.

Konklusjonen er ikke at AI ikke duger. Den er at en regel må gjøres maskinkontrollerbar for å holde. En regel i et dokument brytes. En regel som gjør en test rød, gjør det ikke. Nesten alle vokterne i dette prosjektet er skrevet etter at noe glapp - ikke i stedet for tillit, men fordi konsistens over tid ikke er noe verken mennesker eller språkmodeller leverer av seg selv.

Og så er det den erfaringen som kanskje betyr mest, og som er lett å undervurdere: grunnen under prosjektet har flyttet seg hele veien. På under et år har verktøyene rundt språkmodellene endret seg gjentatte ganger - nye språkmodeller med andre styrker, nye måter å gi dem verktøy på, nye måter å skrive ned framgangsmåter, nye grenser for hvor mye de kan holde i hodet på én gang.

Det er overveiende positivt: flere av tingene i dette prosjektet var rett og slett ikke mulige da det startet. Men det har en pris som sjelden nevnes. Løsninger bygget for å komme rundt en begrensning, blir liggende igjen etter at begrensningen er borte. Framgangsmåter skrevet for én utgave av et verktøy, passer ikke den neste. Og en del av arbeidstiden går med til å holde tritt framfor til å bygge noe.

Lærdommen er å binde seg løst. Det som er skrevet ned - reglene, framgangsmåtene, begrunnelsene - overlever et verktøybytte. Det som er bygget tett på en bestemt utgave av et verktøy, gjør ikke det. Det er også grunnen til at prosjektet holder på åpne avtaler framfor på leverandørspesifikke løsninger der det finnes et valg.

Alt over er kostnadssiden. Den er reell, og den er verdt å si høyt. Men den er ikke hovedsaken.

Hovedsaken er at læringskurven har vært brattere enn i noe prosjekt med et team rundt seg. Grunnen er enkel: ingen ting kan skyves videre til noen andre. Datamodellering, databearbeiding, nettsted, tilgjengelighet, drift, overvåkning, redaksjonelle valg, kostnadsstyring - alt sammen må forstås godt nok til å tas ansvar for. I et vanlig prosjekt ville hver av disse vært en annens rolle, og berøringspunktene ville vært det eneste man så.

Regnestykket går i pluss. Det koster 1 245 kroner i måneden og betydelig mer i tid enn noen ville budsjettert med. Til gjengjeld finnes det ikke noe kurs som gir det samme.

Det ærligste å avslutte med er hva som fortsatt står åpent.

• De automatiske kontrollene har en kjent blindsone: de oppdager at et datasett er ufullstendig, men ikke at datahentingen har sluttet å kjøre. Da blir rådataene bare ikke oppdatert, og alt ser riktig ut fordi alt er som sist.
• De to dataarkitekturene lever fortsatt side om side. Det er en bevisst avveining, men det er også teknisk gjeld: en regning som forfaller senere.
• Manuelt vedlikeholdte datasett har ingen god løsning. Vakten sier fra, men noen må fortsatt gjøre jobben.
• Noen sider bruker fortsatt faner framfor egne adresser, selv om konvensjonen sier noe annet.
• Kvaliteten på det maskinene tolker ut av dokumenter, er god nok til å publisere, men ikke god nok til å slutte å kontrollere.
• Hvor grensen for autonomi bør gå, er ikke ferdig tenkt. Publisering blir hos et menneske. Alt annet er åpent.
• Automatikken oppretter oppgaver raskere enn de lukkes, og å avgjøre at noe er ferdig, krever fortsatt at et menneske leser gjennom.

Denne siden oppdateres jevnlig. Tallene på den oppdaterer seg selv; teksten leses over med jevne mellomrom. Er noe her galt eller uklart, hører vi gjerne fra deg.