Claude Code und die unvernünftig hohe Wirksamkeit von HTML-Artefakten

Markdown hat die erste Phase der Agenten-Zusammenarbeit gewonnen, weil es einfach ist.

Es ist leicht zu erzeugen, leicht zu diffen, leicht in einen Pull Request zu kopieren und gut genug für die meisten Notizen. Dadurch wurde es zum natürlichen Standard für Coding Agents: Pläne, Zusammenfassungen, Spezifikationen, Review-Notizen, Incident-Writeups und Implementierungs-Checklisten endeten alle als Markdown.

Anthropics neuester Claude-Code-Beitrag argumentiert, dass dieser Standard langsam an Grenzen stößt.

Die Aussage ist nicht, dass Markdown schlecht ist. Die Aussage ist, dass Claude Code heute mehr kann, als eine lange Textdatei zu schreiben, und HTML dem Modell eine bessere Oberfläche für diese Arbeit gibt: höhere Informationsdichte, klarere visuelle Struktur, besser teilbare Artefakte und leichte Interaktivität.

Für Entwickler ist das eine praktische Verschiebung. Sie verändert, was wir Claude Code produzieren lassen sollten.

Die Kernidee

Im offiziellen Beitrag erklärt Thariq Shihipar aus dem Claude-Code-Team, warum er für viele Claude-Code-Ausgaben inzwischen HTML-Dateien gegenüber Markdown bevorzugt.

Der Grund ist einfach: Wenn Claude Code größere Aufgaben übernimmt, werden auch die Ausgaben größer.

Eine Markdown-Checkliste mit 30 Zeilen ist in Ordnung. Ein Implementierungsplan, Research-Report, Code Review, Architektur-Explainer oder UI-Experiment mit 300 Zeilen ist nicht automatisch gut, nur weil es technisch gerendert wird.

HTML gibt Claude Code mehr Raum, dieselben Informationen zu organisieren:

• Tabellen für dichte Vergleiche
• CSS für visuelle Hierarchie
• SVG für Diagramme
• Bilder für Referenzen
• JavaScript für lokale Interaktionen
• Tabs und Abschnitte für Navigation
• Buttons zum Kopieren generierter Prompts, JSON, Diffs oder Einstellungen

Damit ist HTML weniger ein Dokumentformat und eher eine einmalige Arbeitsfläche.

Für Agenten-Workflows ist dieser Unterschied wichtig.

Warum das für Claude-Code-Nutzer wichtig ist

Claude Code unterscheidet sich von einer normalen Chat-Oberfläche, weil es das lokale Projekt lesen, Git-Historie prüfen, mit Dateien arbeiten, MCP-Server verwenden und Artefakte im selben Workspace erzeugen kann, in dem die echte Engineering-Arbeit passiert.

Dadurch ist es ungewöhnlich gut geeignet, nützliche HTML-Artefakte aus echtem Kontext zu erstellen.

Statt zum Beispiel zu fragen:

Write a plan for refactoring the billing module.

kannst du fragen:

Create an HTML artifact that explains the billing refactor.
Include a module map, the key file changes, risks by severity,
a staged migration plan, and a copyable implementation prompt.

Diese beiden Prompts können denselben Grundwunsch enthalten, aber der zweite fordert ein Format an, das leichter zu prüfen, leichter zu teilen und leichter in einer späteren Claude-Code-Sitzung als Referenz zu verwenden ist.

Das ist der eigentliche Vorteil: HTML kann zu dauerhaftem Projektkontext werden, nicht nur zu einer einmaligen Antwort.

Vier Bereiche, in denen HTML Markdown schlägt

1. Spezifikationen und Planung

Planung ist der erste Bereich, in dem Markdown schwächelt.

Lange Implementierungspläne kombinieren oft Architektur, Code-Snippets, Abhängigkeiten, Diagramme, Tradeoffs, Screenshots und offene Fragen. Markdown kann all das enthalten, hilft dem Leser aber nicht beim Navigieren.

HTML lässt Claude Code den Plan in eine besser prüfbare Oberfläche aufteilen:

• Überblick am Anfang
• Flow-Diagramm für das System
• Datei-für-Datei-Änderungskarte
• Risikotabelle
• gestufter Rollout-Plan
• offene Fragen
• kopierbare Follow-up-Prompts

Das ist besonders nützlich, wenn ein Plan über Sitzungen hinweg überleben soll. Ein zukünftiger Agent kann die HTML-Datei als Kontext lesen, während ein Mensch sie scannen kann, ohne eine Textwand zu lesen.

2. Code Review und Verständnis

Code Review ist nicht nur Text. Es ist Struktur.

Ein gutes Review braucht oft Diff, Schweregrade, betroffene Module, Call Paths, Datenfluss und kurze Erklärungen, warum etwas wichtig ist. Markdown kann das annähern, HTML kann es direkt darstellen.

Für Claude Code ergibt sich daraus ein besserer Workflow:

Review this PR by creating an HTML artifact.
Show the diff with inline annotations, group findings by severity,
and include a small diagram of the streaming/backpressure path.

So wird Review-Ausgabe eher zu einem interaktiven Review-Paket. Sie kann temporär bleiben, ist aber leichter an andere Entwickler weiterzugeben.

3. Design und Prototypen

HTML ist ein natürliches Ziel für Claude Code, wenn die Ausgabe eine visuelle oder interaktive Komponente hat.

Auch wenn die Produktions-App in React, Swift, Kotlin oder etwas anderem gebaut ist, bleibt HTML ein schneller Weg, Layouts zu skizzieren, Richtungen zu vergleichen, Motion zu testen und UI-Parameter abzustimmen.

Der Originalartikel nennt Slider, Knobs und Copy-Buttons als nützliche Primitive. Das ist das richtige mentale Modell. Claude Code kann eine Wegwerf-Oberfläche erstellen, um Werte auszuwählen, die schwer in Prosa zu beschreiben sind:

• Farbpaletten
• Easing Curves
• Komponentendichte
• Crop-Regionen
• Prompt-Varianten
• Feature-Flag-Kombinationen
• Ticket-Prioritäten

Wichtig ist der Export. Ein gutes HTML-Artefakt sollte mit etwas Nutzbarem enden: als JSON kopieren, als Markdown kopieren, als Prompt kopieren oder Diff kopieren.

Wenn das Artefakt seine Ausgabe nicht zurück in den Engineering-Workflow bringen kann, ist es nur eine Demo.

4. Reports, Recherche und Lernen

Claude Code kann über Codebase, Git-Historie, Docs, Slack über MCP, Linear über MCP und Webquellen hinweg synthetisieren. Markdown kann diesen Kontext zusammenfassen, HTML kann ihn lesbar machen.

Für interne Erklärungen, Incident Reviews, wöchentliche Statusberichte, Dependency Audits und Onboarding Guides gibt HTML dem Modell genug visuellen Raum, Beziehungen zu zeigen, statt sie nur zu beschreiben.

Hier wird HTML zu einem Lernformat:

• annotierte Code-Snippets
• Systemdiagramme
• Glossar-Callouts
• Timeline-Ansichten
• Risikomatrizen
• Entscheidungstabellen

Das Ergebnis muss kein poliertes Produkt werden. Es muss nur lesbar genug sein, dass jemand es tatsächlich nutzt.

Der versteckte Punkt: HTML hält Menschen im Loop

Der stärkste Teil von Anthropics Beitrag ist nicht das Formatargument. Es ist das Workflow-Argument.

Wenn Claude Code größere Aufgaben übernimmt, riskieren Entwickler, weniger von dem zu lesen, was der Agent produziert. Lange Markdown-Pläne lassen sich leicht abnicken, ohne sie gründlich zu prüfen. Das ist gefährlich, weil der Plan schwache Annahmen, ausgelassene Edge Cases oder Änderungen enthalten kann, die der Entwickler selbst nicht gewählt hätte.

HTML kann diesen Fehlermodus reduzieren, weil es Menschen bessere Griffe gibt:

• Überblick scannen
• Diagramm prüfen
• Optionen nebeneinander vergleichen
• zu Risiken springen
• einen Slider anpassen
• ausgewählte Ausgabe zurück in Claude Code kopieren

Das ersetzt Review nicht. Es macht Review wahrscheinlicher.

Für ernsthafte Agenten-Workflows ist das nicht kosmetisch. Es ist Teil der Kontrolle.

Wann Markdown weiterhin besser ist

HTML sollte Markdown nicht überall ersetzen.

Markdown ist weiterhin besser, wenn ein Artefakt:

• klein sein soll
• diff-freundlich sein muss
• häufig manuell editiert wird
• in eine README eingebettet wird
• in ein Issue oder eine PR-Beschreibung kopiert wird
• von Tools verarbeitet wird, die Markdown erwarten

Die praktische Regel ist einfach:

Nutze Markdown, wenn die Ausgabe hauptsächlich Text ist und von Menschen editiert wird.

Nutze HTML, wenn die Ausgabe Layout, Diagramme, dichte Vergleiche, Interaktivität oder eine bessere Leseerfahrung braucht.

So wird HTML nicht zum nächsten übernutzten Standard.

Ein einfaches Prompt-Muster

Wenn du das in Claude Code ausprobieren willst, beginne mit einem direkten Prompt:

Create a single HTML artifact for this task.
It should be readable in a browser, self-contained, and optimized for review.
Use tables, diagrams, and sections where useful.
Add copy buttons for any output I may want to paste back into Claude Code.
Keep all source references visible.

Dann mach den Zweck konkret:

For this refactor, include:
- a dependency map
- the proposed file changes
- migration steps
- risks by severity
- test plan
- open questions

Mit der Zeit sollten wiederkehrende Muster zu Skills oder Templates werden. Der erste Schritt braucht aber keine Infrastruktur. Er braucht nur die Gewohnheit, Claude Code nach einem besseren Artefakt zu fragen.

Was Teams als Nächstes tun sollten

Die kurzfristige Chance besteht nicht darin, jedes interne Dokumentsystem um HTML herum neu zu bauen.

Der nützliche Schritt ist enger:

1. Identifiziert die Claude-Code-Ausgaben, die euer Team nicht wirklich liest.
2. Wandelt eine dieser Ausgaben in ein HTML-Artefakt um.
3. Verlangt, dass das Artefakt etwas Nützliches zurück in den Workflow exportiert.
4. Behaltet das Artefakt im Repo, wenn es späteren Sitzungen hilft.
5. Löscht es, wenn es nur für eine Entscheidung nützlich war.

Der letzte Punkt ist wichtig. Viele HTML-Artefakte sollten wegwerfbar sein. Ihr Wert liegt darin, einem Menschen jetzt eine bessere Entscheidung zu ermöglichen.

Fazit

Die unvernünftig hohe Wirksamkeit von HTML liegt nicht darin, dass es eine bessere Markup-Sprache als Markdown ist.

Sie liegt darin, dass HTML Claude Code eine reichere Kollaborationsoberfläche gibt.

Für kleine Notizen bleibt Markdown das richtige Werkzeug. Aber für Spezifikationen, Code Reviews, Architektur-Erklärungen, Design-Explorationen, Research-Reports und benutzerdefinierte Bearbeitungsoberflächen kann HTML Agenten-Ausgaben lesbarer, teilbarer und handlungsorientierter machen.

Wenn Claude Code größere Arbeitsstücke übernehmen kann, wird das Ausgabeformat Teil des Workflow-Designs. Teams, die Artefakte als erstklassige Review-Oberflächen behandeln, behalten mehr Kontrolle als Teams, die weiter Markdown-Textwände abnicken.

Quelle

• Claude blog: Using Claude Code: The unreasonable effectiveness of HTML
  https://claude.com/blog/using-claude-code-the-unreasonable-effectiveness-of-html