🤖 AI

BUILD-AND-FIND: An Effort-Aware Protocol for Evaluating Agent-Managed Codebases

Dit artikel introduceert BUILD-AND-FIND, een evaluatieprotocol dat rekening houdt met de inspanning en de kwaliteit van door agenten gegenereerde codebases beoordeelt door niet alleen hun functionele correctheid te meten, maar ook de nauwkeurigheid en het inspectie-vereiste voor downstream-agenten om het oorspronkelijke ontwerpintent en de specificaties te herstellen.

Oorspronkelijke auteurs: Jhen-Ke Lin

Gepubliceerd 2026-05-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jhen-Ke Lin

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Grote Idee: Het Gaat Niet Alleen om het Antwoord, Maar om de Notitie

Stel je voor dat je een chef (een AI-agent) huurt om een complexe maaltijd te bereiden op basis van een geheim recept dat je hen hebt gegeven.

Oude Manier: Je proeft het eten. Als het lekker smaakt, krijgt de chef een goedkeuring.
Nieuw Probleem: Wat als de chef een heerlijk gerecht bereidt, maar de geheimzinnige ingrediënten verbergt in een afgesloten doos, het recept in onzichtbare inkt schrijft of de keuken in de war achterlaat? Later moet een andere chef (een andere AI) binnenkomen, het eten proeven en uitzoeken hoe het is gemaakt, zodat ze een verbrande rand kunnen repareren of meer zout kunnen toevoegen. Als de eerste chef geen duidelijke aanwijzingen heeft achtergelaten, kan de tweede chef falen, zelfs als het eten heerlijk smaakte.

Dit paper introduceert een nieuwe manier om AI-programmeurs te testen, genaamd BUILD-AND-FIND. In plaats van alleen te controleren of de code "werkt" (lekker smaakt), wordt er gecontroleerd of de code makkelijk te lezen en te begrijpen is voor de volgende persoon (of AI) die er mee moet werken.

De Twee Rollen: De Bouwer en De Zoeker

De onderzoekers hebben een spel opgezet met twee verschillende rollen:

De Bouwer (De Chef):
- Zij krijgen een verborgen "specificatie" (het geheim recept).
- Hun taak is om een compleet softwareproject (de keuken en de maaltijd) te bouwen op basis van die instructies.
- Zij weten niet dat iemand anders direct naar hun werk zal kijken; ze moeten het gewoon laten werken.
De Zoeker (De Inspecteur):
- Zij krijgen alleen de afgewerkte code (de keuken en de maaltijd). Zij mogen het originele geheim recept niet zien.
- Zij krijgen een lijst met meerkeuzevragen over de ontwerptaken (bijvoorbeeld: "Waarom koos de chef voor dit specifieke type oven?" of "Waar is het zout bewaard?").
- Hun taak is om door de code te kijken, het bewijs te vinden en de vragen correct te beantwoorden.

Het Scorebord: Nauwkeurigheid versus Inspanning

Het paper meet twee belangrijke dingen:

Kregen ze het goed? (Nauwkeurigheid)
- Kan de Zoeker het juiste antwoord uitzoeken door alleen naar de code te kijken?
- Analogie: Lukt het de Inspecteur om het verborgen kruidenpotje te vinden?
Hoe hard moesten ze zoeken? (Inspectie-inspanning)
- Dit is de grote innovatie van het paper. Als twee Bouwers allebei code maken waarmee de Zoeker het juiste antwoord kan krijgen, welke code was dan makkelijker uit te zoeken?
- De onderzoekers meten "inspanning" door te tellen hoeveel bytes code de Zoeker moest lezen of doorzoeken.
- Analogie: Als Chef A het zoutpotje op het aanrecht laat staan, en Chef B het verbergt in een afgesloten kluis die een complexe code vereist om te openen, hebben beide chefs eetbaar eten gemaakt. Maar Chef A heeft het makkelijker gemaakt voor de volgende persoon om mee te werken. Het paper beloont de chef die het "zout" op het aanrecht laat staan.

Waarom Dit Belangrijk Is

Het paper betoogt dat AI-agenten in de toekomst in teams zullen werken. Eén AI schrijft een programma, en een andere AI moet het later repareren of updaten.

Als de eerste AI code schrijft die "correct" is maar rommelig of verwarrend, zal de tweede AI moeite hebben.
BUILD-AND-FIND bewijst dat we kunnen meten hoe "leesbaar" of "communicatief" de code van een AI is, los van of de code daadwerkelijk draait.

De Resultaten (Wat Ze Vonden)

De onderzoekers testten dit met verschillende krachtige AI-modellen (zoals GPT-5, Claude Opus en anderen) op twee soorten taken: het bouwen van een mini-database en het bouwen van een kleine webserver.

Het "Hoge Prioriteit"-Probleem: De vragen die ze stelden, waren dingen die ervaren ingenieurs meestal uit het hoofd weten (zoals "databases slaan meestal logs op voordat ze schrijven"). Omdat de AI's slim zijn, konden ze de antwoorden correct raden door alleen hun algemene kennis te gebruiken, zelfs zonder de code te lezen.
De Oplossing: Omdat iedereen de antwoorden goed had, konden de onderzoekers niet alleen "juiste antwoorden" tellen. In plaats daarvan keken ze naar hoeveel lezen de AI's moesten doen.
- Sommige AI-modellen schreven code waarbij de antwoorden voor de hand lagen en makkelijk te vinden waren (lage inspanning).
- Anderen schreven code waarbij de antwoorden diep in de bestanden begraven lagen, waardoor de Zoeker veel meer moest lezen om ze te vinden (hoge inspanning).
De Winnaar: De modellen die code produceerden waarbij de minste hoeveelheid lezen nodig was om de antwoorden te vinden, werden beschouwd als de besten in het "communiceren" van hun ontwerptaken.

Het Veiligheidsnet (Controles)

Om ervoor te zorgen dat de AI's niet gewoon bedrogen of gokten, voegden de onderzoekers veiligheidscontroles toe:

Alleen-Vragen-test: Ze stelden de Zoeker de vragen zonder hen enige code te tonen. Als de AI het hier goed had, was het gewoon gokken op basis van algemene kennis.
Alleen-Specificatie-test: Ze toonden de Zoeker het geheim recept maar geen code. Dit bewees dat het recept duidelijk was.
De "Poort": De onderzoekers telden alleen de "inspanning"-score als de Zoeker het antwoord daadwerkelijk goed had. Als de Zoeker het antwoord helemaal niet kon vinden, werd de code beschouwd als een mislukking, ongeacht hoe weinig ze moesten lezen.

Samenvatting

BUILD-AND-FIND is een nieuwe test voor AI-programmeurs. Het vraagt: "Als je deze code schrijft, zal een andere AI dan makkelijk kunnen begrijpen waarom je de keuzes hebt gemaakt die je hebt gemaakt?"

Het gaat verder dan de vraag "Werkt de code?" en vraagt "Is de code een goed communicatiemiddel voor de toekomst?" De beste AI is niet alleen degene die het juiste ding bouwt; het is degene die het ding bouwt op een manier die het voor de volgende persoon makkelijk maakt om het op te pakken en verder te werken.

Technische Samenvatting: BUILD-AND-FIND

Probleemstelling

Huidige benchmarks voor codeeragenten evalueren voornamelijk functionele correctheid (bijvoorbeeld het doorlopen van unit-tests). Naarmate agenten echter overstappen van functiesynthese naar engineering op repository-niveau, fungeren gegenereerde codebases steeds vaker als intermediaire artefacten: één agent schrijft een repository, en daaropvolgende agenten moeten deze inspecteren, auditeren of uitbreiden. In deze context is een repository niet louter een antwoord op een taak, maar een communicatie-artefact.

Het artikel identificeert een gat: een repository kan zichtbare functionele tests doorstaan, maar faalt erin om de ontwerprichtlijnen en keuzes achter dat gedrag duidelijk bloot te leggen. Als een gegenereerde repository haar intentie verbergt, legt dit een extra inspectielast op aan downstream-agenten, zelfs als de code correct functioneert. Bestaande benchmarks meten niet of beoogde beslissingen uit het artefact zelf herleidbaar zijn voordat er enige wijziging wordt geprobeerd.

Methodologie: Het BUILD-AND-FIND-protocol

De auteurs stellen BUILD-AND-FIND voor, een protocol ontworpen om herstel op basis van artefactbewijs te evalueren. Deze aanpak scheidt het vermogen om code te bouwen van het vermogen om intentie uit die code te herstellen.

Kernrollen

Bouwer: Ontvangt een verborgen specificatie (die beoogd gedrag en ontwerprichtlijnen definieert) en genereert een zelfstandige codebase.
Zoeker: Ontvangt uitsluitend de gegenereerde codebase en een meerkeuzevragenbank die is getraceerd naar de specificatie. De verborgen specificatie blijft ontoegankelijk. De zoeker moet bestanden inspecteren, tooloproepen doen en vragen beantwoorden uitsluitend op basis van het artefact.

Evaluatielagen

Het protocol definieert drie distincte lagen van evaluatie:

Functionele Correctheid: Slaagt de code de tests? (Standaard focus van benchmarks).
Herstelbaarheid van Intentie aan Artefactzijde: Kan een downstream-agent beoogd gedrag en ontwerprichtlijnen herstellen uitsluitend uit het artefact? (De focus van BUILD-AND-FIND).
Succes van Downstream-wijziging: Kan een latere agent de repository veilig wijzigen? (Toekomstig werk).

Metrieken en Controles

Het protocol rapporteert vier kernmetrieken, met een strikte hiërarchie van interpretatie:

Herstelnauwkeurigheid: Exact-match-nauwkeurigheid op de vragenbank.
Stabiliteit/Herhaalbaarheid: Consistentie van antwoorden over herhaalde trials.
Implementatie-dekking: Het fractie van specificatieclaims die daadwerkelijk is geïmplementeerd in het artefact (geauditeerd om te waarborgen dat zoekers niet worden gestraft voor niet-geïmplementeerde 'gold claims').
Inspectie-inspanning: Gemeten in novel agent inspectie-bytes (nieuwe bytes opgehaald via tooloproepen, exclusief systeemprompts en transport-overhead).

Cruciale Beperking: Inspectie-inspanning wordt geïnterpreteerd als een proxy voor artefactleesbaarheid alleen nadat de poorten voor herstelnauwkeurigheid en stabiliteit zijn gepasseerd. Als herstel faalt, is inspanning betekenisloos.

Controles:

Alleen Vragen: Zoekers zien alleen vragen (meet generieke engineering-priors).
Alleen Specificatie: Zoekers zien de specificatie (meet de bovengrens van antwoordbaarheid).
Compile-fout: Artefacten die falen bij compilatie worden bewaard als stressdiagnostiek.
Bewijsaudit: Post-hoc controles om te verifiëren of correcte antwoorden specifiek artefactbewijs citeren (bronbestanden, configuraties) in plaats van te vertrouwen op priors.

Kernbijdragen

Evaluatiedoel: Definieert herstel op basis van artefactbewijs als een distincte laag tussen functionele correctheid en downstream-wijziging.
Bouwer-Zoeker-protocol: Een gesplitste-rollenframework waarbij bouwers verborgen specificaties coderen in code, en zoekers proberen deze te decoderen zonder de specificatie te zien.
Meetcontract: Een rigoureus rapportagestandaard die nauwkeurigheid (validiteit) scheidt van inspanning (leesbaarheid), waarbij wordt gewaarborgd dat inspanning alleen wordt geanalyseerd wanneer herstel betrouwbaar is.
Kalibratie en Release: Een uitgebreide release inclusief de harness, taken (scratch_minidb, scratch_nanoweb), gegenereerde artefacten, canonieke tabellen en bewijsaudits. Dit omvat diagnostiek voor bouwer-zoeker-affiniteit en gevoeligheid voor lage priors.

Empirische Resultaten

De studie evalueerde 12 agentconfiguraties (waaronder GPT-5.5, Opus 4.7, Sonnet 4.6 en MiMo-varianten) over twee taakfamilies.

Hoog herstelregime: In de vrijgegeven taakpakket met hoge priors ligt de herstelnauwkeurigheid dicht bij verzadiging (bijvoorbeeld ~98,9% voor artefact-geconditioneerde runs versus 94,5% voor alleen-vragen). Omdat de nauwkeurigheid hoog is, fungeert deze voornamelijk als een poort in plaats van een discriminerend signaal.
Inspectie-inspanning als discriminator: Zodra de herstelpoorten zijn gepasseerd, wordt conditionele inspectie-inspanning de primaire metriek voor het vergelijken van artefactleesbaarheid.
- GPT-5.5 toonde de laagste inspectie-inspanning (hoge leesbaarheid), met een relatieve inspanningsscore ( $R_b$ ) van 1,033 in het paneel met hoge inspanning.
- MiMo-varianten vereisten over het algemeen hogere inspectie-inspanning.
- Claude Sonnet 4.6 en Opus 4.7 vertoonden gemiddelde inspanningsniveaus, met enige variatie op basis van instellingen voor redeneerinspanning (hoog versus laag).
Affiniteit: De studie vond dat leesbaarheid lezer-afhankelijk kan zijn. Bouwer-zoekerparen uit dezelfde familie (bijvoorbeeld OpenAI-bouwer + OpenAI-zoeker) vertoonden positieve affiniteitsresiduen, wat suggereert dat ze intentie gemakkelijker herstellen dan paren uit verschillende families.
Bewijsaudit: In een steekproef van 72 correcte antwoorden werden 65 "ondersteund" door aangehaald artefactbewijs (voornamelijk bronbestanden), wat bevestigt dat hoge nauwkeurigheid in deze opstelling over het algemeen correleert met redenering gebaseerd op het artefact.

Betekenis en Claims

Het artikel claimt dat BUILD-AND-FIND een noodzakelijk evaluatiecontract vestigt voor door agenten beheerde codebases. De betekenis hiervan ligt in:

Verschuiving van de Focus: Van "werkt het?" naar "is het begrijpelijk voor een andere agent?".
Proxy voor Leesbaarheid: Inspectie-inspanning behandelen als een meetbare proxy voor hoe goed een artefact ontwerprichtlijnen communiceert, mits herstel stabiel is.
Scheiding van Belangen: Implementatievermogen expliciet ontkoppelen van het vermogen om intentie te herstellen, waardoor een genuanceerdere analyse van agentprestaties mogelijk wordt.
Auditbaar Framework: Het bieden van een reproduceerbare, audit-klaar infrastructuur die generieke priors scheidt van herstel op basis van artefact, waardoor wordt voorkomen dat benchmarks worden opgelost door uitsluitend memorisatie of generieke engineeringkennis.

De auteurs blijven bescheiden en merken op dat de huidige claims beperkt zijn tot het vrijgegeven paneel en de taakfamilies. Ze benadrukken dat de benchmark niet runtime-correctheid, beveiliging of menselijke onderhoudbaarheid meet, maar wel het specifieke vermogen van agenten om gegenereerde repositories te gebruiken als extern geheugen en communicatiemedium.