Lathe: LLM-Generated Tutorials You Work Through by Hand
Generate hands-on, multi-part technical tutorials on demand, with LLM skills tuned to make content approachable. Then you work through them yourself, by hand ✋
At a glance
- What is it?
- Lathe is a Go CLI and local web UI that stores, manages, and serves multi-part technical tutorials generated by LLM skills inside your coding agent. The binary never calls a model itself, which is the design decision that shapes both its strengths and its limits.
- Who is it for?
- Lathe suits engineers who learn by typing code and who already run a coding agent with a capable model. It is the wrong choice if you want the tool to call a model on its own, or if you need Windows support, since Homebrew distribution is macOS-only and the install script and go install path are the documented alternatives.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 44 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Lathe tries to fill: tutorials you read versus tutorials you build
Most LLM coding tools optimize for producing working code. Lathe inverts that. The README describes it as an experiment in using LLMs to teach you, rather than think for you, and the project's own framing is that you generate a tutorial and then work through it yourself, by hand, in a local UI. The target reader is someone who already learns by building: the author's own account describes learning through PSP homebrew, the build-your-own-x repository, Crafting Interpreters, and one-off tutorials on raytracers and timeseries databases. If your learning style matches that description, the product premise will be legible immediately. If you want an assistant that writes the code for you, Lathe is pointed the other way on purpose.
The architecture: skills generate, the binary stores and serves
The split is explicit in the README. Lathe is a combination of LLM skills and a Golang CLI used to store, manage, and view generated tutorials. The model work runs in your interactive agent session, and the README states plainly that the binary never drives a model itself. That single constraint explains several downstream choices. There is no API key to configure in Lathe, no provider abstraction, and no billing surface. A local model needs no Lathe-specific setup: point your coding agent at an OpenAI-compatible endpoint such as Ollama's http://localhost:11434/v1 and run the skills as usual. The README also notes that the bigger the local thinking model you can run, the better the tutorials, on the grounds that these are research- and explanation-heavy tasks rather than mechanical edits. Every tutorial records its sources, the model used, and the prompt that drove the voice, which makes provenance a first-class part of the stored artifact rather than an afterthought.
Two ways the Ask, Verify, and Add-a-part buttons work
The UI affordances are the most interesting mechanism in the project, because they have two distinct operating modes. In live mode, you run /lathe-work once in your coding agent while lathe serve is running. That starts a small worker loop, the Ask drawer shows a connected indicator, and the Ask, Verify this tutorial, and Add a part buttons drive work directly in that session. The answer renders in the reader, and verify and extend update in place. Stop the loop and the buttons revert to the copy-paste fallback, where each button hands you the exact /lathe-* command to paste into your LLM. This is a sensible degradation path, and it is worth noting what it costs: the live mode depends on a long-running agent session staying open alongside the server. The README also states that the interactive handoff model is documented against Claude Code, so a few runtime details differ on the other agents. That sentence is doing real work. If you are on Cursor, Codex, Gemini CLI, opencode, Cline, or Windsurf, expect the copy-paste path to be the better-understood one.
Install and skill placement: the commands that matter
Lathe ships as a single self-contained binary. On macOS the documented path is brew install devenjarvis/tap/lathe, distributed as a cask, which the README notes makes it macOS-only on that channel; Linux users are directed to the install script or go install. The script is curl -sSf https://raw.githubusercontent.com/devenjarvis/lathe/main/install.sh | sh, and the Go path is go install github.com/devenjarvis/lathe@latest, which needs Go 1.25 or later. From source it is git clone, cd lathe, go build -o lathe. Installing the binary is only half the setup. The skills are bundled into the binary and must be dropped into a project so your agent can discover them: lathe skills install writes ./.claude/skills/<name>/SKILL.md, --user writes to the agent's home directory, and --agent selects a target, with cursor, codex, gemini, opencode, cline, windsurf, antigravity, and all as the documented values. lathe skills list shows the bundled skills. The README explains the translation rule: SKILL.md with name and description frontmatter is a cross-tool standard, so every target except Cursor ships the raw skill verbatim, and Cursor is the lone translation case because its commands are slash-invoked as /<slug>. Cursor and Windsurf are project-only for --user and warn plus fall back. Day to day, the README says lathe serve is all you need, and the other CLI commands exist mainly to give the LLM a deterministic way to manage tutorials.
Where Lathe is the wrong tool
The dependency on an external agent session is the main limitation, and it is structural rather than incidental. Lathe cannot generate anything on its own. If your team does not use one of the supported agents, or if your environment blocks interactive agent sessions, the product has no path to first use. The README's own admission that a few runtime details differ on non-Claude-Code agents compounds this: the live worker loop is the feature most likely to behave differently from the documentation depending on which agent you installed skills into. There is also a platform constraint. The recommended Homebrew channel is a cask, so it is macOS-only there. Two further limits follow from the design rather than from any stated bug. Because tutorials are research- and explanation-heavy, a small local model will produce weaker content, and the README says so directly. And because the binary stores rather than generates, there is no server-side generation queue, no retry-on-failure for a model call, and no way to regenerate a tutorial without going back to your agent.
How this differs from build-your-own-x and Crafting Interpreters
The obvious comparison is the material the author cites as formative. The build-your-own-x repository and Crafting Interpreters are curated by humans, fixed in scope, and identical for every reader. Lathe generates a tutorial from any prompt and stores it in your library with search, filter, and management. The difference in approach is not quality, it is provenance and specificity. A curated resource has been read by many people and corrected over time. A Lathe tutorial is generated on demand, records the model and the voice prompt that produced it, and can be extended with a new part or verified by asking the agent to check it. That verification step is the interesting part, because it is the only mechanism in the project that pushes back on a generated tutorial's accuracy. It is also optional. Nothing in the described flow forces a tutorial to be verified before you work through it, and a generated tutorial that is subtly wrong will read exactly like one that is correct.
Maintenance cost, licence, and what to check before committing
Lathe is MIT licensed, which permits commercial and private use with the usual requirement to carry the licence text; this is a description of the licence identifier, not legal advice, and you should read the LICENSE file for the operative terms. On maintenance, the release history in the supplied material shows v0.3.0 in June 2026, v0.4.0 the same month, and v0.5.0 in July 2026, with the last push in August 2026. That cadence is consistent with active development on a pre-1.0 project, which means the CLI surface and skill file locations can still move between releases. The upgrade cost is concentrated in the skills, not the binary: because lathe skills install writes SKILL.md files into your repository at paths like ./.claude/skills/<name>/SKILL.md, a version bump that changes skill contents will show up as diffs in your project tree, and you will need to re-run the install command for each agent target you use. Before adopting Lathe, verify three things in your own environment: that lathe skills install --agent <your-agent> writes to the directory your agent actually scans, that the live worker loop connects when you run /lathe-work alongside lathe serve, and that your chosen model produces tutorials at a depth you would accept from a human author. If the third check fails, the first two do not matter.
Editorial conclusion
Lathe suits engineers who learn by typing code and who already run a coding agent with a capable model. It is the wrong choice if you want the tool to call a model on its own, or if you need Windows support, since Homebrew distribution is macOS-only and the install script and go install path are the documented alternatives. Before adopting it, verify that lathe skills install places SKILL.md files where your specific agent looks for them, and confirm whether the live worker loop behaves as documented in your agent rather than only in Claude Code.
Community notes