TikZ Editor Makes LaTeX Figures Less Painful

TikZ Editor is an open-source web and desktop WYSIWYG editor for LaTeX figures, shared by its maintainer as a Show HN project. It deals with the old TikZ pain: moving nodes, arrows, labels, and shapes by editing coordinates and recompiling until the figure looks right. The useful takeaway is not that visual editing beats code; it is that good tools let you manipulate the result while keeping the source readable. That is also the quiet lesson for ai coding for teams: automation is safest when humans can still inspect and edit the underlying text.

Move the figure without losing the code

TikZ is a LaTeX package for drawing figures with commands such as \\draw[->] (0,0) -- (1,2);. It is powerful because the figure lives in source control with the paper, but it is fiddly because every small visual adjustment becomes coordinate work.

TikZ Editor attacks that exact loop. You can drag and resize elements visually, while still working with TikZ source instead of exporting a detached image.

That matters because academic figures are rarely disposable. A diagram in a paper may live for years, get copied into a talk, and then be edited again by someone who did not draw the first version.

The trap is the same one developers know from code generators. A visual editor that turns a tidy hand-written file into generated-looking soup wins the demo and loses the repo. The Hacker News objection that landed hardest was not “can I draw a new figure?” It was “can I safely touch an old one?”

A small example shows the line:

\\draw[->] (0,0) -- (1,2);
\\node at (1.1,2.1) {Result};

If a visual move changes only the endpoint and nearby label position, great. If it rewrites the whole figure into opaque output, you bought yourself a review problem.

Why developers cared about this small editor

The reaction was warm because the pain is real. STEM students and researchers often learn enough TikZ to draw a figure, then spend the next hour nudging coordinates and recompiling the paper.

TikZ is also “code-like” in a way that plain SVG is not. It has loops, macros, styles, and reusable patterns. That makes it a good fit for LaTeX projects, but a hard target for WYSIWYG editing.

That is why TikZ Editor is interesting beyond LaTeX. It sits in the same design space as modern ai software development tools: help me change the artifact faster, but do not hide the representation I need to review.

There was also a fair Typst-shaped objection. Some developers would rather avoid LaTeX entirely and use Typst with CeTZ. If your documents are already Typst-first, TikZ Editor may be the wrong tool today unless that ecosystem support appears. The project is compelling because of the problem it solves, not because every document stack should bend around TikZ.

For a shorter companion note on the project itself, see TikZ Editor Makes LaTeX Figures Draggable.

Keep the human-editable boundary

The practical lesson for Codex users is simple: preserve the artifact people review. Codex, OpenAI’s coding agent, can help edit code, docs, tests, and paper-adjacent files, but the safest boundary is still a readable diff.

If you ask a coding agent to update a TikZ figure, give it the same constraint you would want from TikZ Editor: make the smallest meaningful change, preserve structure, and prove the output still builds.

A useful AGENTS.md note for a repo with LaTeX figures could be this:

# Diagram edits

- Preserve existing TikZ structure unless the user asks for a rewrite.
- Prefer small coordinate, label, color, and style changes over regenerating a full figure.
- After editing a figure, run the paper build command and include the relevant git diff in the handoff.
- Do not replace TikZ source with exported images unless explicitly requested.

Model Context Protocol (MCP) is an open protocol for connecting agents to external tools and data sources. If an agent reaches paper files, issue trackers, or design references through MCP, keep the same rule: read broadly if needed, write narrowly, and make the changed source easy to review.

This is where the related training topic connects to a tiny LaTeX editor. The point is not policy theater. The point is keeping a clear boundary between assistance, generation, and the commit someone has to own.

Try it safely with a fit table

Use TikZ Editor when the figure is important enough that visual feedback saves time, but not so fragile that any automated rewrite is unacceptable. It is overkill for a one-line arrow and risky if your project depends on very particular macro style that the editor cannot preserve.

For ai coding for teams, this table is the more general pattern. Try tools where they shorten the loop without corrupting the thing your team reviews.

Review the diff, not the demo

A good first experiment is boring on purpose. Pick one old figure, make one visible change, build the document, and review the diff like any other code change.

git checkout -b tikz-editor-smoke
# Edit one figure in TikZ Editor.
latexmk -pdf paper.tex
git diff -- figures/model.tex

The important check is not “did the preview look nice?” It is “can another maintainer understand what changed?”

Use the same posture for ai code generation and ai pair programming. A fast assistant is useful when the output lands in a normal verification loop: build, test, diff, review, merge.

Try one old figure

Pick one figure that already hurts to edit, move one thing, and keep the result only if the source diff stays readable. That tiny test will tell you more than a polished demo.

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 Codex artifact first: an AGENTS.md instruction, a Codex CLI verification loop, an MCP boundary note, or a skills handoff.
- [ ] 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 Codex, 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 Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification 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: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “TikZ Editor Makes LaTeX Figures Less Painful.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• TikZ Editor — source
• Model Context Protocol — specification
• Codex — 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.