Hacker News Reader

Comment by pipes | Hacker News Reader

I've now been trying for six months to get agents to produce decent code. As in readable / easy to follow, easy to change. I'm doing something really wrong. It's killing me. Everything it produces will work, buts it diabolically over complicated. I've built skills that have helped. But not massively. I've used other people's skills, in particular Matt pococks grill me and Dex hortlys show me. These have helped a bit. I work in enterprise, I want to be proud of what I'm producing, but trying to understand and then cajole and agents code into something that's good is exhausting. If anyone here has been through this and can share how they got through this, I'd really appreciate the help.

Edit: I have access to codex, vscode, GitHub co pilot cli and all anthropic and openai models (excluding mythos).

View on HN

> I'm doing something really wrong. It's killing me.

You're not doing anything wrong. The cold hard reality is that this tech doesn't work half as well as its supporters claim it does. You've seen it with your own eyes, as have I. LLMs are not good at programming.

Same, it’s so smart but so dumb. I explain an architecture change to it and write examples of strongly typed Go code and how to store structure, it agrees and then proceeds to write some untyped string map ball of mud that has 900 specializations.

But maybe that’s on us, AI doesn’t care about all these special cases, it’s not debt to it as it will simply read them all when making changes. We’re obsessed with quality and what code is supposed to look like but those are human standards, AIs evolve to look at this complexity as a single picture, they can simply see through it so what is spaghetti code to us is merely some code to them that works as it should and is efficient. It’s interesting we can see how the two things drift apart, you would think at some point AI generated code should explode but it hold together unreasonably well in most cases…

Use hooks to run a bunch of review steps after -all- code writing steps your agent does and give it the exact review criteria you just described (via git hooks, or your agent harness of choice's own hooks eg https://code.claude.com/docs/en/hooks or AGENTS.md). So after every step where the agent writes the shitty untyped string map ball of mud, your orchestrator/main thread agent that spawned the code-writing-subagent spawns a follow-up review agent automatically that is given that output, your prompt that explains what well written Go code looks like, and even the sample/golden-path code of your choice to use as a style guide.

Each time you encounter a shitty thing you hate, add a new 'review type' / 'thing to watch out for' and just ask your agent to add it to your hooks for you. This works well with Claude at least.

I have about a dozen or so hooks that run on every integration branch my agents write that review for all sorts of things from correctness to spec, performance improvement opportunities, modularity, analysis of any dependencies added, 'definition of done', UI/UX, etc.

I recently told Claude it should run the whole suite of reviews twice. I will probably go on and proceed to having it run like 5 times eventually idfk.

But the more you start asking your agents to modify their own behavior, using the native solutions offered by Cursor, or Claude, or Codex, the sooner you'll start to feel better about the results.

I'm having bad results with SotA models. Some questions, if you're up for it:

In your workflow, who implements the review feedback - the review subagent or the code-writing-subagent?

Do have a baseline styleguide (like Google's Go style guide) for the review subagents, or is it entirely the subjective things and specific corrections? I remember 6 months ago it seemed like piling general "good taste" code advice into AGENTS.md was considered bad.

Do you move between harnesses or have you gone all in on claude? I've bounced between claude/codex/omp, maybe to my detriment.

Not asking for answers to these questions, just frustration dumping:

The biggest things I've struggled with are models having taste. For spec writing I was having a lot of issues with them making statements that were interpretable in a superposition of ways, eg "we'll do XYZ with entities that support and need it" when there's 3 possible entities and the model hand-waved at exactly the wrong tokens.

I added AGENTS.md guidance + memories to be unambiguous (with short but good examples) and "no coined shorthand". Now I'm getting a marked increase in specificity, but it's places that don't matter (claude explaining existing code to itself). I'm having difficulty controlling the spew of new text, but feature writing/research still gets fuzzy and lazy around the difficult underspecified aspects of the problem/feature.

Do I just keep dumping examples into reviewer subagent context and have them rewrite and simplify the research subagent spew?

I repeatedly have "Risks and gotchas" sections have a whole paragraph dedicated to things that don't matter, and then a single sentence bullet point that's actually a huge problem when I dig into it.

Do I have a generic hook to make subagents to review bullet points and size them commensurate with impact? If I tell them to "have taste", do they have taste?

I'm just trying to get good code done. I hate these things.

> In your workflow, who implements the review feedback - the review subagent or the code-writing-subagent?

I think currently my orchestrator - which spins up subagents for impl, research, review, fixes, etc.

I've been working with a single orchestrator per "project" or "feature" or whatever sort of "thing I'm paying attention to" is (I guess...chat?) and that orchestrator is told to use subagents to do any/all of this type of stuff, it's sole purpose is to just communicate with me, instantiate these types of 'work', and tell me about results or ask for input.

I am just now considering changing this though and considering something even heavier, but for the purpose of "cleaning up / polishing" lazy work by a single pass of "build thing X", this sort of orchestrator with an AGENTS.md or skill that says "always do a review pass after you finish a task by spinning up N sequential (or parallel) follow up subagents to review and another M parallel or sequential fix subagents to 'fix' those things should make a meaningful difference, if a person sees the same types of traps that their model falls into repeatedly.

You don't even need to have some complex harness. Just take a stock frontier model and its default cli or harness, ask it to edit its agents file to tell itself to always work in this manner, and you're done.

I just wanted to thank you for the followup and the clarity on your pattern. So many people say "it's working great for me" without explaining how they go beyond "tell claude to implement feature".

Thanks so much for taking the time to write this. I'm going to try it.

We are also building a framework for mechanically enforced adverserial review cycles - think it could be relevant here so I am mentioning it: zeroshot.sh

Codify your project working philosophy in AGENTS.md and of course skills. Give AI an example of code you liked and code you didn't; let it help you articulate some succinct rules or philosophies that capture your preferences(for example I prefer early return, limiting nesting, unnecessary tests, excessive local error handling, comments that are self explanatory, etc).

Then have a separate review agent review the work against your codified working philosophy. THEN, give it a review yourself(just don't tell anyone you look at code or you'll get called a boomer).

You said you've tried this but that it hasn't helped massively. I have found this to help massively just not without fault.

The struggle is real though.

Thanks for responding, I'll try this

Reply on news.ycombinator.com