TikZ Editor Makes LaTeX Figures Draggable

TikZ Editor is an open-source Show HN project from its maintainer: a WYSIWYG editor for TikZ figures in LaTeX, available on the web and desktop. The old academic pain of nudging coordinates, recompiling, and repeating until a diagram looks right. The useful answer is not to stop writing TikZ; it is to make visual changes without losing reviewable source. That is also the quiet lesson for AI coding for teams: helpers earn trust when they preserve the artifact people already review.

Edit the figure, not the compile loop

TikZ is a LaTeX drawing package that lets authors describe diagrams with code: lines, arrows, shapes, labels, loops, and coordinates. A tiny example can look like \draw[->] (0,0) -- (1,2);, which is pleasant when the idea is simple and tedious when the arrowhead is three pixels off.

That is the itch TikZ Editor scratches. Instead of changing numbers, compiling, squinting at the PDF, and doing it again, you can drag or resize elements visually while keeping the TikZ source in the loop.

This is not just a drawing convenience. It is a source-preservation problem. In academic repositories, the diagram is often part of the paper, reviewed in Git, built by CI, and reused by the next student who inherits the project.

Don't assume WYSIWYG means the code no longer matters. For TikZ, the code is the durable interface. A good visual editor should make the coordinates easier to touch, not turn a careful hand-written figure into generated soup.

Keep old TikZ readable

The most interesting objection from the Hacker News discussion was not that visual editing is bad. It was sharper: the killer feature is being able to touch old TikZ without wrecking the source.

That is the standard worth holding. A lab may have five-year-old figures with named nodes, helper macros, comments, alignment tricks, and a few ugly but intentional offsets. If a tool moves one label but rewrites the whole file, the maintainer now has a review problem instead of a geometry problem.

A real repo example is a paper with paper/figures/architecture.tex checked in beside the manuscript. A good diff says one node moved and one arrow was shortened. A bad diff says every coordinate changed, comments vanished, and the PR reviewer has to reopen the PDF to understand anything.

This is where the story rhymes with ai software development. AI code generation and visual editing are both useful when they shorten a loop. Both become risky when the output stops looking like something humans can review.

Ask what source control will see

Cursor is useful here even though TikZ Editor is not an AI tool. The right Cursor move is small: put a boundary around figure edits so the agent, the human, and the reviewer agree on what counts as acceptable change.

For example, a repo rule can tell Cursor's Agent to treat TikZ files as source, not disposable output. This is a light guardrail, not ceremony.

---
description: Keep TikZ figure edits reviewable
globs:
  - "paper/figures/**/*.tex"
alwaysApply: false
---
When editing TikZ figures, preserve existing macro names, node names, comments, and formatting where possible.
Do not rewrite a whole figure to make a small visual move.
In the PR summary, list semantic changes separately from coordinate-only changes.
If a visual editor reformats the file, stop and ask before committing the rewrite.

That rule is deliberately boring. It says the reviewer should not need to replay a chat, open a design tool, or reverse-engineer a regenerated file to know what happened.

If your agent workflow reaches outside the repo through Model Context Protocol, the same idea applies. Pulling a requirement from an issue tracker or a figure note from a document store is fine. Letting that external context silently rewrite a paper figure is not.

For a broader version of this bounded-loop habit, see Dan Luu on Agentic Coding: Keep the Loop Bounded. The same review instinct shows up in small tools and big coding agents.

Use it when the figure belongs in LaTeX

TikZ Editor looks strongest when the final artifact is already supposed to be TikZ. Papers, theses, lecture notes, and packages that compile with LaTeX are the natural home. In that world, visual editing removes friction without changing the build system.

It is less compelling when the team has already moved away from LaTeX. One fair request in the thread was support for CetZ, the Typst ecosystem's drawing package. If your writing stack is Typst-first, a TikZ editor may be an impressive tool for someone else's workflow.

This is the practical bridge to AI coding for teams. Treat TikZ Editor the way you would treat ai pair programming: use it for fast local movement, then review the durable source. The faster the assistant, the more boring the diff should be.

The useful habit is simple: make the visual editor prove that it respects the text file. That is the same habit behind good AI coding governance, even when the tool in front of you is just helping drag an arrow.

Try one old figure

Pick one annoying legacy TikZ figure, edit it visually, and judge the tool by the diff before you judge it by the canvas. If the source stays readable and the PDF gets better, keep the workflow; if not, revert without guilt.

Further reading

• TikZ Editor
• MCP specification
• Cursor Agent docs

Where to go next

Start from AI coding governance.