Better Harness: zo wil Qoder AI-codeerworkflows meetbaar verbeteren

Better Harness is een opensourceproject van Qoder dat de workflow rond een programmeeragent doorlicht en helpt verbeteren. Het beoordeelt dus niet alleen één modelantwoord of één codewijziging, maar ook de projectinstructies, controles, validatiestappen, agentconfiguratie en – waar beschikbaar – sporen van echte werksessies. Het doel: zwakke plekken aanwijzen, een afgebakende reparatie voorstellen en die bij een volgende controle verifieerbaar maken. 124

Volgens berichtgeving maakte Qoder de GitHub-openstelling op 28 juli 2026 bekend. 5

Niet alleen de agent beoordelen, maar de omgeving eromheen

Een programmeeragent werkt nooit los van zijn omgeving. Die omgeving omvat bijvoorbeeld repositoryrichtlijnen, specificaties, tools, toegangsrechten, scripts, tests, reviewvereisten, releasechecks en overdrachtsmomenten met mensen. Qoder noemt die totale omgeving een harness. In de documentatie vallen daar onder meer instructies, regels, skills, hooks, plugins, koppelingen, scripts, testcommando’s, releasecontroles en menselijke reviewstappen onder. 2

Dat onderscheid is belangrijk. Zelfs een capabel model levert minder betrouwbare resultaten als de werkwijze onduidelijk is of nauwelijks meetbaar wordt gemaakt. Een project kan wel een testcommando hebben, zonder dat duidelijk is wanneer een agent het moet uitvoeren. Of er is een regelbestand dat de agent in de praktijk niet gebruikt. Better Harness probeert juist zulke operationele gaten zichtbaar te maken. 145

Drie lagen: praktijk, beoordeling en uitvoering

Qoder presenteert Better Harness als een raamwerk met drie lagen, waarin engineeringpraktijken, een beoordelingsmodel en een uitvoerbare implementatie samenkomen. 5

1. Harness Engineering-praktijken

De eerste laag gaat over de concrete middelen die het werk van een agent sturen: sessie- en CLI-patronen, observeerbaarheid, regels, skills, MCP-configuratie, geheugen, hooks en automatisering. 5

Praktisch vertaalt dat zich in vragen als:

• Krijgt de agent heldere doelen, beperkingen en repositorycontext?
• Zijn uitvoerpaden en rechten passend begrensd?
• Zijn tests, controles en reviews verbonden met het werk dat de agent uitvoert?
• Kunnen lessen uit een taak worden vastgelegd als onderhoudbare projectkennis, in plaats van met een sessie te verdwijnen?

Better Harness begint met een inventarisatie van de bestaande harness: doelen, context, uitvoerpunten, feedbacklussen, oplevermechanismen en het vastleggen van leerpunten. 1

2. Beoordeling van de Agent Work Loop

De tweede laag vertaalt die praktijken naar vijf samenhangende aspecten van oplevering: taakbegrip, gecontroleerde uitvoering, validatie van wijzigingen, betrouwbare oplevering en het vastleggen van leerpunten. 14

Daarmee verandert de centrale vraag van: heeft de agent aannemelijke code gegenereerd? naar: kan de volledige workflow herhaaldelijk wijzigingen opleveren die begrijpelijk, beheerst, gevalideerd, leverbaar en gebaseerd op eerdere lessen zijn?

Het model zoekt naar breekpunten in die keten, zoals een ontbrekend mechanisme, een niet-gekoppelde integratie, een stap die nooit werkelijk is uitgevoerd of onvoldoende bewijs voor het resultaat. 1

3. Uitvoerbare implementatie

De derde laag moet voorkomen dat de aanpak beperkt blijft tot documentatie en richtlijnen. Better Harness draait via een coding agent, verzamelt project- en waar mogelijk sessiebewijs, en levert geprioriteerde vervolgstappen op die te controleren zijn. 4

De huidige projectinformatie noemt ondersteuning voor tien hostadapters. In berichtgeving rond de lancering werden onder meer Claude Code, Codex, Qoder en Cursor genoemd als ondersteunde omgevingen. 56

De adapterdekking kan veranderen. Wie een specifieke integratie wil gebruiken, doet er daarom goed aan de actuele adapterdocumentatie te controleren. De aangeleverde bronnen onderbouwen bijvoorbeeld geen ondersteuning voor OpenClaw.

Drie soorten bewijs, apart verzameld

Een belangrijk onderdeel van de aanpak is dat Better Harness het verzamelen van bewijs scheidt van de eindoordeling. Volgens Qoder verzamelt de hoofdanalyse eerst ruwe gegevens en legt die vervolgens voor aan drie onafhankelijke subagenten met alleen-lezenrechten, voordat de resultaten worden samengevoegd. 1

De drie invalshoeken zijn:

• Project Harness: de technische basis van de repository, zoals instructies, scripts, controles en opleveringsmaatregelen.
• Agent Customization: agentspecifieke regels, skills, hooks en andere configuratie.
• Session Evidence: vastlegging van wat de agent tijdens echt werk daadwerkelijk heeft gedaan, wanneer dat bewijs beschikbaar is.

Zo wordt onderscheid gemaakt tussen een beoogd proces en een aantoonbaar uitgevoerd proces. Project- en configuratiebewijs laten zien dat een mogelijkheid bestaat; sessiebewijs kan aantonen of die mogelijkheid bij een echte taak passend is gebruikt. 14

Een test hebben is niet hetzelfde als hem gebruiken

Het bruikbaarste uitgangspunt van het raamwerk is dat de aanwezigheid van een artefact geen bewijs is dat het effectief werkt.

Neem een repository met geautomatiseerde tests. De aanwezigheid van die testset toont dat er in theorie een validatiemogelijkheid is. Maar het bewijst niet dat een agent na een wijziging de relevante tests heeft gedraaid, de uitslag juist heeft geïnterpreteerd of de uitkomst heeft gebruikt om een foutieve oplevering te voorkomen. Hetzelfde geldt voor regels, hooks, skills en goedkeuringspoorten. 15

Daarom probeert Better Harness de bewijsketen expliciet te houden. Rapporten zetten onderbouwde hiaten om in geprioriteerde bevindingen met een impact, verwacht resultaat, afgebakende reparatie en acceptatiecontroles. Ontbrekend bewijs blijft zichtbaar, in plaats van stilzwijgend in een zelfverzekerde score te veranderen. 46

Een team moet per bevinding kunnen nagaan:

1. Wat er is waargenomen in het project, de configuratie of het sessieverslag.
2. Waarom dit ertoe doet voor de opleveringscyclus.
3. Welke beperkte ingreep wordt voorgesteld, bijvoorbeeld een regel, skill, hook, script, automatisering of menselijke goedkeuring.
4. Hoe de ingreep kan worden geverifieerd nadat die is doorgevoerd.

Verbeteren in een herhaalbare cyclus

Better Harness is niet bedoeld als een eenmalige audit. De werkwijze is iteratief:

1. Breng de huidige harness in kaart.
2. Zoek naar breekpunten en gaten in het bewijs.
3. Maak een afgebakende reparatietaak voor een onderbouwde bevinding.
4. Valideer de reparatie aan de hand van vooraf bepaalde acceptatiecontroles.
5. Voer de review opnieuw uit en bekijk het bijgewerkte bewijs. 14

Hierop rust de claim van continue verbetering. De tool kan laten zien dat een workflow is veranderd en of nieuw bewijs een sterkere beoordeling ondersteunt. Daarmee bewijst hij op zichzelf niet dat een ingreep in elk project of elke hostomgeving betere agentprestaties veroorzaakt. Qoder benadrukt waargenomen bewijs en expliciete beperkingen, in plaats van scoreveranderingen als causaal bewijs te behandelen. 46

Hoe de beoordeling van 30 GitHub-projecten moet worden gelezen

Bij de lancering werd gemeld dat het raamwerk in een eerste oefening op 30 echte GitHub-projecten is toegepast. 5 Dat is vooral te lezen als een verkennende toepassing van de methode, niet als een gecontroleerd bewijs dat Better Harness elke programmeeragent of repository verbetert.

De beschikbare primaire documentatie onderbouwt het bewijsmiddel, de opbouw van bevindingen en de iteratieve herstelcyclus. Maar de aangeleverde bronnen bieden onvoldoende primaire details om de selectie van die 30 projecten, het scoreprotocol of de gezamenlijke uitkomsten onafhankelijk te beoordelen. Dat onderscheid is relevant bij vergelijking met formele benchmarks of brede prestatieclaims. 14

Richting meetbaardere AI-softwareontwikkeling

Qoders bredere inzet is om Harness Engineering te ontwikkelen tot kwaliteitsinfrastructuur voor AI-ondersteunde softwareontwikkeling: een gedeelde taal voor workflowcontroles, observeerbaar bewijs, vergelijkbare opleveringsaspecten en herhaalbare verbetercycli. 12

Better Harness is daarvan een praktische uitwerking. Teams kunnen er de voorwaarden rond agentwerk in ondersteunde omgevingen mee inspecteren, op basis van bewijs in plaats van indrukken discussiëren en toetsen of een voorgestelde workflowreparatie bij latere runs overeind blijft. De waarde zit niet in een garantie dat elke reparatie resultaat oplevert, maar in een gedisciplineerdere manier om agentworkflows inspecteerbaar, beoordeelbaar en weerlegbaar te maken. 46