I've seen this happen a bunch too, though fortunately it hasn't been _that_ common. More often is managers that don't understand things using AI tools to try to understand them, mostly failing, and then regurgitating the LLM output during a meeting. Added as a link on my blog, too, since I have a similar article.
If you are asking for human attention, demonstrate human effort
271–280 of 551 posts
Re: If you are asking for human attention, demonstrate human effort
#272This is beautiful. I even had people reach out to me with suspiciously long "long time no chat" instant messages until I realised they were AI written (in one case misspelling the name of their own partner). "If you are requesting human attention, demonstrate human effort" is going to be my new answer to that!
This is exactly the same as the ""If you didn't take the time to write something, I'm not going to the take the time to read it" mantra that was floating about HN a few months ago.
I think in many cases people use LLM outputs without even understanding the contents of it. You're only really able to say something in your own words if you understand it. As a matter of fact, it is a good way of probing if you truly grok something. So it isn't just laziness to write, but also laziness (or inability) to understand.
Re: If you are asking for human attention, demonstrate human effort
#273Earlier 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…
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
Re: If you are asking for human attention, demonstrate human effort
#274Earlier 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, 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
Re: If you are asking for human attention, demonstrate human effort
#275This exactly reflects my feelings lately. I have a specific coworker who has gone somewhat overboard - every single code review, answer to any question on email or Teams, every new story, even their personal opinions during a design or ideas meeting, are all direct AI output with no massaging or human touch or review. They're working on planning out an upcoming project, and I just get verbose and long documents to re…
Another idea to slow down the stream of slop of big PRs: request to split big PRs into smaller PRs. This typically keeps the author+clanker busy for quite some time. E.g. I got a 5k lines PR to review; requested to split that into 7 smaller, self-contained PRs. Took them about a week to finish this work.
Re: If you are asking for human attention, demonstrate human effort
#276Earlier 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…
Comprehensive end-to-end tests and CI can only attest to correctness , most engineers worth their salt won't review code only in regards to that aspect though.
In the bad old days before auto-formatters and linters, PRs were heavily used to enforce style guidelines. If we can enforce both style and correctness in our CI pipeline, what is actually left?
Re: If you are asking for human attention, demonstrate human effort
#277[dead]
Re: If you are asking for human attention, demonstrate human effort
#278A 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…
Well, it's either:
1. Your skills are >2 standard deviations above everyone else's.
2. You're fast at producing a lot of half-baked garbage, and your coworkers are too shy to confront you, so they just try to ignore it.
(one of these scenarios is much more likely)
Re: If you are asking for human attention, demonstrate human effort
#279Earlier 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
Agree. All the subtleties of how a high trust environment work are hard to enumerate
Re: If you are asking for human attention, demonstrate human effort
#280Earlier 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
> Sadly, in my case, it is the auditor.
Change your auditor and compliance, SOC2 is created for a trust between organizations employing humans, if you think agents can own the things, lead the way, introduce a new compliance, if companies sign up for it, then you will be the first who is removing the human bottleneck.