That's a really good question. Before, I was using Google Translate, which is not perfect. Now I'm using Claude and I think I tend to centralize my tools... Like before, when I was using both Google Search and Google Translate, now I just use Claude for a lot of thing.
Plus, I think Claude is a better model than the one used by Google Translate, but correct me if I'm wrong.
But you're right, DeepL should be perfect to do it, because is model is dedicated for translations !
A really big up for you, I launched my lib https://pithos.dev fews days ago, and I tried to coordinate posts on HN, Reddit, dev.to and Linkedin... but it was a failure because I didn't have accounts for HN and Reddit, so I was not able to post :) Now I understand I have to interact with people to win karma and it's a better way to share and communicate with a community !
Might be you could add this point to your guide ?
I totally agreed with you. I'm French (nobody is perfect ^^), I'm not so fluent in english and I'm dyslexic, that why I often write my message, then I ask to Claude to translate it in english because i'm feeling I will lose the credibility of my message if there is too much mistake...
But you're right, so this message is not translated by LLM :D
it's a clever idea but the perception of the color is not easy to have a graduated difficulty.
Plus, an alternative to the div might be to use the canvas to avoid cheating by watching the position of the gradient on the console :p
anyway, thank you ! i didn't clean my screen since 1 week, and this game need to !
haha, I know that feeling! I worked on a RAG system for a pharmaceutical client and the hardest part was exactly this: You know, when everything looks fine, without error, but results are silently wrong!!!
I think LLMs answering with full confidence on bad data is the most dangerous failure mode.
oups, I just realized you already explain you're using a git worktree. Sorry about that!
I think the demo statement idea is really clever! Without something like that, agents always build layers of plumbing that never connect to anything visible...
I've seen the same problem by using CC on my own projects.
I'm sometime using Claude Code for the work, and I really like to parallelize multiple agents. So I'm wondering how you manage two workers who are editing a same file?
The "patch file" approach for LLM output on large files is spot on. I've hit the same wall and forcing targeted replacements instead of full rewrites is the only sane way past a certain codebase size. Also respect for managing state manually in 9k lines of vanilla JS without reaching for a framework.
The Getting Real philosophy aged remarkably well !
"Say no by default" is something I wish more open-source maintainers would internalize... Every feature you add is a feature you maintain forever and knowing where to draw the line is probably one of the hardest skill in software.
The bitmap trick is elegant and I've seen similar patterns in other contexts. The core insight resonates beyond Rust and SQL: the data structure that's "obvious" at design time can become a bottleneck when the real-world usage pattern diverges from your assumptions. Most fields exist vs most fields might not exist is a subtil but critical distinction.
The fix being a simple layout change rather than a clever algorithm is also a good reminder. I've spent 20 years building apps and the most impactful optimizations were almost always about changing the shape of data, not adding complexity.
I'm building Pithos (https://pithos.dev), a zero-dependency TypeScript utility ecosystem.
Five modules, one package:
data utilities (Arkhe), schema validation (Kanon), Result/Option types (Zygos), typed error classes (Sphalma), and a Lodash migration bridge (Taphos).
The idea is that these patterns compose natively:
Validate with Kanon, get a typed Result back via Zygos, chain transformations with Arkhe.
One pipeline, no try/catch, full type inference.
Benchmarks: ~4x smaller and 5-11x faster than Zod 4, ~21x smaller than Lodash, ~3x smaller than Neverthrow.