Je hebt geen idee hoe goed je AI-developer is. En dat is nu een probleem.

Ik heb de afgelopen maanden tientallen coding agents getest. Claude Code, OpenHands, Codex CLI, Gemini CLI, OpenClaw — je kent ze. En elke keer stuit ik op dezelfde vraag: hoe weet ik of die agent écht werkt?

Niet "mooi redeneren." Niet "indrukwekkende chat-output." Maar aantoonbaar werkende softwarewijzigingen. Verifieerbaar. Herhaalbaar. Meetbaar.

Vorige week kreeg ik die vraag eindelijk een antwoord. Hugging Face lanceerde Repo2RLEnv — een tool die van élke GitHub-repository een verifieerbare RL-trainingsomgeving maakt. Het mijnt echte PR's, commits en CVE-fixes, synthetiseert daar taken uit, en scoort agents automatisch. Geen menselijke grading. Geen "vind je dit antwoord goed?"-vibes. Gewoon: slaagt de test of niet?

Wat het doet — en wat het níet is

Repo2RLEnv is géén coding agent. Het is een benchmark factory. Je voert een repo in, kiest een pipeline, en de tool genereert taken die een agent moet oplossen. De output is Harbor-formaat — een standaard die 25+ agent harnesses ondersteunt, waaronder Claude Code, OpenHands, Codex CLI en Gemini CLI.

Eén command en je hebt een dataset:

repo2rlenv generate --repo pallets/click --pipeline pr_runtime \
  --pipeline-opt limit=10 --llm anthropic/claude-sonnet-4-6 --out ./env-click

Daarna draai je een agent los op die taken, en in /logs/verifier/reward.json staat precies hoe goed hij was. Geen meningen. Geen vibes. Gewoon data.

De architectuur is helder: GitHub als bron, LiteLLM voor modelaanroepen, Docker/Harbor voor runtime-isolatie, en Hugging Face Hub voor distributie. De echte innovatie zit in de bootstrap-fase: een LLM-agent itereert shell-commands in een verse container tot de repo buildt én z'n testsuite collect. Die image wordt gecached per content-hash — de dure stap draai je maar één keer.

Twee stabiele pipelines, zes experimentele

Van de acht pipelines zijn er twee stabiel genoeg voor serieus werk:

| Pipeline | Wat het doet | Verificatie | |----------|-------------|-------------| | pr_diff | Mijnt gemergede PR-diffs → text-only taken | Diff-similarity + optioneel LLM-judge | | pr_runtime | Mijnt PR's en draait de echte testsuite in Docker | Tests die de PR moest fixen gaan van fail → pass; bestaande tests blijven groen |

pr_runtime is de sterkste: het draait de echte testsuite van de repo in een Docker-sandbox. Een agent moet code schrijven die de failing tests laat slagen terwijl bestaande tests niet breken. Dat is meetbaar, niet-gameable (binnen redelijke grenzen), en sluit direct aan op hoe echte software-engineering werkt.

Daarnaast zijn er zes experimentele pipelines — commit_runtime, cve_patches, mutation_bugs, code_instruct, equivalence_tests, refactor_synthesis. Die zijn interessant voor R&D, maar de README waarschuwt expliciet dat interfaces en outputkwaliteit nog evolueren. Voor governance-metrics: handen af.

Waarom dit er nú toe doet

We zitten in een rare fase met agentic coding. Iedereen dénkt dat Claude Code of Codex "goed" is — maar op basis waarvan? Een demo op een zondagmiddag? Een PR die toevallig werkte? Dat is geen evaluatie. Dat is anekdotisch bewijs met een CLI eromheen.

Repo2RLEnv geeft je drie dingen die nu bijna niemand heeft:

1. Een benchmark op je eigen type code. Niet SWE-bench of HumanEval — taken uit repo's die lijken op wat jij bouwt. Python CLI-tooling, FastAPI-securitywerk, policy-as-code, noem maar op. De benchmark past zich aan jouw domein aan, niet andersom.

2. Een model placement benchmark. Je kunt Claude Sonnet, Claude Opus, GPT, Gemini, Qwen-Coder, DeepSeek en je lokale modellen tegen dezelfde taken aan gooien. Welke agent haalt de hoogste reward? Welke kost het minst per opgeloste taak? Welke faalt op een manier die je niet zag aankomen? Eindelijk outcome-based modelvergelijking in plaats van "deze voelt sneller."

3. Een governance evidence trail. Elke gegenereerde dataset bevat provenance: pipeline, base commit, PR URL, content hash, reward types. Dat is nog geen ISO 27001-dossier, maar het is een fundering die je kunt uitbouwen tot een auditeerbare agent-evaluatie.

De realiteit: Pre-Alpha, en dat mag je letterlijk nemen

De README zegt v0.8.3. De pyproject.toml classificeert het project als "Development Status :: 2 - Pre-Alpha". 51 commits, solo-dev (adithya-s-k van Hugging Face). Apache 2.0, dus geen licentie-gedoe — maar de volwassenheid is wat het is.

Vijf risico's die je moet kennen voor je dit in een serieuze omgeving aanraakt:

Sandbox supply chain. De bootstrap-documentatie zegt letterlijk: "een LLM-agent itereert shell-commands in een container tot de build en tests slagen." Een LLM schrijft dus shell-commands die in Docker worden uitgevoerd op code uit willekeurige GitHub-repo's. Dat is krachtig — en je moet het behandelen als untrusted code execution. Geen host Docker socket met secrets. Ephemeral containers, disposable VMs, read-only tokens.

LLM-as-judge in pr_diff. De pr_diff pipeline gebruikt Claude Haiku om semantische correctheid te beoordelen. Dat is een model dat een ander model beoordeelt. Voor governance is dat een aanvullend signaal, nooit primair bewijs. pr_runtime is hier beter — die draait echte tests.

LLM-cost en nondeterminisme. Bootstrap kan itereren, fallback gebruiken, en per pipeline verschillend LLM's aanroepen. Er is een cost guardrail van $5 per bootstrap run, maar complexe repo's kunnen daar doorheen schieten. Reproduceerbaarheid vereist dat je álles pint: repo refs, package versions, base images, modelversies.

CVE-pipeline als wapen. cve_patches genereert taken van publieke CVEs — inclusief exploit-beschrijvingen. Wie die dataset pulled, heeft kwetsbare code én exploit in handen. Air-gapped deployment, nooit pushen naar publieke Hub, en expliciete dataclassificatie zijn harde eisen.

Geen SECURITY.md. Ik vind dit opvallend voor een tool die Docker-containers bouwt uit willekeurige repos en LLM-judges in reward-signalen injecteert. Geen threat model, geen responsible disclosure policy. Bij een volwassen project een red flag; bij Pre-Alpha een signaal dat je zelf moet doen wat de auteurs nog niet hebben gedaan.

Mijn scores:

Strategische relevantie: 9/10 — past perfect bij evidence-based agentic SDLC. Technische innovatie: 8/10 — benchmark factory uit echte repo's is sterk. Volwassenheid: 4/10 — Pre-Alpha, snel bewegend, API's kunnen breken. Productieklaarheid: 3/10 — gebruik dit niet als enterprise control-plane. Lab/pilotwaarde: 9/10 — direct bruikbaar voor een benchmarklab.

Wat je er wél mee kunt

Laat ik concreet zijn. Dit zijn de use cases waar ik direct waarde zie:

Agentic SDLC Benchmark Lab. Je kunt klanten niet vertellen dat agentic coding waarde heeft — je moet het laten zien. "Op deze klasse repositories haalt agent A 62% test_execution reward, agent B 41%, lokaal model C 28% tegen 12% van de kosten." Dat is een gesprek. Dat verkoopt.

Secure coding agent evaluation. Gebruik cve_patches en mutation_bugs om te testen of agents kwetsbaarheden kunnen repareren zonder regressie. Experimenteel, dus positioneer het als lab-signaal — niet als auditbewijs.

AI workload placement. Dezelfde dataset, meerdere modellen. Claude, Gemini, OpenAI, Qwen-Coder, GLM, lokale modellen via LiteLLM. Meet reward, kosten, latency, retry-loops. Eindelijk een antwoord op "wanneer gebruik ik cloud, wanneer lokaal?"

Governance evidence pack. Maak per experiment een dossier: repo ref, pipeline, taken, model, harness, reward, failed tasks, logs, container digest, SBOM. Dit past in ISO 27001, BIO2, NIST CSF, en AI-governance frameworks.

"Van Data naar Doen." Geen PowerPoint over AI-productiviteit. Een werkende meetstraat die laat zien waar agents échte deliverywaarde leveren.

De vijf-fase pilot

Wil je dit serieus inzetten, dan is dit mijn aanbevolen pad:

Fase 1 — Local-only baseline (week 1). Kies 2–3 publieke repo's in je domein. Python CLI-tools, FastAPI/security, een Node/TS repo. Draai pr_diff en daarna pr_runtime met limit=10. Publiek, niets pushen.

Fase 2 — Harness benchmark (week 2). Zelfde taken, vier agents: Claude Code, OpenHands, Codex CLI, een lokaal model via LiteLLM. Meet reward, kosten, latency, failure modes.

Fase 3 — Security benchmark (week 3). cve_patches en mutation_bugs op publieke repo's. Label output expliciet als research-grade.

Fase 4 — Governance hardening (week 3–4). SBOM, image signing (Cosign), isolated Docker runner, egress policy, no-secret mounts, immutable logs, dataset classification.

Fase 5 — Propositie (doorlopend). Bouw een "Agentic SDLC Evidence Dashboard." Executive view: kwaliteit, kosten, risico, governance readiness, model placement advies.

De kernboodschap

Repo2RLEnv is niet "nog een coding-agent tool." Het is de ontbrekende meetlaag tussen AI-demo's en bestuurbare enterprise-adoptie. Het maakt agentic coding meetbaar.

Het is Pre-Alpha. Het is niet productieklaar. De sandbox is een supply-chain risico. De LLM-judge is een black box.

Maar het antwoord op "hoe bewijs ik dat mijn AI-developer werkt?" ligt niet in betere prompts. Het ligt in een verifieerbare meetstraat die per taak, per model, per harness laat zien wat er écht gebeurt.

En dat is precies wat Repo2RLEnv belooft.

---

Dit artikel is onderdeel van DjimIT's doorlopende analyse van agentic SDLC-tooling. Lees ook: wat AI-agents in 2026 kunnen, de agentic dreiging, en governance voor AI-gegenereerde code.