yup, the standard way of thinking about agents seems backwards and probably costly. Use LLMs to write scripts, then stick all your scripts in your own looping harness and call out for LLMs for those parts that are too hard to automate with some deterministic validation at the end.
Sure; for reference most of what I end up doing is concurrent and distributed systems, so that's more or less what I focus on. I don't know if this stuff translates to other domains.
Basically, when I have an idea for a project, I usually start drawing a diagram for how I think things should work. I usually draw it with draw.io first because it's easy and quick. After that, I usually translate this to Mermaid, primarily just to have a second draft, but also because having a text-based system makes it easy to copy and paste around, and that kind of stuff tends to translates well to state-machine based stuff that most distributed systems tend to morph into.
If what I'm working on is relatively simple, I feed the mermaid code into Claude or Codex, give it some surrounding context text about what I want, and get it to hack away.
For more complicated stuff, especially if I want to be more clever with concurrency, I will take my Mermaid diagram and manually convert it to TLA+. If I get stuck with the TLA+ translation, I will sometimes ask Claude for a bit of help but even then I almost always write 90+% of the TLA+ spec by hand.
After that it's basically the same. I feed the TLA+ spec, and provide context to it as well (e.g. how to translate a manual TLA+ mutex or channel implementation to whatever the language has built in).
Since I focus very heavily on the implementation, Claude and Codex generally don't have a huge issue with doing a one-to-one implementation.
Yup, strange to see people still don’t understand LLMs massively speed up coding greenfield pet projects. Anytime you see a bee web app it’s better to assume AI use rather than not anymore.
reply