HTML statt Markdown: Warum KI-Agenten besser HTML ausgeben (und wann nicht)

TL;DR: Thariq Shihipar aus dem Claude-Code-Team von Anthropic hat im Mai 2026 eine These populär gemacht: Lass dir von KI-Agenten Pläne, Reviews und Reports nicht als Markdown, sondern als HTML ausgeben. Der Grund ist die Lesbarkeit. Ab etwa 100 Zeilen liest niemand mehr eine Markdown-Datei, HTML dagegen liefert Tabellen, Diagramme, einklappbare Abschnitte und teilbare Links. Der Preis: HTML verbraucht je nach Komplexität das Zwei- bis Zehnfache an Token, und HTML-Diffs sind kaum noch reviewbar. Die entscheidende Differenzierung, die in der Debatte oft untergeht: HTML gewinnt nur beim Output an Menschen. Bei der Eingabe in ein Modell ist Markdown klar überlegen, in Tests bis zu 80 Prozent token-sparsamer und in RAG-Aufgaben deutlich genauer. Die richtige Antwort ist deshalb keine Entweder-oder-Wahl, sondern eine Input-Output-Regel.

Was steckt hinter „HTML statt Markdown"?

Markdown ist das De-facto-Format, in dem KI-Agenten mit uns kommunizieren. Es ist simpel, portabel und leicht editierbar. Genau das wurde zum Problem, als die Agenten leistungsfähiger wurden. Thariq Shihipar, Mitglied des technischen Teams hinter Claude Code, beschreibt in seinem Beitrag „Using Claude Code: The Unreasonable Effectiveness of HTML" (veröffentlicht am 20. Mai 2026), warum er und Kollegen im Team Markdown als Output-Format zunehmend durch HTML ersetzen. Seine Begründung: Markdown sei „statischer Text, der vorgibt, Struktur zu sein". Sobald Claude eine Systemarchitektur skizziert oder einen dichten Pull Request reviewt, entsteht in Markdown eine Textwand. Du scrollst, verlierst den Kontext und kopierst Teile manuell in andere Tools, um sie zu visualisieren. HTML ändert dieses Verhältnis. Aus dem Dokument wird laut Shihipar ein „Arbeitsbereich" mit sortierbaren Tabellen, einklappbaren Code-Blöcken, Diagrammen und Schiebereglern. Andrej Karpathy hat diese Entwicklung als Fortschritt eingeordnet, der die Geschichte der Computer-Interfaces spiegelt: roher Text, dann Markdown, dann HTML, irgendwann interaktives neuronales Video. Jeder Schritt tauscht Effizienz gegen Verständlichkeit.

Warum HTML als Output-Format überzeugt

HTML bringt drei Vorteile, die Markdown systembedingt nicht liefern kann.

Informationsdichte und visuelle Klarheit

HTML kann Informationen transportieren, die Markdown nur umständlich annähert: tabellarische Daten, CSS-Design, SVG-Illustrationen, ausführbaren Code, räumliche Layouts. Ohne diese Mittel behilft sich ein Modell mit ASCII-Diagrammen oder, im Extremfall, mit Unicode-Zeichen als Farbersatz. Der eigentliche Hebel ist aber die menschliche Wahrnehmung. „Ich lese keine Markdown-Datei mit mehr als hundert Zeilen, und ich bringe garantiert niemanden sonst in meiner Organisation dazu", schreibt Shihipar. Andrej Karpathy hat den Gedanken zugespitzt: Etwa ein Drittel unseres Gehirns sei auf das Sehen spezialisiert, die visuelle Wahrnehmung sei die „zehnspurige Datenautobahn" ins Gehirn. Markdown nutzt mit Fettungen, Überschriften und Aufzählungen nur einen schmalen Kanal, HTML bedient diesen breiten visuellen Kanal.

Teilen und Zwei-Wege-Interaktion

Markdown-Dateien rendern die wenigsten Browser nativ, du verschickst sie als Anhang. Eine HTML-Datei öffnet jeder per Link im Browser. Die Wahrscheinlichkeit, dass eine Spezifikation oder ein PR-Writeup tatsächlich gelesen wird, steigt damit deutlich. Dazu kommt Two-way Interaction: Du kannst Claude bitten, Schieberegler oder Buttons einzubauen, um Design-Parameter direkt im Dokument zu testen. Ein „Copy as JSON"- oder „Copy as Prompt"-Button exportiert das Ergebnis zurück in die Coding-Session. Aus der Einbahnstraße Output wird eine Schleife, die enger wird.

Im Loop bleiben und Halluzinationen senken

Der von Shihipar genannte Hauptgrund ist überraschend: Er fühle sich mit HTML „mehr im Loop" mit Claude. Je mehr der Agent übernimmt, desto weniger genau las er die Pläne, HTML brachte ihn zurück ins Geschehen. Das ist exakt die Gegenstrategie zur Cognitive Debt, dem schleichenden Verständnisverlust in KI-gestützten Teams. Es gibt sogar einen technischen Nebeneffekt auf der Modellseite. Valides HTML zu erzeugen zwingt das Modell über das Document Object Model (DOM) zu hierarchischer Planung: Welches Kind-Element gehört in welches Eltern-Element? Diese Vorab-Strukturierung kann laut der Analyse logische Brüche reduzieren, während Markdown ein unstrukturiertes Herunterschreiben erlaubt.

Der Haken: Token-Kosten, Diffs und Sicherheit

HTML ist kein kostenloses Upgrade. Drei Nachteile sind konkret. Token-Kosten: HTML ist geschwätzig. Sauberes HTML kostet das Zwei- bis Dreifache an Token gegenüber gleichwertigem Markdown, reales HTML mit CSS und JavaScript kann auf das Acht- bis Zehnfache anwachsen. Bei großen Kontextfenstern fällt das pro Anfrage weniger ins Gewicht, in der Summe und bei hochfrequenter Nutzung treibt es die API-Kosten spürbar nach oben. Wer Token sparen will, findet im Caveman Mode das Gegenmodell. Diffs: Das größte praktische Hindernis im Entwickler-Workflow. Ein Markdown-Diff zeigt im Terminal Zeile für Zeile, was sich geändert hat. Ein HTML-Diff ist nach einer kleinen CSS- oder div-Änderung kaum noch lesbar. Du prüfst nicht mehr den Diff, du öffnest die Datei im Browser und vertraust dem visuellen Eindruck. Shihipar räumt diesen Punkt selbst als größten Nachteil ein. Sicherheit: Roher HTML-Output kann JavaScript enthalten und damit Cross-Site-Scripting und Injection-Angriffe ermöglichen. Googles A2UI-Protokoll existiert genau deshalb, weil Sicherheitsteams in Unternehmen keine Agenten akzeptieren können, die beliebiges HTML in Produktivumgebungen schreiben.

Die Gegenthese: Bei der Eingabe gewinnt Markdown klar

Hier liegt der wichtigste Punkt, den die HTML-Begeisterung oft überspringt. Shihipars These gilt für den Output an Menschen. Für die Eingabe in ein Modell, also Ingestion, RAG und Agent-zu-Agent-Kommunikation, dreht sich das Bild komplett um. HTML ist hier hochgradig ineffizient, weil Tags, CSS-Klassen, Skript-Blöcke und ARIA-Attribute syntaktisches Rauschen erzeugen, das Kontextfenster blockiert, ohne Bedeutung beizutragen. Einzelne Messungen aus Analysen zum Thema veranschaulichen die Größenordnung (es handelt sich um illustrative Beispielwerte, nicht um repräsentative Benchmarks): - Ein Blogbeitrag schrumpfte von 16.180 HTML-Token auf 3.150 Markdown-Token, rund 80 Prozent weniger. - Ein einzelner Absatz fiel mit dem cl100kbase-Tokenizer von 87 auf 29 Token (67 Prozent). - Ein typisches 3.000-Wörter-Dokument sinkt von etwa 8.000 auf 2.800 Token. Wichtiger noch: Das Rauschen verschlechtert die Qualität. In einem Test, bei dem identische Inhalte als HTML und als Markdown an GPT-4, Claude 3.5 Sonnet und Gemini 1.5 Pro gegeben und von Menschen auf einer Skala von 1 bis 10 bewertet wurden, gewann Markdown durchgehend: | Aufgabe | HTML-Eingabe | Markdown-Eingabe | Verbesserung | |---|---|---|---| | Extraktion von Kernpunkten | 6,5 | 9,1 | +40 % | | Inhaltliche Umformulierung | 6,2 | 8,6 | +39 % | | Zusammenfassung | 6,8 | 8,9 | +31 % | | Frage-Antwort-Präzision | 7,1 | 8,7 | +23 % | | Übersetzung | 7,8 | 8,4 | +8 % | Einordnung: Diese Werte stammen aus einem einzelnen Anbieter-Test ohne Peer-Review (zehn Durchläufe, menschliche Bewertung). Die exakten Prozentzahlen sind deshalb mit Vorsicht zu lesen und eher als Tendenz zu verstehen. Die Richtung deckt sich aber mit der gängigen Praxis: Markdown hat sich nicht ohne Grund als Eingabeformat durchgesetzt. Der Grund ist die semantische Konsistenz: Markdown erzwingt eine einheitliche Struktur, während HTML denselben visuellen Zustand auf unzählige Arten ausdrücken kann. Das erleichtert dem Modell, Hierarchien zu erkennen. Genau deshalb hat sich Markdown als Industriestandard für RAG-Pipelines etabliert. Der Entwickler Kurtis Redux hat als direkte Antwort auf Shihipar den Beitrag „The Unreasonable Ineffectiveness of HTML" geschrieben und argumentiert, der Wechsel jage „visuellen Glanz auf Kosten von Quell-Lesbarkeit, Sicherheit, Ökosystem-Kompatibilität und Reviewbarkeit".

HTML oder Markdown? Die Input-Output-Regel

Die ehrliche Antwort lautet: Es kommt darauf an, wer der Empfänger ist. Statt eines Glaubenskriegs hilft eine einfache Regel. | Szenario | Empfänger | Bestes Format | |---|---|---| | Agent liest Webinhalte, RAG, Trainingsdaten | Modell | Markdown | | Agent gibt Zwischenergebnis an anderen Agenten | Modell/System | Markdown | | Plan, Spec, Code-Review zum Lesen | Mensch | HTML | | Interaktives Dashboard, Prototyp, Report | Mensch | HTML | | Komplexe Tabellen mit verbundenen Zellen | beides | HTML (Markdown kann kein colspan) | Faustregel: Markdown ist zum Lesen durch Maschinen da, HTML zum Verstehen durch Menschen. Wenn ein anderes System die Ausgabe weiterverarbeitet, sind Markdowns Beschränkungen eine Stärke. Wenn ein Mensch eine dichte Analyse bewerten und danach handeln soll, schlägt visuelle Klarheit die Token-Effizienz. Dass dieser Output-Bedarf real ist, zeigen Zahlen aus der Praxis. Salesforce verarbeitet mit seinem Agentforce-System über vier Millionen Sitzungen über 133.000 Agenten und wandelt Textantworten dabei in strukturierte UI-Komponenten um. Die Lehre des Engineering-Teams: Frühe Versionen „überformatierten" und machten aus simplen Ja-Nein-Antworten ganze UI-Bausteine. Rich Output muss zur Komplexität der Information passen.

Wie du HTML-Outputs in Claude Code nutzt

Du brauchst keinen eigenen Skill. Es reicht, im richtigen Moment „mach daraus eine HTML-Datei" zu sagen. Drei bewährte Einsätze: - Implementierungsplan: „Erstelle einen Implementierungsplan als einzelne HTML-Datei mit Mockups, Datenfluss und den wichtigsten Code-Snippets. Mach es leicht lesbar." Den Plan übergibst du in einer neuen Session zur Umsetzung. Das passt zum Prinzip des Spec-Driven Development. - Code-Review: „Hilf mir, diesen PR zu reviewen, indem du ein HTML-Artefakt erstellst. Rendere den echten Diff mit Anmerkungen am Rand und färbe Findings nach Schweregrad." Funktioniert oft besser als die Standard-Diff-Ansicht. - Report mit Kontext: Claude Code kann über das Dateisystem, einen AI Harness und MCP-Tools wie Jira oder Slack Kontext einlesen und daraus ein sortierbares HTML-Dashboard erzeugen, statt einer Bullet-Liste. Hinweis: Wenn du wiederkehrende Muster hast, kannst du sie später zu einem Claude Skill verdichten. Für den Anfang reicht freies Prompten, um ein Gefühl für die Einsätze zu bekommen.

FAQ: Häufig gestellte Fragen zu HTML statt Markdown

Soll ich Markdown jetzt komplett aufgeben? Nein. Markdown bleibt das richtige Format für alles, was ein Modell oder ein anderes System weiterverarbeitet, also Ingestion, RAG und Agent-zu-Agent-Kommunikation. HTML lohnt sich gezielt dort, wo ein Mensch die Ausgabe lesen und bewerten soll. Wie viel teurer ist HTML wirklich? Sauberes HTML kostet etwa das Zwei- bis Dreifache an Token gegenüber Markdown, reales HTML mit CSS und JavaScript bis zum Acht- bis Zehnfachen. Bei einzelnen Anfragen mit großem Kontextfenster fällt das kaum auf, bei hochfrequenter oder automatisierter Nutzung summiert es sich zu spürbar höheren API-Kosten. Warum verarbeiten Modelle Markdown bei der Eingabe besser? Weil HTML mit Tags, Klassen und Skripten viel Rauschen ohne semantischen Mehrwert erzeugt. In einem Anbieter-Test (ohne Peer-Review) verbesserte Markdown-Eingabe die Genauigkeit je nach Aufgabe um 23 bis 40 Prozent, und einzelne Messungen zeigen bis zu 80 Prozent weniger Token. Die genauen Zahlen sind als Tendenz zu lesen, die Richtung ist aber konsistent: Eine einheitlichere Struktur ist für das Modell leichter zu erfassen. Was ist das größte praktische Problem mit HTML? Die Versionskontrolle. HTML-Diffs sind nach kleinen visuellen Änderungen kaum noch lesbar, sodass du den Code-Review faktisch durch einen Blick in den Browser ersetzt. Für Dokumente, die in Git versioniert und von Menschen reviewt werden, bleibt Markdown im Vorteil. Ist HTML-Output ein Sicherheitsrisiko? Es kann eines sein. Von Agenten generiertes HTML kann JavaScript enthalten und damit Cross-Site-Scripting ermöglichen. Öffne solche Dateien bewusst und führe sie nicht ungeprüft in Produktivumgebungen aus. Genau für dieses Problem wurden Protokolle wie Googles A2UI entwickelt. Brauche ich einen speziellen Skill dafür? Nein. Es genügt, Claude im Prompt um eine HTML-Datei oder ein HTML-Artefakt zu bitten. Erst wenn sich ein Muster wiederholt, lohnt es sich, daraus einen Skill zu bauen.

Fazit

„HTML statt Markdown" ist keine Stilfrage, sondern eine Empfänger-Frage. Für den Output an Menschen liefert HTML mehr Informationsdichte, bessere Lesbarkeit und Interaktivität und hält dich stärker im Loop mit dem Agenten, bezahlt das aber mit Token, kaum reviewbaren Diffs und einem Sicherheitsrisiko. Für die Eingabe in ein Modell bleibt Markdown klar überlegen. Wer beides nach der Input-Output-Regel trennt, holt aus beiden Formaten das Maximum heraus. Wie der technische Unterbau aussieht, erklärt der Guide zu AI Harness. Wie du Pläne als primäres Artefakt nutzt, zeigt Spec-Driven Development. Warum das aktive Lesen von KI-Output so wichtig ist, behandelt der Artikel zu Cognitive Debt. Und wie Markdown als Wissensspeicher funktioniert, liest du im Beitrag zu Claude Code und Obsidian als Second Brain. Verifizierte Quellen: Thariq Shihipar, „Using Claude Code: The Unreasonable Effectiveness of HTML" (claude.com, 20. Mai 2026); Simon Willison's Weblog (8. Mai 2026); Kurtis Redux, „The Unreasonable Ineffectiveness of HTML" (Medium); multidimensionale Analyse „HTML- versus Markdown-Strukturierung für Large Language Models"; Test „Markdown vs HTML: Which Format Gets Better AI Responses"; MDEval und StructEval (arXiv); ReaderLM-v2 (Jina AI, arXiv); Andrej Karpathy zur visuellen Informationsverarbeitung und Format-Progression.