Ask HN: Anyone struggling to get value out of coding LLMs?

> I've tried:

> - Cursor (can't remember which model, the default)

> - Google's Jules

> - OpenAI Codex with o4

Cursor's "default model" rarely works for me. You have to choose one of the models yourself. Sonnet 4, Gemini 2.5 Pro, and for tricky problems, o3.

There is no public release of o4; you used o4-mini, a model with poorer performance than any of the frontier models (Sonnet 4, Gemini Pro 2.5, o3).

Jules and Codex, if they're like Claude Code, do not work well with "Build me a Facebook clone"-type instructions. You have to break everything down and make your own tech stack decisions, even if you use these tools to do so. Yes they are not perfect and make regressions or forget to run linters or check their work with the compiler, but they do work extremely well if you learn to use them, just like any other tool. They are not yet magic that works without you having to put in any effort to learn them.

I want to train the LLM on the whole code base and then pass a hand picked context specific to what I'm asking.

So it doesn't only suggest what can be found on w3schools and geeks4geeks and maybe stackoverflow, but also whatever idioms and utility functions my code base has.

> For greenfield it’s amazing

I'll preface this comment with: I am a recent startup owner (so only dev, which is important) and my entire codebase has been generated via Sonnet (mostly 3.7, now using 4.0). If you actually looked at the work I'm (personally) producing, I guess I'm more of a product-owner/project-manager as I'm really just overseeing the development.

> I have yet to see an LLM-generated app not collapse under it’s own weight after enough iterations/prompts.

There's a few crucial steps to make an LLM-generated app maintainable (by the LLM):

- _have a very, very strong SWE background_; ideally as a "strong" Lead Dev, _this is critical_

- your entire workflow NEEDS to be centered around LLM-development (or even model-specific):

  - use MCPs wherever possible and make sure they're specifically configured for your project

  - don't write "human" documentation; use rule + reusable prompt files

  - you MUST do this in a *very* granular but specialized way; keep rules/prompts very small (like you would when creating tickets)

  - make sure rules are conditionally applied (using globs); do not auto include anything except your "system rules"

  - use the LLM to generate said prompts and rules; this forces consistency across prompts, very important

  - follow a typical agile workflow (creating epics, tickets, backlogs etc)

  - TESTS TESTS AND MORE TESTS; add automated tools (like linters) EVERYWHERE you can

  - keep your code VERY modular so the LLM can keep a focused context, rules should provide all key context (like the broader architecture); the goal is for your LLM to only need to read or interact with files related to the strict 'current task' scope

  - iterating on code is almost always more difficult than writing it from scratch: provided your code is well architected, no single rewrite should be larger than a regular ticket (if the ticket is too large then it needs to be split up)

This is off the top of my head so it's pretty broad/messy but I can expand on my points.

LLM-coding requires a complete overhaul of your workflow so it is tailored specifically to an LLM, not a human, but this is also a massive learning curve (that take's a lot of time to figure out and optimize). Would I bother doing this if I were still working on a team? Probably not, I don't think it would've saved me much time in a "regular" codebase. As a single developer at a startup? This is the only way I've been able to get "other startup-y" work done while also progressing the codebase - the value of being able to do multiple things at a time, let the LLM and intermittently review the output while you get to work on other things.

The biggest tip I can give: LLMs struggle at "coding like a human" and are much better at "bad-practice" workflows (e.g. throwing away large parts of code in favour of a total rewrite) - let the LLM lead the development process, with the rules/prompts as guardrails, and try stay out of it's way while it works (instead of saying "hey X thing didn't work, go fix that now") - hold its hand but let it experiment before jumping in.

I have. I was criticized for pointing out spurious nonsense in LLM slop by someone who claimed people wouldn't have to resort to it if other people made an effort to explain things better.

But I don't believe anyone is entitled to an explanation. I find things out by looking up books and testing things. Any explanation someone deigns to give me is a bonus and doubted until corroborated.

I don't know why anyone would think they are owed a custom explanation for their specific questions and thinking like that will get you in trouble when you come to depend on what anyone (or anything) is willing to chew up for you.

Maybe I was terse but I don't think I was rude or illogical.

Not knowing which model you’re using is doing it wrong, unfortunately, that matters with current-gen tools. The differences are significant. And while LLMs do hit limits fast on deep complex work, dismissing them outright misses the real utility: they’re great at the tedious stuff. No fanboyism but more middle of the road it works great for some things, ok for others and terrible for the rest.