Hvad du vil lære

Denne guide dækker harness engineering fra de grundlæggende principper til praktisk implementering. Du vil forstå, hvad det er, hvorfor OpenAI satsede deres største interne projekt på det, de specifikke arkitektoniske mønstre, der får det til at fungere, og hvordan du anvender disse principper på dine egne AI agent-workflows — uanset om du bruger Codex, Claude Code, OpenCode eller ethvert andet agentsystem.

Harness Engineering: Den komplette guide til udvikling af AI-agenter i 2026

Hvis 2025 var året, hvor AI-agenter beviste, at de kunne skrive kode, er 2026 året, hvor vi lærte, at agenten ikke er den svære del — det er seletøjet (harness).

OpenAI's Codex-team offentliggjorde et skelsættende blogindlæg i februar 2026, der beskrev, hvordan de byggede en produktionsapplikation indeholdende cirka en million linjer kode, hvor nul linjer var skrevet af menneskehænder. Hemmeligheden var ikke en bedre model eller et smartere prompt. Det var det system, de byggede omkring agenten — seletøjet (the harness). Kilde

Denne guide gennemgår hvert princip, mønster og praktisk teknik fra det eksperiment og den bredere harness engineering-bevægelse, der er opstået omkring det.

Del 1: Hvad er Harness Engineering?

Definitionen

Harness engineering er disciplinen med at designe hele miljøet — scaffolding, feedback-loops, dokumentation, arkitektoniske begrænsninger og maskinlæsbare artefakter — der gør det muligt for AI-kodningsagenter at udføre pålideligt arbejde af høj kvalitet i stor skala med minimal menneskelig indgriben.

Udtrykket "harness" kommer fra hestens seletøj: tøjler, sadel, bid — det komplette sæt udstyr til at kanalisere et kraftfuldt, men uforudsigeligt dyr i den rigtige retning. En ukontrolleret hest er farlig. En hest i seletøj byggede civilisationer. Det samme gælder for AI-agenter. Kilde

Hvorfor det opstod nu

Skiftet fra prompt engineering til harness engineering afspejler en modning af AI-udviklingslandskabet:

Kilde

Den vigtigste indsigt, der drev denne overgang: agenter blev dygtige nok til, at flaskehalsen skiftede fra modelkvalitet til miljøkvalitet. En state-of-the-art model, der opererer i et dårligt struktureret repository, producerer dårligere resultater end en middelmådig model, der opererer i et veludstyret harness-miljø.

Del 2: OpenAI Codex-eksperimentet

Skalaen

I et fem måneder langt internt eksperiment byggede og lancerede OpenAI-ingeniører et betaprodukt indeholdende cirka en million linjer kode. Repositoriet spænder over applikationslogik, infrastruktur, værktøjer, dokumentation og interne udviklingsværktøjer. Der var ingen eksisterende menneskeskrevet kode til at forankre systemet. Kilde

Teamet

Projektet startede med kun tre ingeniører, der drev Codex. Over den fem måneder lange periode blev cirka 1.500 pull requests åbnet og merget. Da teamet voksede til syv ingeniører, steg gennemløbet — et kontraintuitivt resultat, der antydede, at selve seletøjet var den primære produktivitetsmultiplikator, ikke den individuelle dygtighed.

OpenAI anslår, at de byggede systemet på cirka en tiendedel af den tid, det ville have taget at skrive koden i hånden. Kilde

Den indledende Scaffold

Projektet begyndte med, at Codex CLI genererede den indledende scaffold ved hjælp af GPT-5, guidet af et lille sæt eksisterende skabeloner:

• Repository-struktur og mappekonventioner
• CI/CD-konfiguration
• Kodeformatering og linting-regler
• Opsætning af pakkehåndtering
• Applikationsramme-boilerplate

Fra dette frø voksede alt andet gennem agent-drevet udvikling.

Fredagsproblemet

Tidligt i eksperimentet opdagede teamet et kritisk problem: de brugte hver fredag — 20% af deres ingeniørtid — på at rydde op i det, de kaldte "AI-slop". Dette inkluderede inkonsekvente mønstre, duplikeret logik, forkert navngivne variabler og arkitektonisk drift.

Dette kunne ikke skaleres. Løsningen var at indkode deres standarder i selve seletøjet, så agenterne ville producere renere output fra starten, og at bygge automatiserede oprydningssystemer til den resterende drift.

Del 3: De fem kerneprincipper

Princip 1: Repository-først viden

Fra agentens perspektiv eksisterer alt, hvad den ikke kan få adgang til i-kontekst, mens den kører, reelt set ikke. Viden, der lever i Google Docs, chat-tråde, Slack-beskeder eller i folks hoveder, er usynlig for systemet.

Dette betyder, at al viden skal leve som repository-lokale, versionerede artefakter:

• Kode — det primære artefakt
• Markdown-dokumentation — arkitekturbeslutninger, konventioner, onboarding-guides
• Schemas — API-kontrakter, database-schemas, typedefinitioner
• Eksekverbare planer — trin-for-trin opgaveopdelinger som agenten kan følge
• Konfiguration — linter-regler, CI-pipelines, formateringsstandarder

Teamet lærte, at de over tid havde brug for at skubbe mere og mere kontekst ind i deres repo. Hver gang en agent begik en fejl, fordi den manglede kontekst, var løsningen ikke et bedre prompt — det var at tilføje den kontekst til repositoriet. 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

Princip 2: Gyldne principper

Gyldne principper er holdningsprægede, mekaniske regler, der er indkodet direkte i repositoriet, og som holder kodebasen læselig og konsistent for fremtidige agent-kørsler. De er ikke aspirerende retningslinjer — de er håndhævede begrænsninger.

Eksempler fra OpenAI-eksperimentet:

1. Foretræk delte hjælpepakker frem for hjemmelavede hjælpere — centraliserer invarianter, så når adfærd skal ændres, ændres det ét sted.
2. Undlad at undersøge data YOLO-stil — valider grænser eller stol på typede SDKs, så agenter ikke ved et uheld bygger på gættede dataformer.
3. Ét koncept, én fil — hver fil skal repræsentere et enkelt koncept, hvilket gør det lettere for agenter at finde og ændre den rigtige lokation.
4. Eksplicit over implicit — undgå magisk adfærd, som en agent ville kræve stammeviden for at forstå.

Kilde

Disse principper er ikke bare dokumentation. De håndhæves af:

• Linter-regler — brugerdefinerede lintere (selv genereret af Codex), der flager overtrædelser.
• Strukturelle tests — tests, der validerer arkitektonisk overholdelse.
• CI-gates — pull requests, der overtræder gyldne principper, afvises automatisk.

Princip 3: Lagdelt arkitektur med mekanisk håndhævelse

Hvert forretningsdomæne i OpenAI-projektet er opdelt i et fast sæt lag med strengt validerede afhængighedsretninger:

Types → Config → Repo → Service → Runtime → UI

Afhængigheder flyder kun i én retning. En UI-komponent kan afhænge af Runtime og Service, men en Service må aldrig importere fra UI. En Repo kan afhænge af Config og Types, men aldrig af Service. Kilde

Disse begrænsninger håndhæves 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 tests validerer overholdelse og forhindrer overtrædelser af modulær lagdeling. Dette er ikke et forslag — det håndhæves af CI. Enhver pull request, uanset om den er oprettet af et menneske eller en agent, skal bestå disse tests.

Princip 4: Automatiseret Garbage Collection

Selv med gyldne principper og strukturel håndhævelse, vil agent-genereret kode drifte over tid. OpenAI-teamet løste dette ved at implementere automatiseret garbage collection — tilbagevendende baggrundsopgaver, der:

1. Scanner for afvigelser fra de gyldne principper på tværs af hele kodebasen.
2. Opdaterer kvalitetskarakterer for hvert modul baseret på overholdelsesscorer.
3. Åbner målrettede refactoring pull requests, der retter specifikke kategorier af drift.

Dette erstattede den manuelle "fredagsoprydning" med et system, der kører kontinuerligt. Selve garbage collectoren er drevet af Codex-agenter, hvilket skaber et selvvedligeholdende loop. 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

Princip 5: Eksekverbare planer

Før agenter skriver kode, skriver de planer. Disse planer er ikke uformelle noter — de er strukturerede, eksekverbare dokumenter, der specificerer:

• Objektiv: Hvad opgaven opnår.
• Filer der skal ændres: Eksplicit liste over filer, agenten vil røre ved.
• Afhængigheder: Andre opgaver eller moduler, som dette arbejde afhænger af.
• Acceptkriterier: Hvordan man verificerer, at arbejdet er færdigt.
• Begrænsninger: Arkitektoniske regler, der ikke må overtrædes.

# 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 repositoriet som markdown-filer, er versionsstyrede og kan gennemgås før eksekvering — hvilket giver mennesker et kontrolpunkt mellem hensigt og implementering.

Del 4: Codex Agent-loopet

At forstå, hvordan Codex agent-loopet opererer i et harness, er essentielt for effektiv harness engineering.

Loop-arkitekturen

OpenAI offentliggjorde en detaljeret gennemgang af Codex agent-loopet i deres ledsagende blogindlæg "Unrolling the Codex agent loop." Kilde Loopet følger denne cyklus:

Read Context → Plan → Execute → Validate → Commit (or Retry)

Hver iteration:

1. Read Context: Agenten læser relevante filer, dokumentation, schemas og opgaveplanen fra repositoriet.
2. Plan: Baseret på konteksten bestemmer agenten, hvilke ændringer der skal foretages.
3. Execute: Agenten skriver eller ændrer kode.
4. Validate: Seletøjet (the harness) kører tests, lintere og strukturelle tjek mod ændringerne.
5. Commit eller Retry: Hvis valideringen godkendes, committer agenten. Hvis den fejler, læser agenten fejlmeddelelsen og prøver igen.

Seletøjets rolle er at gøre trin 1 og 4 så informationsrige som muligt. Jo mere kontekst agenten læser, jo bedre er dens plan. Jo mere specifik valideringsfeedbacken er, jo hurtigere konvergerer den mod en fungerende løsning.

App Server-seletøjet

I deres indlæg "Unlocking the Codex harness: how we built the App Server," beskriver OpenAI den konkrete infrastruktur, der driver agent-loopet. Kilde App Server tilbyder:

• Sandboxed eksekveringsmiljøer for hver agent-opgave.
• Prækonfigureret værktøjsadgang (filsystem, terminal, browser).
• Automatisk kontekst-injektion fra repository-artefakter.
• Streaming af valideringsfeedback, så agenter kan se testfejl i realtid.

Del 5: Anvendelse af Harness Engineering på dit team

Kom godt i gang: Et Minimum Viable Harness

Du behøver ikke at kopiere hele OpenAI's infrastruktur for at drage fordel af harness engineering. Start med disse grundlæggende elementer:

Trin 1: Opret en ARCHITECTURE.md

Dokumenter dit projekts arkitektoniske regler i et maskinlæsbart format i roden af dit repository. Inkluder:

• Modulgrænser og tilladte afhængigheder.
• Navngivningskonventioner.
• Regler for filorganisering.
• Testkrav.

Denne enkelte fil forbedrer agentens outputkvalitet markant, fordi agenter læser den, før de foretager ændringer.

Trin 2: Tilføj strukturelle tests

Skriv tests, der validerer dine arkitektoniske regler. Disse tests tjekker ikke forretningslogik — de tjekker, at koden er organiseret korrekt:

// 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);
  }
});

Trin 3: Konfigurer CI-validering

Sørg for, at din CI-pipeline kører strukturelle tests, lintere og typetjek på hver pull request — inklusive dem, der er oprettet af agenter. Agenten skal se det samme valideringsoutput, som en menneskelig udvikler ville se.

Trin 4: Skriv opgaveplaner før agent-eksekvering

Før du beder en agent om at implementere en funktion, skal du skrive et struktureret plandokument, der specificerer de filer, der skal ændres, begrænsninger, der skal følges, og acceptkriterier. Gem disse planer i dit repository.

Trin 5: Opsæt automatiseret oprydning

Implementer et ugentligt eller natligt CI-job, der scanner din kodebase for afvigelser fra dine dokumenterede standarder og opretter fokuserede refactoring-PRs.

Valg af dit agentsystem

Principperne for harness engineering gælder uanset hvilken agent du bruger:

Seletøjet (the harness) lever i dit repository, ikke i din agent. Det betyder, at du kan skifte agenter uden at miste din investering i seletøjet.

Skalering fra én agent til mange

OpenAI-eksperimentet viste, at harness engineering muliggør parallel agent-eksekvering. Fordi seletøjet håndhæver arkitektoniske grænser, kan flere agenter arbejde på forskellige dele af kodebasen samtidigt uden at skabe konflikter.

Nøglekrav til parallel agent-eksekvering:

1. Tydeligt modulejerskab — hver agent arbejder inden for en defineret grænse.
2. Typede grænseflader mellem moduler — agenter kan kode mod interfaces uden at kende implementeringsdetaljer.
3. Forebyggelse af merge-konflikter — opgaver afgrænses for at minimere fil-overlap.
4. Centraliseret validering — alle agenter indsender til den samme CI-pipeline.

Del 6: Almindelige faldgruber og anti-mønstre

Anti-mønster 1: At behandle agenten som seletøjet

Agenten er ikke seletøjet. Seletøjet er det miljø, agenten opererer i. At bede en smartere model om at kompensere for et dårligt struktureret repository er den forkerte tilgang. Fix miljøet, ikke promptet.

Anti-mønster 2: Dokumentation på det forkerte sted

Hvis dine arkitektoniske beslutninger lever i Confluence, Notion eller Google Docs, kan agenter ikke se dem. Løsningen er enkel, men kræver disciplin: flyt al udviklingsrelevant dokumentation ind i repositoriet.

Anti-mønster 3: Manuel oprydning i stedet for automatiseret håndhævelse

Hvis du bruger betydelig tid på at rydde op i agent-genereret kode, har du brug for bedre håndhævelse, ikke flere oprydningssessioner. Enhver tilbagevendende oprydningsopgave bør enten blive til en linter-regel, en strukturel test eller et automatiseret refactoring-job.

Anti-mønster 4: Over-begrænsning

Et seletøj, der er for stift, forhindrer agenter i at finde kreative løsninger. Målet er at begrænse arkitekturen, ikke implementeringen. Fortæl agenterne, hvilke moduler de kan ændre, og hvilke afhængigheder der er tilladt, men lad dem beslutte, hvordan de implementerer logikken inden for disse grænser.

Anti-mønster 5: Ignorering af agent-feedback

Når en agent gentagne gange fejler i visse opgaver, indikerer fejlen normalt et hul i seletøjet, ikke en begrænsning hos agenten. Spor fejlmønstre og brug dem til at forbedre din dokumentation, strukturelle tests eller arkitektoniske begrænsninger.

Del 7: Fremtiden for Harness Engineering

Martin Fowlers perspektiv

Martin Fowler offentliggjorde en analyse af harness engineering på sin blog og bemærkede, at det repræsenterer et fundamentalt skift i, hvordan softwareteams opererer. Disciplinen låner fra årtiers best practices inden for software engineering — continuous integration, arkitekturbeslutningsoptegnelser, dependency injection — men genanvender dem til en agent-drevet verden. Kilde

HumanLayer-rammeværket

Teamet hos HumanLayer offentliggjorde deres analyse, hvor de kaldte harness engineering for et "skill issue" — og argumenterede for, at evnen til at designe effektive seletøjer vil blive den primære differentiator mellem højtydende og kæmpende ingeniørteams. Kilde

Hvad dette betyder for udviklere

Harness engineering erstatter ikke udviklerfærdigheder — det omdirigerer dem. I stedet for at skrive kode, designer senioringeniører de systemer, der gør det muligt for agenter at skrive god kode. De færdigheder, der betyder noget, skifter fra implementering til arkitektur, fra kodning til systemdesign, fra at skrive tests til at designe testrammer.

For teams, der bygger applikationer, inkorporerer platforme som ZBuild allerede harness engineering-principper i deres app-builder workflows. I stedet for at kræve, at udviklere designer deres egne seletøjer helt fra bunden, leverer ZBuild prækonfigurerede arkitektoniske mønstre, afhængighedshåndtering og valideringssystemer, der guider AI-agenter mod output af høj kvalitet — hvilket lader udviklere fokusere på produktbeslutninger frem for infrastruktur.

De tre horisonter

Når vi ser fremad, vil harness engineering sandsynligvis udvikle sig gennem tre faser:

1. Nær fremtid (2026): Teams tager repository-først dokumentation, strukturelle tests og gyldne principper til sig. Agent-assisteret udvikling bliver standardpraksis for projekter med gode seletøjer.

2. Mellemlang sigt (2027): Selve genereringen af seletøjer bliver agent-drevet. Agenter analyserer eksisterende kodebaser og foreslår harness-konfigurationer — linter-regler, strukturelle tests, afhængighedsgrænser — baseret på de mønstre, de observerer.

3. Lang sigt (2028+): Seletøjer bliver adaptive. I stedet for statiske regler udvikler de sig baseret på resultaterne af agent-genereret kode, og strammer automatisk begrænsninger i områder, hvor agenter ofte producerer fejl, og løsner begrænsninger, hvor de konsekvent har succes.

Del 8: Praktisk tjekliste

Brug denne tjekliste til at evaluere dit teams modenhed inden for harness engineering:

Grundlag (Start her)

• ARCHITECTURE.md findes i repositoriets rod.
• Kodeformatering er automatiseret (Prettier, Black, gofmt).
• Linting kører på hver pull request.
• Typetjek er håndhævet (TypeScript strict, mypy, osv.).

Mellemniveau

• Strukturelle tests validerer afhængighedsgrænser.
• Gyldne principper er dokumenterede og maskinelt håndhævbare.
• Opgaveplaner skrives før agent-eksekvering.
• Agent-genererede PRs gennemgår samme CI som menneskelige PRs.

Avanceret

• Automatiseret garbage collection kører efter en tidsplan.
• Flere agenter kan arbejde parallelt uden konflikter.
• Agent-fejlmønstre spores og bruges til at forbedre seletøjet.
• Selve seletøjet er versionsstyret og gennemgås som kode.

Ekspert

• Agenter genererer dele af seletøjet (linter-regler, strukturelle tests).
• Kvalitetskarakterer tildeles automatisk til hvert modul.
• Forbedringer af seletøjet er datadrevne baseret på agentens succesrate.
• Teamet leverer mere kode per ingeniør per uge end før indførelsen af agenter.

Konklusion

Harness engineering er ikke en døgnflue. Det er den naturlige udvikling af software engineering i en æra, hvor AI-agenter er dygtige nok til at skrive produktionskode, men har brug for strukturerede miljøer for at gøre det godt. OpenAI's million-linjers eksperiment beviste konceptet i stor skala, og principperne de formulerede — repository-først viden, gyldne principper, lagdelt arkitektur, automatiseret garbage collection og eksekverbare planer — er anvendelige for teams af enhver størrelse.

De teams, der mestrer harness engineering i 2026, vil levere hurtigere, opretholde højere kodekvalitet og skalere mere effektivt end dem, der behandler AI-agenter som en glorificeret autocomplete. Agenten er hesten. Seletøjet er det, der gø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