Lathe: LLM이 대신 생각하게 두지 말고 배움의 도구로 쓰세요

Lathe An experiment in using LLMs to teach you, rather than think for you. Lathe generates hands-on, multi-part technical tutorials on demand, with skills tuned to make content approachable. Then you work through them yourself, by hand, in a local UI built from the ground up for pleasant learning. (Just like we did it in the stone age 😎) What is it? Generate hands-on technical tutorials (single-part or a multi-part series) from any prompt Work through the tutorial yourself in a purpose-built local UI Use skills to ask questions, verify the tutorial, and extend it with a new part Search, filter, and manage tutorials from your library Every tutorial documents its sources, which model was used, and what prompt drove the "voice" for the tutorial Quick start Lathe is a combination of LLM skills and a Golang CLI used to store, manage, and view generated tutorials. After install (below), you can generate a tutorial inside any LLM session (Claude Code, Cursor, and Codex supported) by prompting something like: /lathe build a 3D Slicer in Erlang Then open lathe from any terminal: lathe serve # starts the web server, opens the browser Don't worry, we also have dark mode: Click the tutorial you want to read and start learning! The CLI has a bunch of other commands, but honestly those were built to give the LLM a deterministic way to manage tutorials. I expect the above to be all you need (it's all I ever use) for day-to-day. If you want to ask a question about a tutorial, have the LLM verify it, or extend it with an additional part, the UI has affordances for each of these which will give you the exact skill/prompt to give your LLM in order to trigger the action. Install Lathe is a single self-contained binary. All you need is lathe on your $PATH ; the skills run in an interactive Claude Code, Cursor, or Codex session. Homebrew (macOS, recommended): brew install devenjarvis/tap/lathe Distributed as a cask (a pre-built binary), so it's macOS-only — on Linux use the install script or go install below. Install script ( curl | sh ): curl -sSf https://raw.githubusercontent.com/devenjarvis/lathe/main/install.sh | sh Go (needs Go 1.25+): go install github.com/devenjarvis/lathe@latest From source: git clone https://github.com/devenjarvis/lathe cd lathe go build -o lathe Install the skills The skills are bundled into the binary. After installing lathe , drop them into a project so Claude Code (or Cursor / Codex) can discover them: lathe skills install # ./.claude/skills/<name>/SKILL.md (this project) lathe skills install --user # ~/.claude/skills/<name>/SKILL.md (all projects) lathe skills install --agent cursor # ./.cursor/commands/<slug>.md (Cursor slash commands) lathe skills install --agent codex # ./.agents/skills/<name>/SKILL.md (Codex Agent Skills) lathe skills install --agent all # Claude Code, Cursor, and Codex lathe skills list # show the bundled skills Codex uses the same SKILL.md format as Claude Code, so its skills ship verbatim (and --user installs to ~/.agents/skills/... ). Cursor commands are slash-invoked as /<slug> (e.g. /lathe ); the interactive handoff model is documented for Claude Code, so a few runtime details differ on Cursor and Codex. Why does this exist? I learned how to program as a teen in the 2000s by building homebrew games for my PSP (PlayStation Portable) in Lua, and then in C++. Lots of what I learned at the time was through the small PSP homebrew community I'm incredibly grateful I got to be a part of, but I also owe much of that formative learning to free online resources and tutorials available on the internet (shoutout to 2007 cplusplus.com - man does that site have a lot more ads now than it used to 😅). Eventually I became a professional software engineer and I spent the next decade "upskilling" (though usually to learn more interesting topics than needed for ) by finding and consuming a wealth of technical blogs, and more importantly for my learning style - hands on tutorials. Resources like the build-your-own-x repo , and Crafting Interpreters , and the 1,000 other one-off tutorials that taught me everything from building a raytracer , to a timeseries database , to a linear algebra matrix library and everything in between (seriously, I couldn't even begin to list all the amazing hands-on tutorials out there that have influenced me). Hands on learning is how I've always learned best. These tutorials gave me the learning curve I needed to go from zero-to-one in a brand new domain, but even more importantly they gave me footing and confidence to take it from one-to-two-to-ten on my own. Fast forward to 2026, and now we've got LLMs. I'm not going to go off topic about my complicated relationship with LLMs, but for writing software they are interesting and in many cases they can be really productive! But they do most of the work for you, and with that work gone they also take away the part that helped me learn a new concept or domain. In some cases, that doesn't matter - we've got a product to ship and LLMs help us ship it faster - but for me and my joy in this field and hobby I still crave those "ah ha!" moments where something finally clicks and I have the confidence I need to begin shaping it into my own. So lathe is an experiment in using LLMs to teach me, rather than think for me. To recreate those moments of hands-on learning that taught me to love this work, and marry it with the potential of a broad "expert" LLM who can, in theory, teach me anything. I use lathe as a catalyst to get me started on projects I wouldn't know how to start in, and can't find any existing human written resources to teach . For example I first came up with lathe because I wanted to write a 3D Slicer Software from scratch (just finding documentation on g-code was a pain, shoutout to reprap ). At the time of writing I'm diving into the world of embedded software development with Zig. Both of these cases lathe has been an effective tool in getting me from zero-to-one in obscure or extremely young domains where the human written resources just don't exist yet (and I wonder for how long humans will still bother writing tutorials if only the LLMs read them...). But what about hallucinations? Are lathe tutorials as good as ones written by humans? Not in the slightest. But what they lack in heart, personality, and architectural soundness, they make up for by having the tutorial writer ready and waiting to answer all of your questions, always willing to fix or update their tutorial when it isn't exactly what you wanted, and they actually complete writing all 6 parts to that series they started in 2018 (we've ALL been there 😁). Lathe is an LLM, and while I've built and tuned it to be as good as I know how to make it for this particular task, it's still going to fail in the ways LLMs fail. I recommend using the biggest "thinking" model you have access to (Opus, GPT-5 Codex, etc) as these tasks are less about iterative mechanical execution you might optimize for when programming, and more about researching, designing, and explaining a tangible concept from start to finish. Additionally, the risk for hallucinations in this context is, in my opinion, significantly lower. Lathe is built to help you do the thinking, and is built around the expectation that you're the one typing this code out yourself. By reading through the guide and typing it out, you are actively engaged in the work and should be well positioned to naturally ask "wait, does that make sense?" when you come across something weird. At which point you can /lathe-ask (and sometimes the LLM comes back with good reasoning I didn't have because it's a foreign domain, and I learn something) or just straight tell your LLM to update the tutorial. While I have no pedagogical credentials to back this up, I think I may be actually internalizing concepts better by catching and pushing back on perceived slip-ups of the LLM. YMMV. All of that said, if you can find a tutorial written by a human, I'd always reach