Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you are asking for human attention, demonstrate human effort

tombedor.dev

Post reply on HN
Print view View original

321–330 of 551 posts

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

#321

Post by swiftcoder »

fg137 wrote: post #317
teiferer wrote: post #302

Earlier quoted context omitted.

> 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 t…

> Lots of teams and developers do code review wrong

In this sense, I'm not sure I've ever seen a team that does codereview "right".

In the before times, most PR feedback was stylistic, with the occasional bug identified. Now that we have ubiquitous auto-formatters/linters/CI, most PR review falls into either "you misunderstood the spec", or "I disagree with your architectural choices" - and my personal feeling is that your process ought to catch both of those well before the PR stage

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

#322

Post by wccrawford »

swiftcoder wrote: post #274
throwaw12 wrote: post #257

Earlier quoted context omitted.

> Code review doesn't scale to prolific humans, it definitely can't scale to agents. Then don't review the code. Ask Agents to review and merge it, also shift the responsibilities to the AI agents as well. If you think human is a bottleneck, then either optimize for humans, or remove humans. What's the problem?

> If you think human is a bottleneck, then either optimize for humans, or remove humans. What's the problem? Sadly, in my case, it is the auditor. Our SOC2 documents have this lovely "every change has been reviewed by at least one other human", and it's going to be a fun battle to get that reworded

I think the "and merge it" is the problem in the above comment.

If a coworker is creating a ton of AI-made PRs, I think the first step should always be to run an AI against them with the "assume this is low quality code and find all problems, big and small" text that was suggested in a comment here, and let that be the first line of defense.

To keep the dev on their toes, each dev should come up with their own prompt for AI PR review and they can switch off who reviews it each time, until there are no problems remaining.

Then a human can start to review it.

It will quickly show the low quality code being produced and the massive waste of time it is for everyone, not to mention all the money spent on tokens for the whole process.

Or it'll work, and everyone will have their way, and only have to review code that's pretty decent.

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

#323

Post by kombookcha »

_carbyau_ wrote: post #30
SchemaLoad wrote: post #10

Earlier quoted context omitted.

It's the empty calories of literature. More would be more if there actually was more but AI writing is making it bigger without adding anything actually more. It inserts loads of fluff and repetition that takes longer to read but doesn't exchange more information or ideas.

Which is why so many people want to see the prompt that generated the text. Because the prompt is the quintessence of intent regarding the information to be conveyed.

I always have a strong hunch that it would be vastly more efficient if they just sent me whatever the prompt was, rather than the output. If you blow 2-3 sentences of intentional information up into a verbose e-mail, you're needlessly wasting both your and my time. Just send me the 2-3 sentences of actual stuff!

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

#324

Post by barrell »

jstummbillig wrote: post #270
barrell wrote: post #241

Earlier quoted context omitted.

I think it’s safe to say that this will not be consensus. Personally, I am getting increasingly (irrationally) angry at AI generated content. AI generated art quite literally makes me nautious. I mean an actual, physical reaction where I feel queasy. I know I’m not the only one who feels this way, and notice more and more people reporting the same. Several of my non-technical AI generated content is bland and soulles…

That is not how it will play out. Everyday AI writing was not a thing with GPT 3.5. It happened more around GPT 4o. And now some people are entirely comfortable with using AI writing and not even trying to hide it (while, I would agree, it's obviously still fairly garbage and easily identifiable, which helps with triggering strong averse reactions). However the models are getting better at everything, including writi…

To claim there was amazing progress in the past therefore there will be amazing progress in the future is an inductive fallacy.

And as someone who gets dozens if not hundreds of AI generated emails I have to go through every day, it is _incredibly_ easy to spot which ones are AI generated and which are human written.

By its nature AI generated content is statistically consistent, the narrative equivalent of monotone speech. I don’t know anyone that can’t spot it a mile away at this point, and the more people are confronted with slop, the more attuned they become to it.

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

#325

Post by wccrawford »

crjohns648 wrote: post #208
niuzeta wrote: 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…

Even before AI, I've worked with people who would produce a huge wall of code and ask for review, and sometimes that code was completely off base or needed a significant rework. I would always feel bad in those cases, because it's clear they spent a lot of time, and I'm going to have to say "no" and they will feel like they wasted a ton of effort. The thought process around this has started shifting for me in the las…

When I felt like that, I'd often ask questions about it, like "How does it deal with [situation]?" When it's obvious that it doesn't deal with the situation, they either answer "it doesn't" and then I point them to the ticket they didn't read well enough that points that out, or we have a conversation about thinking beyond the ticket, or they actually realize themselves that they didn't do it right and go back to it. I don't actually have to say "you did a bad job" and they don't have to hear it from anyone but themselves.

If they continue to do that, then someone has to tell them they're doing a bad job.

And a some of them never did improve, and got fired for it.

I think slowly opening their eyes to the actual scope of the ticket is a lot easier on them than saying "no".

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

#326

Post by swiftcoder »

bartread wrote: post #315
teiferer wrote: post #302

Earlier quoted context omitted.

> 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…

The flip side of this tends to be that if 1,000 lines of code need to happen, filling the review queue up with 10x PRs each of 100 lines isn't exactly great either. The author spends a bunch of extra effort producing a raft of atomic PRs, and the reviewers get to context-switch a whole bunch (and may not end up with a clear picture of the feature end-to-end).

I think the ultimate answer to this is a stacked PR workflow (which we had at Meta), where I can cheaply maintain/review a 1,000 line PR as a stack of 10 incremental PRs. But unfortunately GitHub et al are still not quite there on this one.

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

#327

Post by wffurr »

JimDabell wrote: post #196
emodendroket wrote: post #99

Earlier quoted context omitted.

Well, what's the solution here, he should ship less stuff?

He isn’t shipping anything. Asking for code review is not shipping. This is the complaint: > he doesn't make it easy for the team to look at. He has traded readability for volume. The lack of readability is causing him to ship less. This was a bad trade because the readability is the bottleneck not the code creation. He should improve readability.

>> the readability is the bottleneck not the code creation. He should improve readability.

See this is where I think LLMs can actually improve software engineering. Use them to write better code not more code. The most useful LLM at work so far is the code review bot that occasionally finds things that I missed even with a careful self review and good test coverage.

We should be prompting the LLMs to review our hand written code for security, correctness, style, maintainability, etc., and then use human review for good design and sanity checking. The bots can do things like hold all the C++ correctness rules in their context and apply them sometimes better than even a human expert.

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

#328

Post by rplnt »

swiftcoder wrote: post #273
jvanderbot wrote: post #254

Earlier quoted context omitted.

Gently, as long as you work with humans, you should consider yourself working _for_ those humans. Everyone needs shared state to work from, and that's just the cost of doing business. That said, sometimes low-trust environments are the issue, not PRs. In a higher trust environment, PR review is a helpful thing you usually desire, not dread.

> In a higher trust environment, PR review is a helpful thing you usually desire, not dread Respectfully, in a high-trust environment, feedback should be delivered well before the PR stage. If you've let someone write a whole bunch of code without having a shared understanding of how the solution should work, you may have earlier process issues that PRs are papering over

You cannot deliver feedback on something that doesn't exist. If you mean a review in the style of "all of this is wrong and needs to be rewritten differently" then yes, that's something to be discussed beforehand. But I don't imagine this is what people think of when discussing a review.

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

#329

Post by fg137 »

swiftcoder wrote: post #321
fg137 wrote: post #317

Earlier quoted context omitted.

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 t…

> Lots of teams and developers do code review wrong In this sense, I'm not sure I've ever seen a team that does codereview "right". In the before times, most PR feedback was stylistic, with the occasional bug identified. Now that we have ubiquitous auto-formatters/linters/CI, most PR review falls into either "you misunderstood the spec", or "I disagree with your architectural choices" - and my personal feeling is tha…

> most PR feedback was stylistic, with the occasional bug identified.

I think that only speaks for your own experience. I have definitely seen more than a few PRs that needed significant work.

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

#330

Post by swiftcoder »

jonahx wrote: post #301
swiftcoder wrote: post #273

Earlier quoted context omitted.

> In a higher trust environment, PR review is a helpful thing you usually desire, not dread Respectfully, in a high-trust environment, feedback should be delivered well before the PR stage. If you've let someone write a whole bunch of code without having a shared understanding of how the solution should work, you may have earlier process issues that PRs are papering over

Depends on how PRs function within teams. For some, the PR is a lightweight thing that is the preferred method of communication. It sounds like you are imagining a case where face to face communication, or communication over chat, is preferred for early stages, with the PR being a nearly final artifact. But it doesn't have to work like that.

I think that's a valuable point. Especially as LLMs bring the cost of prototyping down (and reduce emotional investment in code written), it may be more viable to use PRs as proposals/sketches of a solution.

With human reviewers, I find that by the time someone has churned out enough of a solution to post a PR, they are already quite invested in specifics of the solution, and it makes it emotionally costly (to both author and reviewer) when someone says "hey, I'm not a fan of this whole approach, lets start over and do it this other way"

Post reply on HN