Lathe is an experiment in using LLMs to teach me something new, instead of doing the work for me. It generates a hands-on, source-backed tutorial for any technical topic you want to learn. Then you work through it yourself by reading and typing the code by hand (gasp) in a local UI built for exactly that.
It's a Go CLI plus LLM agent skills (Claude Code / Cursor / Codex). You prompt something like "/lathe build a 3D slicer in Erlang", run `lathe serve` to spin up a local webapp, and read it in your browser. Every tutorial comes with the things that have made self-learning a pleasant experience for me in the past:
- table of contents that follows along as you scroll - side-notes that nudge you to think - exercises for the reader - sources backing up the content that you can use to take you deeper
To help make up for the lack of human brainpower behind the tutorial, you can also ask questions about the content, have another LLM verify the tutorial actually compiles and runs, or extend it with another part (no more "Part 4 of 6" that hasn't seen an update since 2021).
I didn't build lathe to replace human-written tutorials. I built lathe because I _love_ human-written tutorials, but wanted to learn technical domains where no good human-written tutorial exists yet (building a 3D slicer from scratch, making embedded Zig approachable, etc). There's a longer story in the README about how I got started with programming through PSP homebrew tutorials, and why losing that to LLMs bugged me enough to build this.
I'm not here to sell you anything (there's nothing close to a VC-backed startup here :D). It's an LLM, and its output is usually good but not perfect by any means. So far, my experience is that because you're the one typing and actually engaged, you catch the weird stuff (and I'm finding that pushing back on it is its own kind of learning). And yes, it's vibecoded, because it's low scope, low risk, and scratching a personal itch. I run it on Claude Code + macOS personally, other setups should work but I haven't been able to verify them yet.
If you can find resources to learn something that was written by a human, read that first. But Lathe is here to fill in the gaps when that isn't the case, and I hope it serves as an example where LLMs can help us think better, rather than less.
Repo: https://github.com/devenjarvis/lathe
Would love your feedback if you decide to check it out!
Discussion (72 Comments)Read Original on HackerNews
https://pchalasani.github.io/claude-code-tools/plugins-detai...
For example I’ve used this to better understand counter-intuitive things about diabetes/insulin, dopamine and motivation, Claude’s implementations, etc (to combat so-called cognitive debt).
Strong LLMs are surprisingly good at this type of quizzing, they display a semblance of “theory of mind”.
I'll definitely check out your other skills.
The harder questions will only arrive when the context is getting full.
If it's something actually novel, no matter how much context you provide it'll still hallucinate.
Traditional method of looking up stuff, going through guided lessons etc are just more streamlined and faster than this method.
LLM are a dream come true for these curious types. They'll only be accelerated by them. I don't think there's any real "loss" out there, just a bunch of people that don't care boing things easier. Good for them, good for the curious people. Net win.
I find that LLMs are useful for both cases in the end.
That hasn't really been my experience, at least not for a long time (decades+). At least since jQuery's been around. There's always been a large group of people whose approach to software development was basically "run these commands, don't worry about why they work".
The tendency to treat tools as black boxes over time isn't new, I don't think.
A silver lining here is that in my experience the non-curious tended to stagnate over time and the curious tended to succeed, but obviously there's more to it than just that.
LLMs probably just let those organisations make a larger and more load-bearing website faster, so that poor decisions speed the time to catastrophe.
Not sure how to accomplish this. Anyone have any suggestions? Are there libraries for this yet? (And how would they even work? It feels like, to do this right, there would have to be some background service that CLI software could expect to interact with via a well-known local IPC socket — similar to how e.g. the docker daemon works. But I'm unaware of any coding agent software/frameworks that expose such an IPC capability...)
It runs as a background terminal that the agent can observe, and then exposes all interaction options as structured commands that can be run from the foreground CLI which then update the state of the background terminal via IPC. My hope is to establish a sort of “ARIA for terminals” standard to improve accessibility for both humans and agents. Email in profile, ping me if you’re interested in giving it a spin (just have plugins for Inquirer + Commander right now, hoping to broaden to other frameworks & TUIs soon).
You'd have to exec out, so it's alittle clunkier than an IPC, but I think you could achieve what you want with it.
But in my experience, to actually get where they're going quickly (as opposed to spending hours and hundreds of dollars stumbling around in the dark), coding agents generally need more interactive hand-holding than that. If you just fire off one non-interactive session and wait for it to come to a stop, the problem usually isn't fully+correctly solved at the point at the LLM decides to "finish." And if you then start another non-interactive session to continue the work, the new session will have lost the old session's state/memory/context, and so will stumble through many of the same mistakes / misapprehensions.
What you really want, for a CLI program with a "use coding agent to do X" workflow-step, is for the CLI program to play the role of a human in a temporary durable coding-agent conversation session: prompting the agent; then waiting for it to finish responding (and side-effecting); then either asking the agent itself to evaluate an "am I done yet" predicate with a constrained output syntax; or having the CLI program do its own out-of-band validation of the changes made to the shared state by the agent; where, in either case, if the agent isn't "done yet", then the workflow step must continue poking it — or prompt the human to make a decision on how to proceed (possibly involving providing direct input to the LLM, but this is not ideal; ideally the CLI "abstracts away" the need for the end-user to understand the intricacies of the conversation the program is having with the LLM. Even more ideally, the conversation just whizzes by and the human doesn't have to think about an LLM being involved at all.)
Basically, think of this not as the CLI program saying to an agent "answer me this question" or "edit this file for me", but rather, the CLI program popping open a mini "guided + 99%-of-the-time automated" TUI coding-agent micro-IDE "inside" the workflow, in about the same way that git pops open your EDITOR inside `git commit`.
I was telling my friend the other day. The way you learn programming is by typing code out by hand. And I suggested using LLMs to generate minimal educational examples aligned with his interests and needs.
I've tried the Zed Shaw method to learning programming (just typing out code examples by hand -- doing "studies", the same way you would with music or art). I tested it on a programming language I had been learning for a while and was struggling with. After just a few hours of typing my fluency had skyrocketed.
I realized that in several hours of typing I had written more code than in weeks of study. Because when you don't know a language yet, producing code is extremely slow and error prone. But typing out correct code is relatively straightforward.
So due to changing my approach to "just blindly typing", I got more practice (at least as far as reading and muscle memory goes) in a few hours than the previous few weeks.
Now of course understanding is important too, but it's a separate dimension, and largely comes after memory and fluency in my experience. (Understanding something theoretically and being able to use it are two very different things!)
The general principle here is Stephen Krashen's Input Hypothesis of language acquisition (https://en.wikipedia.org/wiki/Input_hypothesis) which says a baby learns language by just hearing stuff -- just being exposed to inputs -- and that adults can learn the same way too.
And I heard it on the excellent website (now defunct?) All Japanese All The Time, where the author tested the hypothesis on himself by mostly listening to a lot of Japanese and gained fluency in a year.
https://web.archive.org/web/20080705194055/http://www.alljap...
But at the same time, I'm afraid getting everything laid out for you in exactly the way you want will erode some of the understanding you build by going through a primary source directly and figuring things out the hard way. So this having more focus on actually doing stuff by yourself seems right up my alley (while still tending to the LLM induced intellecutal laziness... ) .
Still, it took a lot more effort than just delivering the initial request. AI makes everyone produce something average but you still need taste to produce something good - I guess this applies to courses too.
90% of my Claude usage is getting it to write me guides, that I can then spend most of my time following to build the end results.
Keeps the brain healthy and also provides bespoke learning, rather than a generic course off the internet. Definitely a great use of AI.
Also, I wouldn't say "have another model test the tutorial compiles" a feature, but also I do not expect a fool-proof tutorial from a one-shot, I guess.
Not sure why I would try this over a hand-written promot. Also wondering why ChatGPT Study mode failed, it seemed interesting.
That said, it's been a tool that's been helpful for me personally, but doesn't have to be for everyone! I've never used ChatGPT Study, I'll look into it more. Thanks for sharing!
See the best place I learn and read through materials is when I'm commuting. Far away from a console.
Could you envision a way to deliver this as a web app linked to e.g. an OpenRouter/Anthropic/OpenAI API key?
Do you think Lathe could be adapted to use a codebase as the source material?
I don’t write my own - I can’t optimize for the models understanding, and so I just give the skill-creator skill an outline and then have it refine until the output is what I want.
Well, but it will still serve you content from humans, but without any attribution.
If it does find some, maybe it could supplement them instead of just from scratch
Even now, LLMs are terrible educators. They do not make coherent progressive curriculums. They hallucinate details which the student will not have the knowledge to challenge.
If you use an LLM to make a tutorial you will get some benefit for sure, especially if you use it for Socratic sessions based on a corpus of data you provide (like a blog post or documentation).
Don’t expect it to teach you reliably though. It feels good to ask the LLM whatever you want, but if you’re learning a topic you don’t have the instinct to realize when it’s giving you a poorly chosen progression of information or teaching you something flat out untrue.
A few thoughts based on my limited experience building and using lathe:
- Part of the lathe skills are to first find source materials to base curriculum on. It's not foolproof by any means, nor is it a novel approach, but it's helped ground the content in reality more than an open ended prompt usually does (in my experience)
- We're scoped to tutorials, over full blown curriculum. I found having lathe write one part of a tutorial series at a time, over the whole thing at once, usually gave me better results (and is why `/lathe-extend` is a thing)
- To your point about not having the instinct to realize when it's giving me a poor progression or untrue content, my experience is that by actually writing the program the tutorial walks me through, I get definitive proof of if the results are true or not. One of the most impactful (and all too frequent) answers I got as a young programmer was "write a program and find out" and it's still good advice today. Not at all proposing this makes lathe tutorials infallible, but in the context and scope of the project it seems to take the bite out of the worst failure modes here. That said, maybe that implies lathe is most useful and least dangerous in the hands of an experience developer looking to learn a new domain, over someone looking to build foundational technical (and technical learning) skills? I'll think that over!
I'm really curious what your experience would lead you to think about the above though? Are there critical failure modes for LLMs writing hands on technical education I just haven't tripped over yet?
Context and scope limitations are also helpful, as you mention. And yes, having experience in a domain makes learning with an LLM a dramatically different experience than from-scratch, since the LLM is nudged in different directions by our responses. When a novice uses an LLM to learn, the questions they ask the LLM can drive it in directions and hallucinations that would look obvious to an experienced person.
The worst failure mode is what I mentioned: the novice asking the wrong questions or driving the LLM in the wrong direction. Inference is strongly influenced by input tokens, and that's fairly unavoidable.
I don't mean to say your project doesn't have value though! I hope people use LLMs to help them learn (by directing them to good source materials from humans) rather than just asking it to do things for them and blindly trusting the results.
Someone else asked about Gemini, so I think broader LLM support will be my focus for v0.4.0
LLM's big point is that it is an excellent learning tool
Lot of people want to generate stuff from it
but perhaps overlooked is the knowledge you can gain from it
it is the best tutor you will ever have!
btw it sucks that you have to disclose if you are trying to make a buck from a project or not.
Making money shouldn't be vilified or frowned upon.
In coding-agent work I see a similar pattern. The best outcomes usually happen when the agent is forced to study concrete source material first: real repos, real docs, real examples, and the constraints behind them. The worse outcomes happen when it generates a plausible path from a vague prompt and never has to reconcile that with existing practice.
For learning, I imagine the same thing matters: the LLM should help structure the path and explain the friction, but the learner still needs to touch the code and compare against sources.
The source-backed part feels more important than the generated tutorial part.
> https://news.ycombinator.com/newsguidelines.html