logoalt Hacker News

NitpickLawyertoday at 10:14 AM2 repliesview on HN

The cool thing about LLMs is that once a capability is "good enough" you can always "chain" them together for better overall results. On the client side this means "write an API that does x y z" -> "analyse this API for security concerns" -> "PoC for each finding from this report" -> "fix this code according to these verified claims".

On the "server side" (i.e. training) you can use the current gen models to improve the training data by running many parallel environments with a similar loop as above. Then incorporate the new data and repeat. Reminiscent of the old GAN approach, where the generator and discriminator are trained together in an adversarial regime. The end result should be safer code on "vanilla" prompts. "Write an API that does x y z" should now contain the learnings from this loop, and the models should produce better code.

Works really well for every verifiable scenario. And as the models become better, they can also more reliably create environments that closely match real-world scenarios. If you also have some data from human devs (say you run a subsidised coding model for a few months), even better.

An example of turning a "normal" repo into a verifiable environment that I read recently in the Cursor blog: take a repo, ask an LLM to remove a feature, verify that the app still works w/o the feature, verify that the tests for that feature fail. Ask a generator to "add feature x". Verify with the original tests. If pass -> give carrot :)

The key is composition. Once you unlock a new capability, that gets implemented and incorporated into the next training run. Pretty neat, I would say, and the main driver for the recent increase in the breadth of capabilities for new models.


Replies

ameliustoday at 10:54 AM

> If pass -> give carrot :)

More like, give $$$ pass or not.

onlyrealcuzzotoday at 2:26 PM

The bad thing about software is that there's infinite ways to solve the same problem, and the vast majority of them are terrible and unmaintainable, so "working" is a prerequisite, but not really "good enough".

It's good if no LLMs can find a bug. It certainly does not mean there isn't one...

I've found LLMs to be very disappointing at identifying overly complex code (that they've written) and the correct architectural decisions to 1) make the code actually work, and 2) be simple, maintainable, and future proof.

They can certainly find some bugs, which definitely has value, but I've not had much success with them writing code that simply has no bugs...

That requires simplicity and architectural correctness, something LLMs are good at vaguely bullshitting, but not very good at getting correct.

I think this can be solved by feeding them the right metrics, but I haven't found prior art for how to algorithmically pinpoint: 1) what is actually complex in a bad way (there's a lot of ways to do this roughly), and 2) where exactly the problem is most acutely (less prior art here, but some), and 3) what viable solutions are.

If you can get better at 1 and 2, the LLMs can get much better at 3.

Anybody who has ideas, I'd love to hear them, as this is what I'm working on now.