Email us at hn@ycombinator.com if you want some tips about how to present this to HN. (Same invitation goes for everybody who wants such tips.)
Edit: here's what I sent the users who emailed:
If you're sharing
your own work and there's a way to try it out, put "Show HN" in
the title. Make sure you've read the Show HN guidelines: https://news.ycombinator.com/showhn.html.
Include text giving the backstory of how you came to work on this, and explaining what's different about it. That tends to seed discussion in a good direction. (Your text should show up at the top of the Show HN submission, but if for some reason it doesn't, add it as a first comment to the thread. Either way is fine.)
Include a clear statement of what your project is or does. If you don't, the discussion will consist of "I can't tell what this is".
Include links to any previous HN threads that are relevant. Readers like those.
Drop any language that sounds like marketing or sales. On HN, that is an instant turnoff. Use factual, direct language. Personal stories and technical details are great.
For Show HN, the product/project needs to actually exist and there needs to be a way for people to try it out. It can't just be a landing page or market test or fundraiser or a blog post or a curated list or other reading material. Please respect this rule. If we allowed "Show HN" on all those things, nearly every post would be a Show HN.
Please make it easy for users to try your thing out, preferably without having to sign up, get a confirmation email, and other such barriers. You'll get more feedback that way, plus HN users get ornery if you make them jump through hoops.
If it's hardware or something that's not so easy to try out over the internet, find a different way to show how it actually works—a video, for example, or a detailed post with photos.
Don't have your username be that of your company or project. It creates a feeling of using HN for promotion and of not really participating as a person. You don't have to use your real name, just something to indicate that you're here as a human, not a brand. If you'd like to change your username, email hn@ycombinator.com.
If you're comfortable doing so, put your email address in your profile so we can
contact you if we notice anything, and also so
we can send you a repost invite. We do that sometimes.
Make sure your friends and users do not add booster comments in the thread. HN users are adept at picking up on those, they consider it spamming, and they will flame you for it. If a friend or a fan has something interesting to say, that's fine, but comments should not be promotional.
You can post a new release as a Show HN only if the new version is significantly different. It shouldn't just be an incremental upgrade. If you do repost, add a comment linking to the previous Show HN and explaining what is different from last time. This should probably only happen once or twice a year—more starts to be excessive.
Sure. First of all, although I do spend a lot of time interacting with Claude Code in chat format, that is not what I am talking about here. I have setup Claude Code with very specific instructions for use of agents, which I'll get to in a second.
First of all, there's a lot of collections of subagent definitions out there. I rolled my own, then later found others that worked better. I'm currently using this curated collection: https://github.com/VoltAgent/awesome-claude-code-subagents
CLAUDE.md has instructions to list `.agents/agents/**/*.md` to find the available agents, and knows to check the frontmatter yaml for a one-line description of what each does. These agents are really just (1) role definitions that prompts the LLM to bias its thinking in a particular way ("You are a senior Rust engineer with deep expertise in ..." -- this actually works really well), and (2) a bunch of rules and guidelines for that role, e.g. in the Rust case to use thiserror and strum crates to avoid boilerplate in Error enums, rules for how to satisfy the linter, etc. Basic project guidelines as they relate to Rust dev.
Secondly, my CLAUDE.md for the project has very specific instructions about how the top-level agent should operate, with callouts to specific procedure files to follow. These live in `.agent/action/**/*.md`. For example, I have a git-commit.md protocol definition file, and instructions in CLAUDE.md that "when the user prompts with 'commit' or 'git commit', load git-commit action and follow the directions contained within precisely." Within git-commit.md, there is a clear workflow specification in text or pseudocode. The [text] is my in-line comments to you and not in the original file:
"""
You are tasked with committing the currently staged changes to the currently active branch of this git repository. You are not authorized to make any changes beyond what has already been staged for commit. You are to follow these procedures exactly.
1. Check that the output of `git diff --staged` is not empty. If it is empty, report to the user that there are no currently staged changes and await further instructions from the user.
2. Stash any unstaged changes, so that the worktree only contains the changes that are to be committed.
3. Run `./check.sh` [a bash script that runs the full CI test suite locally] and verify that no warnings or errors are generated with just the currently staged changes applied.
- If the check script doesn't pass, summarize the errors and ask the user if they wish to launch the rust-engineer agent to fix these issues. Then follow the directions given by the user.
4. Run `git diff --staged | cat` and summarize the changes in a git commit message written in the style of the Linux kernel mailing list [I find this to be much better than Claude's default commit message summaries].
5. Display the output of `git diff --staged --stat` and your suggested git commit message to the user and await feedback. For each response by the user, address any concerns brought up and then generate a new commit message, as needed or instructed, and explicitly ask again for further feedback or confirmation to continue.
6. Only when the user has explicitly given permission to proceed with the commit, without any accompanying actionable feedback, should you proceed to making the commit. Execute 'git commit` with the exact text for the commit message that the user approved.
7. Unstash the non-staged changes that were previously stashed in step 2.
8. Report completion to the user.
You are not authorized to deviate from these instructions in any way.
"""
This one doesn't employ subagents very much, and it is implicitly interactive, but it is smaller and easier to explain. It is, essentially, a call center script for the main agent to follow. In my experience, it does a very good job of following these instructions. This particular one addresses a pet peeve of mine: I hate the auto-commit anti-feature of basically all coding assistants. I'm old-school and want a nice, cleanly curated git history with comprehensible commits that take some refining to get right. It's not just OCD -- my workflow involves being able to git bisect effectively to find bugs, which requires a good git history.
What's important about this new type of image generation that's happening with tokens rather than with diffusion, is that this is effectively reasoning in pixel space.
Example: Ask it to draw a notepad with an empty tic-tac-toe, then tell it to make the first move, then you make a move, and so on.
You can also do very impressive information-conserving translations, such as changing the drawing style, but also stuff like "change day to night", or "put a hat on him", and so forth.
I get the feeling these models are quite restricted in resolution, and that more work in this space will let us do really wild things such as ask a model to create an app step by step first completely in images, essentially designing the whole app with text and all, then writing the code to reproduce it. And it also means that a model can take over from a really good diffusion model, so even if the original generations are not good, it can continue "reasoning" on an external image.
Finally, once these models become faster, you can imagine a truly generative UI, where the model produces the next frame of the app you are using based on events sent to the LLM (which can do all the normal things like using tools, thinking, etc). However, I also believe that diffusion models can do some of this, in a much faster way.
There might be some papers or other guides out there, but their advice will be based on whatever tools happened to be available at the time they were written and on the particular types of translations the authors cared about. The technology is advancing so rapidly that you might be better off just experimenting with various LLMs and prompts for texts and language pairs you are interested in.
I started using LLMs for translation after GPT-4 came out in March 2023—not that long ago! At first, the biggest problem was the context window: it wasn’t possible to translate more than a couple of pages at a time. Also, prompt writing was in its infancy, and a lot of techniques that have since emerged were not yet widely known. Even now, I still do a lot of trial and error with my prompts, and I cannot say with confidence that my current prompting methods are the best.
But, for what it’s worth, here are some strategies I currently use when translating with LLMs:
- In the prompt, I explain where the source text came from, how the translation will be used, and how I want it to be translated. Below is a (fictional) example, prepared through some metaprompting experiments with Claude:
- I run the prompt and source text through several LLMs and glance at the results. If they are generally in the style I want, I start compiling my own translation based on them, choosing the sentences and paragraphs I like most from each. As I go along, I also make my own adjustments to the translation as I see fit.
- After I have finished compiling my draft based on the LLM versions, I check it paragraph by paragraph against the original Japanese (since I can read Japanese) to make sure that nothing is missing or mistranslated. I also continue polishing the English.
- When I am unable to think of a good English version for a particular sentence, I give the Japanese and English versions of the paragraph it is contained in to an LLM (usually, these days, Claude) and ask for ten suggestions for translations of the problematic sentence. Usually one or two of the suggestions work fine; if not, I ask for ten more. (Using an LLM as a sentence-level thesaurus on steroids is particularly wonderful.)
- I give the full original Japanese text and my polished version to one of the LLMs and ask it to compare them sentence by sentence and suggest corrections and improvements to the translation. (I have a separate prompt for this step.) I don’t adopt most of the LLM’s suggestions, but there are usually some that I agree would make the translation better. I update the translation accordingly. I then repeat this step with the updated translation and another LLM, starting a new chat each time. Often I cycle through ChatGPT --> Claude --> Gemini several times before I stop getting suggestions that I feel are worth adopting.
- I then put my final translation through a TTS engine—usually OpenAI’s—and listen to it read aloud. I often catch minor awkwardnesses that I would overlook if reading silently.
This particular workflow works for me because I am using LLMs to translate in the same language direction I did manually for many years. If I had to translate to or from a language I don’t know, I would add extra steps to have LLMs check and double-check the accuracy of the translation and the naturalness of the output.
I was asked recently by some academics I work with about how to use LLMs to translate documents related to their research into Japanese, a language they don’t know. It’s an interesting problem, and I am planning to spend some time thinking about it soon.
Please note that my translation process above is focused on quality, not on speed. If I needed to translate a large volume of text more quickly, I would write a program to do the translation, checking, and rechecking through API calls, accepting the fact that I would not be able to check and polish the translation manually as I do now.
If anyone here would like to brainstorm together about how to use LLMs for translation, please feel free to email me. My website, with my email address on the Contact page, is linked from my HN profile page.
Edit: here's what I sent the users who emailed:
If you're sharing your own work and there's a way to try it out, put "Show HN" in the title. Make sure you've read the Show HN guidelines: https://news.ycombinator.com/showhn.html.
Include text giving the backstory of how you came to work on this, and explaining what's different about it. That tends to seed discussion in a good direction. (Your text should show up at the top of the Show HN submission, but if for some reason it doesn't, add it as a first comment to the thread. Either way is fine.)
Include a clear statement of what your project is or does. If you don't, the discussion will consist of "I can't tell what this is".
Include links to any previous HN threads that are relevant. Readers like those.
Drop any language that sounds like marketing or sales. On HN, that is an instant turnoff. Use factual, direct language. Personal stories and technical details are great.
For Show HN, the product/project needs to actually exist and there needs to be a way for people to try it out. It can't just be a landing page or market test or fundraiser or a blog post or a curated list or other reading material. Please respect this rule. If we allowed "Show HN" on all those things, nearly every post would be a Show HN.
Please make it easy for users to try your thing out, preferably without having to sign up, get a confirmation email, and other such barriers. You'll get more feedback that way, plus HN users get ornery if you make them jump through hoops.
If it's hardware or something that's not so easy to try out over the internet, find a different way to show how it actually works—a video, for example, or a detailed post with photos.
Don't have your username be that of your company or project. It creates a feeling of using HN for promotion and of not really participating as a person. You don't have to use your real name, just something to indicate that you're here as a human, not a brand. If you'd like to change your username, email hn@ycombinator.com.
If you're comfortable doing so, put your email address in your profile so we can contact you if we notice anything, and also so we can send you a repost invite. We do that sometimes.
Make sure your friends and users do not add booster comments in the thread. HN users are adept at picking up on those, they consider it spamming, and they will flame you for it. If a friend or a fan has something interesting to say, that's fine, but comments should not be promotional.
You can post a new release as a Show HN only if the new version is significantly different. It shouldn't just be an incremental upgrade. If you do repost, add a comment linking to the previous Show HN and explaining what is different from last time. This should probably only happen once or twice a year—more starts to be excessive.