Kvalitets- og autonomiregnskapet

Portalen er bygget av én person med en språkmodell som medarbeider. Et rimelig spørsmål er da om det faktisk blir bedre over tid, eller bare mer. Dette kapitlet er forsøket på å svare med tall framfor med følelse.

To ord går igjen. Automatisert betyr at noe skjer av seg selv etter en fast oppskrift. Agentisk betyr noe mer: at det velger selv hvordan oppgaven skal løses, og kommer i mål uten at et menneske godkjenner hvert skritt. Forskjellen er ikke akademisk, og den er lett å pynte på, så den har fått sine egne kriterier lenger nede.

Fire forbehold som gjelder alt du leser her

• Antall fangede feil sier ikke om kvaliteten stiger

  Flere fangede feil kan bety at det bygges dårligere, eller at det oppdages bedre. De to ser identiske ut i en graf. Det som er ærlig målbart, er HVOR feilen blir fanget, og en flytting fra «leseren fant det» mot «en sjekk stoppet det» er den reelle forbedringen.

• Ingenting telles uten en nevner

  Mer aktivitet gir flere av alt. Et tall per måned sier lite hvis måneden var dobbelt så travel som forrige.

• Null omgjort arbeid er ikke et mål

  At noe må gjøres om etter en gjennomlesing, er systemet som virker. Et regnskap som belønner null, belønner å slutte å se etter.

• Tomt er tomt

  Der grunnlaget mangler, står det at det mangler. Ingen erstatningstall uten at det er sagt at det er et erstatningstall.

Alt som kjører her, er plassert på ett av tre nivåer. Plasseringen avgjøres av tre spørsmål med ja- eller nei-svar, ikke av hvor avansert noe høres ut.

Regelen som gjør størst forskjell: en fast oppskrift blir ikke agentisk av å spørre en språkmodell underveis. En betingelse er ikke handlingsrom. Det er en ubehagelig regel, fordi den flytter flere av de mest imponerende delene ned et hakk, og det er nettopp derfor den står her.

10 av de 22 mekanismene har en språkmodell inne i seg, men bare 4 er agentiske. Det er hele forskjellen mellom å bruke en modell og å gi den handlingsrom, uttrykt i to tall.

Alle 22 mekanismene

Dette er listen resten av kapitlet teller på. Hver rad er en mekanisme som gjør noe av seg selv, med nivået den fikk, hvor langt den får lov til å endre noe, og begrunnelsen for plasseringen.

Nivået alene flater ut noe vesentlig. En spørreflate som svarer på spørsmål, og en nattkjøring som bygger ferdig en oppgave, er begge agentiske. Den ene endrer ingenting, den andre leverer noe et menneske må lese gjennom. Uten en akse til blir «agentisk» et honnørord.

Tabellen sier noe som er verdt å stanse ved: det som når lengst ut, er det som velger minst selv. Alt som treffer leseren direkte, er faste oppskrifter uten et eneste valg underveis. Det agentiske stopper ved en leveranse som må leses, eller ved et svar som ikke endrer noe. Det er ikke en tilfeldighet, det er der grensene er trukket.

4 ting kunne vært overlatt til maskinen, og er det ikke. Alle er valgt bort med vilje, ikke noe som bare ikke er bygget ennå.

• Sammenslåing til hovedgrenen

  Det siste steget før noe er felles eiendom, krever et menneske.

• Publisering av innhold

  Utkast skrives uten tilsyn, men et menneske peker ut hva som faktisk går ut.

• Opprettelse av oppgaver

  Køen er menneskekurert. Å la systemet opprette oppgaver selv, fra signaler om utdatert innhold, ble vurdert og forkastet: kontroll over hva som kjøres veier tyngre enn minuttene det sparer.

• Endring av kjøreplanen selv

  Det som styrer de faste jobbene, er utenfor rekkevidde for det som kjører i dem.

Automatiseringsgraden er den enkleste av de tre aksene å måle, fordi alt her er tellbart fra registrene. Ingen av tallene under er skrevet inn for hånd.

De 69 datasettene uten egen jobb er ikke forsømmelser. Noen kilder gir bare ut en rapport i ny og ne, og da er et menneske som leser den, den eneste måten tallet kommer inn på. Hvilke det gjelder, står på oversikten over kilder.

Dette er aksen som betyr mest, og den som er vanskeligst å måle ærlig. Grunnlaget er en dagbok med to slags føringer, og de to holdes fra hverandre overalt på denne sida.

Et antall feil per måned sier lite alene: en travel måned gir flere av alt. Grafen viser derfor en andel. Og feilene er alltid delt i to, fordi de to slagene måler helt ulike ting: 31 av de 114 feilene i perioden under er meldt automatisk av en fast kjøring som stoppet opp, altså av overvåkningen, og ikke av noen som fant noe galt i innholdet. En udelt kurve ville i hovedsak vist hvor ustabile de eksterne tjenestene har vært.

Andelen alene holder likevel ikke, for utviklingen går i rykk og napp. En måned med få feil kan like gjerne bety at ingen jobbet. Stripa under hver måned i figuren er derfor antall aktive utviklingsdager: dager der noen satte i gang en endring. Kunne de ikke telles, står stripa tom framfor å vise null - som ville betydd «ingen jobbet», og det er en påstand vi bare kan gjøre når vi har talt.

Målet skiller ikke mellom menneske og maskin. Det meste av koden her er skrevet av en språkmodell, og de dagene teller like fullt. Grensen går et annet sted: mellom en endring noen ba om, og en fast jobb som kjørte fordi klokka sa det. Spørsmålet er om det ble utviklet den dagen, ikke hvem som holdt tastaturet.

Grensen er ikke kosmetisk. De faste jobbene endrer noe hver eneste dag, så uten den ville hver dag telt som aktiv, tallet vært det samme hver måned, og grafen fortalt ingenting. Hvem som står bak en endring, leses derfor av et register framfor å vurderes fra gang til gang, og et navn som ikke står der, stopper hele tellingen framfor å bli gjettet på. Grunnen er at en gjetning har en retning: blir en ny jobb talt som utvikling, ser månedene travlere ut enn de var, og feilene per arbeidsdag færre. Altså en glidning i den retningen som smigrer oss.

Bytter du figuren under til tabell, står begge målene ved siden av hverandre. De svarer på ulike spørsmål: andelen på hvor stor del av arbeidet som gikk galt, feil per aktiv dag på hvor tett feilene kom når det først ble jobbet. De kan peke hver sin vei, og det er da de er verdt å ha. Måneden som fortsatt pågår er merket, siden et halvmålt tall ikke skal stå umerket ved siden av ferdige måneder.

Hvor tunge oppgavene var

To feil på en oppgave som rørte femten filer i fem deler av løsningen, og to feil på en tekstretting, er ikke det samme. Oppgavene er derfor delt i tre etter hvor mye som måtte henge sammen for å levere dem. Tallene står ved siden av feiltallene og ganges aldri inn i dem: en feilrate delt på en kompleksitets-score ser presis ut, og er det ikke.

• Små

  213

  Rørte høyst ett av fellesregistrene, holdt seg innenfor to deler av løsningen, og under 300 egne linjer.

• Middels

  140

  Alt som verken er lite eller stort.

• Store

  35

  Måtte inn i 4 eller flere fellesregistre - eller rørte 5 eller flere deler av løsningen og skrev minst 300 egne linjer.

Målet teller koordinasjon, ikke volum, og det er hele poenget. Den største enkeltendringen i historikken er på over hundre tusen linjer, og innholdet er nedlastede tabeller fra en offentlig statistikkbank: mye tekst, lite vanskelighet. Linjer som bare er hentet eller generert, trekkes derfor fra, og en endring som måtte inn i mange av fellesregistrene teller tyngre enn en som bare er stor.

To ting måles bevisst ikke. Kompleksiteten leses av førsteleveringen, ikke av summen med alle rettingene etterpå: ellers ville en oppgave sett tyngre ut fordi den gikk galt, og da måler tallet utfallet det skal stå ved siden av. Og hvilken språkmodell som gjorde hva, er ikke målt. Det er ikke registrert noe sted og kan ikke rekonstrueres bakover. Skulle det besvares, måtte det skrives ned framover - og selv da ville det vært en observasjon og ikke et forsøk, siden modellene byttes samtidig som alt annet endrer seg.

Fordelingen per måned står i tabellvekslingen over, i kolonnen som viser små, middels og store oppgaver ved siden av feilandelen. De to er talt fra hvert sitt sted - oppgavene fra endringshistorikken, feilene fra oppgavesporeren - så summene er ikke de samme. En oppgave som ikke endret en eneste linje kode, finnes i sporeren og ikke her.

Grafen svarer ikke på om kvaliteten stiger, og skal ikke leses som om den gjør det. En lav andel kan like gjerne bety at det ble lett mindre etter feil den måneden. Det er nettopp derfor resten av kapitlet handler om hvor feilen ble fanget, og ikke om hvor mange det var.

Hvor feilen ble fanget

Antallet feil sier lite. Det som sier noe, er om de fanges tidligere i kjeden over tid: en flytting fra leseren fant det mot en sjekk stoppet det er den reelle forbedringen. Loggen fører derfor hva som oppdaget hver hendelse, og om den rakk ut til leseren.

Den håndskrevne loggen ble tatt i bruk 2026-09-04 og har 8 føringer. Det er altfor lite til å tegne en kurve av. Derfor er historikken før den lest ut av spor som alt fantes. Figuren under viser de samme månedene som feilkurven over, og alle de 109 avledede føringene faller innenfor. De to slagene føringer blandes aldri, og den avledede delen er skjev.

De avledede føringene skrives tilbake dit dagboka føres, i kunnskapsbasen. Ikke inn i dagboka selv, men på siden ved siden av, i en egen del som bare den daglige kjøringen fyller. Hensikten er å slippe å skrive ned igjen noe som allerede er fanget: står hendelsen der, er den med i tallene på denne sida fra før.

At det er to sider og ikke én, er ikke en ryddedetalj. Skrev kjøringen i dagboka, ville den lest sitt eget arbeid tilbake neste natt og talt det som noe et menneske hadde skrevet. Da ville fordelingen over sakte drevet mot det systemet selv hadde produsert, uten at noe stoppet opp. To sider gjør det umulig framfor bare frarådet, og kjøringen skriver aldri en føring.

Én rad per mekanisme, over de samme månedene som feilkurven. Hver rad er skalert for seg: spørsmålet er hvordan den enkelte mekanismen utvikler seg, ikke hvilken som er størst. Månedene før en mekanismes første spor er merket «ikke målt», ikke tegnet som null - null betyr at mekanismen ikke fanget noe, og det er en helt annen påstand enn at sporet ikke fantes ennå.

Alle 6 mekanismene står i tabellen, også de uten en eneste føring. En opptelling over bare de som forekommer, ville sluppet de tomme ut - og det er nettopp de tomme som bærer opplysningen om hva grunnlaget ikke dekker. De to kolonnene har hver sin ferskhet, og hver sin henvisning over.

Dette er hovedtallet, og det er ikke klart ennå. Håndskrevne føringer med et svar på om feilen rakk ut: 8 av 8. Avledede med et svar: 74 av 109, mens 35 ikke har det. Et spor sier ofte hva som fanget noe, uten å si hvor det da hadde rukket. De uten svar telles for seg framfor å legges til «nei»: en manglende opplysning skal ikke bli til en gunstig påstand.

Ingen andel er regnet ut av dette, og det er med vilje. Nesten alle radene med et svar er avledede, og de er avledede nettopp fordi de ble stoppet et sted som setter spor. Ingen avledningsregel kan gi «rakk ut»: en feil som gled gjennom alt sammen og nådde leseren, setter ingen slike spor, og finnes bare hvis noen skrev den ned. Nullen i den kolonnen er derfor en egenskap ved sporene, ikke en måling. En andel regnet over dette grunnlaget ville sagt at nesten ingenting når leseren, og vært like misvisende. Tallet blir først meningsfullt når den håndskrevne delen har nok volum til å stå alene.

Årsak og omgjort arbeid

Hva slags feil det var, og om arbeid som alt var gjort måtte gjøres om, finnes bare i de håndskrevne føringene. Ingen av sporene svarer på det: en rød sjekk sier at noe ble stoppet, ikke om det var en påstand uten grunnlag, en feil slutning fra riktige tall eller en oppgave som ikke var godt nok beskrevet. Å tildele en årsak i etterkant ville vært gjetning forkledd som data.

Så langt fordeler de håndskrevne føringene seg slik: hallusinasjon 0, feil-antakelse 2, manglende-spesifikasjon 0, konvensjonsbrudd 2, kodefeil 3, drift 1. Omgjort arbeid: 7 av 8. Det er for få til å lese noe ut av, og de står her fordi tomme felter skal synes framfor å bli fylt med noe som ligner.

Det som gjenstår, er tid. Etter noen uker med føringer står den skrevne delen på egne bein, og den avledede blir historikk framfor hovedtall. Da kan andelen som rakk ut regnes, og årsaksfordelingen leses. Ingen av delene skal utledes tidligere enn det.

Egen bolk, ikke en fotnote nederst. Et regnskap som bare viser det som er lett å telle, gir et penere bilde enn det fortjener.

• Hvor mye én instruksjon utløser

  Hvor mange handlinger en modell tar for hver beskjed den får, er kanskje det mest talende målet på hva denne arbeidsmåten faktisk gir. Det kan bare leses av logger som holdes i omtrent en måned, så det blir et øyeblikksbilde og ikke en kurve.

• Hvor lang tid en oppgave faktisk tok

  Det finnes et tidspunkt for når arbeidet ble sagt ferdig, men ikke for når det egentlig begynte. Differansen mellom dem ville vært en gjetning.

• Hvor ofte noe måtte rulles tilbake

  Sto som et nøkkeltall her en kort stund, og var strukturelt låst på null: emnelinjene følger en fast navnekonvensjon, og endringer slås sammen før de går inn, så ordet dukker aldri opp i en emnelinje. Et tall som ikke kan variere, er ikke en måling. Det som måtte gjøres om, fanges av loggen i stedet.

• Feilene som aldri ble oppdaget

  Den viktigste kategorien, og den eneste som per definisjon ikke kan telles. Alt på denne siden handler om det som ble fanget.