Live data from Hacker News

If you are asking for human attention, demonstrate human effort

tombedor.dev

311–320 of 551 posts

Re: If you are asking for human attention, demonstrate human effort

#311
post #34

A very prolific coworker who fully embraced claude has inflicted the team with a flood of AI-generated PRs. About six months later, it is his frequent bemoaning at the standup that their PR don't get reviewed, languishing in inattention. I don't think anyone - including myself - _intentionally_ avoid his PRs. It's just that he doesn't make it easy for the team to look at. This single headline perfectly captures what…

As someone who pushed ~4x the median PRs on my team before LLMs were a thing, I kind of think the problem here is PRs as a concept. Code review doesn't scale to prolific humans, it definitely can't scale to agents. And the exact same things you would need to safely give up on PRs for human developers (auto-formatters, linters, comprehensive end-to-end tests, continuous deployment pipelines, etc), are also things that…

>As someone who pushed ~4x the median PRs on my team before LLMs were a thing, I kind of think the problem here is PRs as a concept. Code review doesn't scale to prolific humans

Prolific humans should scale to the review/test/QA/staging backpressure - not just push to have whatever they produce accepted.

Prolific is not a badge of honor, and "lines of code" is not a quality metric.

Re: If you are asking for human attention, demonstrate human effort

#312

I see this on my team. I honestly thought as engineers we'd all understand the limitations and nuance a bit better. Right now it's kind of a shit show. In addition to seeing my teammates open huge AI generated PRs and just asking for review without them having done much verification, I'm also seeing my teammates (smart ones whom I respect) use AI to "do code reviews". And we already have automated AI code reviews add…

I think this is a kind of nerd chauvanism. What I see is that the general public are deeply skeptical of "AI" in all its forms. Software "engineers" are especially vulnerable to believing that LLMs are smart generally, because LLMs are good at writing code, and skill at writing software is how the software engineer measures the superiority of their own intelligence. But a poet is in no danger of over-anthromorphising an LLM.

Re: If you are asking for human attention, demonstrate human effort

#315

Earlier quoted context omitted.

As someone who pushed ~4x the median PRs on my team before LLMs were a thing, I kind of think the problem here is PRs as a concept. Code review doesn't scale to prolific humans, it definitely can't scale to agents. And the exact same things you would need to safely give up on PRs for human developers (auto-formatters, linters, comprehensive end-to-end tests, continuous deployment pipelines, etc), are also things that…

> Code review doesn't scale to prolific humans If that's genuinely your attitude then your org has a problem. Code review is slow and less fun, for the average sw eng. But for high quality work it's indispensable. So treat code reviews as a scarce resource. Optimize for code reviewer time and attention. Have your PRs the right size? Are they well described? Do you give context? Do they fit in the bigger story? Do you…

> Have your PRs the right size?

I’ve noticed that large PRs aren’t just a problem for human reviewers: they’re a problem for AI reviewers too.

If I submit a 100 line PR I’m likely to get some useful comments back from both humans and LLMs. In fact the LLM is likely to come back with so much feedback it gets down to the nitpicky/annoying level.

If I submit 1000+ lines in my PR, the humans either don’t have time and/or get scrolling blindness, and the AI reviewer is likely to give me a response that amounts to, “> Looks good to me bro: ship it!”

I guess they have a limited token budget for reviews so you can bamboozle them simply by blowing most or all of that budget.

Re: If you are asking for human attention, demonstrate human effort

#317

Earlier quoted context omitted.

As someone who pushed ~4x the median PRs on my team before LLMs were a thing, I kind of think the problem here is PRs as a concept. Code review doesn't scale to prolific humans, it definitely can't scale to agents. And the exact same things you would need to safely give up on PRs for human developers (auto-formatters, linters, comprehensive end-to-end tests, continuous deployment pipelines, etc), are also things that…

> Code review doesn't scale to prolific humans If that's genuinely your attitude then your org has a problem. Code review is slow and less fun, for the average sw eng. But for high quality work it's indispensable. So treat code reviews as a scarce resource. Optimize for code reviewer time and attention. Have your PRs the right size? Are they well described? Do you give context? Do they fit in the bigger story? Do you…

It's clear they consider code review a personal activity than team activity, in the sense that they think "code review is a gate before my code can be merged" rather than "code review is a process where the team discusses, understands and improves the code".

And that's not rare in teams. Lots of teams and developers do code review wrong.

I even hear other people complain that I "block" their code review. I mean, if there are issues in your code, of course I am going to flag them, what do you think the purpose of code review is?

Re: If you are asking for human attention, demonstrate human effort

#318

Earlier quoted context omitted.

As someone who pushed ~4x the median PRs on my team before LLMs were a thing, I kind of think the problem here is PRs as a concept. Code review doesn't scale to prolific humans, it definitely can't scale to agents. And the exact same things you would need to safely give up on PRs for human developers (auto-formatters, linters, comprehensive end-to-end tests, continuous deployment pipelines, etc), are also things that…

> Code review doesn't scale to prolific humans If that's genuinely your attitude then your org has a problem. Code review is slow and less fun, for the average sw eng. But for high quality work it's indispensable. So treat code reviews as a scarce resource. Optimize for code reviewer time and attention. Have your PRs the right size? Are they well described? Do you give context? Do they fit in the bigger story? Do you…

Most orgs have a problem with quality unless it is enforced by government requirements for certifications and such.

Code reviews, documentation, static analysis, only retrieving deps from internal repos, unit tests, integration tests, ....

Especially in domains where shipping software is not the main product, and a plain cost center to the main business of physical goods.

Re: If you are asking for human attention, demonstrate human effort

#319
post #287

Earlier quoted context omitted.

Are PRs honestly helping with either case? Either you severely rate-limit your high-performers, or you drown everyone else in review, and both outcomes are bad for the overall team

The latter has an easy fix: the perpetrator is not allowed to take new work while there are pending review comments left unaddressed.

By perpetrator you mean the person postponing performing a code review?

Right? Right?!

Otherwise you place all burden on high performers to not only push PRs but babysit the rest of the team.

It's not an easy fix, especially with AI letting people cosplay as high performers.

Re: If you are asking for human attention, demonstrate human effort

#320
post #289

Earlier quoted context omitted.

> Code review doesn't scale to prolific humans I've worked with people who consider themselves 'prolific humans'. Someone always has to tidy upp later, and its never them

That's such bullshit. I've managed some incredibly prolific developers and some very slow ones, and the prolific ones are pretty much always the ones more available, more willing to fix things, more willing to take feedback. And also: they make less mistakes because their skills are sharp . This anecdote comes to mind: https://austinkleon.com/2020/12/10/quantity-leads-to-quality... If you have to constantly rationali…

I've worked with both types. Some prolific devs really do care, and are just really good at their job.

Others are just trying to get code done, and don't care about quality. These are the types that are upset that their code gets rejected because their goal is advancement and money, and not doing a good job.

FWIW, it's okay to care about both. But if you don't care about doing a good job, you're going to drive everyone around you insane.

Prolific bad coders are a bane on the company, and AI is only going to make them worse.

Post reply on HN