Er waait een nieuwe wind door de AI-developercommunity, en voor de verandering snap ik de aantrekkingskracht. In plaats van je coding-agent nóg een muur van Markdown te laten produceren, vraag je hem een HTML-bestand te genereren. Open het in een browser. En ineens gaat de output van je agent van een plat document naar een rijke, interactieve, prachtige pagina.
Karpathy doet het. Het Claude Code-team schrijft erover. Theo maakte er een hele video over. En eerlijk? De resultaten zien er verbluffend uit.
Maar als iemand die het grootste deel van deze serie heeft besteed aan het blootleggen van de kloof tussen wat AI demo's laten zien en wat AI in productie oplevert, kan ik niet zomaar meeknikken. Dus doen we wat we hier altijd doen: voorbij de opwinding graven en de ongemakkelijke vragen stellen.
De zaak voor HTML (die is reëel)
Laat me duidelijk zijn: het argument voor HTML boven Markdown is legitiem. Thariq Shihipar van het Claude Code-team legde het goed uit: wanneer je een agent vraagt een specdocument, een projectroadmap of een code-reviewsamenvatting te genereren, geeft Markdown je headers en bullets. HTML geeft je een canvas.
Bedenk wat dat in de praktijk betekent:
- Informatiedichtheid. Een enkele HTML-pagina kan inklapbare secties, kleurgecodeerde statusindicatoren, sorteerbare tabellen en inline SVG's bevatten. Dezelfde informatie in Markdown zou een muur van 500 regels tekst zijn waar niemand voorbij de derde heading leest.
- Visuele hiërarchie. CSS laat je prioriteit coderen via grootte, kleur en positie. In Markdown ziet alles er even belangrijk uit, wat betekent dat niets het is.
- Interactiviteit. Stel je voor dat je agent een migratieplan genereert met een interactieve dependency-graph, of een performancerapport waar je op endpoint kunt filteren. Probeer dat maar eens in een
.md-bestand.
Karpathy zelf onderschreef de aanpak: voeg gewoon "structure your response as HTML" toe aan je query, open het bestand in een browser, en je krijgt iets dat daadwerkelijk communiceert. Hij heeft gelijk. Het werkt. Ik heb het geprobeerd.
Het deel waar niemand over praat
En hier komt mijn scepsis om de hoek kijken.
Token-economie
Een HTML-pagina met Tailwind-classes, embedded CSS en structurele markup is makkelijk 3-5x de tokentellingen van het equivalente Markdown. Die inklapbare sidebar met soepele animaties? Die is niet gratis. Elke <div class="flex items-center justify-between p-4 bg-gradient-to-r from-slate-800 to-slate-900"> zijn tokens waar je voor betaalt.
In een agentische loop waar het model op zijn eigen output itereert, stapelen die tokens zich snel op. Je prachtige, interactieve specdocument kost misschien $2 in plaats van $0,40. Vermenigvuldig dat met een team dat er tientallen per dag genereert, en je API-budget begint op je cloudrekening te lijken: een getal dat sneller groeit dan wie dan ook had verwacht.
Versiebeheer is een nachtmerrie
Markdown-diffs zijn schoon. Je kunt een .md-bestandswijziging in een pull request reviewen en onmiddellijk zien wat er veranderd is. HTML-diffs? Succes ermee. Een enkele contentwijziging kan door tientallen regels structurele markup, classnamen en wrapper-divs cascaderen. De signaal-ruisverhouding in een diff gaat van uitstekend naar catastrofaal.
Als je deze HTML-outputs als documentatie gebruikt, zoals veel voorstanders suggereren, bouw je een documentatiesysteem dat fundamenteel vijandig staat tegenover versiebeheer. Elke review wordt een oefening in het parsen van visuele ruis om de daadwerkelijke contentwijziging te vinden.
Het wegwerpprobleem
Dit is degene die me het meest dwarzit. De hele pitch voor HTML-agentoutput is dat het efemeer is. Genereer het, bekijk het, deel misschien een screenshot, ga door. Thariq beschrijft ze expliciet als "throwaway pages."
Maar we hebben al een woord voor content die er indrukwekkend uitziet, aanzienlijke rekenkracht kost om te genereren, en geen blijvende waarde heeft: AI-slop.
Wanneer elke agentinteractie een prachtig gestylde webpagina produceert die één keer wordt bekeken en weggegooid, hebben we de communicatie tussen mens en machine niet verbeterd. We hebben het afval alleen mooier gemaakt. De onderliggende informatie had drie bullets kunnen zijn, maar in plaats daarvan is het verpakt in een gradientachtergrond met soepele animaties, omdat het medium de boodschap is geworden.
De echte vraag: voor wie is dit?
Hier is waar de HTML-enthousiastelingen nog niet mee hebben geworsteld. Er worden twee fundamenteel verschillende use cases door elkaar gehaald:
1. Visualisatie van complexe data. Als je agent een codebase analyseert en een dependency-graph produceert, is een interactieve HTML-visualisatie oprecht beter dan een ASCII-artdiagram. Geen discussie. Dit is het sterke argument.
2. Simpele output aankleden. Als je agent een vraag beantwoordt, een samenvatting schrijft of een todolijst genereert, voegt het inpakken in HTML niets toe behalve kosten en complexiteit. Een Markdownbestand geopend in welke editor, preview-pane of documentatiesite dan ook doet het werk prima.
Het probleem is dat de trend geen onderscheid maakt tussen deze cases. De boodschap is niet "gebruik HTML wanneer visuele dichtheid ertoe doet." De boodschap is "laat je agents stoppen met Markdown schrijven," punt. En dat absolutisme is precies het soort denken dat ertoe leidt dat developers grijpen naar zwaargewichtoplossingen voor lichtgewichtproblemen.
Het patroon dat we blijven herhalen
We hebben dit eerder gezien. Elke paar maanden ontdekt de AI-developercommunity iets nieuws dat agents kunnen, verwart mogelijkheid met noodzaak, en herschrijft hun hele workflow eromheen.
Weet je nog toen het antwoord op alles "gebruik gewoon een vectordatabase" was? Toen elk probleem RAG nodig had? Toen agentische loops alle lineaire code zouden vervangen? Elk van deze tools heeft oprechte waarde in specifieke contexten. Maar de hype-cyclus maakt van elke nuttige tool een universele hamer.
HTML-output voor agents is een nuttige tool. Het zal de standaard worden in bepaalde specifieke workflows: prototyping, datavisualisatie, stakeholderpresentaties. En in die contexten is het uitstekend.
Maar het ademloze "Markdown is dood"-narratief is, zoals de meeste ademloze AI-narratieven, een verhaal dat spannender is dan accuraat.
Wat je eigenlijk moet doen
Als je HTML-output effectief wilt gebruiken, is hier de pragmatische aanpak:
- Gebruik het voor visualisatie, niet voor communicatie. Als de output gezien moet worden in plaats van gelezen, wint HTML. Voor al het andere is Markdown prima.
- Let op je tokenuitgaven. Houd het kostenverschil bij. Als je 4x meer betaalt voor output die één keer bekeken wordt, optimaliseer je voor esthetiek boven waarde.
- Check het niet in. HTML-agentoutput hoort in
/tmp, niet in je repository. Op het moment dat je gegenereerde HTML versiebeheerd, heb je een onderhoudsbelasting gecreëerd die langer zal leven dan het enthousiasme. - Houd de bron van waarheid in platte tekst. Je specs, docs en plannen horen in formaten die schoon diffen, overal renderen en geen browser nodig hebben om te lezen.
Tot slot
Ik hou van mooie dingen. Ik geniet er oprecht van om een HTML-bestand te openen dat door Claude is gegenereerd en een gepolijste, interactieve pagina te zien in plaats van nóg een Markdown-muur. Er zit een viscerale voldoening in.
Maar voldoening is geen strategie. De vraag is niet of HTML-output er beter uitziet dan Markdown. Dat doet het overduidelijk. De vraag is of de kosten, de wegwerpbaarheid en de vijandelijkheid voor versiebeheer het waard zijn voor jouw specifieke use case.
Voor de meeste developer-workflows, het meeste van de tijd, is het antwoord nee. Een goed gestructureerd Markdownbestand, geschreven door een agent die weet welke informatie er écht toe doet, zal altijd winnen van een prachtig gestylde webpagina die hetzelfde zegt in vijf keer zoveel tokens.
Het medium is niet de boodschap. De informatie is de boodschap. Laat je niet afleiden door een mooie verpakking als je je afvraagt of er eigenlijk wel iets inzit.