Utviklingsprosess og autonomi

Portalen er bygget av én person med AI som medarbeider i alle roller. Det gjør prosessen viktigere, ikke mindre viktig. Uten et team som stiller spørsmål underveis, må spørsmålene stilles på forhånd - og skrives ned.

Derfor starter alt arbeid med en spesifikasjon og en plan som godkjennes før noe bygges. Det høres tungvint ut for et prosjekt med én utvikler. Det motsatte er tilfellet: en AI-medarbeider bygger nøyaktig det som står beskrevet, raskt, også når beskrivelsen er feil. Kostnaden ved en uklar spesifikasjon er høyere her enn i et vanlig prosjekt, ikke lavere.

1. 1. Spesifikasjon

   Oppgaven beskrives før noe bygges: hva som skal løses, hvorfor, og hva som må være sant for at det er ferdig.

2. 2. Plan

   Planen skrives ut og godkjennes før første kodelinje. Er den tvetydig, avklares det nå framfor halvveis.

3. 3. Test først

   Testen skrives før koden og skal feile først. En test som består med én gang, har som regel ikke testet noe.

4. 4. Bygging

   Arbeidet skjer på en egen gren, aldri direkte i det som er publisert.

5. 5. Kontroll

   Stilkontroll, typesjekk, hele testsettet og de egne reglene skal være grønne før noe går videre. Det er en arbeidsregel, ikke en lås.

6. 6. Kodegjennomgang

   Endringen leses gjennom kritisk før den tas inn, uansett hvor liten den er. Unntak må sies med rene ord.

Siden april 2026 har endringene fra utviklingsøktene vist til en oppgave i oppgavesporeren, og siden da har 556 oppgaver satt spor i kodelageret. Lageret har 3 330 endringer siden 2025-11-21, de faste jobbenes egne medregnet. Kjeden over er bygget opp underveis, så de tidligste oppgavene gikk ikke gjennom alle stegene.

Prosjektet har 218 testfiler. En god del av dem tester ikke en beregning, men vokter en regel. Forskjellen er verdt å forklare, for det er den mest nyttige lærdommen herfra.

Vokterne er der fordi en skreven regel ikke holder av seg selv. En regel som står i et dokument, blir brutt. En regel som gjør testen rød, blir ikke det. De fleste vokterne i prosjektet er skrevet etter at feilen de vokter mot, faktisk ble gjort.

Ingen kodeendring fra en utviklingsøkt skal tas inn uten at den er lest gjennom kritisk først. Det de faste jobbene skriver, som nye tall fra kildene og den samlede endringsloggen, går rett inn. Det kontrolleres av vokterne etter at det er tatt inn, ikke av en gjennomlesing før. Regelen har ett unntak, og det krever at man sier det med rene ord - «ser bra ut» holder ikke.

Kravet ble skjerpet etter en periode der en rekke endringer gikk inn uten gjennomgang. Ingen av dem var ondsinnede eller store. Regelen fantes, men den var plassert et sted i prosessen der den var lett å hoppe over, og da ble den hoppet over. Rettelsen var ikke å skrive regelen tydeligere, men å flytte kontrollpunktet til det siste steget som ikke kan angres.

Å flytte kontrollpunktet holdt heller ikke. Senere ble en leveranse tatt inn tjue sekunder etter at den ble åpnet, mens gjennomlesingen fortsatt pågikk, og to av funnene kom ikke med. Regelen om å vente var fortsatt en påminnelse. Nå åpnes leveranser som utkast, og de markeres klare til å tas inn først når gjennomlesingen er ferdig. Det er samme lærdom som vokterne over: en påminnelse blir glemt, en mekanisme blir ikke det. Nattkjøringen følger den samme regelen: en leveranse åpnes som utkast og markeres aldri klar av seg selv. Det er fortsatt gjennomlesingen neste morgen som avgjør, men den avgjørelsen kan nå ikke droppes ved et uhell - utkast-tilstanden er den samme mekaniske sperren som resten av prosjektet bruker, ikke en påminnelse som gjelder for natten alene.

Gjennomlesingen gjøres av en egen agent som får endringen, reglene og planen, men ikke arbeidsloggen fra implementeringen. Den arver dermed ikke antakelsene som eventuelt var feil, og det er den egenskapen som gjør den nyttig. En annen leverandør som ekstra leser ble vurdert og valgt bort: to maskinlesere som kommenterer det samme, gir mer støy enn signal når det er én person som leser alt. Leseren finner reelle feil, men den er ikke uttømmende, og en ny runde kan finne noe den forrige ikke så. Mer om det i kapitlet om hva det krever, og hva det gir.

Dokumentasjon som må vedlikeholdes ved siden av koden, blir feil. Ikke fordi noen er slurvete, men fordi det andre stedet alltid taper mot det første. Prosjektet forsøker derfor å la dokumentasjonen skrive seg selv der det går an.

Det som ikke kan utledes, må skrives. Prosjektet har 101 dokumentasjonssider ut over disse. En egen regel krever at dokumentasjonen oppdateres i samme slengen som endringen den beskriver, ikke etterpå - «etterpå» kommer aldri.

Flaskehalsen i et soloprosjekt er ikke å skrive kode. Det er å ta avgjørelser. En AI-medarbeider kan bygge raskere enn én person rekker å bestemme hva som skal bygges.

Køsystemet er svaret på det. Flere oppgaver kan planlegges i én økt, godkjennes, og legges i kø. Senere kjøres køen gjennom: hver oppgave hentes fram, bygges etter sin egen plan, og stopper før den tas inn. Ingen av dem går inn i hovedgrenen uten at et menneske tar beslutningen. Hvor grundig det mennesket leser, er ikke målt: leveransen åpnes når arbeidet er ferdig, så tiden den står åpen, sier lite, som kapitlet om prosess, tid og forbruk viser.

Det er den grensen autonomien har i dag, og den er valgt bevisst. Retningen videre er å flytte den ett hakk om gangen framfor å hoppe:

1. Først

   Planer godkjennes på forhånd, bygges uten tilsyn, og leses av et menneske før de tas inn.

2. Nå

   Flere oppgaver bygges parallelt om natten, i hvert sitt isolerte miljø, uten at noen er til stede.

3. Ikke påbegynt

   Innhold som er blitt utdatert, oppdages allerede. Neste trinn er at signalet får med seg et utkast til omskriving, som et menneske velger å ta videre eller la ligge. Køen fyller seg fortsatt ikke selv.

4. Grensen

   Publisering av tekst og faglige valg blir værende hos et menneske. Det er ikke en teknisk begrensning, men en redaksjonell. Nye tall fra kildene går ut uten godkjenning, fordi oppskriften er fast, og en henting som feiler, beholder forrige versjon.

Det andre trinnet er ikke lenger en plan. Oppgaver kan nå settes i kø om kvelden, bygges parallelt i hvert sitt isolerte miljø gjennom natten, og ligge klare til gjennomlesing neste morgen. Ingenting tas inn i hovedgrenen underveis.

Kjeden har ni ledd. Om kvelden merker du en oppgave, kandidatene hentes, konflikter avgjør hvilke som kan gå samtidig, og én kjøring settes i gang per oppgave. Gjennom natten implementeres planen, den verifiseres, arbeidet legges fram, og den gjennomleses og drives til grønn automatisk kontroll. Neste morgen ber du om rapporten, og leser gjennom.

Planen natten bygger etter, er den samme som ble godkjent i en vanlig økt. Når den godkjennes, skrives den inn i oppgaven, og kjøringen får hele teksten med seg. En plan på noen få linjer avvises. Før noe settes i gang, bygges hovedgrenen: feiler det bygget, avbrytes hele natten, fordi alle leveransene uansett ville fått rød kontroll.

Køen er menneskekurert, og det er et valg

Ingenting legger seg selv i køen. En oppgave kjøres bare fordi et menneske har merket den for det. Å la systemet opprette oppgaver selv, fra signaler om utdatert innhold, ble vurdert og forkastet: kontroll over hva som kjøres veier tyngre enn de minuttene det sparer å slippe å opprette oppgaven.

Hva som hindrer at parallelt arbeid kolliderer

• Planen må si hva den rører

  En plan uten en liste over hvilke filer den endrer, avvises. Uten den listen kan ikke risikoen vurderes, og da er det ærligere å si nei enn å håpe.

• To planer mot samme fil kjører etter tur

  Overlapper to oppgaver, venter den ene på den andre framfor å kollidere. Enkelte felles filer, blant dem registrene enhver ny side må inn i, får dessuten høyst én oppgave per natt røre. Kontrollen ser bare oppgavene i nattens kø, ikke arbeid som pågår i andre økter.

• Grensene kjøringen ikke skal krysse

  Aldri ta noe inn i hovedgrenen. Aldri skrive til den direkte. Aldri endre det som styrer kjøreplanen. Aldri gjette ved tvil: stopp, og skriv hva som manglet, for en kjøring kan ikke spørres underveis. Grensene står i instruksen kjøringen får, ikke i rettighetene den har. Hovedgrenen er ikke låst for skriving, og forbudet mot filene som styrer kjøreplanen sjekkes mot filene planen oppgir, ikke mot det kjøringen faktisk endrer. Det som skal fange et brudd, er gjennomlesingen neste morgen.

• Stillhet regnes ikke som suksess

  Morgenrapporten skiller tre utfall: klar for gjennomlesing, krever en avgjørelse, og ingen spor. Det siste er det viktigste designvalget - en oppgave som mangler i statusdataene rapporteres aldri som stille suksess.

Rekkefølge og hvor mange om gangen

• Rekkefølgen er prioriteringen din

  Køen leses i den rekkefølgen oppgavene er rangert. Står to i konflikt om samme fil, kjøres den øverste, og den andre venter til neste natt med en forklaring på oppgaven. Vurderingen gjøres hver natt når kjøringen starter, ikke når oppgaven merkes.

• En oppgave som bygger på en annen, venter

  Er en oppgave merket som blokkert av en annen, kjøres den ikke før den andre er tatt inn i hovedgrenen. Levert er ikke nok. Dermed kan en hel kjede merkes på én gang, og den går ett ledd per natt.

• 3 om gangen, 5 som tak

  Begrunnelsen er morgenen etter, ikke natta: hver leveranse skal leses gjennom og tas inn, og omarbeid oppstår når leveranse nummer to tas inn mot en hovedgren nummer én nettopp endret. Budsjettvinduet deles dessuten av alle kjøringer som går samtidig. Taket ble hevet i september 2026, da tre leveranser ble lest og tatt inn samme morgen uten at det ble trangt, og køen besto mye av artikler som rører hver sine filer. Høyere ble det ikke, fordi hver artikkel har tall som skal kontrolleres før den tas inn.

• Én forbudt fil feller hele planen

  Planer som vil endre det som styrer kjøreplanen, eller hemmeligheter, avvises i sin helhet - ikke bare den ene filen. Slike endringer gjøres for hånd etterpå.

Hvor ofte endringer som er åpne samtidig faktisk deler fil, og hva parallelt arbeid gjør med forbruket, måles i kapitlet om prosess, tid og forbruk.

Status på 7 deler av oppsettet

Det mest lærerike funnet

Den første ekte nattkjøringen leverte oppgaven sin riktig. Men den uavhengige gjennomlesingen den selv kjørte, fant fem reelle feil i infrastrukturen som kjørte den - blant annet at en rapport aldri leste om en leveranse allerede var tatt inn, og derfor kunne meldt en ferdig oppgave som «klar til gjennomlesing». En annen var at konfliktkontrollen sammenlignet filstier ordrett, så to planer kunne kjørt samtidig mot samme fil. Samme feil gjorde at forbudet mot at en nattkjøring endrer filene som styrer kjøreplanen, kunne omgås ved å skrive stien med et punktum og en skråstrek foran. Grensen var altså en tekstsammenligning med et hull i. Alle fem ble bekreftet før de ble rettet, og alle fikk en test som hindrer at de kommer tilbake.

Poenget er ikke at systemet var dårlig bygget. Det er at et system som skal jobbe uten tilsyn, må testes av noe som ser på det utenfra - og at den beste gjennomlesingen ofte kommer fra den som nettopp har brukt tingen til noe ekte.

Når det har gått galt

Hendelsene under står i prosjektets egen historikk. De fleste følger samme mønster: en regel eller en antakelse holdt ikke, og svaret ble en sjekk eller en mekanisme framfor en tydeligere formulering.

• Tatt inn før gjennomlesingen var ferdig

  En leveranse ble tatt inn tjue sekunder etter at den ble åpnet, mens gjennomlesingen pågikk. Samtidig ble en ny leveranse åpnet fra det samme arbeidet. Den fikk konflikt og måtte gjøres om til en oppfølging. Regelen om å vente fantes. Nå åpnes leveranser som utkast.

• Tatt inn før rettelsene

  En leveranse ble tatt inn før rettelsene fra gjennomlesingen var lagt til. Med den fulgte regenererte datafiler med feil, blant annet en tidsserie over 21 år som var blitt tømt. Filene ble satt tilbake i en egen runde.

• Statusmarkeringer som dro oppgaver bakover

  Statusmarkeringer skrevet inn i endringsbeskrivelsene dro ferdige oppgaver tilbake i oppgavesporeren. Når en leveranse slås sammen til én endring, blir beskrivelsene med, og integrasjonen leste markeringene på nytt et halvt til ett minutt etter at oppgaven alt var satt til ferdig. Regelen nå er at slike markeringer holdes ute av det som slås sammen, og at en egen jobb setter oppgaven til ferdig når leveransen tas inn. Verktøyene som starter en oppgave, skriver fortsatt markeringer, og det står igjen som en kjent rest.

• Samme arbeid i parallelle økter

  Samme oppgave ble løst i tre økter som ikke visste om hverandre, og alle tre la løsningen i samme fil. Én ble tatt inn, én ble lukket, og den tredje måtte skrives om til bare det den første ikke dekket. Konfliktkontrollen for natten ville ikke fanget det: den ser bare oppgavene i sin egen kø.

• Fordeling som stille ble til noe annet

  Kjøringene som skulle gå i hvert sitt miljø i skyen, ble i én kjøring startet som underagenter på maskinen som satte dem i gang. Svaret var at kjøringene var startet, og det var sant, men de ville stoppet sammen med maskinen. Nå sjekkes verktøyet før fordelingen lover noe, og det bekreftes etter start hvor kjøringene havnet.

• Grønn kontroll av feil versjon

  Kontrollen av hovedgrenen før natten ble meldt grønn, men den hadde bygget en foreldet lokal kopi som skilte seg fra hovedgrenen med 190 filer. Ingen av nattens kjøringer ville sett den versjonen. Nå bygges hovedgrenen slik den ligger sentralt, og begge versjonene skrives ned, så kontrollen kan etterprøves.

• Rød kontroll etter at leveransen var tatt inn

  En endring besto testene som ble kjørt lokalt, men brøt en test et annet sted. Bare de nyskrevne testfilene var kjørt, og feilen ble synlig først da hele testsettet kjørte, etter at leveransen alt var tatt inn. Kravet nå er hele testsettet slik den automatiske kontrollen kjører det.

• Avvist for noe som sto der

  Sju oppgaver ble avvist samme natt fordi planen skulle mangle lista over filer som endres. Alle sju hadde lista, men ikke i en form innlesingen kjente igjen. Beskrivelsene var lagret som ren tekst i stedet for med ekte overskrifter og lister, og koblingen som kjøringen i skyen leser oppgavene gjennom, merket tegnene slik at en overskrift ikke lenger så ut som en overskrift. Lest fra maskinen så det meste riktig ut, så feilen var vanskelig å se utenfra. Beskrivelsene ble skrevet om, og innlesingen skal tåle den merkede formen og gi en egen begrunnelse når en liste finnes, men ikke kan leses.

• Hele køen på det dyreste nivået

  En kø startet fra en økt på det dypeste modellnivået kjørte alle oppgavene på det nivået, fordi kjøringene arvet det fra den som startet dem, og forbruket ble ganget med antall samtidige kjøringer. Nivået velges nå per oppgave, med standardnivået som utgangspunkt.

Alt over beskriver hva systemet gjør. Sett fra den som bruker det, er det tre handlinger, og ingen av dem krever at maskinen din står på. Selve kjøringen starter av seg selv hver kveld. Den kan fortsatt startes for hånd tidligere, men da må oppgaven være levert før kveldskjøringen går, ellers plukkes den opp to ganger.

Oppgaver som ikke passer for natten

Markeringen er billig fordi det dyre alt er gjort: planen er skrevet og godkjent i en vanlig økt, med et menneske til stede. Natten tar heller ikke alt. Planer som rører mer enn en håndfull filer, bør holdes utenfor, fordi de som regel trenger avgjørelser underveis, og en kjøring kan ikke spørre. Oppgaver som krever at tall kontrolleres mot kildene underveis, kan ikke kjøres, fordi verktøyene for det ikke finnes i kjøremiljøet om natten.

Én markering inn, to spor ut

Systemet fører fire markeringer på tre ulike steder. To settes av et menneske: den som legger oppgaven i køen, og en valgfri som ber om det dypeste modellnivået for akkurat den oppgaven. De to andre skriver systemet selv: en oversikt over hva natten forsøkte seg på, og et spor tilbake til hver enkelt kjøring. De finnes for at en kjøring som stoppet halvveis skal kunne finnes igjen i ettertid, ikke for at noen skal vedlikeholde dem.

Å skru det av er den billigste handlingen i systemet

Fjern markeringen fra alle oppgaver, så er køen tom. Kveldskjøringen starter fortsatt, finner ingenting og avslutter, uten at noe må rulles tilbake og uten at noen innstilling må endres. Det er et bevisst valg, og det er verdt å si høyt: et system som er dyrt å stoppe, blir stående lenger enn det burde. Når stoppknappen er én handling, koster det ingenting å ombestemme seg.

«Ingenting å gjøre» er ikke en feil

En tom kø og «dette krever deg» er to forskjellige utfall, og ingen av dem er en feiltilstand. Systemet skiller på dem med vilje, av samme grunn som rapporten skiller «ingen spor» fra suksess: den dagen alt uvanlig ser likt ut, slutter du å lese meldingene.

En portal med mange temaer har alltid noe som kunne vært dekket bedre. Å holde oversikt over det for hånd er håpløst, så to agenter gjør hver sin del av jobben.

Den ukentlige gjennomgangen leverer ikke en liste over problemer, men ferdige forslag. Hvert av dem sier hvilken adresse siden ville fått og hvilke datasett som allerede finnes for temaet. Idébanken legger i tillegg ved en kort begrunnelse for hvorfor ideen er verdt å se på.

Det er ikke pynt. Et forslag som må utredes før du kan si nei til det, blir liggende - og en liste som bare vokser, slutter du å åpne. Forslaget må være ferdig nok til å kunne avvises på et halvminutt.

Den daglige skriver til en idébank et menneske plukker fra. Den ukentlige legger forslagene fram som en leveranse et menneske må ta inn. Ingen av dem oppretter oppgaver selv. Idébanken har i tillegg en hard grense: agenten kan bare skrive i sin egen, avgrensede del av hvert dokument. Alt et menneske har skrevet, er utenfor rekkevidde. Uten den grensen ville en agent som misforsto formatet, kunnet overskrive tenkearbeid ingen hadde sikkerhetskopi av.