IME you can get good results if:
1. You have very good tests. The agent can write them, but you have to prompt it to do that, and some human input may be needed here.
2. You have a good, modular architecture. Again, this is something that needs to be prompted and/or developed up front. Agent work can scale if you divide and conquer, so that any given task has a well-defined scope, limiting the amount of context needed to handle it well. If you let an agent just build a big pile of code, you’ll have issues.
Once you have the above, you’re more likely to be able to just let the agent run.
This is why you hear about things like SQLite being ported to Rust (by multiple groups!) It has a comprehensive unit test suite and a good existing architecture. Such porting projects are benefitting from already having done the upfront work that I mentioned, plus they have the original source code as a reference implementation.
Because of that, most of what I do involves a lot of interaction with the agent. That’s because I’m typically working on complex existing systems, that don’t necessarily have the above properties, and agents aren’t at the point where they can handle that autonomously.
This is exactly the case for "porting" Bash to Rust. There is a huge amount of existing tests that can be leverage and when in doubt you can run the same code in bash and Huck and compare the result and then fix the issue.