171 karma · joined January 3, 2018
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?
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.
Someone else asked about Gemini, so I think broader LLM support will be my focus for v0.4.0
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!
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!
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.
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!
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!
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).