Harness Engineering: Byg systemer omkring AI-agenter (2026)

TL;DR

Hvad er Harness Engineering?

Harness engineering er disciplinen i at bygge systemer, værktøjer, begrænsninger og feedback-loops omkring AI-kodningsagenter for at gøre dem pålidelige og produktive.

Udtrykket blev opfundet af Mitchell Hashimoto (medstifter af HashiCorp) og fik bred opmærksomhed, da OpenAI publicerede deres Codex-artikel om emnet i starten af 2026.

Kerneidéen er enkel:

Agent = Model + Harness

Modellen leverer intelligens. Harness gør denne intelligens nyttig. En bedre harness betyder ofte mere end en bedre model.

Hvorfor det er vigtigt nu

I 2025 adopterede alle teams AI-kodningsagenter. I 2026 er vinderholdene dem, der engineerede deres agent-miljøer — og ikke blot valgte den bedste model.

Mitchell Hashimotos ledende princip:

"Hver gang du oplever, at en agent laver en fejl, bruger du tid på at designe en løsning, så agenten aldrig laver den fejl igen."

Dette er ikke prompt engineering. Det er systems engineering til AI.

Beviset: Harness > Model

LangChain udførte et kontrolleret eksperiment på Terminal Bench 2.0. Uden at ændre den underliggende model forbedrede de deres kodningsagents nøjagtighed fra 52,8 % til 66,5 % — en forbedring på 26 % — udelukkende ved at forbedre deres harness.

Ændringerne inkluderede:

• Bedre kontekst-filer (AGENTS.md)


• Strukturerede output-begrænsninger


• Selvverifikations-loops


• Værktøjsoptimering

De 7 komponenter i en Harness

1. Context Engineering

Kontekst-engineering er fundamentet. Det er her, du giver agenten et kort over dit codebase, dine konventioner og dine begrænsninger.

• CLAUDE.md / AGENTS.md filer i din repo-root
• Oversigtskort over mapper og arkitektur
• Regler for kodestil og navngivningskonventioner

# CLAUDE.md example
## 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 begrænsninger

I stedet for at håbe på, at agenten vælger den rigtige arkitektur, så gennemtving den.

• Stive lagdelte arkitekturer valideret af linters
• Strukturelle tests, der fejler, hvis mønstre brydes
• Import-restriktioner via ESLint-regler eller brugerdefinerede scripts

3. Værktøjer & MCP-servere

Agenter har brug for værktøjer for at være effektive. De bedste harnesses eksponerer interne værktøjer via:

• CLI-wrappers — foretræk velkendte CLI'er (git, docker, npm) frem for specialbyggede værktøjer
• MCP (Model Context Protocol) servere — lad agenter kalde dine interne API'er, databaser og tjenester
• Filsystem-adgang — afgrænset til specifikke mapper for at forhindre utilsigtede skader

4. Underagenter & kontekst-firewalls

Langvarige agent-sessioner ophober kontekst, som til sidst forringer ydeevnen — dette kaldes context rot.

Løsningen: Underagenter med kontekst-firewalls.

• Opdel komplekse opgaver i diskrete underopgaver
• Hver underopgave kører i sin egen session med en frisk kontekst
• Overfør kun strukturerede resultater mellem agenter, ikke den rå samtale

1. Initializer Agent — planlægger arbejdet, opretter en funktionsliste
2. Coding Agent — udfører hver funktion i isolation

5. Hooks & Back-Pressure

Automatiserede feedback-loops, der fanger fejl, før de hober sig op:

• Pre-commit hooks — type-checking, linting, formatering
• Test-runners — agenter bør køre tests efter hver ændring
• Build-verifikation — fejl hurtigt ved ødelagte builds

6. Selvverifikations-loops

Tving agenter til at verificere deres eget arbejde, før de markerer opgaver som færdige:

• Kør test-suiten efter ændringer
• Tjek at buildet går igennem
• Verificer at outputtet matcher specifikationen
• Tag et screenshot og sammenlign (ved UI-arbejde)

7. Dokumentation af fremskridt

Ved langvarige opgaver (30+ minutter):

• Vedligehold en fremskridtsfil, der sporer gennemførte trin
• Commit arbejde ofte, så efterfølgende sessioner kan fortsætte
• Brug strukturerede opgavelister, ikke fritformede noter

Resultater fra den virkelige verden

OpenAI Codex Team

3 ingeniører producerede en million-linjers codebase uden manuelt skrevet kode over 5 måneder. De snittede 3,5 mergede PR'er pr. ingeniør pr. dag — et gennemløb, der er umuligt uden en moden harness.

Deres harness inkluderede: Strikte commit-konventioner, automatiseret testning på hver PR og agent-bevidste CI/CD-pipelines.

Stripe's "Minions"

Stripe's interne system producerer 1.000+ mergede PR'er pr. uge ved hjælp af AI-agenter. Deres harness inkluderer:

• Stramt definerede opgaveafgrænsninger
• Obligatorisk code review af mennesker
• Automatiseret regressionstestning
• Rollback-automatisering

Anthropic's to-agent arkitektur

Anthropic publicerede deres tilgang til effektive harnesses for langvarige agenter:

• Strukturerede funktionslister som format til overdragelse mellem agenter
• Git-baseret fremskridtssporing, så agenter kan genoptage efter afbrydelser
• Eksplicitte exit-kriterier, så agenter ved, hvornår de skal stoppe

Sådan begynder du at bygge din Harness

Trin 1: Opret din kontekst-fil

Tilføj en CLAUDE.md (eller AGENTS.md) til din projekt-rod:

# Project: [Your Project]

## Stack
[Framework, language, database, hosting]

## Architecture
[Directory structure with one-line descriptions]

## Rules
[5-10 hard rules the agent must follow]

## Common Tasks
[How to run tests, build, deploy]

Trin 2: Tilføj arkitektoniske begrænsninger

# Example: ESLint rule preventing direct DB imports in components
# .eslintrc — no-restricted-imports rule

Opsæt pre-commit hooks, der håndhæver dine regler automatisk.

Trin 3: Byg verifikations-loops

Sørg for, at din agent kan:

1. Køre tests (npm test, pytest, osv.)


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


3. Linte (eslint ., ruff check)

Trin 4: Afgræns agent-sessioner

Giv ikke en agent hele din backlog. I stedet:

• Én funktion pr. session
• Én fejlrettelse pr. session
• Klare acceptkriterier for hver opgave

Trin 5: Iterer på din harness

Hver gang en agent laver en fejl:

1. Identificer rodårsagen
2. Tilføj en regel, begrænsning eller hook, der forhindrer det
3. Test rettelsen

Harness Engineering vs. Prompt Engineering

Prompt engineering er stadig nyttigt, men det er kun en lille del af billedet. Harness engineering er multiplikatoren.

Den nye rolle: Harness Engineer

Ingeniørarbejde splittes i to halvdele:

1. Miljøbygning — skabelse af struktur, værktøjer, begrænsninger og feedback-loops
2. Arbejdsstyring — planlægning, review og orkestrering af parallelle agent-sessioner

Må ikke forveksles med: Harness.io

Hvis du søgte på "Harness Engineering" efter DevOps-platformen — så er Harness.io noget helt andet. Det er en AI-drevet CI/CD-platform værdisat til 5,5 mia. USD (pr. december 2025), der tilbyder kontinuerlig integration, levering, feature flags, styring af cloud-omkostninger og sikkerhedstestning.

Selvom Harness.io og harness engineering deler navn, løser de forskellige problemer. Dog er der et interessant overlap: Harness.io's AI-drevne DevOps er velsagtens en anvendelse af harness engineering-principper på deployment-pipelinen.

Konklusion

Modellen er motoren. Harness er bilen. Ingen vinder et løb med kun en motor.

Hvis du bruger AI-kodningsagenter i 2026 og ikke investerer i din harness, går du glip af størstedelen af værdien. Start med en kontekst-fil, tilføj begrænsninger, byg verifikations-loops og iterer hver gang noget går i stykker.

De teams, der leverer hurtigst, bruger ikke bedre modeller. De bruger bedre harnesses.