Better Harness granskar arbetsflödet runt kodagenter – inte bara koden

Qoders Better Harness är ett projekt med öppen källkod för att granska och förbättra arbetsflödet runt en kodagent. I stället för att bedöma ett enskilt modellsvar eller en kodändring isolerat analyserar det projektinstruktioner, styrning, valideringsvägar, agentkonfiguration och – när det finns stöd – spår från verkliga sessioner. Målet är att hitta luckor i arbetsflödet, föreslå en tydligt avgränsad åtgärd och sedan göra resultatet möjligt att kontrollera vid en senare körning. 124

Enligt samtida rapportering öppnade Qoder projektet på GitHub den 28 juli 2026. 5

Fokus ligger på agentens omgivning

En kodagent arbetar alltid i en större miljö: instruktioner i kodbasen, specifikationer, verktyg, behörigheter, skript, tester, granskningskrav, releasekontroller och överlämningar till människor. Qoder kallar den samlade miljön för en harness. Den kan omfatta bland annat instruktioner i kodförrådet, regler, färdigheter, hooks, plugin-program, anslutningar, skript, testkommandon, releasekontroller och manuella granskningssteg. 2

Skillnaden är viktig. En kapabel modell kan ändå ge opålitliga resultat om arbetsflödet är otydligt eller dåligt instrumenterat. Det kan finnas ett testkommando utan en tydlig regel för när agenten ska köra det. Det kan finnas en regel-fil som agenten aldrig använder. Eller så saknas ett beständigt sätt att ta vara på lärdomar från misslyckade uppgifter. Better Harness är tänkt att synliggöra sådana operativa svagheter, snarare än att tolka förekomsten av en konfigurationsfil som bevis för att processen fungerar. 145

Tre lager: arbetssätt, utvärdering och körbarhet

Better Harness beskrivs som ett ramverk i tre lager som knyter ihop ingenjörspraxis, en utvärderingsmodell och en körbar implementation. 5

1. Praktiker för Harness Engineering

Det första lagret omfattar de praktiska mekanismer som formar agentens arbete: sessioner och CLI-mönster, observerbarhet, regler, färdigheter, MCP-konfiguration, minne, hooks och automatisering. 5

I praktiken handlar det om frågor som:

• Får agenten tydliga mål, begränsningar och tillräcklig kontext från kodbasen?
• Är dess körvägar och behörigheter lämpligt styrda?
• Är tester, kontroller och granskningar kopplade till arbetet agenten utför?
• Kan användbara lärdomar bli underhållna tillgångar i projektet, i stället för att försvinna när en session avslutas?

Better Harness börjar med att kartlägga den befintliga miljön: mål, kontext, ingångar för exekvering, återkopplingsslingor, leveransmekanismer och hur lärdomar fångas upp. 1

2. Utvärdering av Agent Work Loop

Det andra lagret omvandlar praktikerna till en utvärdering av fem sammanlänkade delar av leveransen: uppgiftsförståelse, kontrollerad exekvering, validering av ändringar, tillförlitlig leverans och fångst av lärande. 14

Det flyttar frågan från ”genererade agenten rimlig kod?” till en mer användbar driftsfråga: Kan arbetsflödet från början till slut återkommande skapa ändringar som är begripliga, kontrollerade, validerade, levererbara och informerade av tidigare arbete?

Modellen ska hitta avbrott i den loopen – till exempel en saknad mekanism, en frånkopplad integration, ett steg som aldrig faktiskt kördes eller för svaga belägg för resultatet. 1

3. Körbar implementation

Det tredje lagret gör praktikerna och utvärderingsmodellen användbara i riktiga projekt, i stället för att lämna dem som vägledning på papperet. Better Harness körs genom en kodagent, samlar projekt- och sessionsbevis där det stöds och tar fram prioriterade nästa steg som går att verifiera. 4

Qoders aktuella projektmaterial uppger stöd för tio värdadaptrar. Vid lanseringen nämndes särskilt Claude Code, Codex, Qoder och Cursor bland de stödda miljöerna. 56

Adapterstödet kan ändras över tid, så integration med en viss värdmiljö bör kontrolleras mot projektets aktuella adapterdokumentation. De tillhandahållna källorna styrker exempelvis inte stöd för OpenClaw.

Tre sorters bevis ska skilja avsikt från verklighet

En viktig del av arbetssättet är att insamlingen av underlag hålls isär från den slutliga bedömningen. Qoder uppger att huvudflödet först samlar rådata och därefter skickar den till tre oberoende, skrivskyddade underagenter innan resultatet vägs samman. 1

De tre perspektiven är:

• Project Harness: kodförrådets tekniska grund, till exempel instruktioner, skript, kontroller och leveransstyrning.
• Agent Customization: agentspecifika regler, färdigheter, hooks och annan konfiguration.
• Session Evidence: spår av vad agenten faktiskt gjorde under verkligt arbete, när sådant underlag finns tillgängligt.

Strukturen hjälper team att skilja en avsedd process från en observerad process. Projekt- och konfigurationsbevis kan visa att en funktion finns tillgänglig. Sessionsbevis kan däremot bidra till att visa om funktionen användes korrekt i en konkret uppgift. 14

Att något finns betyder inte att det fungerar

Ramverkets kanske mest användbara princip är att förekomsten av en artefakt inte är samma sak som bevis för effekt.

Anta att ett kodförråd har en automatiserad testsvit. Sviten visar att det finns en möjlig valideringskapacitet, men inte att en agent körde relevanta tester efter sin ändring, tolkade resultatet rätt eller använde det för att stoppa en felaktig leverans. Samma resonemang gäller regler, hooks, färdigheter och godkännandesteg. 15

Better Harness försöker därför hålla beviskedjan tydlig. Rapporterna omvandlar styrkta brister till prioriterade fynd med påverkan, förväntat resultat, avgränsad åtgärd och acceptanskriterier. Underlag som saknas förblir synligt i stället för att tyst bli en säker poäng eller slutsats. 46

Ett användbart fynd ska därmed låta ett team granska:

1. Vad som observerades i projektet, konfigurationen eller sessionsspåret.
2. Varför det spelar roll för arbetsloopen och leveransen.
3. Vilken smal åtgärd som föreslås, exempelvis en regel, färdighet, hook, ett skript, automatisering eller ett manuellt godkännande.
4. Hur åtgärden ska verifieras efter införandet.

Förbättringsloopen: granska, åtgärda, mät igen

Better Harness positioneras inte som en engångsrevision. Flödet är iterativt:

1. Kartlägg den befintliga miljön.
2. Identifiera brytpunkter i arbetsflödet och luckor i underlaget.
3. Skapa en avgränsad åtgärdsuppgift för ett styrkt fynd.
4. Validera åtgärden mot definierade acceptanskriterier.
5. Kör granskningen igen och bedöm det uppdaterade underlaget. 14

Det är grunden för verktygets anspråk på kontinuerlig förbättring. Verktyget kan visa att ett arbetsflöde har ändrats och om nytt underlag motiverar en starkare bedömning. Det bevisar däremot inte på egen hand att en viss åtgärd orsakade bättre agentprestanda i varje projekt eller värdmiljö. Qoders material betonar observerbara belägg och uttalade begränsningar, snarare än att behandla poängförändringar som kausala bevis. 46

Vad säger granskningen av 30 GitHub-projekt?

Rapporteringen vid lanseringen uppgav att ramverket användes i en inledande genomgång av 30 verkliga GitHub-projekt. 5 Det bör läsas som en utforskande tillämpning av ramverket, inte som ett kontrollerat bevis för att Better Harness förbättrar varje kodagent eller varje kodförråd.

Den primära dokumentation som finns här stöder verktygets evidensmodell, struktur för fynd och iterativa åtgärdsflöde. Men källunderlaget innehåller inte tillräckligt med primär detaljinformation för att oberoende bedöma urvalet av de 30 projekten, poängsättningsprotokollet eller samlade resultat. Den begränsningen är viktig vid jämförelser med formella riktmärken eller breda påståenden om prestanda. 14

Ett försök att göra agentutveckling mer mätbar

Qoders bredare idé är att Harness Engineering ska bli kvalitetsinfrastruktur för AI-assisterad mjukvaruutveckling: ett gemensamt språk för arbetsflödeskontroller, observerbara bevis, jämförbara leveransdimensioner och upprepningsbara förbättringscykler. 12

Better Harness är en praktisk tillämpning av den idén. Det ger team ett sätt att granska förutsättningarna runt agentarbete i stödda miljöer, diskutera belägg snarare än intryck och kontrollera om en föreslagen förbättring håller vid senare körningar. Värdet ligger inte i en garanti om att varje ändring förbättrar utfallet, utan i ett mer disciplinerat sätt att göra agentarbetsflöden granskbara, verifierbara och möjliga att motbevisa. 46