Hva du vil lære

Denne guiden dekker harness engineering fra grunnleggende prinsipper til praktisk implementering. Du vil forstå hva det er, hvorfor OpenAI satset sitt største interne prosjekt på det, de spesifikke arkitektoniske mønstrene som får det til å fungere, og hvordan du kan bruke disse prinsippene i dine egne arbeidsflyter for AI-agenter — enten du bruker Codex, Claude Code, OpenCode eller et hvilket som helst annet agentsystem.

Harness Engineering: Den komplette guiden for utvikling av AI-agenter i 2026

Hvis 2025 var året AI-agenter beviste at de kunne skrive kode, er 2026 året vi lærte at agenten ikke er den vanskelige delen — det er harness (seletøyet) som er det.

OpenAI sitt Codex-team publiserte et landemerke av et blogginnlegg i februar 2026 som beskrev hvordan de bygde en produksjonsapplikasjon som inneholdt omtrent en million linjer med kode, der null linjer ble skrevet av menneskehender. Hemmeligheten var ikke en bedre modell eller en smartere prompt. Det var systemet de bygde rundt agenten — selve harness-en. Kilde

Denne guiden bryter ned hvert prinsipp, mønster og praktiske teknikk fra det eksperimentet og den bredere harness engineering-bevegelsen som har vokst frem rundt det.

Del 1: Hva er Harness Engineering?

Definisjonen

Harness engineering er disiplinen med å designe hele miljøet — stillas (scaffolding), tilbakemeldingssløyfer, dokumentasjon, arkitektoniske begrensninger og maskinlesbare artefakter — som lar AI-kodeagenter utføre pålitelig arbeid av høy kvalitet i stor skala med minimal menneskelig inngripen.

Begrepet "harness" kommer fra seletøy til hest: tøyler, sal, bitt — det komplette settet med utstyr for å styre et kraftfullt, men uforutsigbart dyr i riktig retning. En ukontrollert hest er farlig. En hest i seletøy bygget sivilisasjoner. Det samme gjelder AI-agenter. Kilde

Hvorfor det oppstod nå

Skiftet fra prompt engineering til harness engineering gjenspeiler en modning av AI-utviklingslandskapet:

Kilde

Den viktigste innsikten som drev denne overgangen: agentene ble kapable nok til at flaskehalsen flyttet seg fra modellkvalitet til miljøkvalitet. En toppmoderne modell som opererer i et dårlig strukturert repository produserer dårligere resultater enn en middelmådig modell som opererer i et godt tilrettelagt harness-miljø.

Del 2: OpenAI Codex-eksperimentet

Skalaen

I et fem måneder langt internt eksperiment bygde og lanserte OpenAI-ingeniører et betaprodukt som inneholdt omtrent en million linjer med kode. Repository-et spenner over applikasjonslogikk, infrastruktur, verktøy, dokumentasjon og interne utviklerverktøy. Det fantes ingen eksisterende menneskeskrevet kode å forankre systemet i. Kilde

Teamet

Prosjektet startet med bare tre ingeniører som drev Codex. Over femmånedersperioden ble omtrent 1,500 pull requests åpnet og merget. Etter hvert som teamet vokste til syv ingeniører, økte gjennomstrømmingen — et kontraintuitivt resultat som antydet at selve harness-en var den primære produktivitetsmultiplikatoren, ikke individuelle ferdigheter.

OpenAI estimerer at de bygde systemet på omtrent en tiendedel av tiden det ville tatt å skrive koden for hånd. Kilde

Det første stillaset

Prosjektet begynte med at Codex CLI genererte det første stillaset (scaffold) ved hjelp av GPT-5, veiledet av et lite sett med eksisterende maler:

• Repository-struktur og konvensjoner for mapper
• CI/CD-konfigurasjon
• Regler for kodeformatering og linting
• Oppsett av pakkebehandler
• Boilerplate for applikasjonsrammeverk

Fra dette frøet vokste alt annet gjennom agent-drevet utvikling.

Fredagsproblemet

Tidlig i eksperimentet oppdaget teamet et kritisk problem: de brukte hver fredag — 20% av ingeniørtiden sin — på å rydde opp i det de kalte "AI-slop" (AI-slurv). Dette inkluderte inkonsekvente mønstre, duplisert logikk, feilnavnede variabler og arkitektonisk avvik.

Dette kunne ikke skaleres. Løsningen var å kode standardene deres inn i selve harness-en slik at agentene ville produsere renere resultater fra starten av, og å bygge automatiserte opprydningssystemer for det gjenværende avviket.

Del 3: De fem kjerneprinsippene

Prinsipp 1: Repository-først-kunnskap

Fra agentens perspektiv eksisterer ingenting som den ikke har tilgang til i sin kontekst mens den kjører. Kunnskap som lever i Google Docs, chat-tråder, Slack-meldinger eller i folks hoder, er usynlig for systemet.

Dette betyr at all kunnskap må leve som repository-lokale, versjonerte artefakter:

• Kode — det primære artefaktet
• Markdown-dokumentasjon — arkitekturbeslutninger, konvensjoner, onboarding-guider
• Schemas — API-kontrakter, databaseskjemaer, typedefinisjoner
• Utførbare planer — steg-for-steg oppgavebeskrivelser agenten kan følge
• Konfigurasjon — linter-regler, CI-pipelines, formateringsstandarder

Teamet lærte at de trengte å dytte mer og mer kontekst inn i repo-et over tid. Hver gang en agent gjorde en feil fordi den manglet kontekst, var løsningen ikke en bedre prompt — det var å legge den konteksten til i repository-et. Kilde

Praktisk implementering:

# ARCHITECTURE.md (lives in repo root)

## Dependency Rules
- UI components may import from Service layer but never from Repo layer
- Service layer may not import from Runtime layer
- All cross-domain communication goes through typed event bus

## Naming Conventions
- React components: PascalCase, suffixed with purpose (UserListPage, UserCard)
- Services: camelCase, suffixed with Service (userService, authService)
- Types: PascalCase, prefixed with domain (UserProfile, OrderItem)

## Testing Requirements
- All Service functions require unit tests
- All API endpoints require integration tests
- Coverage threshold: 80% per package

Prinsipp 2: Gylne prinsipper

Gylne prinsipper er meningstunge, mekaniske regler kodet direkte inn i repository-et som holder kodebasen lesbar og konsekvent for fremtidige agent-kjøringer. De er ikke aspirerende retningslinjer — de er håndhevede begrensninger.

Eksempler fra OpenAI-eksperimentet:

1. Foretrekk delte utility-pakker fremfor egenproduserte hjelpere — sentraliserer invarianter slik at når oppførsel må endres, endres den på ett sted
2. Ikke utforsk data YOLO-stil — valider grenser eller stol på typede SDK-er slik at agenter ikke ved et uhell bygger på gjettede dataformer
3. Ett konsept, én fil — hver fil skal representere et enkelt konsept, noe som gjør det lettere for agenter å finne og endre riktig sted
4. Eksplisitt over implisitt — unngå "magisk" oppførsel som en agent ville trenge intern kunnskap for å forstå

Kilde

Disse prinsippene er ikke bare dokumentasjon. De håndheves av:

• Linter-regler — tilpassede lintere (som i seg selv er generert av Codex) som flagger brudd
• Strukturelle tester — tester som validerer arkitektonisk samsvar
• CI-porter (gates) — pull requests som bryter med gylne prinsipper blir automatisk avvist

Prinsipp 3: Lagdelt arkitektur med mekanisk håndheving

Hvert forretningsdomene i OpenAI-prosjektet er delt inn i et fast sett med lag med strengt validerte avhengighetsretninger:

Types → Config → Repo → Service → Runtime → UI

Avhengigheter flyter kun i én retning. En UI-komponent kan avhenge av Runtime og Service, men en Service kan aldri importere fra UI. En Repo kan avhenge av Config og Types, men aldri av Service. Kilde

Disse begrensningene håndheves mekanisk:

// structural-test.ts — enforces dependency boundaries
import { analyzeImports } from './tools/import-analyzer';

describe('Dependency Layer Enforcement', () => {
  it('Service layer must not import from Runtime', () => {
    const violations = analyzeImports({
      sourceLayer: 'service',
      forbiddenLayers: ['runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });

  it('Repo layer must not import from Service', () => {
    const violations = analyzeImports({
      sourceLayer: 'repo',
      forbiddenLayers: ['service', 'runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });
});

De strukturelle testene validerer samsvar og forhindrer brudd på modulær lagdeling. Dette er ikke et forslag — det håndheves av CI. Hver pull request, enten den er opprettet av et menneske eller en agent, må bestå disse testene.

Prinsipp 4: Automatisert søppeltømming (Garbage Collection)

Selv med gylne prinsipper og strukturell håndheving, vil agent-generert kode avvike over tid. OpenAI-teamet løste dette ved å implementere automatisert søppeltømming — tilbakevendende bakgrunnsoppgaver som:

1. Skanner etter avvik fra gylne prinsipper over hele kodebasen
2. Oppdaterer kvalitetskarakterer for hver modul basert på samsvarspoeng
3. Åpner målrettede refaktorerings-pull requests som fikser spesifikke kategorier av avvik

Dette erstattet den manuelle "fredagsoppryddingen" med et system som kjører kontinuerlig. Selve søppeltømmeren drives av Codex-agenter, noe som skaper en selvvedlikeholdende sløyfe. Kilde

# .github/workflows/garbage-collection.yml
name: Codebase Garbage Collection
on:
  schedule:
    - cron: '0 2 * * *'  # Run nightly at 2 AM

jobs:
  gc-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run golden principle scanner
        run: npx codex-gc scan --principles ./GOLDEN_PRINCIPLES.md
      - name: Generate refactoring PRs
        run: npx codex-gc fix --auto-pr --max-prs 5

Prinsipp 5: Utførbare planer

Før agenter skriver kode, skriver de planer. Disse planene er ikke uformelle notater — de er strukturerte, utførbare dokumenter som spesifiserer:

• Mål (Objective): Hva oppgaven oppnår
• Filer som skal endres: Eksplisitt liste over filer agenten vil røre
• Avhengigheter: Andre oppgaver eller moduler dette arbeidet avhenger av
• Akseptansekriterier: Hvordan verifisere at arbeidet er fullført
• Begrensninger: Arkitektoniske regler som ikke må brytes

# Plan: Add user notification preferences

## Objective
Allow users to configure which notification channels (email, SMS, push) they
receive alerts on, with per-category granularity.

## Files to Modify
- src/types/user.ts — Add NotificationPreferences type
- src/repo/userRepo.ts — Add getPreferences/setPreferences methods
- src/service/notificationService.ts — Filter notifications by preferences
- src/ui/pages/SettingsPage.tsx — Add preferences UI section

## Constraints
- Must follow Types → Repo → Service → UI dependency flow
- NotificationPreferences type must be shared, not duplicated
- All new methods require unit tests

## Acceptance Criteria
- [ ] User can toggle email/SMS/push per notification category
- [ ] Preferences persist across sessions
- [ ] Toggling a channel off stops notifications on that channel within 30s

Planer lever i repository-et som markdown-filer, er versjonskontrollerte og kan gjennomgås før utførelse — noe som gir mennesker et kontrollpunkt mellom intensjon og implementering.

Del 4: Codex-agentens løkke

Å forstå hvordan Codex-agentens løkke opererer innenfor en harness er avgjørende for effektiv harness engineering.

Løkkearkitekturen

OpenAI publiserte en detaljert gjennomgang av Codex-agentens løkke i sitt tilhørende blogginnlegg "Unrolling the Codex agent loop." Kilde Løkken følger denne syklusen:

Les kontekst → Planlegg → Utfør → Valider → Commit (eller prøv på nytt)

Hver iterasjon:

1. Les kontekst: Agenten leser relevante filer, dokumentasjon, skjemaer og oppgaveplanen fra repository-et
2. Planlegg: Basert på konteksten bestemmer agenten hvilke endringer som skal gjøres
3. Utfør: Agenten skriver eller endrer kode
4. Valider: Harness-en kjører tester, lintere og strukturelle sjekker mot endringene
5. Commit eller prøv på nytt: Hvis valideringen godkjennes, committer agenten. Hvis den feiler, leser agenten feilmeldingen og prøver på nytt.

Harness-ens rolle er å gjøre trinn 1 og 4 så informasjonsrike som mulig. Jo mer kontekst agenten leser, desto bedre blir planen. Jo mer spesifikk valideringstilbakemeldingen er, desto raskere konvergerer den mot en fungerende løsning.

App Server-harness-en

I innlegget "Unlocking the Codex harness: how we built the App Server," beskriver OpenAI den konkrete infrastrukturen som driver agentløkken. Kilde App Server tilbyr:

• Sandkasse-miljøer for utførelse for hver agentoppgave
• Forhåndskonfigurert verktøytilgang (filsystem, terminal, nettleser)
• Automatisk kontekst-injeksjon fra repository-artefakter
• Streaming av valideringstilbakemeldinger slik at agenter kan se testfeil i sanntid

Del 5: Bruk av Harness Engineering i ditt team

Slik kommer du i gang: En Minimum Viable Harness

Du trenger ikke å kopiere OpenAI sin komplette infrastruktur for å dra nytte av harness engineering. Start med disse grunnleggende elementene:

Trinn 1: Opprett en ARCHITECTURE.md

Dokumenter prosjektets arkitektoniske regler i et maskinlesbart format i roten av repository-et ditt. Inkluder:

• Modulgrenser og tillatte avhengigheter
• Navnekonvensjoner
• Regler for filorganisering
• Testkrav

Denne ene filen forbedrer kvaliteten på agentens utdata dramatisk fordi agenter leser den før de gjør endringer.

Trinn 2: Legg til strukturelle tester

Skriv tester som validerer de arkitektoniske reglene dine. Disse testene sjekker ikke forretningslogikk — de sjekker at koden er organisert riktig:

// No service file should import from a UI module
test('service layer isolation', () => {
  const serviceFiles = glob('src/services/**/*.ts');
  for (const file of serviceFiles) {
    const imports = extractImports(file);
    const uiImports = imports.filter(i => i.startsWith('../ui/'));
    expect(uiImports).toHaveLength(0);
  }
});

Trinn 3: Konfigurer CI-validering

Sørg for at CI-pipelinen din kjører strukturelle tester, lintere og typesjekker på hver pull request — inkludert de som er opprettet av agenter. Agenten bør se de samme valideringsresultatene som en menneskelig utvikler ville sett.

Trinn 4: Skriv oppgaveplaner før agentutførelse

Før du ber en agent implementere en funksjon, skriv et strukturert plandokument som spesifiserer filene som skal endres, begrensninger som skal følges og akseptansekriterier. Lagre disse planene i repository-et ditt.

Trinn 5: Sett opp automatisert opprydding

Implementer en ukentlig eller nattlig CI-jobb som skanner kodebasen din for avvik fra de dokumenterte standardene dine og oppretter fokuserte refaktorerings-PR-er.

Valg av agentsystem

Prinsippene for harness engineering gjelder uavhengig av hvilken agent du bruker:

Harness-en lever i ditt repository, ikke i agenten din. Dette betyr at du kan bytte agenter uten å miste investeringen i harness-en.

Skalering fra én agent til mange

OpenAI-eksperimentet viste at harness engineering muliggjør parallell utførelse av agenter. Fordi harness-en håndhever arkitektoniske grenser, kan flere agenter jobbe på forskjellige deler av kodebasen samtidig uten å skape konflikter.

Sentrale krav for parallell agentutførelse:

1. Tydelig moduleierskap — hver agent jobber innenfor en definert grense
2. Typede grensesnitt mellom moduler — agenter kan kode mot grensesnitt uten å kjenne til implementasjonsdetaljer
3. Forebygging av merge-konflikter — oppgaver er avgrenset for å minimere filoverlapping
4. Sentralisert validering — alle agenter sender inn til samme CI-pipeline

Del 6: Vanlige fallgruver og antimønstre

Antimønster 1: Behandle agenten som selve harness-en

Agenten er ikke harness-en. Harness-en er miljøet agenten opererer i. Å be en smartere modell om å kompensere for et dårlig strukturert repository er feil tilnærming. Fiks miljøet, ikke prompten.

Antimønster 2: Dokumentasjon på feil sted

Hvis arkitekturbeslutningene dine lever i Confluence, Notion eller Google Docs, kan ikke agentene se dem. Løsningen er enkel, men krever disiplin: flytt all utviklingsrelevant dokumentasjon inn i repository-et.

Antimønster 3: Manuell opprydding i stedet for automatisert håndheving

Hvis du bruker betydelig tid på å rydde opp i agent-generert kode, trenger du bedre håndheving, ikke flere opprydningsøkter. Hver tilbakevendende opprydningsoppgave bør enten bli en linter-regel, en strukturell test eller en automatisert refaktoreringsjobb.

Antimønster 4: For mange begrensninger

En harness som er for rigid, hindrer agenter i å finne kreative løsninger. Målet er å begrense arkitekturen, ikke implementeringen. Fortell agentene hvilke moduler de kan endre og hvilke avhengigheter som er tillatte, men la dem bestemme hvordan logikken skal implementeres innenfor disse grensene.

Antimønster 5: Ignorere tilbakemeldinger fra agenten

Når en agent gjentatte ganger feiler på visse oppgaver, indikerer feilen vanligvis et gap i harness-en, ikke en begrensning hos agenten. Spor feilmønstre og bruk dem til å forbedre dokumentasjonen, de strukturelle testene eller de arkitektoniske begrensningene dine.

Del 7: Fremtiden for Harness Engineering

Martin Fowlers perspektiv

Martin Fowler publiserte en analyse av harness engineering på bloggen sin, og bemerket at det representerer et fundamentalt skifte i hvordan programvareteam opererer. Disiplinen låner fra tiår med beste praksis innen software engineering — continuous integration, architecture decision records, dependency injection — men gjenbruker dem for en agent-drevet verden. Kilde

HumanLayer-rammeverket

Teamet hos HumanLayer publiserte sin analyse der de kaller harness engineering et "skill issue" (ferdighetsproblem) — og argumenterer for at evnen til å designe effektive harnesses vil bli den primære differensiatoren mellom høytpresterende og strevende ingeniørteam. Kilde

Hva dette betyr for utviklere

Harness engineering erstatter ikke utviklerferdigheter — det omdirigerer dem. I stedet for å skrive kode, designer senioringeniører systemene som gjør det mulig for agenter å skrive god kode. Ferdighetene som betyr noe skifter fra implementering til arkitektur, fra koding til systemdesign, fra å skrive tester til å designe testrammeverk.

For team som bygger applikasjoner, er plattformer som ZBuild allerede i ferd med å inkorporere prinsipper for harness engineering i sine arbeidsflyter for app-bygging. I stedet for å kreve at utviklere designer sine egne harnesses fra bunnen av, tilbyr ZBuild forhåndskonfigurerte arkitektoniske mønstre, avhengighetshåndtering og valideringssystemer som leder AI-agenter mot resultater av høy kvalitet — slik at utviklere kan fokusere på produktbeslutninger i stedet for infrastruktur.

De tre horisontene

Når vi ser fremover, vil harness engineering sannsynligvis utvikle seg gjennom tre faser:

1. Kort sikt (2026): Team tar i bruk repository-først-dokumentasjon, strukturelle tester og gylne prinsipper. Agent-assistert utvikling blir standard praksis for godt tilrettelagte prosjekter.

2. Mellomlang sikt (2027): Selve harness-genereringen blir agent-drevet. Agenter analyserer eksisterende kodebaser og foreslår harness-konfigurasjoner — linter-regler, strukturelle tester, avhengighetsgrenser — basert på mønstrene de observerer.

3. Lang sikt (2028+): Harnesses blir adaptive. I stedet for statiske regler, utvikler de seg basert på resultatene av agent-generert kode, og strammer automatisk inn begrensninger i områder der agenter ofte gjør feil, og løsner opp der de konsekvent lykkes.

Del 8: Praktisk sjekkliste

Bruk denne sjekklisten for å evaluere teamets modenhet innen harness engineering:

Grunnmur (Start her)

• ARCHITECTURE.md eksisterer i roten av repository-et
• Kodeformatering er automatisert (Prettier, Black, gofmt)
• Linting kjører på hver pull request
• Typesjekking er påkrevd (TypeScript strict, mypy, osv.)

Viderekommen

• Strukturelle tester validerer avhengighetsgrenser
• Gylne prinsipper er dokumentert og maskinhåndhevbare
• Oppgaveplaner skrives før agentutførelse
• Agent-genererte PR-er går gjennom samme CI som menneskelige PR-er

Avansert

• Automatisert søppeltømming kjører etter planen
• Flere agenter kan jobbe parallelt uten konflikter
• Agentfeilmønstre spores og brukes til å forbedre harness-en
• Selve harness-en er versjonskontrollert og gjennomgås som kode

Ekspert

• Agenter genererer deler av harness-en (linter-regler, strukturelle tester)
• Kvalitetskarakterer tildeles automatisk til hver modul
• Forbedringer av harness-en er datadrevne basert på agentens suksessrate
• Teamet leverer mer kode per ingeniør per uke enn før de tok i bruk agenter

Konklusjon

Harness engineering er ikke en døgnflue. Det er den naturlige utviklingen av programvareutvikling i en tid der AI-agenter er kapable nok til å skrive produksjonskode, men trenger strukturerte miljøer for å gjøre det bra. OpenAI sitt million-linjers eksperiment beviste konseptet i stor skala, og prinsippene de formulerte — repository-først-kunnskap, gylne prinsipper, lagdelt arkitektur, automatisert søppeltømming og utførbare planer — er anvendelige for team av alle størrelser.

Teamene som mestrer harness engineering i 2026 vil levere raskere, opprettholde høyere kodekvalitet og skalere mer effektivt enn de som behandler AI-agenter som en glorifisert autocomplete. Agenten er hesten. Harness-en er det som gjør den nyttig.

Kilder

• Harness Engineering: Leveraging Codex in an Agent-First World — OpenAI
• Unlocking the Codex Harness: How We Built the App Server — OpenAI
• Unrolling the Codex Agent Loop — OpenAI
• OpenAI Introduces Harness Engineering — InfoQ
• Harness Engineering — Martin Fowler
• Skill Issue: Harness Engineering for Coding Agents — HumanLayer
• From Prompt Engineering to Harness Engineering — SoftmaxData
• How to Build an Agent Harness — Study Notes
• Harness Engineering — GTCode
• OpenAI Harness Engineering: Ship 1M Lines of Code — The Neuron
• How OpenAI Built 1M Lines of Code Using Only Agents — TonyLee
• Harness Engineering — The New Discipline — CodeNote