Vad du kommer att lära dig

Denna guide täcker Harness Engineering från grundläggande principer till praktiskt genomförande. Du kommer att förstå vad det är, varför OpenAI satsade sitt största interna projekt på det, de specifika arkitektoniska mönster som gör att det fungerar, och hur du tillämpar dessa principer på dina egna AI-agentarbetsflöden — oavsett om du använder Codex, Claude Code, OpenCode eller något annat agentsystem.

Harness Engineering: Den fullständiga guiden för AI-agentutveckling år 2026

Om 2025 var året då AI-agenter bevisade att de kunde skriva kod, så är 2026 året då vi lärde oss att agenten inte är den svåra delen — selen (the harness) är det.

OpenAI:s Codex-team publicerade ett banbrytande blogginlägg i februari 2026 som beskrev hur de byggde en produktionsapplikation innehållande ungefär en miljon rader kod där noll rader skrevs av mänskliga händer. Hemligheten var inte en bättre modell eller en smartare prompt. Det var systemet de byggde runt agenten — "the harness" (selen). Source

Denna guide bryter ner varje princip, mönster och praktisk teknik från det experimentet och den bredare Harness Engineering-rörelse som har vuxit fram kring det.

Del 1: Vad är Harness Engineering?

Definitionen

Harness Engineering är disciplinen att utforma hela miljön — scaffolding, feedback loops, dokumentation, arkitektoniska begränsningar och maskinläsbara artefakter — som gör det möjligt för AI-kodningsagenter att utföra tillförlitligt arbete av hög kvalitet i stor skala med minimal mänsklig intervention.

Termen "harness" kommer från hästutrustning: tyglar, sadel, betsel — den kompletta uppsättningen utrustning för att kanalisera ett kraftfullt men oförutsägbart djur i rätt riktning. En okontrollerad häst är farlig. En selad häst byggde civilisationer. Detsamma gäller AI-agenter. Source

Varför det växte fram nu

Skiftet från Prompt Engineering till Harness Engineering speglar en mognad i AI-utvecklingslandskapet:

Source

Den viktigaste insikten som drev denna övergång: agenter blev tillräckligt kapabla för att flaskhalsen skulle skifta från modellkvalitet till miljökvalitet. En toppmodern modell som arbetar i ett dåligt strukturerat repository producerar sämre resultat än en medioker modell som arbetar i en välutrustad harness-miljö.

Del 2: OpenAI Codex-experimentet

Skalan

I ett fem månader långt internt experiment byggde och lanserade OpenAI-ingenjörer en betaprodukt innehållande ungefär en miljon rader kod. Repositoryt omfattar applikationslogik, infrastruktur, verktyg, dokumentation och interna utvecklarverktyg. Det fanns ingen tidigare mänskligt skriven kod att förankra systemet i. Source

Teamet

Projektet startade med endast tre ingenjörer som drev Codex. Under femmånadersperioden öppnades och slogs ungefär 1,500 pull requests samman. När teamet växte till sju ingenjörer ökade genomströmningen — ett kontraintuitivt resultat som antydde att själva selen (the harness) var den primära produktivitetsmultiplikatorn, inte den individuella skickligheten.

OpenAI uppskattar att de byggde systemet på ungefär en tiondel av den tid det skulle ha tagit att skriva koden för hand. Source

Den initiala strukturen (The Initial Scaffold)

Projektet började med att Codex CLI genererade den initiala strukturen med hjälp av GPT-5, vägledd av en liten uppsättning befintliga mallar:

• Repository-struktur och katalogkonventioner
• CI/CD-konfiguration
• Kodformatering och linting-regler
• Inställningar för pakethanterare
• Boilerplate för applikationsramverk

Från detta frö växte allt annat fram genom agentdriven utveckling.

Fredagsproblemet

Tidigt i experimentet upptäckte teamet ett kritiskt problem: de spenderade varje fredag — 20% av sin ingenjörstid — med att städa upp vad de kallade "AI slop" (AI-slask). Detta inkluderade inkonsekventa mönster, duplicerad logik, felnamnade variabler och arkitektonisk avvikelse.

Det var inte skalbart. Lösningen var att koda in sina standarder i själva selen så att agenterna skulle producera renare output från början, och att bygga automatiserade upprensningssystem för den kvarvarande avvikelsen.

Del 3: De fem kärnprinciperna

Princip 1: Repository-First Knowledge

Från agentens perspektiv existerar ingenting som den inte kan komma åt i sin kontext under körning. Kunskap som lever i Google Docs, chatt-trådar, Slack-meddelanden eller i människors huvuden är osynlig för systemet.

Detta innebär att all kunskap måste leva som repository-lokala, versionerade artefakter:

• Kod — den primära artefakten
• Markdown-dokumentation — arkitekturbeslut, konventioner, onboarding-guider
• Scheman — API-kontrakt, databasscheman, typdefinitioner
• Exekverbara planer — steg-för-steg uppgiftsnedbrytningar som agenten kan följa
• Konfiguration — linter-regler, CI-pipelines, formateringsstandarder

Teamet lärde sig att de behövde trycka in mer och mer kontext i repositoryt över tid. Varje gång en agent gjorde ett misstag för att den saknade kontext, var lösningen inte en bättre prompt — det var att lägga till den kontexten i repositoryt. Source

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: Gyllene principer (Golden Principles)

Gyllene principer är åsiktsdrivna, mekaniska regler kodade direkt i repositoryt som håller kodbasen läsbar och konsekvent för framtida agentkörningar. De är inte bara riktlinjer — de är påtvingade begränsningar.

Exempel från OpenAI-experimentet:

1. Föredra delade verktygspaket framför handgjorda hjälpare — centraliserar invarianter så att när beteendet behöver ändras, ändras det på ett ställe
2. Sondera inte data YOLO-stil — validera gränser eller förlita dig på typade SDK:er så att agenter inte råkar bygga på gissade datamodeller
3. Ett koncept, en fil — varje fil ska representera ett enda koncept, vilket gör det lättare för agenter att hitta och ändra rätt plats
4. Explicit framför implicit — undvik magiskt beteende som en agent skulle behöva tyst kunskap för att förstå

Source

Dessa principer är inte bara dokumentation. De upprätthålls av:

• Linter-regler — anpassade linters (själva genererade av Codex) som flaggar överträdelser
• Strukturella tester — tester som validerar arkitektonisk efterlevnad
• CI gates — pull requests som bryter mot gyllene principer avvisas automatiskt

Princip 3: Lagerarkitektur med mekanisk kontroll

Varje affärsdomän i OpenAI-projektet är uppdelad i en fast uppsättning lager med strikt validerade beroenderiktningar:

Types → Config → Repo → Service → Runtime → UI

Beroenden flödar endast i en riktning. En UI-komponent kan bero på Runtime och Service, men en Service får aldrig importera från UI. Ett Repo kan bero på Config och Types, men aldrig på Service. Source

Dessa begränsningar upprätthålls mekaniskt:

// 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 strukturella testerna validerar efterlevnad och förhindrar brott mot modulär lagring. Detta är inte ett förslag — det upprätthålls av CI. Varje pull request, oavsett om den skapats av en människa eller en agent, måste klara dessa tester.

Princip 4: Automatiserad Garbage Collection

Även med gyllene principer och strukturell kontroll avviker agentgenererad kod över tid. OpenAI-teamet löste detta genom att implementera automatiserad Garbage Collection — återkommande bakgrundsuppgifter som:

1. Söker efter avvikelser från gyllene principer över hela kodbasen
2. Uppdaterar kvalitetsbetyg för varje modul baserat på efterlevnadspoäng
3. Öppnar riktade refaktorerings-pull requests som fixar specifika kategorier av avvikelser

Detta ersatte den manuella "fredagsstädningen" med ett system som körs kontinuerligt. Garbage collector själv drivs av Codex-agenter, vilket skapar en självunderhållande loop. Source

# .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: Exekverbara planer

Innan agenter skriver kod skriver de planer. Dessa planer är inte informella anteckningar — de är strukturerade, exekverbara dokument som specificerar:

• Mål: Vad uppgiften åstadkommer
• Filer som ska ändras: Explicit lista över filer som agenten kommer att röra
• Beroenden: Andra uppgifter eller moduler som detta arbete beror på
• Acceptanskriterier: Hur man verifierar att arbetet är slutfört
• Begränsningar: Arkitektoniska regler som inte får brytas

# 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 repositoryt som markdown-filer, är versionsstyrda och kan granskas före exekvering — vilket ger människor en kontrollpunkt mellan avsikt och implementering.

Del 4: Codex Agent Loop

Att förstå hur Codex agent loop fungerar inom en harness är nödvändigt för effektiv Harness Engineering.

Loop-arkitekturen

OpenAI publicerade en detaljerad nedbrytning av Codex agent loop i sitt kompletterande blogginlägg "Unrolling the Codex agent loop." Source Loopen följer denna cykel:

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

Varje iteration:

1. Read Context: Agenten läser relevanta filer, dokumentation, scheman och uppgiftsplanen från repositoryt
2. Plan: Baserat på kontexten bestämmer agenten vilka ändringar som ska göras
3. Execute: Agenten skriver eller modifierar kod
4. Validate: Selen (the harness) kör tester, linters och strukturella kontroller mot ändringarna
5. Commit or Retry: Om valideringen går igenom committar agenten. Om den misslyckas läser agenten felmeddelandet och försöker igen.

Harness-systemets roll är att göra steg 1 och 4 så informationsrika som möjligt. Ju mer kontext agenten läser, desto bättre blir dess plan. Ju mer specifik feedback från valideringen, desto snabbare konvergerar den mot en fungerande lösning.

App Server Harness

I sitt inlägg "Unlocking the Codex harness: how we built the App Server" beskriver OpenAI den konkreta infrastruktur som driver agent loopen. Source App Server tillhandahåller:

• Isolerade exekveringsmiljöer (sandboxes) för varje agentuppgift
• Förkonfigurerad verktygsåtkomst (filsystem, terminal, webbläsare)
• Automatisk kontextinjektion från repository-artefakter
• Strömmande valideringsfeedback så att agenter kan se testfel i realtid

Del 5: Att tillämpa Harness Engineering i ditt team

Komma igång: En Minimum Viable Harness

Du behöver inte replikera hela OpenAI:s infrastruktur för att dra nytta av Harness Engineering. Börja med dessa grundläggande element:

Steg 1: Skapa en ARCHITECTURE.md

Dokumentera ditt projekts arkitektoniska regler i ett maskinläsbart format i roten av ditt repository. Inkludera:

• Modulgränser och tillåtna beroenden
• Namnkonventioner
• Regler för filorganisation
• Testkrav

Denna enda fil förbättrar dramatiskt kvaliteten på agentens output eftersom agenter läser den innan de gör ändringar.

Steg 2: Lägg till strukturella tester

Skriv tester som validerar dina arkitektoniska regler. Dessa tester kontrollerar inte affärslogik — de kontrollerar att koden är korrekt organiserad:

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

Steg 3: Konfigurera CI-validering

Se till att din CI-pipeline kör strukturella tester, linters och typkontroller på varje pull request — inklusive de som skapats av agenter. Agenten bör se samma valideringsresultat som en mänsklig utvecklare skulle se.

Steg 4: Skriv uppgiftsplaner före agentexekvering

Innan du ber en agent att implementera en funktion, skriv ett strukturerat plandokument som specificerar filer som ska ändras, begränsningar som ska följas och acceptanskriterier. Spara dessa planer i ditt repository.

Steg 5: Ställ in automatiserad upprensning

Implementera ett vecko- eller nattligt CI-jobb som skannar din kodbas efter avvikelser från dina dokumenterade standarder och skapar fokuserade refaktorerings-PRs.

Att välja ditt agentsystem

Harness Engineering-principer gäller oavsett vilken agent du använder:

Selen (the harness) lever i ditt repository, inte i din agent. Detta innebär att du kan byta agenter utan att förlora din investering i din harness.

Skala från en agent till många

OpenAI-experimentet visade att Harness Engineering möjliggör parallell exekvering av agenter. Eftersom selen upprätthåller arkitektoniska gränser kan flera agenter arbeta på olika delar av kodbasen samtidigt utan att skapa konflikter.

Viktiga krav för parallell agentexekvering:

1. Tydligt modulägande — varje agent arbetar inom en definierad gräns
2. Typade gränssnitt mellan moduler — agenter kan koda mot gränssnitt utan att känna till implementeringsdetaljer
3. Förebyggande av merge-konflikter — uppgifter avgränsas för att minimera filöverlappning
4. Centraliserad validering — alla agenter skickar in till samma CI-pipeline

Del 6: Vanliga fallgropar och antimönster

Antimönster 1: Behandla agenten som selen (the harness)

Agenten är inte selen. Selen är miljön agenten verkar i. Att be en smartare modell kompensera för ett dåligt strukturerat repository är fel väg att gå. Fixa miljön, inte prompten.

Antimönster 2: Dokumentation på fel ställe

Om dina arkitekturbeslut lever i Confluence, Notion eller Google Docs kan agenter inte se dem. Lösningen är enkel men kräver disciplin: flytta all utvecklingsrelevant dokumentation till repositoryt.

Antimönster 3: Manuell städning istället för automatiserad kontroll

Om du spenderar betydande tid på att städa upp agentgenererad kod behöver du bättre kontroll, inte fler städsessioner. Varje återkommande städuppgift bör bli antingen en linter-regel, ett strukturellt test eller ett automatiserat refaktoreringsjobb.

Antimönster 4: Överdriven begränsning

En harness som är för rigid hindrar agenter från att hitta kreativa lösningar. Målet är att begränsa arkitekturen, inte implementeringen. Tala om för agenter vilka moduler de kan ändra och vilka beroenden som är tillåtna, men låt dem bestämma hur de ska implementera logiken inom dessa ramar.

Antimönster 5: Ignorera feedback från agenter

När en agent upprepade gånger misslyckas med vissa uppgifter tyder misslyckandet vanligtvis på en lucka i din harness, inte en begränsning hos agenten. Spåra felmönster och använd dem för att förbättra din dokumentation, dina strukturella tester eller dina arkitektoniska begränsningar.

Del 7: Framtiden för Harness Engineering

Martin Fowlers perspektiv

Martin Fowler publicerade en analys av Harness Engineering på sin blogg och noterade att det representerar ett fundamentalt skifte i hur mjukvaruteam arbetar. Disciplinen lånar från årtionden av bästa praxis inom mjukvaruuteckling — kontinuerlig integration, Architecture Decision Records, Dependency Injection — men anpassar dem för en agentdriven värld. Source

HumanLayer-ramverket

Teamet på HumanLayer publicerade sin analys och kallade Harness Engineering för en "skill issue" (kompetensfråga) — och argumenterade för att förmågan att designa effektiva harnesses kommer att bli den främsta skillnaden mellan högpresterande och kämpande ingenjörsteam. Source

Vad detta innebär för utvecklare

Harness Engineering ersätter inte utvecklarens skicklighet — den styr om den. Istället för att skriva kod designar seniora ingenjörer de system som gör det möjligt för agenter att skriva bra kod. De färdigheter som spelar roll skiftar från implementering till arkitektur, från kodning till systemdesign, från att skriva tester till att designa testramverk.

För team som bygger applikationer integrerar plattformar som ZBuild redan Harness Engineering-principer i sina arbetsflöden för app-byggande. Istället för att kräva att utvecklare designar sina egna harnesses från grunden, tillhandahåller ZBuild förkonfigurerade arkitektoniska mönster, beroendehantering och valideringssystem som guidar AI-agenter mot högkvalitativ output — vilket låter utvecklare fokusera på produktbeslut snarare än infrastruktur.

De tre horisonterna

När vi blickar framåt kommer Harness Engineering sannolikt att utvecklas genom tre faser:

1. Nära sikt (2026): Team anammar repository-first dokumentation, strukturella tester och gyllene principer. Agent-assisterad utveckling blir standardpraxis för välutrustade projekt.

2. Medellång sikt (2027): Själva skapandet av en harness blir agentdrivet. Agenter analyserar befintliga kodbaser och föreslår harness-konfigurationer — linter-regler, strukturella tester, beroendegränser — baserat på de mönster de observerar.

3. Lång sikt (2028+): Harnesses blir adaptiva. Istället för statiska regler utvecklas de baserat på resultaten av agentgenererad kod, genom att automatiskt strama åt begränsningar i områden där agenter ofta gör fel och lätta på begränsningar där de konsekvent lyckas.

Del 8: Praktisk checklista

Använd denna checklista för att utvärdera ditt teams mognad inom Harness Engineering:

Grundläggande (Börja här)

• ARCHITECTURE.md finns i repositoryts rot
• Kodformatering är automatiserad (Prettier, Black, gofmt)
• Linting körs på varje pull request
• Typkontroll framtvingas (TypeScript strict, mypy, etc.)

Medelnivå

• Strukturella tester validerar beroendegränser
• Gyllene principer är dokumenterade och maskinellt genomförbara
• Uppgiftsplaner skrivs före agentexekvering
• Agentgenererade PRs genomgår samma CI som mänskliga PRs

Avancerad

• Automatiserad Garbage Collection körs enligt schema
• Flera agenter kan arbeta parallellt utan konflikter
• Agenters felmönster spåras och används för att förbättra selen
• Själva selen (the harness) är versionsstyrd och granskas som kod

Expert

• Agenter genererar delar av selen (linter-regler, strukturella tester)
• Kvalitetsbetyg tilldelas automatiskt till varje modul
• Förbättringar av selen är datadrivna baserat på agenters framgångsfrekvens
• Teamet levererar mer kod per ingenjör per vecka än före införandet av agenter

Slutsats

Harness Engineering är inte en fluga. Det är den naturliga utvecklingen av mjukvaruuteckling i en era där AI-agenter är kapabla nog att skriva produktionskod men behöver strukturerade miljöer för att göra det bra. OpenAI:s experiment med en miljon rader kod bevisade konceptet i stor skala, och principerna de formulerade — repository-first kunskap, gyllene principer, lagerarkitektur, automatiserad Garbage Collection och exekverbara planer — är tillämpliga på team av alla storlekar.

De team som bemästrar Harness Engineering under 2026 kommer att leverera snabbare, bibehålla högre kodkvalitet och skala mer effektivt än de som behandlar AI-agenter som en glorifierad autocomplete. Agenten är hästen. Selen är det som gör den användbar.

Källor

• 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