Claude Code nutzen: Die überraschende Effizienz von HTML

 (twitter.com/trq212)
2 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn man in Claude Code statt Markdown HTML als Ausgabeformat verwendet, lassen sich Visualisierungen, Farben, Diagramme und Interaktionen deutlich reichhaltiger darstellen, sodass Ergebnisse leichter von Menschen gelesen und geprüft werden können
  • HTML kann mit Tabellen, CSS, SVG, script, JavaScript-Interaktionen, Bildern, Canvas und absoluter Positionierung den Großteil der Informationen, die Claude lesen kann, effizient ausdrücken
  • Claude Code kann Kontexte wie Dateisystem, MCP, Browser und Git-Historie einlesen und zu HTML-Ergebnissen zusammenführen; man kann einfach damit anfangen, indem man sagt: „Erstelle mir eine HTML-Datei“
  • Die wichtigsten Einsatzarten lassen sich in Spezifikationen, Planung und Exploration, Code-Reviews und Codeverständnis, Design und Prototyping, Berichte, Research und Lernen sowie maßgeschneiderte einmalige Bearbeitungsoberflächen einteilen
  • HTML braucht im Vergleich zu Markdown 2- bis 4-mal länger zum Erzeugen und ist wegen lauter Diffs schwieriger in der Versionsverwaltung, bietet aber große Vorteile bei Ausdrucksstärke, Teilbarkeit und der Wahrscheinlichkeit, tatsächlich gelesen zu werden

Warum ich HTML statt Markdown bevorzuge

  • Markdown ist zum dominierenden Dateiformat geworden, mit dem Agenten mit Menschen kommunizieren; es ist einfach, portabel, kann etwas Formatierung ausdrücken und lässt sich von Menschen leicht direkt bearbeiten
  • Claude kann in Markdown auch gut ASCII-Diagramme erzeugen, aber je leistungsfähiger Agenten werden, desto stärker wirkt Markdown wie ein einschränkendes Format
  • Markdown-Dateien mit mehr als 100 Zeilen sind schwer zu lesen, und man möchte reichhaltigere Visualisierungen, Farben und Diagramme einfacher teilen
  • Da man immer häufiger Claude um Bearbeitungen bittet, statt Dateien selbst direkt zu editieren, verliert ein großer Vorteil von Markdown — die einfache direkte Bearbeitung — an Wert
  • Auch im Claude-Code-Team wird HTML zunehmend als Ausgabeformat genutzt; Beispiele gibt es unter html-effectiveness

Ausdrucksstärke und Teilbarkeit von HTML

  • HTML kann nicht nur Dokumentstruktur wie Überschriften und Formatierungen darstellen, sondern weit mehr Arten von Informationen als Markdown
  • Zu den darstellbaren Informationen zählen Tabellendaten über Tabellen, Designdaten über CSS, SVG-Illustrationen, Codefragmente über das script-Tag sowie Interaktionen mit JavaScript und CSS
  • Mit SVG und HTML lassen sich Workflows darstellen, mit absoluter Positionierung und Canvas räumliche Daten ausdrücken, und mit dem img-Tag können Bilder eingebunden werden
  • Der Großteil der Informationsmenge, die Claude lesen kann, lässt sich mit HTML recht effizient ausdrücken; dadurch wird es zu einem Format, in dem das Modell tiefgehende Informationen vermitteln kann und das für Menschen effizient zu prüfen ist
  • Wenn HTML nicht verwendet wird, kann es passieren, dass Claude in Markdown ineffiziente Darstellungen nutzt, etwa ASCII-Diagramme oder das Schätzen von Farben über Unicode-Zeichen
  • Da Claude komplexere Aufgaben übernimmt, schreibt es größere Spezifikationen und Pläne; Markdown-Dateien mit mehr als 100 Zeilen werden in der Praxis tatsächlich kaum gut gelesen
  • HTML-Dokumente lassen sich mit Tabs, Illustrationen und Links visuell strukturieren und dadurch leicht navigieren; sie können zudem responsiv für Mobilgeräte aufgebaut werden, sodass sie je nach Bildschirmgröße unterschiedlich lesbar sind
  • Markdown-Dateien werden vom Browser standardmäßig nicht gut gerendert und müssen daher oft per E-Mail oder Nachricht angehängt werden, während HTML sich etwa auf S3 hochladen und einfach per Link teilen lässt
  • Spezifikationen, Berichte und PR-Beschreibungen in HTML lassen sich von Kolleginnen und Kollegen leicht öffnen und nachschlagen, wodurch die Wahrscheinlichkeit deutlich steigt, dass sie tatsächlich gelesen werden
  • HTML-Dokumente können bidirektionale Interaktion unterstützen, etwa mit Slidern oder Reglern, um Designs anzupassen oder Algorithmusoptionen zu verändern und die Ergebnisse zu prüfen
  • Man kann auch Funktionen einbauen, um die vorgenommenen Anpassungen als Prompt zurück in Claude Code zu kopieren; ein passendes Beispiel behandelt der playgrounds post

Warum Claude Code und HTML gut zusammenpassen

  • Claude Code kann verschiedenste Kontexte wie Dateisystem, MCP, Browser und Git-Historie lesen und zu HTML-Ergebnissen zusammenführen
  • Es kann zum Beispiel alle in einem Codeordner erzeugten HTML-Dateien finden, gruppieren und klassifizieren und anschließend eine HTML-Datei mit Diagrammen erstellen, die die einzelnen Typen repräsentieren
  • Neben dem Dateisystem kann es zusätzlichen Kontext aus MCP wie Slack oder Linear, aus dem Webbrowser über Claude in Chrome oder aus der Git-Historie holen
  • Der Prozess, HTML-Dokumente gemeinsam mit Claude zu erstellen, macht mehr Spaß und vermittelt stärker das Gefühl, am erzeugten Ergebnis beteiligt und in es investiert zu sein
  • Man braucht kein separates /html-Skill; es reicht, einfach zu sagen: „Erstelle mir eine HTML-Datei“ oder „Erstelle mir ein HTML-Artefakt“
  • Ein wichtiger Kniff ist zu wissen, was das Artefakt tun soll und wie es genutzt werden soll; anfangs ist es sinnvoll, Prompts jedes Mal neu von Grund auf zu schreiben, um verschiedene Einsatzmöglichkeiten kennenzulernen

Wichtige Einsatzarten

  • Spezifikationen, Planung, Exploration

    • HTML ist eine reichhaltige Arbeitsfläche, auf der Claude tiefer in ein Problem einsteigen kann; statt mit einem einzelnen Markdown-Plan kann man eine Arbeit auch mit einem Bündel mehrerer HTML-Dateien beginnen
    • Man kann zuerst mehrere Richtungen brainstormen, dann eine Richtung weiter ausbauen und Mockups oder Codefragmente erstellen und schließlich einen Implementierungsplan schreiben
    • Wenn der Plan zufriedenstellend ist, kann man eine neue Sitzung starten und diese Dateien zur Umsetzung übergeben; auch ein Validierungs-Agent kann dieselben Dateien lesen und so breiteren nötigen Kontext erfassen
    • Für einen Onboarding-Bildschirm kann man sechs Ansätze mit unterschiedlichem Layout, Ton und Informationsdichte in einem einzigen HTML-Grid anlegen lassen und die Trade-offs jeder Auswahl markieren
    • Man kann auch einen gut lesbaren HTML-Implementierungsplan mit Mockups, Datenflüssen und zu prüfenden Codefragmenten erstellen lassen
    • Es lässt sich für die Exploration von Implementierungsansätzen und für den Vergleich mehrerer visueller Designs nutzen

  • Code-Review und Codeverständnis

    • Code kann in Markdown-Dateien schwer lesbar sein, während sich in HTML Diffs, Kommentare, Flussdiagramme und Modulstrukturen rendern lassen
    • Es kann genutzt werden, um von Agenten geschriebenen Code zu verstehen, Code-Reviews zu erhalten oder Personen, die ein PR prüfen, Änderungen zu erklären
    • In manchen Fällen funktioniert es besser als die Standard-Diff-Ansicht von GitHub; auch ein Ablauf, bei dem jedem PR eine HTML-Datei zur Code-Erklärung beigefügt wird, ist denkbar
    • Man kann ein HTML-Artefakt für PR-Reviews erstellen lassen, es auf unbekannte Streaming-/Backpressure-Logik fokussieren und im echten Diff Randkommentare mit farblicher Markierung nach Schweregrad einfügen lassen
    • Es kann für das Schreiben von PRs, PR-Reviews und das Verständnis von Codethemen verwendet werden

  • Design und Prototyping

    • Claude Design basiert auf HTML, und HTML bietet hohe gestalterische Ausdrucksstärke, selbst wenn die finale Oberfläche nicht HTML ist
    • Claude kann ein Design zunächst in HTML skizzieren und es dann in der gewünschten Sprache wie React oder Swift umsetzen
    • Interaktionen wie Animationen und Aktionen lassen sich prototypisch umsetzen, und mit Slidern oder Reglern können gewünschte Werte angepasst werden
    • Man kann etwa einen Checkout-Button erstellen lassen, der beim Klick eine Abspielanimation zeigt und dann schnell violett wird, ergänzt um mehrere Slider und Optionen sowie einen Button zum Kopieren gut passender Parameter
    • Es eignet sich für das Erzeugen von Designsystem-Artefakten, das Anpassen von Komponenten, die Visualisierung von Komponentenbibliotheken und spielerische Animationsprototypen

  • Berichte, Research, Lernen

    • Claude Code ist stark darin, Informationen aus mehreren Datenquellen zusammenzuführen und in leicht lesbare Berichte zu verwandeln
    • Man kann es Slack, die Codebasis, die Git-Historie, das Internet usw. durchsuchen lassen und leicht lesbare Berichte für sich selbst, das Leadership oder das Team erzeugen
    • Die Ergebnisse können lange HTML-Dokumente, interaktive Erklärungen, Folien oder Decks sein
    • Wenn man Diagramme per SVG erstellen lässt, hilft das bei der Visualisierung
    • Beim Vorbereiten eines Textes zu Prompt Caching wurde etwa die Git-Historie gelesen und eine tiefgehende HTML-Research-Datei erstellt, die sämtliche Änderungen rund um Prompt Caching behandelt
    • Man kann relevanten Code eines Rate Limiters lesen lassen und eine einzelne HTML-Erklärseite erzeugen, die ein Token-Bucket-Flussdiagramm, drei bis vier kommentierte Kern-Codefragmente und unten einen Abschnitt mit Gotchas enthält
    • Es lässt sich für Zusammenfassungen zur Funktionsweise von Features, Konzepterklärungen, wöchentliche Statusberichte, Incident-Reports sowie SVG-Illustrationen, Flussdiagramme und technische Diagramme einsetzen

  • Maßgeschneiderte Bearbeitungsoberflächen

    • Wenn sich das Gewünschte nicht gut nur mit Textfeldern erklären lässt, kann man einen einmaligen HTML-Editor erstellen, der auf die aktuell bearbeiteten Daten zugeschnitten ist
    • Es geht dabei nicht um ein Produkt oder ein wiederverwendbares Tool, sondern um eine einzelne HTML-Datei, die gezielt für ein bestimmtes Datenstück gebaut ist
    • Entscheidend ist, am Ende einen Export wie „copy as JSON“ oder „copy as prompt“ einzubauen, damit das in der UI bearbeitete Ergebnis wieder in Claude Code eingefügt werden kann
    • Man kann etwa 30 Linear-Tickets als ziehbare Karten in den Spalten Now / Next / Later / Cut darstellen und die finale Reihenfolge zusammen mit einer einzeiligen Begründung je Bucket als Markdown kopieren lassen
    • Man kann die Konfiguration von Feature-Flags als formularbasierten Editor aufbauen, nach Bereichen gruppieren, Abhängigkeiten anzeigen, warnen, wenn ein Flag aktiviert wird, obwohl ein vorausgesetztes Flag deaktiviert ist, und nur geänderte Schlüssel als Diff kopieren lassen
    • Beim Anpassen eines Systemprompts kann links ein editierbarer Prompt mit hervorgehobenen Variablen-Slots stehen und rechts drei Beispiel-Eingaben in Echtzeit gerendert werden, ergänzt um Zeichen-/Token-Zähler und Kopier-Buttons
    • Es lässt sich für das Umordnen von Tickets, Testfällen und Feedback, das Bearbeiten strukturierter Konfigurationen, das Anpassen von Prompts, Templates und Formulierungen, die Kuratierung von Datensätzen, das Kommentieren von Dokumenten, Transkripten und Diffs sowie für die Auswahl schwer textuell beschreibbarer Werte wie Farben, Easing-Kurven, Crop-Regionen, Cron-Schedules oder Regex verwenden

Häufige Fragen und Grenzen

  • Markdown verbraucht meist weniger Tokens, aber HTML bietet mehr Ausdrucksstärke und eine höhere Chance, tatsächlich gelesen zu werden, wodurch das Gesamtergebnis besser ausfällt
  • Im 1MM context window von Opus 4.7 fällt der erhöhte Tokenverbrauch im Kontextfenster nicht besonders ins Gewicht
  • Für fast alle Zwecke wurde die Nutzung von Markdown eingestellt; das ist allerdings eine Nutzungsweise, die HTML maximal bevorzugt
  • HTML-Dateien können im lokalen Browser geöffnet werden, man kann Claude auch bitten, sie zu öffnen, und wenn ein teilbarer Link nötig ist, lassen sie sich auf S3 hochladen
  • Das Erzeugen von HTML dauert länger als bei Markdown und kann 2- bis 4-mal so viel Zeit benötigen, aber das Ergebnis wird als den Aufwand wert betrachtet
  • Einer der größten Nachteile ist die Versionsverwaltung, denn HTML-Diffs sind lauter und schwieriger zu reviewen als Markdown
  • Damit Claude HTML nach dem eigenen Geschmack erzeugt, kann ein Frontend-Design-Plugin hilfreich sein
  • Um es an den Stil des Unternehmens anzupassen, kann man Claude die Codebasis ansehen lassen, damit es eine einzelne HTML-Datei für das Designsystem erstellt, die anschließend als Referenz für andere HTML-Dateien dient
  • Mit HTML sinkt die Angst, dass man von Claude geschriebene Pläne nicht tief genug liest und dadurch Entscheidungen einfach überlässt; außerdem bleibt man im Arbeitsprozess mit Claude stärker im Flow

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Wenn man sich zu sehr zu HTML hinbewegt, verliert man womöglich die Fähigkeit, Dokumente gemeinsam mit Menschen und LLMs zu verfassen und zu überarbeiten
    Für einfache beschreibende Texte ist das in Ordnung, aber bei komplexeren Spezifikationen ist die Fähigkeit, direkt in das erzeugte Ergebnis hineinzugehen und es zu korrigieren, sehr wichtig. HTML-Dokumente sind dafür deutlich ungeeigneter als Markdown, und man kann das LLM zwar erneut anweisen, das HTML zu ändern, aber wenn man im Kopf schon genau weiß, was man sagen will, ist das selbst wieder ein Hindernis. Wenn sich dieses Muster verbreitet, wird es wohl weniger gemeinsame Mensch/LLM-Kreativität geben und eher dahin gehen, dass man sogar Ausdruck, Ton und Inhaltsauswahl an das LLM delegiert. Ich war überrascht, dass diese Sorge in den Blog-FAQ nicht auftaucht

    • Markdown unterstützt Inline-HTML für interaktive Elemente, daher könnten Markdown-Dokumente mit bekannten HTML-Templates und einem einfachen Build-Prozess eine interessante Alternative sein
      Zum Beispiel in Form eines einzeiligen pandoc-Befehls
    • Ich denke, es gibt noch eine weitere Stufe darüber. Mit HTML ist vieles möglich, aber es war auch überraschend effektiv, das LLM seine eigene Sprache definieren zu lassen
      Ich baue gerade ein kleines Mobile-Game mit isometrischer Perspektive und Sound. Ich habe Codex gebeten, in vorhandener three.js-Dokumentation Blöcke zu platzieren und ein Tool zu bauen, das mit den Chromium-Entwicklertools Screenshots macht. Daraufhin hat es eine kleine JSON-Struktur erstellt, die Blöcke, Farben und Effekte definiert und ein 2.5D-Tileset ausgibt. Außerdem ließ ich Sounds und Musik in einem uv-Python-Skript definieren, woraufhin es ein YAML-Format erfand, das Rauschen erzeugen kann. Der SVG-Pelican-Test wurde komplett übertroffen, und Codex erzeugte sogar genügend Prototyp-Art für Soldaten, Ritter und Priester sowie einen Prototyp-Soundtrack
    • Wir schreiben HTML seit Jahrzehnten problemlos von Hand. Texteditoren eignen sich hervorragend zum Schreiben von HTML, und es gibt viele Befehle wie automatischen Zeilenumbruch und automatisches Schließen, sodass Lesen und Schreiben einfach ist
    • Das scheint nur zu gelten, wenn man sich selbst auf einen primitiven Fernschreiber-Emulator beschränkt. In einer vernünftigen Coding-Umgebung sollte HTML-Bearbeitung sehr einfach sein, und wenn der Trend zu reichhaltigeren Model-Outputs geht, könnten eingebaute WYSIWYG-Editoren ebenfalls eine Option sein
    • Ich habe vor Kurzem begonnen, HTML in Berichten zu verwenden, halte aber immer eine Markdown-Datei als Zwischenformat und lasse das LLM auf Basis der Tabellen im Markdown eine schickere Version mit SVG-Grafiken und Illustrationen erstellen

  • Ironisch ist, dass es sich hier nicht um eine interaktive HTML-Seite handelt, sondern um einen Twitter-Post mit einem gerenderten HTML-Bild
    Auf einer Plattform für HTML zu argumentieren, deren semantische Struktur noch ärmer ist als die von Markdown, ist am Ende ziemlich komisch

  • Ein Prompt, den ich oft nutze, wenn ich neue Ideen oder Tools ausprobiere, lautet so

    In a single index.html, no dependencies, sparse styling, create an app that

    Schon vor der AI habe ich kleine Tools so gebaut, und ich finde gut, dass ich einem Freund ein Tool per E-Mail schicken und sagen kann: „Wenn du etwas ändern willst, wirf es einfach in ein LLM“

    • Genau so sollte man es machen
      Es ist erstaunlich, wie groß der Bereich ist, den man mit einer einzigen HTML-Datei inklusive Styles und JS abdecken kann, wenn man Dashboards, kleine Apps oder Utilities baut, die mit APIs interagieren oder irgendwo Daten holen. Wenn man sie in den persönlichen ~-Ordner auf dem geteilten Firmenserver wirft, können alle sie sofort ansehen und nutzen
    • Auch wenn ich das Design eines neuen Clients iteriere, baue ich es zuerst in einer einfachen index.html mit Inline-CSS. Wenn mir das Ergebnis gefällt, lege ich die Datei neben die Template-Dateien des Projekts und bitte das LLM, das Design aus index.html in die Templates zu übertragen
    • Ich habe über diesen Use Case früher nie richtig nachgedacht, deshalb kam ich mir etwas dumm vor. Dass das nützlich ist, liegt so offensichtlich auf der Hand
      Bisher lag mein Fokus beim Einsatz von LLMs auf der „App“ selbst, nicht auf den Hilfswerkzeugen rundherum. Diese Hilfswerkzeuge müssen nicht ausgereift sein oder jeden Fall abdecken, sie müssen nur gut genug funktionieren, um nützlich zu sein. Danach wirft man sie weg und baut morgen neue
    • Ich habe diesen Trick vor langer Zeit herausgefunden und eine ganze Menge Rechner für analoge Elektronik gebaut: https://cofree.coffee/~solomon/calculators/
      Es ist sehr praktisch, solche Tools schnell zusammenzustecken und auf einer statischen Website zu veröffentlichen
    • Im Claude-Web mache ich es genauso, wenn ich HTML anfordere. Es wird als Artifact erzeugt, daher ist es gut möglich, dass das Modell auf dieses Muster besonders gut trainiert ist

  • Webtechnologien haben wirklich sehr vieles richtig gemacht. Viele beschweren sich, aber es ist beeindruckend
    In meinem letzten Job hatte ich mit vibe-gecodeten Apps zu tun und habe am Ende genau deswegen gekündigt. Es gab eine Next.js-Single-Page-Frontend-Struktur mit separatem API-Backend, sodass die benutzerseitigen URLs nicht zu den Backend-Endpunkten passten. Weil AI überall React Hooks einsetzt, liegt der Zustand im Speicher, und URL-basiertes Routing existiert nur, wenn man es bewusst entwirft. Deshalb entstehen Links nicht kostenlos, und Nutzer konnten auf nichts außer dem obersten Einstiegspunkt verlinken. Links also. Gerade bei internen Tools sollte alles verlinkbar sein, damit Zusammenarbeit und Problemlösung einfach bleiben. Dass man einheitliche Ressourcenadressen und Verben braucht, war schon vor 30–40 Jahren ein wirklich guter Designgedanke

    • Heißt das, dass die URL nicht aktualisiert wurde, wenn man zu einer anderen Seite oder in einen anderen Tab gewechselt hat?

  • Bei HTML vs. Markdown fehlen hier ein paar Kompromisse. HTML ist viel weniger tokeneffizient, und präzises Feedback zu einem HTML-Plan zu geben ist schwieriger als bei Markdown
    Beide Trade-offs spielen Anthropic in die Hände. Wenn HTML als Medium verwendet wird, steigt der Tokenverbrauch, und vermutlich investiert Anthropic ohnehin in Tools zum Kommentieren oder Markieren von HTML als Teil von Claude Design, was den Lock-in noch verstärken könnte. Entweder Zufall oder brillante Strategie

    • Es ist zwar etwas weniger effizient, aber solange Struktur und visuelle Elemente nicht extrem umfangreich sind, ist der Unterschied nicht riesig
      Ich verstehe auch nicht ganz, warum präzises Feedback dazu schwerer sein soll als bei Markdown. Man kann Tags mit id, Abschnitten usw. versehen
    • HTML hat außerdem einen größeren Angriffsbereich für Code-Ausführungs-Schwachstellen. Reiner Text ist harmlos

  • Obwohl ich seit Jahrzehnten mit HTML arbeite, ist Markdown für einfache Dokumente immer noch schneller. Ein Mittelweg wäre gut, und tatsächlich gibt es schon funktionsreichere Varianten wie GitHub Markdown
    Man kann Mermaid einbetten oder mit etwas wie MDX Komponenten dazumischen, wenn man sie braucht. Soweit ich weiß, verwendet readme.com intern ebenfalls MDX. Wenn man Karten oder Layouts braucht, könnte man auch Komponenten auf Basis von etwas wie Bootstrap einfügen. Was jetzt noch fehlt, ist nur die Unterstützung in der Oberfläche. Reines HTML kann ohnehin schon gerendert werden, daher dürfte es nicht allzu schwer sein, stärkeres Markdown hinzuzufügen

    • Ich finde, MDX ist der perfekte Mittelweg. Wegen dieses Kommentars werde ich wohl anfangen, MDX statt normalem Markdown zu verwenden

  • Sowohl die ursprüngliche Markdown-Spezifikation [1] als auch CommonMark [2] definieren Unterstützung für Inline-HTML ausdrücklich. Je nach Anwendungsfall kann man damit also ein gutes Stück der Vorteile beider Seiten mitnehmen
    Meistens verwendet man normale Markdown-Überschriften und Absätze, und wenn man Bilder und Tabellen einfügt, bleibt der Text auch ohne HTML-Tags in seiner Rohform gut lesbar. Wenn man etwas wie das vom Autor erwähnte SVG einfügen will, bettet man das SVG einfach direkt ein, und Betrachter können das Markdown mit ihrem bevorzugten Viewer rendern. Wenn man in VS Code eine rohe Markdown-Datei betrachtet und auf HTML-Tags stößt, reicht Cmd+Shift+V, um die Vorschau zu öffnen. Natürlich ist das schwer umzusetzen, wenn man eine echte Webseite mit interaktiven Buttons und vollständigem Custom-Styling will, aber wenn es hauptsächlich um Text, Bilder und Tabellen geht und man hier und da nur zusätzliche Elemente einstreuen möchte, kommt man damit ziemlich weit
    [1] https://daringfireball.net/projects/markdown/syntax#html
    [2] https://spec.commonmark.org/0.31.2/#html-blocks

    • Ich finde, Markdown-Dokumente sollten keine Vorschau brauchen. Sonst kann man auch einfach HTML-Dokumente erstellen

  • Seit Januar treibe ich diese Methode für Nicht-Coding-Zwecke stark voran. Die entscheidende Eigenschaft ist, dass sie eine einzige Quelle der Wahrheit ist, die editierbar, für LLM und Menschen verständlich, renderbar und schrittweise veränderbar ist
    Ich spreche oft mit ganz normalen Leuten über AI-Arbeit und dränge mich manchmal wie ein Anthropologe in Gespräche über AI auf der Straße ein. HTML-Artifacts sind wie die neue URL-Leiste des Browsers. So wie manche Nutzer die Adressleiste eigentlich für Google halten. Viele Leute sagen heute, dass Dinge wie „Spreadsheet“, „Präsentation“, „einseitige Marketing-Zusammenfassung“, „Slideshow“, „Wettbewerbsanalyse“ oder „HVAC-Systemdiagramm“ im ChatGPT- oder Claude-Web kaum funktioniert haben, während das Erstellen neuer Dokumente mit Claude Code oder OpenClaw wie ein Wunder wirkte
    Wenn man nachfragt, was das eigentliche Dokument war und worin der Erfahrungsunterschied bestand, muss man oft stark nachbohren oder es sich direkt zeigen lassen, weil noch das Vokabular des Computings fehlt. Am Ende landet man aber immer bei HTML als Artifact. Die gute Erfahrung kommt daher, dass eine HTML-Datei im Dateisystem (+CSS+Bilddateien) mit hochwertigem Sofort-Rendering iterativ überarbeitet wird und man bei Bedarf auch etwas JavaScript darüberstreuen kann. Wenn ein Git-System vorhanden ist, passiert Versionskontrolle vielleicht sogar unbemerkt. Wenn nicht, empfehle ich, Checkpoints zu erstellen. Für normale Nutzer könnte Versionskontrolle der nächste Lernschritt sein
    Demgegenüber besteht die im Web eingebettete Erfahrung darin, mehrfach auf DOCX/PPTX/XLSX herumzustochern, die im Kontextfenster verbleiben, und mit einem verschwommenen Begriff von lokalem Speicher umzugehen. Das gilt sogar dann, wenn im Sidebar eigentlich HTML gerendert wird. Ein HTML-Workflow erleichtert auch die Integration anderer Medien erheblich. Im Grunde ist diese Art von Präsentationsarbeit das vibe coding der breiten Masse, und man muss nicht alle Schildkröten darunter kennen. Wenn man will, kann man es aber öffnen, ändern oder leicht an einen anderen Agenten weitergeben. Ein System, das für kollaborative multimediale Kommunikation geschaffen wurde, erweist sich nun also als nützlich dafür, dass maschinelle Intelligenz unsere Kommunikation unterstützt

  • Früher haben wir bei unserem (https://www.definite.app/) Agenten Berichte und Dashboards als YAML-Spezifikation schreiben lassen, die dann von einem Frontend-Framework gerendert wurde
    Wenn ein Nutzer zum Beispiel sagte: „Erstelle einen Bericht, der den monatlichen Umsatz und die Bestellzahlen zeigt und die letzten 100 Bestellungen darstellt“, dann schrieb der Agent eine Spezifikation, die im Frontend gerendert wurde. Das war schnell, aber wir wurden mit Funktionswünschen überhäuft, die das Framework rendern können musste. Dinge wie: „Hier möchte ich kein Label“, „Dort brauche ich ein Label“ oder „Kann dieses Diagramm ein Heatmap sein?“. Vor ein paar Monaten haben wir den Agenten stattdessen einfach HTML schreiben lassen. Die Erzeugung dauert länger, aber es gibt keine Grenzen mehr bei der Anpassung. Auch der neue Ansatz hat viele Probleme, etwa dass nichttechnische Nutzer ihre selbstgebauten Monster-Apps debuggen müssen, aber insgesamt gefällt er den Kunden deutlich besser

    • Wie verhindert ihr in diesem Fall Prompt Injection?

  • Lange Agent-Outputs lese ich mit VIM und macOS Quick Look (inklusive Erweiterungen für Markdown-Rendering) oder ich kopiere sie in MarkEdit mit Vorschaupanel
    Im schlimmsten Fall lässt man den Agenten einfach eine schlichte lokale Webseite bauen, die Markdown interpretiert und rendert. Markdown wurde als Kurzform der Web-Syntax erfunden [0], und genau dafür ist es da. Die Tokens und Zeit, die es kostet, den Agenten einfach grundlegendes Markdown in HTML umwandeln zu lassen, dürften größer sein als bei diesen Methoden
    0. https://daringfireball.net/projects/markdown/

    • Wahrscheinlich verbraucht das tatsächlich mehr Tokens, aber der Autor arbeitet bei Anthropic, daher hat er die Tokenkosten vermutlich nie selbst bezahlen müssen
    • Wenn man bis zum Ende auf Vibe fahren will, könnte man den Bot doch auch einfach bitten, lange Outputs zusammenzufassen, oder?
      Die Bot-Nutzung wird wirklich chaotisch und selbstreferenziell
    • Ich würde gern wissen, welche Quick-Look-Erweiterung das ist. Ich habe nach einer guten gesucht