i love tldraw offline, here's why

Every architecture diagram I've ever committed to a repo was stale within a month, because the code moved and the diagram didn't. Boxes and arrows are a snapshot of a codebase at one point in time, and codebases don't stay at one point in time.

tldraw offline fixes that. It's a free desktop whiteboard with no accounts and no servers, and your AI coding agent can draw on it. The agent reads your code and produces the diagram, and when the code changes, you ask it again instead of dragging boxes around by hand.

What tldraw offline is

The tldraw team released it in July 2026 as a desktop app built on the same canvas SDK that powers tldraw.com. It works fully offline, and Steve Ruiz's launch post says you can use it "offline or underwater". Your documents are saved as self-contained .tldraw files that carry the canvas, any images and videos, and even scripts. There's a build for macOS, Windows, and Linux.

Your AI agent does the drawing

The app runs a local HTTP API on your machine, and it ships with a built-in command to install agent skills. Under Develop → Install Agent Skills, it writes a tldraw skill into the skill folders of Claude Code, Codex, Cursor, and Gemini CLI. After that, your agent drives the canvas with plain HTTP calls from its terminal while you watch it draw.

The app doesn't care which agent you use, because the integration is a skill plus a local API, not a subscription to someone's hosted thing. You bring your own AI, and the diagram lands in a file you own.

Compare that to Excalidraw. It's a web app first, so the usual agent workflow is to have your agent generate an .excalidraw file through an MCP server or a skill, then upload or import it into the web app yourself. That's real friction, and the file you get isn't live in the tool you're looking at. With tldraw offline the agent draws straight into the app that's already open on your screen.

Slides are worse. A deck about your architecture is a maintenance liability, because every refactor makes it a little more wrong and updating it costs you an evening you don't have.

What I actually used it for

I pointed Claude, with the tldraw-offline skill installed, at a movie recommendation app I was working on and asked it to map the architecture. It explored the codebase first and figured out the auth setup, the Express API, Postgres, and the external movie data source. Then it drew a sequence diagram with eight lifelines covering six phases of the app, from auth through search, title details, collections, recommendations, and notifications.

After that, I asked for the login flow specifically, with both the email and password branch and the Google OAuth branch, including the CAPTCHA check and the session bootstrap that both paths share. It drew that too, with file references in the messages.

Both diagrams went into the repo under docs/architecture/. The .tldraw file itself is the source of truth, created at the repo path rather than exported and copied, next to an .svg, a .jpg, and a short markdown README documenting the actors and phases. Anyone on the team can open the live file, and anyone can regenerate it when the code drifts.

More places it fits

A PR description with a blast-radius diagram beats a paragraph listing touched files. Ask the agent to read the diff and draw which services and components the change reaches, and reviewers see the shape of the risk before they read a line. Dependency graphs work the same way. The agent reads your imports or your package.json, draws the graph, and the god-module (a file that does too much, the one everything imports and nothing can untangle) becomes visible in about thirty seconds.

The other direction is just as useful. Screenshot a UI you like, drop it on the canvas, and mark it up. An arrow that says "match this spacing", a note that says "this button, but on mobile". Then let the agent read your marks and turn the feedback into code. The same flow handles a sketch of a rough UI idea, where you box out some screens and the agent turns the sketch into a first component. Design feedback happens in the medium the work actually lives in, instead of a Figma comment thread or a meeting where someone says "the thing on the left, no, the other left".

Gotchas

The agent knows the code, but not your audience. It will draw everything at roughly the same level of detail, and deciding what to emphasize, what to compress, and what to leave out for a specific review is still your job. Hand the agent a constraint like "diagram just the request path, skip the background jobs" and it does well. Hand it nothing and you get a wall of boxes that explains everything and clarifies nothing.

That doesn't mean the diagram stays current on its own. It's only as fresh as the last time you regenerated it. The difference is that regenerating costs one prompt instead of an afternoon, which changes the behavior, because cheap maintenance actually happens.

A diagram that can be rebuilt from the code whenever it drifts stops being a document you babysit and becomes something closer to a build artifact.

Try it yourself

Download tldraw offline from offline.tldraw.com, open a document, and run Develop → Install Agent Skills so your agent picks up the skill. Then start small. Pick one flow from your codebase, not the whole system, and tell the agent who the diagram is for. "Map the checkout flow for a new backend dev" gets you a better drawing than "diagram everything", because the agent now knows what to leave out.

And if you'd rather play than diagram, the same team makes tldraw flash, a browser tool for small animations. It runs in the browser after a sign-in, and it's a nice way to make a tiny explainer for when a static diagram isn't enough.