Better Harness: Qoders værktøj til at teste arbejdsgangen omkring AI-kodeagenter

AI-kodeagenter bliver ikke kun gode af at have en stærk model. De afhænger også af rammerne omkring arbejdet: instruktioner i repositoryet, adgangsregler, scripts, tests, reviewkrav og den viden, et team bevarer fra tidligere opgaver.

Det er dét miljø, Qoder kalder en harness. Better Harness er et open source-projekt, der gennemgår denne arbejdsgang omkring en kodeagent frem for kun at bedømme et enkelt svar eller et enkelt kode-diff. Formålet er at finde dokumenterede svagheder, foreslå en afgrænset udbedring og kontrollere resultatet ved en senere kørsel. 124

Qoder offentliggjorde projektet som open source på GitHub den 28. juli 2026, ifølge samtidig omtale. 5

Ikke bare: Gav agenten et plausibelt svar?

En harness kan blandt andet bestå af repository-instruktioner, regler, skills, hooks, plugins, forbindelser, scripts, testkommandoer, releasekontroller og menneskelig review. 2

Derfor kan en agent godt skrive tilsyneladende fornuftig kode i et workflow, der stadig er skrøbeligt. Måske findes der en testkommando, men agenten får ingen klar besked om, hvornår den skal bruges. Måske ligger en regel i projektet, men agenten anvender den ikke. Eller måske forsvinder erfaringen fra en fejlet opgave, når sessionen slutter.

Better Harness forsøger at flytte samtalen fra “findes konfigurationen?” til “blev den brugt, og er der belæg for, at den virkede?” 145

Tre lag: praksis, evaluering og kørbarhed

Qoder beskriver Better Harness som en ramme med tre lag, der forbinder konkrete ingeniørpraksisser med en evalueringsmodel og en implementering, der kan køres i projekter. 5

1. Harness Engineering i praksis

Det første lag handler om de praktiske elementer, som former agentens arbejde: sessioner og CLI-mønstre, observerbarhed, regler, skills, MCP-konfiguration, hukommelse, hooks og automatisering. 5

I praksis er det spørgsmål som:

• Har agenten et klart mål, relevante begrænsninger og tilstrækkelig projektkontekst?
• Er kommandoer, værktøjer og tilladelser styret forsvarligt?
• Er test, kvalitetstjek og review koblet til de ændringer, agenten laver?
• Kan læring fra en opgave gemmes som vedligeholdte projektaktiver frem for at forsvinde med sessionen?

Første skridt er at kortlægge den eksisterende harness: mål, kontekst, indgange til udførelse, feedbacksløjfer, leveringsmekanismer og opsamling af læring. 1

2. Evaluering af agentens arbejdsloop

Det andet lag vurderer fem sammenhængende dele af leveringen: opgaveforståelse, kontrolleret udførelse, validering af ændringer, pålidelig levering og opsamling af læring. 14

Det er en mere operationel test end blot at se på kodeoutputtet: Kan workflowet igen og igen føre til ændringer, der er forståelige, kontrollerede, validerede, leverbare og informeret af tidligere arbejde?

Modellen skal pege på brud i kæden – eksempelvis en manglende mekanisme, en integration der ikke hænger sammen, et trin som aldrig blev kørt, eller manglende dokumentation for resultatet. 1

3. En implementering, der kan køres

Det tredje lag skal sikre, at principperne ikke kun ender som dokumentation. Better Harness kører via en kodeagent, indsamler projekt- og, hvor det understøttes, sessionsdata og leverer prioriterede næste skridt med mulighed for efterfølgende kontrol. 4

Qoders aktuelle projektmateriale omtaler ti værtsadaptere. Ved lanceringen blev blandt andre Claude Code, Codex, Qoder og Cursor nævnt som understøttede miljøer. 56

Understøttelsen kan ændre sig, så en konkret integration bør altid tjekkes i den aktuelle adapterdokumentation. De foreliggende kilder dokumenterer ikke understøttelse af OpenClaw.

Tre slags beviser – holdt adskilt først

Et centralt element i Better Harness er, at indsamling af data adskilles fra den samlede vurdering. Qoder oplyser, at hovedforløbet først samler rå data og derefter sender dem til tre uafhængige underagenter med skrivebeskyttet adgang, før resultaterne kombineres. 1

De tre perspektiver er:

• Project Harness: projektets tekniske grundlag, eksempelvis instruktioner, scripts, tjek og leveringskontroller.
• Agent Customization: agentspecifikke regler, skills, hooks og anden konfiguration.
• Session Evidence: spor af, hvad agenten faktisk gjorde under reelt arbejde, når sådanne data er tilgængelige.

Skellet er vigtigt. Projekt- og konfigurationsdata kan vise, at en funktion er til rådighed. Sessionsdata kan i højere grad vise, om den blev brugt relevant i en konkret opgave. 14

At noget findes, er ikke det samme som, at det virker

Det måske mest nyttige princip er, at et artefakts blotte eksistens ikke er dokumentation for effektivitet.

Et repository kan have en automatisk testpakke. Det viser en potentiel kapacitet, men ikke i sig selv, at agenten kørte de relevante tests efter en ændring, fortolkede resultatet korrekt eller undgik at levere en fejl. Det samme gælder regler, hooks, skills og godkendelsesporte. 15

Derfor skal fundene holde beviskæden synlig. Understøttede mangler bliver til prioriterede findings med effekt, forventet resultat, afgrænset udbedring og acceptkriterier. Manglende beviser bliver stående som manglende beviser i stedet for at blive omsat til en sikker score. 46

Et brugbart fund bør dermed gøre fire ting klare:

1. Hvad der blev observeret i projektet, konfigurationen eller sessionssporet.
2. Hvorfor det har betydning for leveringsforløbet.
3. Hvilken begrænset ændring der foreslås – for eksempel en regel, skill, hook, et script, automatisering eller et menneskeligt godkendelsestrin.
4. Hvordan ændringen kan verificeres bagefter.

En løkke for forbedring, ikke et engangstjek

Better Harness er tænkt som en iterativ proces:

1. Kortlæg den nuværende harness.
2. Find brud i workflowet og huller i dokumentationen.
3. Opret en afgrænset reparationsopgave for et understøttet fund.
4. Valider ændringen mod klart definerede acceptkriterier.
5. Kør gennemgangen igen og vurder de opdaterede beviser. 14

Det kan vise, at et workflow har ændret sig, og om der nu findes stærkere belæg for vurderingen. Det beviser derimod ikke alene, at en bestemt rettelse har forbedret agentens præstation i ethvert projekt eller på enhver vært. Qoders materiale fremhæver observerede beviser og eksplicitte begrænsninger frem for at behandle ændrede scorer som kausalt bevis. 46

Hvad siger den omtalte gennemgang af 30 GitHub-projekter?

Omtalen ved lanceringen beskrev en første øvelse med 30 virkelige GitHub-projekter. 5 Det bør læses som en udforskende anvendelse af rammen – ikke som et kontrolleret bevis for, at Better Harness forbedrer alle kodeagenter eller alle repositories.

Den primære dokumentation understøtter værktøjets evidensmodel, struktur for findings og løkken med udbedring og ny måling. Men de foreliggende kilder giver ikke tilstrækkelige primære oplysninger til selvstændigt at vurdere udvælgelsen af de 30 projekter, scoringsmetoden eller samlede resultater. 14

Et forsøg på kvalitetssikring af AI-assisteret udvikling

Qoders bredere ambition er at gøre Harness Engineering til en slags kvalitetsinfrastruktur for AI-assisteret softwareudvikling: et fælles sprog for workflow-kontroller, synlige beviser, sammenlignelige leveringsdimensioner og gentagelige forbedringsforløb. 12

Better Harness er et konkret bud på den idé. Det giver teams en metode til at undersøge betingelserne omkring agentarbejde på tværs af understøttede værter, diskutere belæg frem for mavefornemmelser og afprøve, om en workflow-rettelse holder ved næste kørsel.

Værdien er ikke en garanti for bedre resultater efter enhver ændring. Værdien er en mere disciplineret måde at gøre agent-workflows gennemskuelige, gennemgåelige og efterprøvelige på. 46