devenjarvis

Not quite the same, but Ball Lightning is one of my favorite similar phenomena (https://en.wikipedia.org/wiki/Ball_lightning)

Really appreciate your perspective here! I do _not_ have a background in technical education, and am certain you've used and seen the failure modes of LLMs in this space far more than I have so far.

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?

I reverted this due to impending billing changes, but Claude and most LLM providers to my knowledge do offer a way to directly fire a prompt to the LLM in a "headless" or non-interactive mode. Specifically "claude -p <your_prompt_here>" is the way to do it with Claude Code. It allows for using the agent to do a one-off command with a given structured prompt. Originally Lathe would use this from the Go application to allow you to extend a tutorial directly from the UI without directly interacting with the LLM.

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.

I agree! I want to say I first saw this pattern in some work Simon Willison did (Rodney and Showboat). For certain workflows the pair of Skills + CLI give me a nice balance between the flexibility of LLMs and the consistency of a CLI.

Thanks for sharing NotebookLM, I hadn't seen that! I'll take a look and add a comparison to the README if it's compelling.

Thanks for checking it out! ollama wasn't top of my list for support, just because I don't have a machine powerful enough to run decent local LLMs (I wish I did!). I'll look into it though, nothing here should be locked in to any one LLM, as long as it has the concept of a skill/slash command/reusable prompt.

Someone else asked about Gemini, so I think broader LLM support will be my focus for v0.4.0

I've been using it quite a bit and I like it a lot! You certainly could roll your own prompt for this. The value I'm seeing is in the reusable skill/prompt to structure tutorials in a way that help me think and learn a new concept (rather than Claude just giving me code to copy/paste), and the local UI that makes working through the tutorial much more pleasant than scrolling through Claude's markdown output. Plus tutorial series are persistent so I can easily come back around later with a `/lathe-extend` to explore an extension to a topic/tutorial I'm interested in.

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!

Thanks for checking it out!

Yea that’s definitely been a primary usecase for me! Easing the barrier to entry into a new project, and giving me the foundation to take it further on my own once I’m comfortable.

Over the last few weeks I’ve been building Pointless (https://pointless.cards), a Planning Poker webapp that’s both frictionless (no sign up) and actually fun!

I’m trying to embody the experience of a JackBox game into a Scrum ceremony that should be lightweight but is often painful and tedious. I’ve also gotten to learn a lot about Cloudflare Durable Objects building this and have been delighted with how easy they (and PartyKit) make building multiplayer apps like this.

It’s completely free (I plan to keep it that way) and full of easter eggs and delightful jokes at the expense of Jira and modern software development, of course. If your team is following Scrum and could use a bit more joy in the process you should check it out!

This is great feedback, thank you!

I agree RunSecret adds a level of indirection at this stage that op doesn’t (if you are using 1pass). This is something I plan to polish up once more vaults are supported. You’ve given me some ideas on how to do that here.

And thanks for the advice on doing a Show HN, planning to do so once a few more rough edges are smoothed out.

The 1pass CLI is great! However if you aren’t using 1password as your secrets vault, I’m building an open source, vault-agnostic alternative called RunSecret (https://github.com/runsecret/rsec)

Yea that is a hard problem to solve. Right now RunSecret depends on the host system (your laptop, CI runner, or application container) having access to the secret vault(s) of choice that you reference. This can be through ENV VARS, OIDC, or IAM roles (in some cases) but currently there is no HSM support.

Ahh, yup! The RunSecret CLI is completely free and open source.

Azure KeyVault support is in progress and should land soon. I will notate it in the release changelog once it’s ready, but I’m also happy to reply here or let you know another way if you are interested!

Thanks for checking it out! The pain point for me has largely been during local development, especially in a team setting when secrets change or people onboard or roll off and those manually managed .env files get unwieldy.

Gitlab Secrets looks cool, but that hits at another reason I think RunSecret is valuable even for CI - we don’t use GitLab at my day job so it’s not an option for me! I think GitLab and 1password have interesting proprietary solutions that definitely have inspired RunSecret, but I’d love to see an open source, universal solution here - which I’m hoping RunSecret can be!

https://github.com/runsecret/rsec

An easier and more secure way to work with secrets during local development. It’s open source, cloud/vault agnostic, and doesn’t require a single line of code change to use. I call it RunSecret.

RunSecret is a CLI that replaces your static secrets with “secret references” in your ENV VARs (or .env files). These references are then replaced when your application starts up by reaching out to your secret vault of choice - making your .env safe to share across your whole team and removing a slew of gotchas when you use git ignored env files. Even better RunSecret redacts any instance of these secrets from your application output, reducing your chances for accidental leaks.

The approach is inspired by the 1password CLI, but built for the rest of us. I’ve got AWS Secrets Manager support pretty well baked, but the goal is to support all major secret vaults within the next couple of months (Azure KeyVault is already in progress).

Thanks! It’s a slightly modified version of this Hugo Tufte theme: https://github.com/loikein/hugo-tufte