AI’s First Wave of Boring Engineering, Starting with TikZ

It’s 2 AM. Six hours until the paper deadline. You’re staring at the third figure — a neural network architecture diagram — making the nth micro-adjustment to \draw coordinates. Change (4.5,3.2) to (4.6,3.1). Compile. Check the PDF. Nope. Change it back. Recompile. You remember your advisor saying “figures need to look good or reviewers won’t read carefully,” so you keep tweaking. The clock ticks past three.

Everyone who’s written a LaTeX paper has lived through this scene. TikZ is the de facto standard for drawing academic figures in the LaTeX ecosystem, but it’s a “graphics language” rather than a “graphics tool” — the author Till Tantau even explicitly states in the documentation: TikZ ist kein Zeichenprogramm (TikZ is not a drawing program). You draw with code, and every coordinate tweak requires recompiling the entire document. Academia has shouldered this burden for decades.

In June 2026, a developer named Dominik Peters posted a project on HN: TikZ Editor — a WYSIWYG TikZ figure editor where you can drag nodes like Figma, with source code updating in real time. 293 points, 58 comments. What made this project worth discussing was how it was built.

”The Kind of Task No Human Would Want to Do”

Dominik Peters dropped a line in his Show HN post that essentially delivers the project’s core thesis:

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

Translated into plainer terms: to build a drag-and-drop TikZ editor, you need to reimplement most of TikZ’s underlying machinery — parser, renderer, layout system, color handling. This is an engineering task with absurdly low ROI. No reasonable person would take it on.

But Codex did. The entire project — the frontend, the Tauri desktop app, the TikZ syntax parser, the JavaScript-based SVG rendering pipeline, multiple format converters (SVG/PPTX/IPE → TikZ), and those borderline-insane “side quests” — was almost entirely generated by Codex. Dominik started pushing on this project in February 2026, consuming approximately 700 million tokens, which at API pricing would be around $15,000 — though he actually paid only about $500 through a ChatGPT subscription.

The logic chain is clear: when development cost approaches zero, projects that were previously “not worth doing” suddenly become worth doing. This proposition isn’t new. But TikZ Editor provides a case study of sufficient precision that we can dissect exactly what kind of engineering labor AI coding tools took over — and what they didn’t.

Two Categories of Outsourced Engineering Work

The work involved in implementing TikZ Editor falls into two categories, and it’s worth making the distinction.

Category one: mechanical format conversion. This includes SVG-to-TikZ, PPTX-to-TikZ, IPE-to-TikZ, and other converters. The logical complexity of these converters isn’t trivial — SVG path commands mapping to TikZ \draw syntax, PowerPoint’s shape model translating into TikZ nodes and paths — but they’re fundamentally mapping rules and boundary-condition engineering. Rules are exhaustible. Boundary cases are coverable. You can imagine an experienced engineer spending three weeks on this and, upon finishing, not feeling like they’d gained any profound insight. For this kind of work, AI coding tools are relatively reliable, because verification is binary: did the converted TikZ compile? Does the rendered output match the original format?

Category two: reimplementing classic algorithms in unfamiliar domains. This is the more interesting category. Dominik mentioned several “side quests” in his post, two of which are worth unpacking:

1. Reimplementing LaTeX’s line-breaking algorithm (Knuth-Plass). To support multi-line text nodes, TikZ Editor needed to implement correct line-breaking and hyphenation in the browser (JavaScript environment). This meant reproducing the dynamic-programming line-breaking algorithm published by Donald Knuth and Michael Plass in 1981 — an algorithm that globally optimizes a paragraph’s “badness” score, not a simple greedy line-fill. Browser CSS text-align: justify only does per-line greedy breaking, with rough results; TeX’s algorithm computes a global optimum, handling inter-word glue stretch and shrink, hyphenation penalties, and an aesthetic scoring function for the entire paragraph.

2. Implementing the red!20!black color mixing system. In LaTeX papers, colors often use the {color1}!{ratio}!{color2} syntax for mixing, e.g., red!20!black means 20% red mixed with 80% black. Implementing a color picker in the browser that supports this syntax meant reverse-engineering the exact mixing model from the xcolor package, handling RGB/CMYK conversion, alpha calculations, and nesting of the ! operator (like red!20!blue!50!green).

I group these two together because they share a property: if you don’t do them, the feature is incomplete; if you do them, your core capability doesn’t become any clearer as a result. This is classic “boring engineering” — not unimportant, but the ROI is too low. A human engineer’s first reaction to such a task is “is there an existing library I can use to work around this?” If not, the feature often gets marked WONTFIX.

AI coding tools’ performance in this kind of scenario is rather intriguing. Dominik shared his specific workflow in the HN comments: he first had a LaTeX engine (dvisvgm) and the JavaScript renderer process the same batch of TikZ figures, then manually compared the differences, telling Codex where things were wrong and asking it to go back and fix them. He tried having multimodal models do the comparison automatically — it didn’t work well. The models “are still somewhat blind, and considered two clearly different images to be identical.”

There’s a subtle detail here: the human in the loop is doing judgment. Deciding which rendering discrepancy is a bug, which is normal font-rendering variation, which is acceptable. The human didn’t disappear — they just shifted from implementer to quality arbiter.

The Second Half of Armin Ronacher’s Sentence

The day before TikZ Editor was posted, Flask and Jinja2 author Armin Ronacher wrote something on his blog “The Coming Loop” that forms a precise dialogue with this story:

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

Then he pivots:

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

Ronacher’s core concern is this: when a harness loop runs continuously, each iteration appending a local defense, code growing unseen by human eyes, the final product becomes an organism that needs itself to maintain it. He calls this “software shifting from a deterministic machine into an organism” — you monitor it, you stabilize it, but you don’t understand it.

But another line of his may be more crucial:

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 believes loops already work well in two scenarios: code transformation (including porting, benchmarking, security scanning) and code that doesn’t need to be long-lived (proof-of-concept, experimental exploration).

An interesting correspondence emerges here. Let me draw it out:

Category	Representative Task	Is AI Good at It?	Why
Mechanical Transformation	Porting code, format conversion	Good	Mappings are exhaustible, verification is binary
Boring Engineering	Knuth-Plass reimplementation, color mixing	Good	Logic is deterministic, interface is clear, ROI makes humans unwilling to invest
Architectural Decisions	Project structure, abstraction levels	Uncertain	Involves value trade-offs
Design Decisions	What figure to draw, how to lay it out	Cannot replace	Requires intent and aesthetic judgment

TikZ Editor happens to span the first two rows. Format conversion sits in row one, algorithm reimplementation in row two. And the project’s architecture — Dominik said he “first validated architectural feasibility with a minimal parser → SVG renderer + basic drag-and-drop” — that decision was his own. Codex only sought his input in plan mode as a multiple-choice question.

What figure to draw is the user’s decision. The editor provides a tool, not an aesthetic.

”Loops Need Clarity” — This Judgment Lands Perfectly on TikZ Editor

Ronacher wrote a line at the end of his post that I read three times:

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

In the development of TikZ Editor, “when is it fixed” was always Dominik’s call. He put the two renderer outputs side by side, stared at the differences, and told Codex what was still wrong. The loop’s stopping condition was defined by someone who knew what the correct output should look like. This is what Ronacher means by “the prerequisite for a loop is clarity” — you have to go through enough broken versions to know what “right” looks like. An agent can shorten the boring parts of the trial-and-error process, but it can’t define “right” for you.

This logic also applies on the user side of TikZ Editor. An academic opens the editor. They want to draw a Bloch sphere representation of a quantum state, or a self-attention mechanism diagram for a Transformer — what these figures look like is an intent that already exists in their mind. An agent can’t decide for you how the core figure of your paper should be laid out, which flow needs emphasis, whether the color should be green or gray. It can only let you, after you have the idea, avoid handwriting \draw[->] (-0.866,-0.5) -- (0.866,0.5) coordinates.

In other words: boring engineering can be outsourced to machines. Judgment of meaning must stay with humans. This is the precise projection of current AI coding tool capability boundaries onto the concrete case of TikZ Editor.

The Optimistic Part, and the Uncertain Part

I don’t want to write this analysis as cheap centrism — “AI has good sides and bad sides.” TikZ Editor is genuinely great. It fills a decades-long unsolved problem in academia with code, and it does so under an open-source license (MIT), with multi-platform support (Web + Linux/Windows/macOS desktop), and can even open an entire paper .tex file and directly edit the TikZ figures inside. One of the top-voted HN comments came from a German graduate student: “All STEM students and researchers thank you.”

The uncertain part: how far can this paradigm go?

Dominik burned 700 million tokens on this project. Ronacher worries that model-generated code quality is regressing — overly defensive, locally reasoned, avoiding invariants. But on this specific case, a GitHub observer commented that “the code structure looks quite good.” Where’s the gap between these assessments?

My guess: the clarity of the task boundary determines output quality. The Knuth-Plass algorithm takes text and line width as input, outputs break positions — correctness can be visually verified in the rendered output. Color mixing takes two colors and a ratio, outputs a color — right or wrong is obvious at a glance. The TikZ parser takes text, outputs an AST — as long as rendering doesn’t break and coordinates match, it’s correct.

When the verification criterion can be visualized, the loop is more reliable. When the verification criterion requires experiential judgment, the loop needs a human.

This isn’t a proposition about whether to “trust” AI or not. It’s an engineering proposition: what kind of task can be automatically verified? If the answer is “can be automatically verified,” the agent is suited to take over. If the answer is “requires human judgment,” the agent’s value is accelerating each cycle of the loop, but not drawing the period for you.

From “Boring Engineering” to “Engineering Worth Doing”

Let’s return to Dominik’s line — “this is the kind of task no human would want to do.” The most interesting subtext of this statement is: not because it can’t be done, but because nobody wants to do it.

TeX’s line-breaking algorithm has existed since 1981. The algorithm is fully described in the public literature. JavaScript implementations exist — more than one. The red!20!black color mixing model is clearly documented in xcolor’s source code. The problem isn’t “nobody can implement it.” The problem is “nobody wants to spend four weeks on something that contributes only 2% to the end product’s core value.”

AI coding tools are changing this calculus. When the time cost for that 2% marginal value drops from four weeks to four hours, or even four minutes, it goes from “not worth it” to “might as well.” This doesn’t mean the human’s role in software development disappears — it means humans can focus more on deciding what to do, while handing the boring parts of how to do it to the machine.

Ronacher’s final line says, in a sense, the negative of the same thing: when “what to do” is also handed to the machine, we may lose the ability to understand the system. These two statements, placed side by side, come closer to the truth than either one alone.

TikZ Editor’s GitHub page is still being updated. Dominik says the next step might be pgfplots support. I won’t say “AI coding is reshaping software development” — that formulation is too vague. But what I can say is this: when a TeX line-breaking algorithm that no human wanted to rewrite gets implemented by an agent in a few conversations and correctly renders multi-line text nodes in the browser, a threshold has been crossed. What’s worth watching next is no longer “can AI code,” but “which engineering decisions should humans not outsource, and which ones don’t matter.”

That distinction itself may be the most important question in software engineering for the next several years.