Slik skal Better Harness gjøre arbeidsflyten rundt AI-kodeagenter mer målbar

Better Harness er et åpenkildekodeprosjekt fra Qoder som gjennomgår og forbedrer arbeidsflyten rundt en kodeagent. I stedet for å bedømme ett modellsvar eller én kodeendring isolert, ser det på prosjektinstruksjoner, kontrollmekanismer, valideringsløp, agentoppsett og – der det finnes – spor fra faktiske økter. Målet er å avdekke hull i arbeidsflyten, foreslå et avgrenset tiltak og gjøre resultatet mulig å kontrollere ved en senere kjøring. 124

Qoder kunngjorde at prosjektet ble gjort tilgjengelig som åpen kildekode på GitHub 28. juli 2026, ifølge samtidig omtale. 5

Det viktige skiftet: Vurder rammene, ikke bare modellen

En kodeagent arbeider aldri i et tomrom. Den er omgitt av veiledning i kodebasen, spesifikasjoner, verktøy, rettigheter, skript, tester, krav til kodegjennomgang, leveransesjekker og overleveringer mellom mennesker. Qoder omtaler dette miljøet som en harness – en ramme eller rigg for agentarbeidet. Dokumentasjonen nevner blant annet repository-instruksjoner, regler, ferdigheter (skills), hooks, utvidelser, koblinger, skript, testkommandoer, lanseringskontroller og manuelle gjennomganger. 2

Skillet er vesentlig: En kompetent modell kan fortsatt gi upålitelige resultater dersom omgivelsene er uklare eller svakt instrumentert. Et prosjekt kan ha en testkommando uten at det er tydelig når agenten skal kjøre den. Det kan ha en regel-fil som agenten aldri bruker. Eller det kan mangle en varig måte å ta vare på læring fra mislykkede oppgaver på. Better Harness er laget for å synliggjøre slike driftsmessige svakheter – ikke for å anta at en konfigurasjonsfil i seg selv beviser at prosessen fungerer. 145

Tre lag: praksis, vurdering og kjørbar bruk

Better Harness presenteres som et rammeverk med tre lag, som knytter sammen ingeniørpraksis, en vurderingsmodell og en kjørbar implementasjon. 5

1. Praksis for Harness Engineering

Det første laget omfatter de praktiske mekanismene som former agentens arbeid: økt- og CLI-mønstre, observerbarhet, regler, ferdigheter, MCP-konfigurasjon, minne, hooks og automatisering. 5

I praksis handler det om spørsmål som:

• Får agenten klare mål, begrensninger og relevant kontekst fra kodebasen?
• Er utførelsesveier og tillatelser styrt på en passende måte?
• Er tester, kontroller og gjennomganger koblet til arbeidet agenten gjør?
• Kan nyttig læring bli vedlikeholdte prosjektressurser, i stedet for å forsvinne når økten avsluttes?

Better Harness starter med å kartlegge den eksisterende rammen: mål, kontekst, inngangspunkter for utførelse, tilbakemeldingssløyfer, leveringsmekanismer og hvordan læring tas vare på. 1

2. Vurdering av Agent Work Loop

Det andre laget omsetter praksisen i en vurdering av fem sammenhengende leveransedimensjoner: oppgaveforståelse, kontrollert utførelse, validering av endringer, pålitelig levering og innhenting av læring. 14

Dermed flyttes spørsmålet fra «skrev agenten plausibel kode?» til et mer nyttig operasjonelt spørsmål: Kan arbeidsflyten fra start til slutt gjentatte ganger produsere endringer som er forståelige, kontrollerte, validerte, leverbare og basert på tidligere erfaringer?

Modellen er ment å finne brudd i denne sløyfen – for eksempel en manglende mekanisme, en frakoblet integrasjon, et trinn som aldri faktisk ble utført, eller for svakt bevisgrunnlag for resultatet. 1

3. Kjørbar implementasjon

Det tredje laget gjør praksisen og vurderingsmodellen anvendbar i reelle prosjekter, fremfor å la dem bli værende som råd i dokumentasjon. Better Harness kjøres gjennom en kodeagent, samler prosjekt- og øktbevis der dette støttes, og lager prioriterte neste steg som kan verifiseres. 4

Qoders nåværende prosjektmateriale oppgir støtte for ti vertsadaptere. Ved lanseringen ble blant annet Claude Code, Codex, Qoder og Cursor nevnt som støttede kodeagentmiljøer. 56

Adapterstøtte kan endre seg, så integrasjon med en bestemt vert bør kontrolleres mot prosjektets oppdaterte adapterdokumentasjon. Kildene som er oppgitt her, dokumenterer særlig ikke støtte for OpenClaw.

Tre typer bevis – holdt adskilt før vurderingen

Et sentralt trekk ved tilnærmingen er at innsamling av bevis holdes adskilt fra den endelige vurderingen. Qoder opplyser at hovedanalysen samler rådata og sender dem til tre uavhengige underagenter med skrivebeskyttet tilgang før resultatene kombineres. 1

De tre perspektivene er:

• Project Harness: kodebasens tekniske grunnmur, som instrukser, skript, kontroller og leveringsstyring.
• Agent Customization: agentspesifikke regler, ferdigheter, hooks og annen konfigurasjon.
• Session Evidence: spor av hva agenten faktisk gjorde i reelt arbeid, der slike data er tilgjengelige.

Oppsettet bidrar til å skille en planlagt prosess fra en observert prosess. Prosjekt- og konfigurasjonsbevis kan vise at en funksjon eller kontroll er tilgjengelig. Øktbevis kan bidra til å vise om den ble brukt hensiktsmessig i en konkret oppgave. 14

At noe finnes, er ikke det samme som at det virker

Det mest nyttige prinsippet i rammeverket er at et artefakts eksistens ikke er bevis på effekt.

Tenk på en kodebase med automatiske tester. At testpakken finnes, viser en potensiell evne. Det viser ikke i seg selv at agenten kjørte de relevante testene etter en endring, tolket resultatet riktig eller brukte utfallet til å hindre en feilaktig levering. Det samme gjelder regler, hooks, ferdigheter og godkjenningsporter. 15

Better Harness forsøker derfor å gjøre beviskjeden tydelig. Rapportene omsetter dokumenterte hull til prioriterte funn med konsekvens, forventet resultat, avgrenset utbedring og akseptansekriterier. Manglende bevis skal fortsatt være synlig, i stedet for å bli omgjort til en skråsikker poengsum. 46

Et nyttig funn bør la teamet undersøke fire ting:

1. Hva som ble observert i prosjektet, konfigurasjonen eller øktloggen.
2. Hvorfor det betyr noe for leveransesløyfen.
3. Hvilket smalt tiltak som foreslås, for eksempel en regel, ferdighet, hook, et skript, automatisering eller et manuelt godkjenningssteg.
4. Hvordan tiltaket kan kontrolleres etter at det er gjennomført.

En forbedringssløyfe: Kartlegg, utbedre, mål på nytt

Better Harness er ikke posisjonert som en engangsrevisjon. Arbeidsflyten er iterativ:

1. Kartlegg den nåværende rammen.
2. Finn brudd i arbeidsflyten og hull i bevisgrunnlaget.
3. Opprett en avgrenset utbedringsoppgave for et dokumentert funn.
4. Valider tiltaket mot definerte akseptansekriterier.
5. Kjør gjennomgangen på nytt og undersøk det oppdaterte bevisgrunnlaget. 14

Dette er grunnlaget for påstanden om kontinuerlig forbedring. Verktøyet kan vise at en arbeidsflyt har endret seg, og om nye spor støtter en sterkere vurdering. Det beviser derimot ikke alene at et tiltak har ført til bedre agentytelse i alle prosjekter eller vertsmiljøer. Qoders materiale vektlegger observert bevis og tydelige begrensninger, fremfor å behandle endringer i poengsum som årsaksbevis. 46

Hva den omtalte gjennomgangen av 30 prosjekter faktisk sier

Lanseringsomtale oppga at rammeverket først ble brukt på 30 reelle GitHub-prosjekter. 5 Det bør leses som en utforskende anvendelse av metoden, ikke som en kontrollert dokumentasjon på at Better Harness forbedrer alle kodeagenter eller kodebaser.

Den tilgjengelige primærdokumentasjonen støtter verktøyets bevismodell, strukturen for funn og den iterative utbedringsprosessen. De oppgitte kildene inneholder imidlertid ikke nok primærinformasjon til å vurdere utvalget av de 30 prosjektene, poengsettingsprotokollen eller samlede resultater uavhengig. Det er viktige forbehold når Better Harness sammenlignes med formelle referansetester eller brukes som grunnlag for brede ytelsespåstander. 14

Et forsøk på mer målbar agentutvikling

Qoders bredere argument er at Harness Engineering bør bli kvalitetsinfrastruktur for AI-assistert programvareutvikling: et felles språk for arbeidsflytkontroller, observerbare bevis, sammenlignbare leveransedimensjoner og gjentakbare forbedringssløyfer. 12

Better Harness er en praktisk utgave av denne ideen. Det gir team en måte å undersøke betingelsene rundt agentarbeid på tvers av støttede vertsmiljøer, diskutere bevis fremfor inntrykk og teste om et foreslått arbeidsflyttiltak holder ved senere kjøringer. Verdien ligger ikke i en garanti om at enhver endring forbedrer resultatene, men i en mer disiplinert metode for å gjøre agentarbeidsflyter undersøkelige, gjennomgåelige og mulig å motbevise. 46