Prosess, tid og forbruk

Kapittel 9 beskriver kjeden fra spesifikasjon til kodegjennomgang. Dette kapitlet måler den. Tre kilder legges ved siden av hverandre: oppgavesporeren, som vet når en oppgave ble opprettet og lukket, kodelageret, som vet når arbeidet faktisk startet og når det ble tatt inn, og arbeidsøktene med språkmodellen, som vet hva som skjedde imellom.

To av tallene har to nevnere, og det er verdt å vite hvilken. 38 av de 574 sakene i sporeren er opprettet av overvåkningen selv når en fast kjøring stoppet opp. De er ikke arbeid, og de er tatt ut av hovedtallene over; tabellvekslingen under viser begge variantene. Her sier tallene at forskjellen er liten: medianen står på 6,7 timer med dem inne og 5,8 uten. Grunnen er en annen enn ventet - de fleste oppgavene opprettes i det arbeidet begynner, så sporeren måler hvor lenge arbeidet tok, ikke hvor lenge oppgaven ventet.

Gjennomgangstiden er målt fra kodelageret, ikke fra sporeren. 59 % av oppgavene har ingen egen gjennomgangsfase i sporeren, så medianen der bygger på under halvparten av arbeidet. Kodelageret har derimot både opprettelse og sammenslåing for hver eneste PR. Begge tallene står i tabellen. Og begge er små av samme grunn: her er det én person som både skriver og slår sammen, så PR-en opprettes når arbeidet allerede er gjort. Tallet måler hvor lang tid sammenslåingen tok, ikke hvor lenge noen så på koden.

Median antall timer fra en oppgave ble opprettet til den ble lukket, per måned den ble lukket. Måneder med færre enn 5 oppgaver vises dempet med antallet synlig: en median av tre sier ingenting. Tabellvekslingen har også antall PR-er, tid i gjennomgang og hvor mange oppgaver som gikk rett fra arbeid til ferdig uten en egen gjennomgangsfase.

Erfaringen som utløste dette kapitlet: det blir kaotisk når for mange oppgaver er i gang samtidig, og forbruket forsvinner fort. Målet på det er hvor ofte to endringer som var åpne på samme tid rørte den samme fila. Nevneren er PR-par med overlappende levetid, fra første commit til merge; telleren er de av dem som delte minst én fil.

Telleren regnes i to varianter. Alle nye sider må inn i de samme registrene - søket, sitemapen, listen over nytt innhold - så to oppgaver som begge rører dem, deler fil av arkitekturens grunner og ikke av oppgavenes. Hovedtallet holder disse fellesfilene utenfor og sier dermed noe om oppgavene; varianten som tar dem med, sier hvor ofte to endringer måtte ryddes mot hverandre uansett årsak. Begge står i tabellen.

Plassert i måneden den seneste av de to ble merget, for det er da kollisjonen eventuelt måtte ryddes. Tabellvekslingen viser også hvor mange oppgaver som var aktive i måneden, og hvor mange oppgaver en typisk arbeidsøkt rørte.

6 PR-er endret over hundre filer, og bare de hundre første er med i sammenligningen. Andelen kan derfor være lavere enn den egentlig var, aldri høyere.

Hver arbeidsøkt med språkmodellen deles i faser etter hvilke verktøy og arbeidsmåter den brukte: en plan som skrives, en test som skrives før koden, en kodegjennomgang som bes om. Fasen gjelder fra signalet kom og til neste signal. Det som ikke gir noe signal, ligger i Uklassifisert, og den bøtta vises: en fase som skjules, er et tall som lyver.

Tokens modellen skrev, ikke tokens den leste. Lesingen av kontekst vokser med hvor langt inn i økta man er, ikke med innsatsen, og en fasegraf på den ville vist hvilke faser som kommer sent. Tabellvekslingen har verktøykall og aktive minutter ved siden av.

I kroner veier sene faser tyngre, fordi konteksten som leses om igjen er størst da. Tabellen viser begge. Kosten er målt per fase, ikke fordelt etter hvor mye som ble skrevet: en fordeling ville skjult akkurat den forskjellen tallet finnes for å vise. Rader som ikke kunne måles, står uten kost, og tabellen sier hvor mange økter hvert kosttall bygger på.

Slått sammen til fem grupper, slik presentasjonen viser dem: Avklaring 325 k, Test først 15 k, Bygging 3,1 mill., Kontroll og levering 3,7 mill., Gjennomgang og retting 1,4 mill..

Arbeidet gjøres på et abonnement med et budsjettvindu som fylles opp. Hva som fyller det, er ikke åpenbart fra utsiden: to økter med like mange instruksjoner kan koste vidt forskjellig, avhengig av modell, hvor lang konteksten har blitt, og hvor mye av den som leses fra cache.

Hva forbruket ville kostet hvis hver forespørsel var betalt til listepris, med egne priser for lesing og skriving av cache. Tabellvekslingen viser tokens og cache-andel per familie.

Hvor mange handlinger språkmodellen utfører for hver beskjed den får, er kanskje det mest talende målet på hva arbeidsmåten gir. En instruksjon er en melding mennesket faktisk skrev. Verktøyresultater, systemets egne påminnelser og oppdragene til underagenter er ikke instruksjoner, og en respons som er skrevet som flere linjer i loggen, telles én gang.

Tre rader over samme akse: hvor mange oppgaver som ble lukket, hvor mye som ble skrevet per lukket oppgave, og hvor mange hendelser som ble ført i hendelsesloggen. Spørsmålet radene stilles for å svare på: blir det billigere per oppgave over tid, og går det på bekostning av noe.

Den midterste raden begynner der innsamlingen begynte. Månedene før den er merket med spørsmålstegn, ikke tegnet som null: arbeidsøktene leses fra logger som lever rundt tretti dager, så for de tidligere månedene finnes ingen tokens - og det er noe helt annet enn at ingenting ble skrevet. mai 26 hadde 197 lukkede oppgaver uten en eneste arkivert økt.

Kurvene over er lette å mislese, og tre av grunnene kan ingen kilde utlede. Utviklingen går i rykk og napp, så en måned med lave tall kan like gjerne bety at ingen jobbet. Abonnementet setter rammen for hvor mange oppgaver som kan gå samtidig, og gir stykkprisen noe å måles mot. Hvilke verktøy som var i bruk, avgjør om tokentallene i det hele tatt dekker arbeidet: bare økter med Claude Code samles inn.

Skillet mellom målt og ført går tvers gjennom denne seksjonen, og det skal være synlig. Aktive dager er talt fra endringshistorikken, med de faste jobbene filtrert bort. Abonnement, verktøy og forklaring er ført for hånd i et register. En måned regnes som stille når den har færre enn 5 aktive dager - det er en utledning fra tellingen, ikke noe noen har erklært. Registeret bidrar bare med forklaringen på hvorfor det ble stille.

Abonnementene er ført fra fakturaene, ikke gjenskapt fra hukommelsen, og periodene er derfor datert på dagen fra 2026-03-22. Nedgraderingen til Pro i tre dager i juni står med som den var - en periode som varte kortere enn en uke, sier noe om hvordan verktøyet faktisk ble brukt. Tiden før det utgjør 3 perioder som står som ukjent. Den kunne vært gjettet, men et gjettet abonnement ville gitt en sammenligning som så like presis ut som de førte uten å være det. Periodene uten Claude Code er like viktige: der finnes det ingen økter å samle inn, og fraværet skal ikke leses som lav aktivitet.

Dager der noen satte i gang en endring. 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 mellom en endring noen ba om og en fast jobb som kjørte fordi klokka sa det. De skraverte månedene i figurene over er de som ligger under terskelen.

Arbeidsøktene er den rikeste kilden og den skjøreste. Loggene finnes bare på utviklerens egen maskin, i rundt en måned, og de inneholder alt som ble skrevet. Det som samles inn, er derfor bare tall per økt: tokens per modellfamilie, minutter, antall handlinger, fase og hvilken oppgave det gjaldt. Ingen tekst, ingen filnavn fra maskinen, ingen grennavn.

• Økter som kjørte i skyen

  Nattkjøringene og andre sky-økter har loggen sin i en beholder som forsvinner. De telles som PR-er, men ikke som tokens. Dekningsgraden over sier hvor stor den blindsonen er.

• Budsjettvinduet i prosent

  Abonnementet viser hvor mye av vinduet som er brukt akkurat nå. Det tallet arkiveres ingen steder, og kan ikke rekonstrueres.

• Tid modellen brukte på å svare

  Loggen har tidspunkt for hver melding, men ikke hvor lenge hvert svar tok å lage. Aktiv tid og veggklokke er det som kan måles, og de står side om side i tabellene.

• Fasene er en tolkning

  Fasekartet leser signaler: hvilken arbeidsmåte som ble kalt, om det var en testfil som ble redigert, om noe ble committet. Det er en heuristikk, og bøtta for det som ikke ga signal, vises alltid.

• Historikken før innsamlingen startet

  Logger eldre enn rundt en måned er borte. Kurvene begynner der innsamlingen begynte, og datoen står på hver av dem.