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 må være grønne før noe går videre.

6. 6. Kodegjennomgang

   Endringen leses gjennom kritisk før den tas inn. Alltid, uansett hvor liten den er.

Til nå er 431 oppgaver ført gjennom denne kjeden, fordelt på 2 934 endringer i koden siden 2025-11-21.

Prosjektet har 135 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. Hver eneste vokter i dette prosjektet er skrevet etter at feilen den vokter mot, faktisk ble gjort.

Ingen endring tas inn uten at den er lest gjennom kritisk først. 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.

Det er også et poeng i seg selv at en AI-assistent leser gjennom sitt eget arbeid med nye øyne. Den finner reelle feil - men den finner ikke alltid de samme feilene to ganger. Mer om det i siste kapittel.

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 75 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. Ingenting går inn i det som er publisert uten at et menneske har lest gjennom det.

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. I dag

   Planer godkjennes på forhånd, bygges automatisk, gjennomleses av et menneske før de tas inn.

2. Nå

   Flere oppgaver bygges parallelt, i hvert sitt isolerte miljø, mens ingen sitter og ser på.

3. Deretter

   Innhold som er blitt utdatert oppdages og skrives om automatisk - men fortsatt bare til utkast.

4. Grensen

   Publisering og faglige valg blir værende hos et menneske. Det er ikke en teknisk begrensning, men en redaksjonell.

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 ligger rapporten klar, og du leser gjennom.

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 filer må dessuten oppdateres samlet når en ny side legges til, så høyst én oppgave per natt får røre dem.

• Grensene er absolutte

  Aldri ta noe inn i hovedgrenen. Aldri skrive til den direkte. Aldri endre det som styrer kjøreplanen. Aldri gjette ved tvil - stopp og spør i stedet.

• 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.

• 2 om gangen, 3 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.

• É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å.

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». 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.

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å.

Én markering inn, to spor ut

Systemet fører tre markeringer på tre ulike steder, men bare den ene settes av et menneske. De to andre skriver det 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. Systemet gjør ingenting, 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, hvilken vinkel den har, hvilke datasett som allerede finnes for temaet, og hvorfor det ble foreslått akkurat nå.

Det siste 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.

Begge skriver til en idébank et menneske plukker fra. Ingen av dem oppretter oppgaver selv. Og de har en hard grense: de kan bare skrive i sin egen, avgrensede del av dokumentet. Alt et menneske har skrevet, er utenfor rekkevidde. Uten den grensen ville en agent som misforsto formatet, kunnet overskrive tenkearbeid ingen hadde sikkerhetskopi av.