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. It deals with 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.

Developers cared because 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.

The trap is assuming 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, Anysphere's AI code editor, 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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Cursor artifact first: a .mdc rule stub, an AGENTS.md boundary, a custom subagent note, or a Cursor review checklist.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about ai coding?

  Start by writing down one visible team rule for Cursor, not a loose preference. That is the practical core of ai software development. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Cursor artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a .mdc rule, AGENTS.md note, or review checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Cursor teams deciding which rule, subagent, skill, or MCP boundary to standardize next around “TikZ Editor Makes LaTeX Figures Draggable.”
• Best first artifact: turn the named fix into a .mdc rule, AGENTS.md note, subagent receipt, or review checklist before the next automated run.
• Best comparison angle: compare the workflow against the current Cursor review path, connector scope, and team rule file; keep the path that leaves the shortest auditable trail.

Further reading

• TikZ Editor — source
• Model Context Protocol — specification
• Cursor — Agent
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.