Ask HN: How are you LLM-coding in an established code base?

I would be very curious to hear about the state of your codebase a year from now. My impression was that LLMs are not yet robust enough to produce quality, maintainable code when let loose like this. But it sounds like you are already having more success than I would have guessed would be possible with current models.

One practical question: presumably your codebase is much larger than an LLM's context window. How do you handle this? Don't the LLMs need certain files in context in order to handle most PRs? E.g. in order to avoid duplicating code or writing something in a way that's incompatible with how it will be used upstream.

I describe functions that I want to change or upgrade. Claude code gives the best results for me. I ask for a plan first to see if it gets what I want to do and I can finetune it then. I have a project that still uses zend framework and it gets it quite good.

> AFAICT, there’s no service that lets me: give a prompt, write the code, spin up all this infra, run Playwright, handle database migrations, and let me manually poke at the system. We approximate this with GitHub Actions, but that doesn’t help with manual verification or DB work.

I think this is almost exactly what we've built with https://superconductor.dev

- set up a project with one or more repos

- set up your environment any way you want, including using docker containers

- run any number of Claude Code, Codex, Gemini, Amp, or OpenCode agents on a prompt, or "ticket" (we can add Cursor CLI also)

- each ticket implementation has a fully running "app preview", which you can use just like you use your locally running setup. your running web app is even shown in a pane right next to chat and diff

- chat with the agent inside of a ticket implementation, and when you're happy, submit to github

(agents can even take screenshots)

happy to onboard you if that sounds interesting, just ping me at sergey@superconductor.dev

I don't "vibe code", but I do two main things:

1) I throw it the simpler tasks that I know only involve a few files and there are similar examples it can work from (and I tend to provide the files I'm expecting will be changed as context). Like, "Ok, I just created a new feature, go ahead and setup all test files for me with all the standard boilerplate. Then I review, make adjustments myself (or re-roll if I forgot to specify something important), then commit and move forward.

2) I use the frontier thinking models for planning help. Like when I'm sketching out a feature and I think I know what will need to be changed, but giving, say, an Opus 4.5 agent a chance to take in the changes I want, perform searches, and then write up its own plan has been helpful in making sure I'm not missing things. Then I work from those tasks.

I agree that Copilot's Cloud agents aren't useful (they don't use smart models, presumably because it's $$$) and also I'm not a great multitasker so having background agents on worktrees would confuse the heck out of me.

How do you review the no?