Harness Engineering: Bygg system runt AI-agenter (2026)

TL;DR

Vad är Harness Engineering?

Harness engineering är disciplinen att bygga system, verktyg, begränsningar och feedback-loopar runt AI-kodningsagenter för att göra dem pålitliga och produktiva.

Termen myntades av Mitchell Hashimoto (medgrundare av HashiCorp) och fick stor uppmärksamhet när OpenAI publicerade sin Codex-artikel i ämnet i början av 2026.

Kärnan i idén är enkel:

Agent = Modell + Harness

Modellen står för intelligensen. En harness gör den intelligensen användbar. En bättre harness spelar ofta större roll än en bättre modell.

Varför det är viktigt nu

Under 2025 implementerade alla team AI-kodningsagenter. Under 2026 är vinnarna de team som konstruerade sina agentmiljöer — inte bara de som valde den bästa modellen.

Mitchell Hashimotos ledstjärna:

"Varje gång du upptäcker att en agent gör ett misstag, tar du dig tid att konstruera en lösning så att agenten aldrig gör det misstaget igen."

Det här är inte prompt engineering. Det är systemteknik (systems engineering) för AI.

Beviset: Harness > Modell

LangChain genomförde ett kontrollerat experiment på Terminal Bench 2.0. Utan att ändra den underliggande modellen förbättrade de sin kodningsagents noggrannhet från 52,8 % till 66,5 % — en förbättring med 26 % — enbart genom att förbättra dess harness.

Förändringarna inkluderade:

• Bättre kontextfiler (AGENTS.md)


• Strukturerade utdatabegränsningar


• Självverifieringsloopar


• Verktygsoptimering

De 7 komponenterna i en harness

1. Context Engineering

Context engineering är grunden. Det är här du ger agenten en karta över din kodbas, dina konventioner och dina begränsningar.

• CLAUDE.md / AGENTS.md-filer i din projektrot
• Katalogkartor och arkitekturöversikter
• Regler för kodstil och namnkonventioner

# CLAUDE.md exempel
## Arkitektur
- src/app/ — Next.js app router-sidor
- src/lib/ — delade verktyg och API-klienter
- src/components/ — React-komponenter (samlokaliserad stil)

## Regler
- Använd server components som standard
- Importera aldrig direkt från node_modules i komponenter
- Alla API-anrop går via src/lib/api.ts

2. Arkitektoniska begränsningar

Istället för att hoppas att agenten väljer rätt arkitektur, bör du tvinga fram den.

• Strikta lagerarkitekturer validerade av linters
• Strukturella tester som misslyckas om mönster bryts
• Importrestriktioner via ESLint-regler eller anpassade skript

3. Verktyg & MCP-servrar

Agenter behöver verktyg för att vara effektiva. De bästa miljöerna exponerar interna verktyg via:

• CLI-wrappers — föredra välkända CLI:er (git, docker, npm) framför specialbyggda verktyg
• MCP-servrar (Model Context Protocol) — låt agenter anropa dina interna API:er, databaser och tjänster
• Filsystemåtkomst — begränsad till specifika kataloger för att förhindra oavsiktliga skador

4. Sub-agenter & kontextbrandväggar

Långvariga agentsessioner samlar på sig kontext som till slut försämrar prestandan — detta kallas kontextröta (context rot).

Lösningen: sub-agenter med kontextbrandväggar.

• Dela upp komplexa uppgifter i avgränsade deluppgifter
• Varje deluppgift körs i en egen session med fräsch kontext
• Skicka endast strukturerade resultat mellan agenter, inte hela konversationen

1. Initializer Agent — planerar arbetet, skapar en funktionslista
2. Coding Agent — utför varje funktion isolerat

5. Hooks & Back-Pressure

Automatiserade feedback-loopar som fångar misstag innan de växer:

• Pre-commit hooks — typpkontroll, linting, formatering
• Test runners — agenter bör köra tester efter varje ändring
• Byggverifiering — misslyckas snabbt vid trasiga byggen

6. Självverifieringsloopar

Tvinga agenter att verifiera sitt eget arbete innan de markerar uppgifter som klara:

• Kör testsviten efter ändringar
• Kontrollera att bygget går igenom
• Verifiera att utdatan matchar specifikationen
• Ta en skärmdump och jämför (för UI-arbete)

7. Framstegsdokumentation

För långvariga uppgifter (30+ minuter):

• Underhåll en framstegsfil som spårar slutförda steg
• Gör commits ofta så att efterföljande sessioner kan fortsätta
• Använd strukturerade uppgiftslistor, inte lösa anteckningar

Verkliga resultat

OpenAI Codex Team

3 ingenjörer producerade en kodbas på en miljon rader helt utan manuellt skriven kod under 5 månader. De snittade på 3,5 mergeade PR:ar per ingenjör och dag — en genomströmning som är omöjlig utan en mogen harness.

Deras harness inkluderade: strikta commit-konventioner, automatiserad testning på varje PR och agent-medvetna CI/CD-pipelines.

Stripes "Minions"

Stripes interna system producerar över 1 000 mergeade PR:ar per vecka med hjälp av AI-agenter. Deras harness inkluderade:

• Tydligt avgränsade uppgiftsdefinitioner
• Obligatorisk kodgranskning av människor
• Automatiserad regressionstestning
• Rollback-automation

Anthropics två-agent-arkitektur

Anthropic publicerade sin metod för effektiva harnesses för agenter som körs under lång tid:

• Strukturerade funktionslistor som format för överlämning mellan agenter
• Git-baserad framstegsspårning så att agenter kan återuppta arbetet efter avbrott
• Tydliga avslutskriterier så att agenter vet när de ska sluta

Så börjar du bygga din harness

Steg 1: Skapa din kontextfil

Lägg till en CLAUDE.md (eller AGENTS.md) i din projektrot:

# Projekt: [Ditt projekt]

## Teknikstack
[Ramverk, språk, databas, hosting]

## Arkitektur
[Katalogstruktur med korta beskrivningar]

## Regler
[5-10 strikta regler som agenten måste följa]

## Vanliga uppgifter
[Hur man kör tester, bygger, deployar]

Steg 2: Lägg till arkitektoniska begränsningar

# Exempel: ESLint-regel som förhindrar direkta DB-importer i komponenter
# .eslintrc — no-restricted-imports rule

Ställ in pre-commit hooks som upprätthåller dina regler automatiskt.

Steg 3: Bygg verifieringsloopar

Se till att din agent kan:

1. Köra tester (npm test, pytest, etc.)


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


3. Köra linting (eslint ., ruff check)

Steg 4: Avgränsa agentsessioner

Ge inte en agent hela din backlog. Istället:

• En funktion per session
• En buggfix per session
• Tydliga acceptanskriterier för varje uppgift

Steg 5: Iterera på din harness

Varje gång en agent gör ett misstag:

1. Identifiera grundorsaken
2. Lägg till en regel, begränsning eller hook som förhindrar det
3. Testa fixen

Harness Engineering vs. Prompt Engineering

Prompt engineering är fortfarande användbart, men det är bara en liten del av helheten. Harness engineering är multiplikatorn.

Bör inte förväxlas med: Harness.io

Om du sökte på "Harness Engineering" och letade efter DevOps-plattformen — Harness.io är något helt annat. Det är en AI-driven CI/CD-plattform värderad till 5,5 miljarder dollar (per december 2025) som erbjuder kontinuerlig integration, leverans, feature flags, hantering av molnkostnader och säkerhetstester.

Även om Harness.io och harness engineering delar namn, löser de olika problem. Det finns dock en intressant överlappning: Harness.io:s AI-drivna DevOps kan sägas vara en tillämpning av principerna för harness engineering på själva deployment-pipelinen.

Slutsats

Modellen är motorn. En harness är bilen. Ingen vinner ett lopp med bara en motor.

Om du använder AI-kodningsagenter under 2026 och inte investerar i din harness, går du miste om det mesta av värdet. Börja med en kontextfil, lägg till begränsningar, bygg verifieringsloopar och iterera varje gång något går sönder.

De team som levererar snabbast använder inte bättre modeller. De använder bättre harnesses.