Die ersten langweiligen Ingenieursarbeiten der KI beginnen mit TikZ

Zwei Uhr morgens, noch sechs Stunden bis zur Paper-Deadline. Du starrst auf die dritte Abbildung — ein Neuronales-Netzwerk-Diagramm — und feilst zum x-ten Mal an \draw-Koordinaten. Von (4.5,3.2) auf (4.6,3.1) ändern, kompilieren, PDF prüfen, falsch, zurückändern, erneut kompilieren. Du erinnerst dich an die Worte deines Betreuers: „Die Abbildungen müssen schön sein, sonst liest der Reviewer nicht gründlich.” Also feilst du weiter, der Zeiger rückt auf drei.

Jeder, der schon einmal eine LaTeX-Publikation geschrieben hat, kennt diese Situation. TikZ ist der De-facto-Standard für akademische Grafiken im LaTeX-Ökosystem, aber es ist eine „Grafiksprache” und kein „Grafikwerkzeug” — der Autor Till Tantau merkt in der Dokumentation sogar ausdrücklich an: TikZ ist kein Zeichenprogramm. Man zeichnet mit Code, und für jede Koordinatenanpassung muss das gesamte Dokument neu kompiliert werden. Die akademische Welt hat das jahrzehntelang so ertragen.

Im Juni 2026 veröffentlichte ein Entwickler namens Dominik Peters auf HN ein Projekt: den TikZ Editor — ein WYSIWYG-Tool für TikZ-Grafiken, bei dem man Knoten wie in Figma per Drag-and-Drop verschieben kann und der Quellcode synchron aktualisiert wird. 293 Punkte, 58 Kommentare. Was das Projekt wirklich diskussionswürdig macht, ist, wie es entstanden ist.

„Dinge, die kein Mensch tun wollen würde”

In seinem Show-HN-Beitrag formuliert Dominik Peters den Kernsatz, der gewissermaßen gleich die ganze These des Projekts liefert:

This approach essentially required reimplementing a large fraction of TikZ, which is the kind of task that no human would ever want to do.

Übersetzt in eine noch direktere Aussage: Um einen Drag-and-Drop-Editor für TikZ zu bauen, muss man den Großteil der TikZ-Grundmechanismen neu implementieren — Parser, Renderer, Layout-System, Farbverarbeitung. Das ist eine Ingenieursaufgabe mit absurd niedrigem ROI, die kein vernünftiger Mensch annehmen würde.

Aber Codex hat sie angenommen. Das gesamte Projekt — das Frontend-Interface, die Tauri-Desktop-App, der TikZ-Syntaxparser, die JavaScript-basierte SVG-Rendering-Pipeline, mehrere Formatkonverter (SVG/PPTX/IPE → TikZ) und die geradezu wahnwitzigen „Nebenquests” — wurde fast vollständig von Codex generiert. Dominik begann im Februar 2026 mit dem Projekt und verbrauchte rund 700 Millionen Token, was nach API-Preisen etwa 15.000 $ entspricht — tatsächlich zahlte er nur etwa 500 $ für sein ChatGPT-Abonnement.

Die Logikkette ist klar: Wenn die Entwicklungskosten gegen Null gehen, werden Projekte, die zuvor „nicht lohnend” waren, plötzlich lohnend. Diese These ist an sich nicht neu. Aber der TikZ Editor liefert einen Fall mit genügend Präzision, dass ich im Detail auseinandernehmen kann, welche Art von Ingenieursarbeit KI-Codierwerkzeuge tatsächlich übernehmen — und welche nicht.

Zwei Kategorien ausgelagerter Ingenieursarbeit

Die Arbeit, die in den TikZ Editor geflossen ist, lässt sich in zwei Kategorien unterteilen.

Erste Kategorie: Mechanische Formatkonvertierung. Dazu gehören die Konverter SVG → TikZ, PPTX → TikZ, IPE → TikZ und so weiter. Die logische Komplexität dieser Konverter ist nicht gering — SVG-Pfadbefehle auf TikZs \draw-Syntax abbilden, das Formmodell von PowerPoint in TikZ-Knoten und -Pfade übersetzen — aber im Kern handelt es sich um Abbildungsregeln und Randbedingungen. Die Regeln sind enumerierbar, die Ränder mit Testfällen abdeckbar. Ein erfahrener Ingenieur würde dafür vielleicht drei Wochen brauchen und danach nicht das Gefühl haben, tiefere Einsichten gewonnen zu haben. Bei dieser Art von Arbeit sind KI-Codierwerkzeuge relativ zuverlässig, denn die Verifikation ist binär: Kompiliert das konvertierte TikZ? Stimmt das Rendering mit dem Originalformat überein?

Zweite Kategorie: Neuimplementierung klassischer Algorithmen in fremden Domänen. Das ist die interessantere Kategorie. Dominik erwähnt mehrere „Nebenquests”, von denen zwei es wert sind, näher betrachtet zu werden:

1. Neuimplementierung des LaTeX-Zeilenumbruch-Algorithmus (Knuth-Plass). Um mehrzeilige Textknoten zu unterstützen, muss der TikZ Editor browserseitig (in JavaScript) korrekten Zeilenumbruch und Silbentrennung implementieren. Das bedeutet, den 1981 von Donald Knuth und Michael Plass veröffentlichten Dynamic-Programming-Zeilenumbruch-Algorithmus nachzubauen — ein Algorithmus, der die „Hässlichkeit” (badness) des gesamten Absatzes global optimiert und nicht einfach greedy zeilenweise auffüllt. Das CSS-text-align: justify des Browsers macht nur gierigen Einzelzeilenumbruch mit grobem Ergebnis; TeX’ Algorithmus berechnet das globale Optimum und muss dabei die Dehnung und Stauchung des Wortzwischenraums (glue), Silbentrennungskosten und eine ästhetische Bewertungsfunktion für den gesamten Absatz berücksichtigen.

2. Implementierung des red!20!black-Farbmischsystems. In LaTeX-Publikationen werden Farben häufig mit der Syntax {Farbe1}!{Anteil}!{Farbe2} gemischt, z. B. red!20!black für 20 % Rot gemischt mit 80 % Schwarz. Einen Farbwähler im Browser zu implementieren, der diese Syntax unterstützt, bedeutet, das exakte Mischmodell aus dem xcolor-Paket zurückzuentwickeln, einschließlich RGB/CMYK-Konvertierung, Transparenzberechnung und der !-Operator-Verschachtelung (etwa red!20!blue!50!green).

Ich fasse diese beiden unter einer Kategorie zusammen, weil sie eine Eigenschaft teilen: Wenn du sie nicht implementierst, ist die Funktionalität unvollständig; wenn du sie implementierst, wird die Kernkompetenz dadurch nicht klarer. Das ist typische „langweilige Ingenieursarbeit” — nicht unwichtig, aber mit zu niedrigem ROI. Die erste Reaktion eines menschlichen Entwicklers auf eine solche Aufgabe ist: „Gibt es eine fertige Bibliothek, mit der ich das umgehen kann?” Falls nicht, wird dieses Feature häufig als WONTFIX markiert.

Die Performance von KI-Codierwerkzeugen in diesem Szenario ist bemerkenswert. Dominik beschreibt in den HN-Kommentaren seinen konkreten Workflow: Er ließ den LaTeX-Renderer (dvisvgm) und den JavaScript-Renderer jeweils dieselben TikZ-Grafiken verarbeiten, verglich die Unterschiede manuell, meldete die Abweichungen an Codex und ließ es nachbessern. Er versuchte, multimodale Modelle für den automatischen Vergleich einzusetzen — mit schlechtem Ergebnis: Die Modelle sind „immer noch so etwas wie blind und halten selbst zwei offensichtlich unterschiedliche Bilder für identisch”.

Hier liegt ein subtiles Detail: Die Rolle des Menschen im Loop ist das Urteilen. Welcher Rendering-Unterschied ein Bug ist, welcher eine normale Abweichung durch Font-Rendering, welcher akzeptabel ist. Der Mensch ist nicht verschwunden, sondern vom Implementierer zum Qualitätsrichter geworden.

Armin Ronachers zweiter Halbsatz

Einen Tag vor der Veröffentlichung des TikZ Editors schrieb Armin Ronacher, der Autor von Flask und Jinja2, in seinem Blogbeitrag „The Coming Loop” eine Passage, die damit ein präzises Zwiegespräch führt:

I absolutely love loops already that take the boring parts out of my day to experiment and measure and to give me ideas.

Dann wendet er das Blatt:

On the other hand using that same looping methodology to write lasting code does not yet sit well with me.

Ronachers Kernbedenken: Wenn der Harness-Loop ununterbrochen läuft, in jeder Iteration eine lokale Verteidigung hinzufügt und Code ohne menschliche Aufsicht wächst, wird das Endprodukt zu einem Organismus, der sich selbst warten muss. Er nennt das den Übergang von „Software als deterministische Maschine” zu „Software als Organismus” — man überwacht ihn, man stabilisiert ihn, aber man versteht ihn nicht.

Doch ein anderer Satz von ihm könnte entscheidender sein:

Porting code is one of them. There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust. I have used it with success myself to port MiniJinja to Go.

Ronacher sieht den Loop in zwei Szenarien bereits als ausgereift: Code-Transformation (Portierung, Benchmarking, Sicherheitsscans) und Code, der nicht langlebig sein muss (Proof-of-Concept, experimentelle Exploration).

Hier ergibt sich eine interessante Entsprechung, die ich versuchsweise in einer Tabelle festhalte:

Kategorie	Repräsentative Aufgabe	KI geeignet?	Grund
Mechanische Transformation	Code portieren, Formatkonvertierung	Geeignet	Abbildungen enumerierbar, Verifikation binär
Langweilige Ingenieursarbeit	Knuth-Plass-Neuimplementierung, Farbmischung	Geeignet	Logik determiniert, Schnittstellen klar, ROI hält Menschen ab
Architekturentscheidungen	Projektstruktur, Abstraktionsebenen	Ungewiss	Beinhaltet Werteabwägungen
Designentscheidungen	Welches Diagramm, wie layouten	Nicht ersetzbar	Erfordert Absicht und ästhetisches Urteil

Der TikZ Editor deckt genau die ersten beiden Zeilen ab. Formatkonvertierung in der ersten, Algorithmus-Neuimplementierung in der zweiten Zeile. Die Architektur des Projekts hingegen — Dominik sagt, er habe „zuerst mit einem einfachsten Parser → SVG-Renderer + grundlegendem Drag-and-Drop die Machbarkeit der Architektur validiert” — diese Entscheidung traf er selbst. Codex fragte ihn nur im Plan-Modus mit Multiple-Choice-Optionen um seine Meinung.

Welches Diagramm gezeichnet wird, ist die Entscheidung des Nutzers. Der Editor liefert das Werkzeug, nicht die Ästhetik.

„Der Loop braucht Klarheit” — dieser Satz passt exakt auf den TikZ Editor

Ronacher schrieb am Ende seines Artikels einen Satz, den ich dreimal lesen musste:

Adopting the idea of harness loops means that the harness decides when work is finished.

Bei der Entwicklung des TikZ Editors lag die Entscheidung, „wann es repariert ist”, durchgehend bei Dominik. Er legte die Ausgaben beider Renderer nebeneinander, starrte auf die Unterschiede und sagte Codex, wo es noch nicht stimmte. Die Abbruchbedingung des Loops wurde von jemandem definiert, der weiß, wie die korrekte Ausgabe aussehen muss. Das ist genau das, was Ronacher mit „die Voraussetzung für den Loop ist Klarheit” meint — man muss genügend schäbige Versionen durchlaufen haben, um zu wissen, was „richtig” ist. Ein Agent kann den langweiligen Teil des Trial-and-Error-Prozesses verkürzen, aber er kann für dich nicht definieren, was „richtig” ist.

Dieselbe Logik gilt für die Nutzerseite des TikZ Editors. Ein Wissenschaftler öffnet den Editor und will eine Bloch-Kugel-Darstellung eines Quantenzustands zeichnen oder ein Self-Attention-Diagramm eines Transformers — wie diese Diagramme aussehen, ist eine Absicht, die zuerst in seinem Kopf existiert. Der Agent kann nicht für dich entscheiden, wie das zentrale Diagramm deines Papers layoutet sein soll, welcher Fluss betont werden muss, ob die Farbe Grün oder Grau sein soll. Er kann dir nur ersparen, nachdem du die Idee hast, Koordinaten wie \draw[->] (-0.866,-0.5) -- (0.866,0.5) von Hand zu schreiben.

Anders gesagt: Langweilige Ingenieursarbeit kann an die Maschine ausgelagert werden, die Bedeutungsentscheidung muss beim Menschen bleiben. Das ist die präzise Projektion der aktuellen Fähigkeitsgrenze von KI-Codierwerkzeugen auf den konkreten Fall des TikZ Editors.

Der optimistische Teil und der ungewisse Teil

Ich will diese Analyse nicht zu einem billigen Mittelweg verkommen lassen — „KI hat gute und schlechte Seiten”. Der TikZ Editor ist ein handfest gutes Werkzeug. Er füllt ein jahrzehntelang ungelöstes Problem der akademischen Welt mit Code, und zwar als Open Source (MIT-Lizenz), plattformübergreifend (Web + Linux/Windows/macOS-Desktop) und mit der Fähigkeit, ganze .tex-Paper-Dateien zu öffnen und die darin enthaltenen TikZ-Grafiken direkt zu bearbeiten. Einer der meistgevoteten HN-Kommentare stammt von einem deutschen Doktoranden: „Alle MINT-Studierenden und Forschenden danken dir.”

Der ungewisse Teil: Wie weit dieses Paradigma trägt.

Dominik verbrauchte 700 Millionen Token für dieses Projekt. Ronacher sorgt sich, dass die Codequalität der Modellausgaben abnimmt — übermäßig defensiv, lokal denkend, Invarianten vermeidend. Doch im Fall des TikZ Editors bewertet ein Beobachter auf GitHub die Code-Struktur als „ziemlich gut aussehend”. Worin liegt die Diskrepanz?

Meine Vermutung: Die Klarheit der Aufgabengrenze bestimmt die Ausgabequalität. Die Eingabe des Knuth-Plass-Algorithmus sind Text und Zeilenbreite, die Ausgabe sind Zeilenumbruch-Positionen — die Korrektheit ist im Rendering-Ergebnis visuell überprüfbar. Die Eingabe der Farbmischung sind zwei Farben und ein Verhältnis, die Ausgabe ist eine Farbe — richtig oder falsch erkennt man auf einen Blick. Die Eingabe des TikZ-Parsers ist Text, die Ausgabe ist ein AST — solange das Rendering nicht abstürzt und die Koordinaten stimmen, ist es korrekt.

Wenn der Verifikationsstandard visualisierbar ist, ist der Loop zuverlässiger. Wenn der Verifikationsstandard Erfahrungsurteil erfordert, braucht der Loop den Menschen.

Das ist keine Frage des „Glaubens” oder „Nicht-Glaubens” an KI. Es ist eine Ingenieursfrage: Welche Art von Aufgabe kann automatisch verifiziert werden? Lautet die Antwort „automatisch verifizierbar”, ist der Agent geeignet. Lautet sie „erfordert menschliches Urteil”, besteht der Wert des Agenten darin, jede Runde des Zyklus zu beschleunigen, aber nicht den Schlusspunkt zu setzen.

Von „langweiliger Ingenieursarbeit” zu „lohnender Ingenieursarbeit”

Zurück zu Dominiks Satz — „Das ist eine Aufgabe, die kein Mensch machen wollen würde.” Die interessanteste Implikation dieses Satzes: Nicht weil sie unmöglich ist, sondern weil niemand sie machen will.

Der TeX-Zeilenumbruch-Algorithmus existiert seit 1981, die Algorithmusbeschreibung in der öffentlichen Literatur ist vollständig, und JavaScript-Implementierungen gibt es mehr als eine. Das Farbmischmodell von red!20!black steht glasklar im xcolor-Quellcode. Das Problem ist nicht „niemand kann es implementieren”. Das Problem ist: „Niemand will vier Wochen damit verbringen, etwas zu tun, das nur 2 % zum Kernwert des Endprodukts beiträgt.”

KI-Codierwerkzeuge verändern diese Rechnung. Wenn der Zeitaufwand für 2 % Grenzwert von vier Wochen auf vier Stunden oder gar vier Minuten sinkt, wechselt die Aufgabe von „nicht lohnend” zu „nebenbei erledigt”. Das bedeutet nicht, dass die Rolle des Menschen in der Softwareentwicklung verschwindet — es bedeutet, dass der Mensch sich stärker auf die Entscheidung was zu tun ist konzentrieren kann, während er das langweilige Wie an die Maschine delegiert.

Ronachers letzter Satz beschreibt in gewissem Sinne die Kehrseite derselben Medaille: Wenn auch das „Was” an die Maschine delegiert wird, verlieren wir möglicherweise die Fähigkeit, das System zu verstehen. Diese beiden Sätze nebeneinander kommen der Wahrheit näher als jeder einzelne für sich.

Die GitHub-Seite des TikZ Editors wird weiter aktualisiert. Dominik sagt, als Nächstes könnte pgfplots-Unterstützung hinzukommen. Ich werde nicht sagen: „KI-Coding verändert die Softwareentwicklung grundlegend” — das ist zu pauschal. Aber ich kann sagen: Wenn ein TeX-Zeilenumbruch-Algorithmus, den kein Mensch neu implementieren wollte, von einem Agenten in wenigen Dialogen umgesetzt wird und mehrzeilige Knoten browserseitig korrekt rendert, dann ist eine bestimmte Schwelle überschritten worden. Die relevante Frage ist nicht mehr „Kann KI coden?”, sondern: „Welche Ingenieursentscheidungen darf der Mensch nicht auslagern, und welche sind egal?”

Genau diese Unterscheidung könnte in den kommenden Jahren die wichtigste Frage der Softwareentwicklung sein.