Reviewing code from less experienced or unmotivated people is also very taxing, both in a cognitive and emotional sense. It will never approach a really good level of quality because you just give up after 4 rounds of reviews on the same feature.

▲

EdwardDiego 4 days ago | parent | next [-]

Except humans learn from your PR comments and in other interactions with more experienced people, and so inexperienced devs become experienced devs eventually. LLMs are not so trainable.

▲

krageon 3 days ago | parent | next [-]

If they're unmotivated enough to not get there after four review rounds for a junior-appropriate feature, they're not going to get better. It's a little impolite to say, but if you spend any significant amount of time coaching juniors you'll encounter exactly what I'm talking about.

	▲	EdwardDiego 2 days ago \| parent [-]
		I have spent plenty, rest assured.

▲

org3 3 days ago | parent | prev | next [-]

Some people say we're near the end of pre-training scaling, and RLHF etc is going to be more important in the future. I'm interested in trying out systems like https://github.com/OpenPipe/ART to be able to train agents to work on a particular codebase and learn from my development logs and previous interactions with agents.

▲

shepherdjerred 3 days ago | parent | prev | next [-]

LLMs can learn if you provide it rules in your repo, and update those rules as you identify the common mistakes the LLM makes

▲

300hoogen 3 days ago | parent | prev [-]

retarded take

	▲	dayjaby 3 days ago \| parent \| next [-]
		Can you elaborate or you call it a day after insulting?
	▲	EdwardDiego 2 days ago \| parent \| prev [-]
		Thanks for the insightful reply that showed me where I went astray.

▲

btown 3 days ago | parent | prev | next [-]

Here’s the thing about AI though - you don’t need to worry about its confidence or impact on professional development if you’re overly critical, and it will do a turn within seconds. That gives a tremendous amount of flexibility and leverage to the code reviewer. Works better on some types of problems than others, but it’s worth exploring!

▲

hakfoo 3 days ago | parent | prev [-]

With human co-workers, you can generally assume things you can't with AI.

My human co-workers generally have good faith. Even the developer who was clearly on the verge of getting a role elsewhere without his heart in it-- he tried to solve the problems assigned to him, not some random delusion that the words happened to echo. I don't have that level of trust with AI.

If there's a misunderstanding the problem or the context, it's probably still the product of a recognizable logic flow that you can use to discuss what went wrong. I can ask Claude "Why are you converting this amount from Serbian Dinars to Poppyseed Bagels in line 476?" but will its answer be meaningful?

Human code review often involves a bit of a shared background. We've been working with the same codebases for several years, so we're going to use existing conventions. In this situation, the "AI knows all and sees all" becomes an anti-feature-- it may optimize for "this is how most people solve this task from a blank slate" rather than "it's less of a cognitive burden for the overall process if your single change is consistent with 500 other similar structures which have been in place since the Clinton administration."

There may be ways to try to force-feed AI this behaviour, but the more effort you devote to priming and pre-configuring the machine, the less you're actually saving over doing the actual work in the first place.