RLVR? Next RLCR?

Do you understand why rhetorical questions make for poor commentary?

Come on, don’t be a potato just because you don’t like someones opinion. The parent posts point is obvious and not rhetorical at all.

It’s more reasonable to extrapolate based on past evidence than arbitrary conjecture.

Self driving cars are great!

…but fully autonomous (level 4+) driving turns out to be really much harder to do that the initial 6-12 of self driving demos suggested it would be.

Its always easier to get the first prototypes and demos up, and its literally ALWAYS wrong to extrapolate exponential improvement based on that initial set of results.

It should be a surprise to no one that AI coding follows a diminishing returns log curve, and that improvements are merely incremental after the initial burst of improvement.

> The parent posts point is obvious and not rhetorical at all.

I am still not sure what their opinion or point is, because they vagueposted instead of telling us.

Coding is a technical problem. Self-driving cars are a political problem.

Right, we've had trains for over a century!

Ironically, even self-driving trains are a political problem. How stupid is it that we still have train wrecks every so often? Obviously a solvable problem, but humans still insist on being involved for some reason.

My experience lines up with this.

Last year, the frontier llms could produce working code, but the code looked brittle and overly defensive. Earlier this year, it got better and started to take more of the codebase into account. Since Claude 5.5, the quality improved substantially.

A lot of these things could be improved with prompt engineering and steering, but much less so nowadays.

But I don't think code quality is easy to measure, so the best we have is people's experience.

I personally do not understand and I'd love to know.

Certainly in 2024 I did not foresee AI coding ending up as reliably good as I find it in recent months.

I'd like to have some understanding of whether this improvement is likely to continue or we've reached plateau.

most people also dont understand why their cars are safer (over the decades). But they still know it to be the case.

Of course, back in the 50's an 60's, they extrapolated that we'd have flying cars today, so you're not wrong to be careful about extrapolating...

Actually, I don't know why. Does anybody know why, other than the model is bigger? They've definitely improved. Throwing billions of dollars and insane amounts of compute at the problem seems to have helped. Amazingly, the "bitter lesson" seems to continue to apply.

I don't know if this is what parent alludes to, but they improved a lot from the collected exchanges. Lots of what developers have done got filtered into training data of what's expected. (That's why xai got so much better after buying Cursor... or Cursor's data to be more precise) Also a lot of synthetic tests that resemble known benchmarks.

agressive rlhf to bias towards massive test suites and verification loops is my guess. after literally every change claude runs the entire test suite, sometimes multiple times, and generated test code well outpaces generated impl code.

llm's are only good for closed systems with robust automated verification loops, which makes me doubt it's general applicability. at least for now, humans seem much better at navigating domains without an easy way to verify systems.

RLHF is only tweaking the LLM to be more "well behaved". You wanted to say RLVR (reinforcement learning from verifable rewards). I know because I am building such RL gyms for computer use.

sure whatever, you get the point :)

i remember a year ago i'd have to tell the llm to use the bash tool to compile to see failures. these days, for every task it

1. throughly inspects git history

2. runs the full test suite to get a baseline

3a. for each change, runs (a subset if i'm lucky) the testsuite

3b. writes about 3 billion lines of tests, including tests to test tests

4a. uses the harness's screenshot tool to check each visual change

4b. for webapps, spends several minutes poking at it with some kind of browser devtool

5. runs the entire "smoke test" suite, which often takes several minutes and regularly interrupts my keyboard focus

6. runs the full test suite at the end

even small changes take at least 10+ minutes to complete, but with much higher accuracy than a year ago.

to me these things are dumb but persistent, useful but not intelligent.

> to me these things are dumb but persistent, useful but not intelligent.

Then you have a very uncommon definition of the term "intelligent", because that's roughly what I would expect an intelligent, conscientious developer to do. Many, many bugs stem from developers who believe themselves to be too "intelligent" to need an extensive test suite.

i would expect someone who can write good code in a single pass to be more intelligent than someone who requires multiple tries.

same with anything else really. a better chef can nail a dish in one or two attempts, whereas a worse but persistent chef might take 100 attempts to achieve the same quality.

or likewise, i'm not as good as a basketball player if it takes me 100 attempts to nail a three pointer when an nba player does it 35% of the time - despite both of us eventually achieving the goal.

I’m with you on this. LLM coding agents are incredibly fast, persistent and knowledgeable, and those are all really useful. But they still make a lot of stupid decisions. Without a feedback loop they just go wild. They write tests, which is a form of feedback, but without direction they just grow vast jungles of pointless tests, while the structure of the code itself gets more and more tangled.

Maybe the LLM is smarter than you give it credit for. Maybe the LLM is intellectually humble and self-aware enough to know that even a small code change can easily break something it hadn't thought of.

> RLHF is only tweaking the LLM to be more "well behaved"

Not quite right - RLHF is about aligning with human preferences (because it trains, as the name implies, on signal from humans). This does not necessarily correlate with behavior. We use RLHF across any number of domains and with any number of goals, not just alignment.

RLVR is a (more recent, better in some cases) way to automate the training loop without the human being involved, because you give the model a way to verify its own results and train on that as a signal.

Environments with millions of coding problems and graders. They solve problems to learn to code, not just learn to predict the next token as they do in pre-training.

I wish I knew which factor had the most impact on coding performance.

The harnesses have improved and I suspect there’s a decent amount of logic pushed there.

Models are larger, so the generalization that happens is better.

Lots of effort has been put towards training on coding tasks.

The "bitter lesson" being that you need teams of dedicated scientists, engineers designing increasingly better training to squeeze more out of existing compute? I love how people think bitter lesson was just "oh we added one more GPU and now the model is better than our hand-crafted approach". When really its just the opposite -- models with better approaches were necessary, and models at 10% the size are showing nearly identical performance when some attention is paid to quality. The "savory lesson" is, don't listen to the bitter lesson, it was only true when the 'hand-crafted features' experts were using were vastly over-aligned to human superstition, but if the priors are well-aligned mathematically, it really does help to have a better strategy (and more compute may not help). The reverse-bitter-lesson every trader and investor knows: throwing more compute can often give worse results (e.g. memorization), not better.

My experience has been that they excel at problems with solutions that are cheap to verify. Things one can unit test for example. Easier to RL. Architectural issues are harder to train for because the training data is dominated by tutorial/toy projects. There's 10,000 toy compilers for every LLVM

As far as I can tell, a large part of that has to do with throwing them into loops with tools which give them feedback and ground them in reality. They still hallucinate but when they do, the feedback calls it out and they correct themselves quickly.

They haven't got significantly better since August 2025. What's happened is people's standards have gone down and brain atrophy has set in. We're just winging it now.