Kuber Mehta betoogt dat het trendmatig 'humaniseren' van LLM-outputs via specifieke prompts (zoals Simplified Technical English of persona-instructies) contraproductief is. Het kernprobleem is dat deze stijlaanpassingen leiden tot lossy compression: cruciale details gaan verloren voordat de taak volledig is voltooid.
De auteur stelt dat dit vooral problematisch is bij communicatie tussen AI-agents, waarbij samenvattingen van samenvattingen ontstaan in plaats van het uitwisselen van ruwe, informatie-dense data. Bovendien maskeert vriendelijk proza vaak technische fouten of hallucinaties die anders direct zichtbaar zouden zijn.
De voorgestelde oplossing is een architectuur waarbij agents communiceren in een hoge getrouwheid (highest-fidelity), vergelijkbaar met hoe databases en compilers werken. Pas bij de uiteindelijke presentatie aan de menselijke gebruiker dient een 'renderer' de informatie te transformeren naar een gewenste, mensvriendelijke vorm.
Het 'humaniseren' van LLM-outputs is onzin
De beste graadmeter voor mij om te zien waar de cultuur en sentimenten rondom AI-tools verschuiven, zijn meestal X, virale GitHub-repositories en Hacker News.
Een trend die ik daar recentelijk veel zie, is het gebruik van specifieke instructies in 'skills' of Agents.md-bestanden, zoals "doe alsof ik ADHD heb" of het eisen dat outputs uitsluitend in ASD-STE100 Simplified Technical English worden gegeven.
Ik begrijp de aantrekkingskracht; niemand van ons houdt echt van de woordigheid en de specifieke eigenaardigheden van LLM-outputs. Maar ik geloof echt dat het proberen op te lossen door het model te 'humaniseren', de verkeerde abstractie is.
Het probleem van verliesgevende compressie
Het probleem is dat deze instructies niet worden toegepast nadat het model het werk heeft voltooid, maar onderdeel worden van het werk zelf. Als je een agent vraagt om korte zinnen te gebruiken, jargon te vermijden, je niet te overweldigen en alleen de belangrijkste details op te nemen, vraag je hem in feite om zijn output continu te comprimeren naar een formaat met een lagere bandbreedte.
Die compressie is lossy (verliesgevend).
Je merkt waarschijnlijk nooit wat er precies is weggevallen, omdat de output nog steeds prettig leest. ASD-STE is hier een uitstekend voorbeeld van, omdat het heel redelijk klinkt; het is immers ontworpen om documentatie ondubbelzinnig te maken voor mensen. Maar een agent is geen menselijke technische schrijver, en de ruwe staat is vaak de meest informatie-dense representatie die beschikbaar is. Ondertussen staan de stijlrules op dezelfde instructielijst als: "los de taak op", "gebruik tools correct", "behoud abstracties" en "maak niets kapot".
Communicatie tussen agenten
Dit wordt nog vreemder zodra agents met andere agents beginnen te communiceren. Een subagent onderzoekt een bug, zet zijn bevindingen om in een mooie, menselijk leesbare samenvatting, de hoofdagent leest die samenvatting en maakt daar vervolgens weer een nieuwe, mooie menselijk leesbare samenvatting van voor jou.
Als een subagent zes tests heeft uitgevoerd, wil ik niet lezen:
"De meeste tests zijn geslaagd, hoewel er één probleem was dat het waard is om naar te kijken."
Ik wil dit zien:
- 5/6 PASS
- FAIL:
testcacheinvalidation
- CAUSE: stale key survives restart
- REPRO:
tests/cache_test.py:184
Het maskeren van falen
Wat nog belangrijker is: humanisering maskeert falen.
Agents falen op nuttige, maar lelijke manieren: tegenstrijdig bewijs, onopgeloste vertakkingen, stack traces en onzekere aannames. Menselijke proza is extreem goed in het gladstrijken hiervan tot zinnen als:
"Er zijn hier een paar overwegingen."
Dat klinkt vriendelijker. Maar ik heb liever dat ik ontdek dat mijn agent hallucineert of tegen zijn token-window aanloopt, dan dat ik tevreden ben met zo'n vage zin.
De juiste architectuur: de grenslaag
Elk ander systeem dat we bouwen, werkt precies andersom. Databases slaan gegevens niet op in het formaat waarin een dashboard ze weergeeft; compilers maken hun intermediate representation (IR) niet prettig leesbaar; API's wisselen geen vriendelijke samenvattingen uit.
We behouden de representatie met de hoogste getrouwheid (highest-fidelity) zo lang mogelijk en transformeren deze pas op de grens waar een mens het consumeert. LLM-tooling doet dit echter steeds vaker achterstevoren.
Om duidelijk te zijn: dit is geen argument tegen toegankelijkheid of personalisatie. Als je antwoorden van drie regels wilt of Simplified Technical English, prima! Ik denk alleen dat het beter is om dit aan het einde te doen.
Laat agents gedetailleerde staten bijhouden; laat subagents schema's, diffs, exacte fouten, betrouwbaarheidsscores en herkomst uitwisselen. En pas daarna: comprimeer het voor mij.
Ik denk dat het mooiste is dat deze virale 'skills' wellicht juist wijzen naar de juiste toekomst. Gebruikers lossen dit nu op via de prompt-laag, terwijl het eigenlijk lager in de stack thuishoort.
"Praat tegen me alsof ik ADHD heb" is volkomen logisch als een renderer (weergave), maar het is veel minder logisch als een operationele instructie. De duurzame versie hiervan zijn agents wiens moedertaal een precieze, machine-gerichte staat is, waarbij de warme, beknopte menselijke versie pas aan de grens wordt gegenereerd.
De virale repositories zijn dus niet het eindstation, maar een bugrapport.
Het 'humaniseren' van LLM-outputs is onzin
De beste graadmeter voor mij om te zien waar de cultuur en sentimenten rondom AI-tools verschuiven, zijn meestal X, virale GitHub-repositories en Hacker News.
Een trend die ik daar recentelijk veel zie, is het gebruik van specifieke instructies in 'skills' of Agents.md-bestanden, zoals "doe alsof ik ADHD heb" of het eisen dat outputs uitsluitend in ASD-STE100 Simplified Technical English worden gegeven.
Ik begrijp de aantrekkingskracht; niemand van ons houdt echt van de woordigheid en de specifieke eigenaardigheden van LLM-outputs. Maar ik geloof echt dat het proberen op te lossen door het model te 'humaniseren', de verkeerde abstractie is.
Het probleem van verliesgevende compressie
Het probleem is dat deze instructies niet worden toegepast nadat het model het werk heeft voltooid, maar onderdeel worden van het werk zelf. Als je een agent vraagt om korte zinnen te gebruiken, jargon te vermijden, je niet te overweldigen en alleen de belangrijkste details op te nemen, vraag je hem in feite om zijn output continu te comprimeren naar een formaat met een lagere bandbreedte.
Die compressie is lossy (verliesgevend).
Je merkt waarschijnlijk nooit wat er precies is weggevallen, omdat de output nog steeds prettig leest. ASD-STE is hier een uitstekend voorbeeld van, omdat het heel redelijk klinkt; het is immers ontworpen om documentatie ondubbelzinnig te maken voor mensen. Maar een agent is geen menselijke technische schrijver, en de ruwe staat is vaak de meest informatie-dense representatie die beschikbaar is. Ondertussen staan de stijlrules op dezelfde instructielijst als: "los de taak op", "gebruik tools correct", "behoud abstracties" en "maak niets kapot".
Communicatie tussen agenten
Dit wordt nog vreemder zodra agents met andere agents beginnen te communiceren. Een subagent onderzoekt een bug, zet zijn bevindingen om in een mooie, menselijk leesbare samenvatting, de hoofdagent leest die samenvatting en maakt daar vervolgens weer een nieuwe, mooie menselijk leesbare samenvatting van voor jou.
Als een subagent zes tests heeft uitgevoerd, wil ik niet lezen:
"De meeste tests zijn geslaagd, hoewel er één probleem was dat het waard is om naar te kijken."
Ik wil dit zien:
- 5/6 PASS
- FAIL:
testcacheinvalidation
- CAUSE: stale key survives restart
- REPRO:
tests/cache_test.py:184
Het maskeren van falen
Wat nog belangrijker is: humanisering maskeert falen.
Agents falen op nuttige, maar lelijke manieren: tegenstrijdig bewijs, onopgeloste vertakkingen, stack traces en onzekere aannames. Menselijke proza is extreem goed in het gladstrijken hiervan tot zinnen als:
"Er zijn hier een paar overwegingen."
Dat klinkt vriendelijker. Maar ik heb liever dat ik ontdek dat mijn agent hallucineert of tegen zijn token-window aanloopt, dan dat ik tevreden ben met zo'n vage zin.
De juiste architectuur: de grenslaag
Elk ander systeem dat we bouwen, werkt precies andersom. Databases slaan gegevens niet op in het formaat waarin een dashboard ze weergeeft; compilers maken hun intermediate representation (IR) niet prettig leesbaar; API's wisselen geen vriendelijke samenvattingen uit.
We behouden de representatie met de hoogste getrouwheid (highest-fidelity) zo lang mogelijk en transformeren deze pas op de grens waar een mens het consumeert. LLM-tooling doet dit echter steeds vaker achterstevoren.
Om duidelijk te zijn: dit is geen argument tegen toegankelijkheid of personalisatie. Als je antwoorden van drie regels wilt of Simplified Technical English, prima! Ik denk alleen dat het beter is om dit aan het einde te doen.
Laat agents gedetailleerde staten bijhouden; laat subagents schema's, diffs, exacte fouten, betrouwbaarheidsscores en herkomst uitwisselen. En pas daarna: comprimeer het voor mij.
Ik denk dat het mooiste is dat deze virale 'skills' wellicht juist wijzen naar de juiste toekomst. Gebruikers lossen dit nu op via de prompt-laag, terwijl het eigenlijk lager in de stack thuishoort.
"Praat tegen me alsof ik ADHD heb" is volkomen logisch als een renderer (weergave), maar het is veel minder logisch als een operationele instructie. De duurzame versie hiervan zijn agents wiens moedertaal een precieze, machine-gerichte staat is, waarbij de warme, beknopte menselijke versie pas aan de grens wordt gegenereerd.
De virale repositories zijn dus niet het eindstation, maar een bugrapport.
Groetjes,