Harness Engineering: Bygg systemer rundt AI-agenter (2026)

TL;DR

Hva er Harness Engineering?

Harness engineering er disiplinen med å bygge systemer, verktøy, begrensninger og tilbakemeldingsløkker rundt AI-kodeagenter for å gjøre dem pålitelige og produktive.

Begrepet ble skapt av Mitchell Hashimoto (medgrunnlegger av HashiCorp) og fikk stor oppmerksomhet da OpenAI publiserte sin Codex-artikkel om emnet tidlig i 2026.

Kjerneideen er enkel:

Agent = Modell + Harness

Modellen gir intelligens. Harnessen gjør denne intelligensen nyttig. En bedre harness betyr ofte mer enn en bedre modell.

Hvorfor det betyr noe nå

I 2025 tok alle team i bruk AI-kodeagenter. I 2026 er vinnerteamene de som har utviklet agent-miljøene sine — ikke bare de som valgte den beste modellen.

Mitchell Hashimotos ledende prinsipp:

"Hver gang du oppdager at en agent gjør en feil, tar du deg tid til å utvikle en løsning slik at agenten aldri gjør den feilen igjen."

Dette er ikke prompt engineering. Det er systemutvikling for AI.

Beviset: Harness > Modell

LangChain kjørte et kontrollert eksperiment på Terminal Bench 2.0. Uten å endre den underliggende modellen, forbedret de kodeagentens nøyaktighet fra 52,8 % til 66,5 % — en forbedring på 26 % — kun ved å forbedre harnessen.

Endringene inkluderte:

• Bedre kontekstfiler (AGENTS.md)


• Strukturerte begrensninger for output


• Selv-verifiseringsløkker


• Verktøyoptimalisering

De 7 komponentene i en Harness

1. Kontekstutvikling (Context Engineering)

Kontekstutvikling er fundamentet. Dette er her du gir agenten et kart over kildekoden, konvensjonene dine og begrensningene dine.

• CLAUDE.md / AGENTS.md-filer i roten av repoet
• Katalogkart og arkitektoversikter
• Regler for kodestil og navngivingskonvensjoner

# CLAUDE.md eksempel
## Architecture
- src/app/ — Next.js app router pages
- src/lib/ — shared utilities and API clients
- src/components/ — React components (co-located styles)

## Rules
- Use server components by default
- Never import from node_modules directly in components
- All API calls go through src/lib/api.ts

2. Arkitektoniske begrensninger

I stedet for å håpe at agenten velger riktig arkitektur, bør du tvinge den fram.

• Strenge lagdelte arkitekturer validert av lintere
• Strukturelle tester som feiler hvis mønstre brytes
• Importrestriksjoner via ESLint-regler eller egne skript

3. Verktøy & MCP-servere

Agenter trenger verktøy for å være effektive. De beste harnessene eksponerer interne verktøy via:

• CLI-wrappere — foretrekk kjente CLI-er (git, docker, npm) fremfor spesiallagde verktøy
• MCP (Model Context Protocol)-servere — la agenter kalle dine interne API-er, databaser og tjenester
• Filsystemtilgang — avgrenset til spesifikke kataloger for å forhindre utilsiktet skade

4. Under-agenter & kontekst-brannmurer

Langvarige agent-økter akkumulerer kontekst som til slutt svekker ytelsen — dette kalles kontekstforfall (context rot).

Løsningen: Under-agenter med kontekst-brannmurer.

• Del komplekse oppgaver inn i diskrete deloppgaver
• Hver deloppgave kjører i sin egen økt med en frisk kontekst
• Send kun strukturerte resultater mellom agenter, ikke hele samtalen

1. Initializer Agent — planlegger arbeidet, lager en funksjonsliste
2. Coding Agent — utfører hver funksjon i isolasjon

5. Hooks & Back-Pressure

Automatiserte tilbakemeldingsløkker som fanger opp feil før de eskalerer:

• Pre-commit hooks — typesjekking, linting, formatering
• Test-kjørere — agenter bør kjøre tester etter hver endring
• Byggeverifisering — feil raskt ved ødelagte bygg (builds)

6. Selv-verifiseringsløkker

Tving agenter til å verifisere sitt eget arbeid før de markerer oppgaver som fullførte:

• Kjør testsuiten etter endringer
• Sjekk at bygget passerer
• Verifiser at output samsvarer med spesifikasjonen
• Ta et skjermbilde og sammenlign (for UI-arbeid)

7. Dokumentasjon av fremdrift

For langvarige oppgaver (30+ minutter):

• Vedlikehold en fremdriftsfil som sporer fullførte steg
• Commit arbeid ofte slik at påfølgende økter kan fortsette
• Bruk strukturerte oppgavelister, ikke friforms-notater

Reelle resultater

OpenAI Codex-teamet

3 utviklere produserte en kodebase på en million linjer med null manuelt skrevet kode over 5 måneder. De snittet på 3,5 mergede PR-er per utvikler per dag — en gjennomstrømming som er umulig uten en moden harness.

Harnessen deres inkluderte: strenge commit-konvensjoner, automatisert testing på hver PR, og agent-bevisste CI/CD-pipelines.

Stripes "Minions"

Stripes interne system produserer over 1 000 mergede PR-er per uke ved hjelp av AI-agenter. Harnessen deres inkluderer:

• Tydelig avgrensede oppgavedefinisjoner
• Obligatorisk kodegjennomgang av mennesker
• Automatisert regresjonstesting
• Automatisering av rollback

Anthropics to-agent-arkitektur

Anthropic publiserte sin tilnærming til effektive harnesser for langvarige agenter:

• Strukturerte funksjonslister som format for overlevering mellom agenter
• Git-basert fremdriftssporing slik at agenter kan gjenoppta etter avbrudd
• Eksplisitte utgangskriterier slik at agenter vet når de skal stoppe

Hvordan begynne å bygge din Harness

Steg 1: Opprett din kontekstfil

Legg til en CLAUDE.md (eller AGENTS.md) i prosjektroten din:

# Project: [Ditt prosjekt]

## Stack
[Rammeverk, språk, database, hosting]

## Architecture
[Katalogstruktur med korte beskrivelser]

## Rules
[5-10 ufravikelige regler agenten må følge]

## Common Tasks
[Hvordan kjøre tester, bygge, deploye]

Steg 2: Legg til strukturelle begrensninger

# Eksempel: ESLint-regel som forhindrer direkte DB-importer i komponenter
# .eslintrc — no-restricted-imports rule

Sett opp pre-commit hooks som håndhever reglene dine automatisk.

Steg 3: Bygg verifiseringsløkker

Sørg for at agenten din kan:

1. Kjøre tester (npm test, pytest, osv.)


2. Sjekke typer (tsc --noEmit, mypy)


3. Linte (eslint ., ruff check)

Steg 4: Avgrens agent-økter

Ikke gi en agent hele backloggen din. I stedet:

• Én funksjon per økt
• Én feilretting per økt
• Tydelige akseptansekriterier for hver oppgave

Steg 5: Iterer på harnessen

Hver gang en agent gjør en feil:

1. Identifiser rotårsaken
2. Legg til en regel, begrensning eller hook som forhindrer det
3. Test rettelsen

Harness Engineering vs. Prompt Engineering

Prompt engineering er fortsatt nyttig, men det er en liten del av det store bildet. Harness engineering er multiplikatoren.

Den nye rollen: Harness-utvikleren

Utvikling deles nå i to:

1. Miljøbygging — skape struktur, verktøy, begrensninger og tilbakemeldingsløkker
2. Arbeidsledelse — planlegge, gjennomgå og orkestrere parallelle agent-økter

Ikke forveksles med: Harness.io

Hvis du søkte etter "Harness Engineering" på jakt etter DevOps-plattformen — Harness.io er noe helt annet. Det er en AI-drevet CI/CD-plattform verdsatt til 5,5 milliarder dollar (per desember 2025) som tilbyr kontinuerlig integrasjon, levering, feature flags, administrasjon av skykostnader og sikkerhetstesting.

Selv om Harness.io og harness engineering deler navn, løser de ulike problemer. Likevel er det en interessant overlapp: Harness.io sin AI-drevne DevOps er argumenterbart en anvendelse av harness engineering-prinsipper på deployment-pipelinen.

Konklusjon

Modellen er motoren. Harnessen er bilen. Ingen vinner et løp med bare en motor.

Hvis du bruker AI-kodeagenter i 2026 og ikke investerer i harnessen din, lar du mesteparten av verdien ligge igjen på bordet. Start med en kontekstfil, legg til begrensninger, bygg verifiseringsløkker, og iterer hver gang noe går galt.

Teamene som leverer raskest bruker ikke bedre modeller. De bruker bedre harnesser.