Vandaag las ik een lang stuk over Harness Engineering — tienduizenden woorden, bijna zeker door AI geschreven. Mijn eerste reactie was niet "wauw, wat een krachtig concept." Het was "hebben deze mensen enige ideeën behalve het bedenken van nieuwe termen voor oude?" Ik ben altijd al geïrriteerd geweest door dit patroon in de AI-wereld — de constante heruitvinding van bestaande concepten. Van prompt engineering tot context engineering, nu naar harness engineering. Elke paar maanden bedenkt iemand een nieuwe term, schrijft een essay van 10.000 woorden, strooit er een paar case studies van grote bedrijven doorheen, en de hele gemeenschap begint te buzzzen. Maar als je daadwerkelijk naar de inhoud kijkt, is het elke keer hetzelfde: Ontwerp de omgeving waarin je model draait — welke informatie het ontvangt, welke tools het kan gebruiken, hoe fouten worden onderschept, hoe geheugen wordt beheerd over sessies. Dit bestaat al sinds de dag dat ChatGPT werd gelanceerd. Het wordt geen nieuwe discipline alleen omdat iemand — om welke reden dan ook — besloot het een nieuwe naam te geven. Dat gezegd hebbende, klachten terzijde, de onderzoeken en case studies die in het artikel worden geciteerd hebben wel waarde — vooral omdat ze sterk overlappen met wat ik heb gebouwd met how-to-sglang. Dus laat me deze gelegenheid aangrijpen om te praten over de fouten die ik daadwerkelijk heb gemaakt. Eerst wat achtergrond. De meest voorkomende verzoeken in de SGLang-gemeenschap zijn Hoe-te-vragen — hoe DeepSeek-V3 op 8 GPU's te implementeren, wat te doen als de gateway het werkadres niet kan bereiken, of het gat tussen GLM-5 INT4 en officiële FP8 significant is. Deze vragen bestrijken een extreem breed technisch terrein, en naarmate de gemeenschap sneller groeit, kunnen we steeds minder bijhouden met antwoorden. Dus begon ik een multi-agent systeem te bouwen om ze automatisch te beantwoorden. Het eerste idee was, natuurlijk, het meest naïeve — bouw een enkele alwetende Agent, stop alle documentatie, code en kookboeken van SGLang erin, en laat het alles beantwoorden. Dat werkte niet. Je hebt geen harness engineering theorie nodig om uit te leggen waarom — het contextvenster is geen RAM. Hoe meer je erin stopt, hoe meer de aandacht van het model verspreid raakt en hoe slechter de antwoorden worden. Een Agent die probeert om tegelijkertijd kwantisatie, PD-disaggregatie, diffusie-servering en hardwarecompatibiliteit te begrijpen, eindigt met het niet diep begrijpen van geen van allen. Het ontwerp waar we uiteindelijk op uitkwamen is een gelaagde sub-domein expertarchitectuur. De documentatie van SGLang heeft al natuurlijke functionele grenzen — geavanceerde functies, platforms, ondersteunde modellen — met kookboeken georganiseerd per model. We hebben elk sub-domein omgevormd tot een onafhankelijke expertagent, met een Expert Debating Manager die verantwoordelijk is voor het ontvangen van vragen, deze opsplitst in sub-vragen, het Expert Routing Table raadpleegt om de juiste agents te activeren, parallel oplost en vervolgens antwoorden synthetiseert. Als ik terugkijk, komt dit ontwerp bijna perfect overeen met de patronen die de harness engineering gemeenschap aanbeveelt. Maar toen ik het bouwde, had ik geen idee dat deze patronen namen hadden. En dat had ik niet nodig. 1. Progressieve onthulling — we dumpen niet alle documentatie in een enkele agent. Elke domeinexpert laadt alleen zijn eigen domeinkennis, en de Manager beslist wie te activeren op basis van het type vraag. Mijn onderbuikgevoel is dat dit ontwerp veel meer verbetering heeft opgeleverd dan het inruilen van een sterker model ooit deed. Je hoeft niet te weten dat dit "progressieve onthulling" wordt genoemd om deze beslissing te nemen. Je moet gewoon de "stop alles erin" aanpak eens geprobeerd hebben en het zien falen. 2. Repository als bron van waarheid — de hele workflow leeft in de how-to-sglang repo. Alle expertagents putten hun kennis uit markdown-bestanden binnen de repo, zonder afhankelijkheid van externe documenten of mondelinge overeenkomsten. In het begin hadden we de drang om één enorme sglang-maintain.md te schrijven die alles dekte. We leerden al snel dat dat niet werkt. Het Codex-team van OpenAI maakte dezelfde fout — ze probeerden een enkele te grote AGENTS.md en zagen het op voorspelbare manieren verrotten. Je hoeft hun blog niet te hebben gelezen om zelf op deze mijn te stappen. Het is het klassieke software-engineeringprobleem van "monolithische documentatie veroudert altijd," behalve in een agentcontext zijn de gevolgen erger — verouderde documentatie wordt niet alleen niet gelezen, het misleidt de agent actief. 3. Gestructureerde routering — de Expert Routing Table koppelt expliciet vraagtypes aan agents. Een vraag over GLM-5 INT4 activeert zowel de Cookbook Domein Expert als de Quantization Domein Expert tegelijkertijd. De Manager raadt niet; het volgt een gestructureerde index. De harness engineering gemeenschap noemt dit "gemechaniseerde beperkingen." Ik noem het normale engineering. Ik zeg niet dat de ideeën achter harness engineering slecht zijn. Het geciteerde onderzoek is solide, het ACI-concept van SWE-agent is oprecht de moeite waard om te weten, en de dual-agent architectuur van Anthropic (initializer agent + coding agent) is waardevol referentiemateriaal voor iedereen die lange termijn taken uitvoert. Wat ik vermoeiend vind, is het constante bedenken van nieuwe termen — het verpakken van gevestigde engineering gezond verstand als een nieuwe discipline, en dan angst creëren rond "je loopt achter als je dit woord niet kent." Prompt engineering, context engineering, harness engineering — het zijn verschillende facetten van hetzelfde. Volgende maand zal iemand waarschijnlijk scaffold engineering of orchestration engineering bedenken, weer een lang essay schrijven waarin hetzelfde SWE-agent paper wordt geciteerd, en de gemeenschap zal weer een nieuwe cyclus van amplificatie starten. Wat ik daadwerkelijk heb geleerd van how-to-sglang kan zonder enige nieuwe vocabulaire worden gesteld:...