Show HN: Lathe – Use LLMs to learn a new domain, not skip past it

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...

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.

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`.