Ask HN: How do people use coding agents? | Hacker News Reader

Ask HN: How do people use coding agents?

3 points0-bad-sectors5 comments

I feel like I am doing something wrong with all the success stories I am reading. I followed the different workflows I have seen here like creating a detailed plans and writing extensive prompts and guardrails. Tried using instructions and skills yet I never get a satisfactory results at least in existing code bases.

The other day I needed to implement a feature that already had very detailed instructions and planning yet the agent gave me very low quality code riddled with naive mistakes. As I knew what should be done I discarded all the changes proposed by the agent and wrote the entire thing with the help of autocomplete in VSCode which was incredible as long as write a meaningful function names and comments it and managed to finish the entire feature in one day thanks to that and I believe that was much cheaper than all my failed attempts at agentic coding.

How do you guys yield good results from Claude Code and the likes of it?

Keep it simple and run a fresh, new context for each prompt.

I use the pi-mono coding agent with several different new open models running locally.

The simpler and more precise the prompt the better it works. Some examples:

"Review all golang code files in this folder. Look for refactor opportunities that make the code simpler, shorter, easier to understand and easier to maintain, while not changing the logic, correctness or functionality of the code. Do not modify any code; only describe potential refactor changes."

After it lists a bunch of potential changes, it's then enough to write "Implement finding 4. XYZ" and sometimes add "Do not make any other changes" to keep the resulting agent actions focused.

I find describing the problem often works well, as opposed specifying a solution / change. And if it has a means to validate it's results then its significantly better as well.

So maybe describe the problem and work first on a means to detect errors, second - then let it rip.

This. And when possible, first asking the AI to add more granular logging around the code where the problem is - then re-run the code and feed the new log in a new context.

I've used this to debug some moderately complex bugs in golang and godot code and it works really well - the combo of having a new context with the (sometimes overly) granular debug logging and only the required, specific source code.

It is really good at refactors. Saying things like "deprecate the following configuration keys" and replace them with the concept of ... Even in a codebase with over 1000 files, it just works.

I let it make a detailed to do list of issues it has or questions it has and discuss it one by one. And fix and push to git. Works very reliably.

Reply on news.ycombinator.com