"Don't expend more effort than they are" has actually long been a good principle to have internalized. Someone done only cursory research before asking a question on a mailing list? Give a cursory answer. Someone obviously spent hours trying to figure things out on their own? Give them a good chunk of your time. Someone on HN responding to you with single-sentence responses? Either don't respond, or respond in kind. Someone obviously engaging with your ideas and taking time to explain their position? Take time to engage with their ideas too.
I've had this same policy since before AI. I kind of formalized it for myself (and this team) after enough instances of "I'm trying to do X. It's not working. Help." type messages.
You need to put as much effort into the question as you expect someone to put into the answer.
It's not "fairness" or "AI" or anything else, it's that doing this any other way fundamentally fucks up the team dynamics.
You have a problem. You want someone's help. If the cost to you is effectively nil (or negative, since you're asking someone to do your job for you), but the cost to the other person is non-zero, then incentives aren't lining up here. Pretty quickly that person is going to start carrying too much load and become a bottleneck.
It can also mask that the context of the work is too concentrated in one person, and does little to nothing to help build that elsewhere in the team.
The other end of this is exactly what you're saying--put as much effort into the answer as they put into the question. You're not doing anyone a service by taking their low effort input and giving them high effort output, least of all yourself. If someone asks "how do I X", that's low effort. If you happen to know the answer off the top of your head, spare a few sentences to explain or point them where in the code they need to be. If you don't know, don't go track it down for them.
> after enough instances of "I'm trying to do X. It's not working. Help." type messages.
Related to this, I will never for the life of me understand why people think it's okay to say "I get an error" without saying what the error is.
I don't expect a non-technical person to understand the error, but I do expect a non-technical person to know that what the error message is is useful to the person trying to help you and to proactively provide the contents of the error message, even if it's a shitty cell phone picture of the error.
I don’t formalize anything that extreme for my teams because I can’t diagnose people, but I know that things like anxiety, imposter syndrome and a whole wack of things that aren’t related to work get involved. It’s acceptable to ask for help. I like to know what people have tried but sometimes they don’t know how to start. And that’s a great place to start.
I guess we all have different styles but some may be more inclusive than others.
How the problem and request are presented matter. "I don't know where to start" is a different problem than "I've done nothing, just solve this for me." And how someone shows an effort was made will vary person to person, so I agree a strict formalized set of rules doesn't make sense. The concept boils down to "expect people to put forth some effort of their own"
"Teams" are also going to have different dynamics than "strangers on a help forum."
These kinds of principles are sensible at their core, and I am a big proponent of the mindset, but the main problem as a sibling comment pointed out in a way is that this assumes that everyone is striving for an honest and accurate correlation between display of effort and value, and that everyone is looking deep enough into and behind that display to recognize the true value behind it. But actual effort, let alone value, is not always clearly visible or honestly displayed, and the perception of it is also subject to your own biases.
You could say that people have the responsibility to demonstrate that they put in the effort and created value, but then you get the situation where people naturally optimize perception of effort or value over actual effort or value, because in the end that is what is rewarded. Then you can also say that people also have the responsibility to look a bit closer before estimating real value, but that takes more effort and people naturally strife towards efficiency. I would guess that the problem today is that the balance between these two is off, and we're doing too much of the former and too little of the latter.
an honest and accurate correlation between display of effort and value
Hmmm. Your choice of words here has just sparked a realization for me.
Before you said this, I was completely on board with the original post. But in juxtaposing effort with value, it illustrates that we're basing the idea on the Labor Theory of Value. That idea seems intuitive, and Adam Smith wrote about it 250 years ago. But it turns out that LTV is very wrong. Economists showed that effort does NOT impart value.
Labor theory of value is a Marxist idea, not an Adam Smith idea. Internet Marxists sometimes point to a passage in The Wealth of Nations to suggest that Smith also supported a labor theory of value, but this is—in the most generous interpretation—a misreading. Smith says that the value of a thing can be measured by how much labor it can be exchanged for: an exchange theory of value, not a labor theory of value (which says the value of a thing is based on how much labor it takes to create).
I mostly agree with your criticism of my post. I was being generous trying to avoid being inflammatory here, since I know there are readers that strongly support socialist ideas (in the strict sense, not just the "safety net" sense). It was certainly Marx that pushed it so hard.
But researching this a bit, I find that it still predates Marx. I find:
Sir William Petty, 1662: "If a man can bring to London an ounce of Silver out of the Earth in Peru, in the same time that he can produce a bushel of Corn, then one is the natural price of the other."
More important, it seems that David Ricardo (a big name in economic history), in 1817 latched onto what Smith had written and states it quite definitively.
I’d push back on this, I think people have a very intrinsic sense of what is valuable and often if you think it’s “perception” of value being rewarded, it’s just that you value something different than that person.
Even in performative scenarios, like say someone gets promoted at work over another person because they are a great “performer” and always make noise, whereas the other actually delivers - they’re being promoted because the promotion is defensible and legible for their superior. That is true value for them, just not to another viewer.
I experienced a similar interaction recently, where this principle was hard to apply, when I was emailing with a CTO / hiring manager who had some "deeper" screening questions. It was essentially:
1. HM: AI generated email with "tailored" questions
2. Me: AI assisted response with answers (I confess)
3. HM: AI generated email with a "thoughtful" response + invite
4. Me: AI generated "thank you & looking forward" response ...
Looking back at the thread, I have to laugh and cry at the same time. It's so obvious and sad.
I tried to recall the last time I saw what I felt was an ego-driven tirade on HN comments, and I'm currently drawing a blank. There's a lot of what's called "performative erudition", and there is the occasional lengthy diatribe, but I would call neither one of those ego-driven tirades.
For him, the cost of editing was much larger. Condensing your writing in his time meant rewriting it more concisely, requiring strictly more time than collecting his thoughts as he went.
With LLM's, we are in a new state of the world: it can expand any one sentence off hand remark in an essay.
You seem to be talking about how one can expand information into useless babbling, whereas you are responding to a comment about condensing information into true essence.
Sure; I was using shorthand. Sometimes a whole edifice of ideas rests on one shaky one; and if you can challenge that one the whole thing falls apart. But even being able to identify the shaky one demonstrates engagement. That's really the key.
There are obvious exceptions to that rule. Laconic phrases are short but have a lot to them, while AI slop is long while having very little to it. But it's a decent rule of thumb when considering the middle of the bell curve.
Sometimes people are not looking for fully fleshed out high-effort answers. They want a pointer (to documentation, or a repo) to get going from someone more experienced.
Google search may throw up too much information and it is hard to make a choice. A one sentence answer from an expert may be enough to set them on the right path.
From the other side, there have been brief tutorials for many years about how to ask useful questions in a technical forum. Making hundreds of other people fish for details about your case is poor form.
AI has collapsed the cost of producing content while leaving the cost of reviewing, verifying higher imho. This has inverted the economics of collaboration. Reviewer attention, not output volume, is now the scarce resource, this happened with my engineering teams (PR reviews) and is now happening in my world in Product.
In some cases there's also no preparation or verification happening at all, which massively inflates the productivity gains of AI. Lots of VCs and investors asking companies to move into "trust the AI" mode.
I once consulted for a company in the content marketing business that was one of the largest and fastest growing startups of its country. The content production in itself was "cheap", a dollar for 500 words. But it collapsed, due to the unbearable amount of people required to review
Now virtually all content is generated by AI and the old customers don't have anyone to verify anymore.
Companies are made of people who are shitty to each other but trust machines blindly.
This has been my policy for a couple of decades. When somebody posts just a bare link (especially if it's to a video), I refuse to click. If it's not worth your time to introduce why something is relevant, then it's not worth my time to go figure that out.
> Someone on HN responding to you with single-sentence responses? Either don't respond, or respond in kind.
Or, depending on the context, perhaps give a thorough enough answer with citations that it should either answer questions on the topic fully or explain where anyone interested in the topic can do their own research, such that if the question is asked again one could just link to your previous post.
This might not satiate a poster if they're dumb enough, but it's worth remembering that the post will be searchable and usable for reference by other people.
It takes considerable energy to train models and run inference. You can't dismiss AI generated content as "low effort", but you can dismiss it as a wasteful diversion.
That's like saying that low effort human-generated posts are worth your time because the phones and computers they're writing on take a lot of time and effort to build from scratch.
The person copy-pasting an AI response is generally not the person who trained said AI. Even if the total amount of effort is fairly large, the amount of effort put in by the person you're actually interacting with, is generally small.
Back when people would train Markov bots on IRC that was actually something novel for the first 30 minutes and you could appreciate it because they put in the work
@dang it's too bad the most interesting single comment in this whole thread is grayed out. as much as i love reading the same thing written 1,200 different ways, maybe the whole system needs to be revisited
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 I have been thinking. It's not that I reject AI content, but it takes _effort_ to review and weed out any mistakes. When your thoughtful reviews that take an hour(because the PR is typically large, and you want to be _right_ when you're pointing out a hallucination) gets an AI-generated response with AI-generated amendments, It doesn't feel _nice_. I feel dismissed and it has continuously trained me to subconsciously avoid his PRs. After all, the team is fully onboarded with AI, so it's not like there is a lack of PRs to review.
It looks like the sentiment isn't just isolated for me.
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 place meaningful guardrails on LLMs, and help them maintain a reasonable quality bar.
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 mix in unrelated drive-by fixes? How easy is it to deal with you once you have received comments? Do you address them promptly? Do you give your reviewers credit (if not praise) for their help? Do you give back by doing code reviews yourself with high quality feedback? There are lot of things you can do to streamline things and give code reviews the place in a teams workflow that it deserves.
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?
> 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
Yeah, that's fair. I have spent most of my career on high-pressure teams within FAANG, where we aggressively managed-out anyone who wasn't making the grade. And now in the startup world, we apply a very aggressive hiring bar.
I'm not sure how much I'd enjoy working on teams who were routinely producing PRs that were in bad shape.
On your original claim, I have seen engineers put up 5x more PRs simply because they paid less attention to the quality or put less thought on each one of them.
I have seen people put up 5x more quality PRs too. But as long as they follow the good practice of doing a code review for every PR they put up (or 2 if you require 2 per PR), they got their stuff through quickly as well.
> your process ought to catch both of those well before the PR stage
We have multiple points where mistakes of any sort can be caught, and code review is one of them.
Yes, most architectural issues should be caught earlier, but some will only become evident in code: some by the dev themselves, others by reviewers.
This is only a problem if you mostly catch architecture issues at code review phase.
> But for high quality work [a code review is] indispensable.
The argument here is that all code reviews are done with attention and care, but quality of a code review is highly dependent on the reviewer and the team’s review process, and in the real world the quality of reviews pretty much follow the same distribution curve as, say, agile project management: For the time invested in reviewing, a handful of teams get excellent utility from them, most teams get little benefit, and a sad few actually cause harm.
If most code reviews provide only a little benefit at base for most teams, recommending that most teams should also delay shipping quality work is going to sound a lot like bad advice.
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, “<<slaps roof>> 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.
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.
I agree about how you can reciprocate for a good code review, but I'd just add that for me, code review is also fun — when done for a fellow human who I might be teaching.
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.
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"
I have seen many a PR where it is obvious it is an exploratory work: eg. figuring out how to use an external dependency that is imperfectly or incorrectly documented, etc. (You can claim this should be done ahead of time, but experience tells me you need to code it to learn it)
The emotional toll there is real, but this is exactly the moment when you expose the knowledge of that external dependency to the unbiased party that is the reviewer.
I like combining approvals to satisfy the urge for completion and closure, with a request for fast-follow refactor to better match the newly discovered model of interaction. (The worst code review experience I have seen is when a reviewer accepts it as-is and does a fast follow refactor themselves, depriving the author of the opportunity to learn and remain an expert in that area)
A discussion ahead of the implementation can also bias the two parties to that discussion and have them overlook the same implementation issue: many things you only understand once you start implementing.
If you have these parties review each other's code, I agree that rarely brings much value.
I think the best way to understand our experience with reviews is to stop and say: in a few sentences, what do you expect out of a quality code review? (sounds like nothing in your case, but I am curious)
Depends on the change. Certainly most PRs don't need feedback before the PR is ready - the task is too obvious, and there's little to feed back on before there's any code.
For bigger changes, of course you need feedback on designs. But that could easily be in the form of draft PRs.
I definitely would push back on anything that required feedback before PRs. That's way too much process. Just going to slow you down for no benefit.
> I've worked with people who consider themselves 'prolific humans'. Someone always has to tidy upp later, and its never them
I run both infrastructure and security - that means a lot of relatively self-contained PRs to infrastructure-as-code and dependency management systems. I'm also the team lead, which makes me responsible for a lot of throwaway prototyping, as well as cleaning up anyone else's mess...
Yes, the prolific-but-damaging engineers are all too common in corporate. But particularly in startup land, you tend to find your high-performers wearing a lot of hats at once.
My experience is that it's even worse: they've already produced enough code that the codebase matches their taste and theirs alone.
So in essence you have one guy working at 4x and e.g. four other getting just 0.7x - net effect is still positive, but everyone save for that one person is miserable.
Mind you, the 4x dev doesn't necessarily have to be particularly talented - they only need to get their foot in the door before anyone else.
Back during the ZIRP days you could immediately tell that this is the case in a team by staff rotation alone. Nowadays people understandably cling to their jobs, so you might now know until it's too late.
IME, it’s because they lack the experience to have the Taste one develops as a senior engineer. “This works, and is somewhat understandable” is as far as they get. Little to no understanding of how this solution could fit better in the codebase.
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.
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.
Sure but if PRs get rejected, nobody has to "tidy upp (sic) later".
That's not prolific, that's just producing slop, with AI otherwise.
I'm just tired of developers pretending that low output is some sort of silver bullet for quality, and high-output is automatic slop. Neither are true. In 99% of cases, low output doesn't correlate with anything positive. High-output can naturally go either way, but slop doesn't make one "prolific".
As someone who often submits significantly more PRs (without using AI) than teammates, it's not exactly a skill delta. Yes that helps but it's often only a piece of the puzzle. The other ingredients include motivations and culture. In such cases, something else is the driving force, such as posturing for promotion, stability, etc. My current team is massively low performing. Management pays some lip service to all the problems, but also runs things in a way that discourages high performance. It's not a good fit for me, as I want to tackle challenges head on, improve the environment, be productive, embrace change. I'm also very comfortable with the code base as well as the code review process, but I'm surrounded by "seniors" who do not know how to code review, and who are happy to drag their feet and spin their wheels for months before pushing out small PRs that hurt my brain. How can that little work be shown after months, barely functional at best?
We had better management for a few months, and many on the team were actually quickly closing the skill gap with me, but we had another shuffle and things are stupid once more.
So I'd offer that's option 3. (There's always a third option to any suggested either-or fallacy.)
It could also potentially be that GP is making atomic PRs, while everyone else is just making 5000-line PRs with multiple responsibilities that just gets merged with "LGTM".
But of course HN has to with the most uncharitable interpretation.
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
> If their PRs don't get merged they don't perform. It is trivial to overload your coworkers with secondary tasks due to your "high performance".
We're all aware that a huge portion of the busywork that makes a team successful is not actually reflected in their upwards-facing deliverables (increasing test coverage, improving infra, adopting new tools/methodologies, preemptive security patching, etc). Your actual high performers, if you have any, are doing all that stuff in addition to their regularly-scheduled duties.
If management weren't at least tacitly on board with this arrangement, your high performers would go work somewhere else. So my experience is that good managers don't tend to see this your way.
Yeah I agree. I was trying to makee the point that it is quite easy to make yourself blocked by others and it is a deep skill to get other stuff done while blocked anyway, like say cleanups and tests etc.
I have been championing this mindset since well before LLMs. It is an admittedly controversial opinion, but one I hold strongly.
Code reviews are a productivity tax. No truly effective team would rely on them. The fact that so many software teams view them as indispensable just shows how few effective software teams there are in our industry.
They are akin to a quality check step in manufacturing. Part of what Deming did in revolutionizing manufacturing was eliminating the step in favor of a holistic quality metric owned by all participants and enforced with rigorous statistical process controls. As you say, we in the software industry have all the pieces (autoformatters, tests, benchmarks, etc) to operate this way, but it seems our organizational and management dynamics combat this shift at every turn.
Relevant: When this conversation comes up at work, I like to share Avery Pennarun's post about the review tax: https://apenwarr.ca/log/20260316
As a prolific PR author, I've found how I communicate has a major factor on how well and quickly people respond to PRs. I've recorded my lessons at https://epage.github.io/dev/pr-style/.
I have always considered Kent Beck understood this the best, the scaling for code reviews as you go to reduced release timeframes is to pair program, that brings the number of people reviewing it down but also increases the understanding for the reviewer. Comprehensive end to end tests are more a replacement for manual quality assurance for regressions.
I am not sure there is a good analogue for reviews in the AI world. The human operating the AI should obviously review everything produced but that is clearly not as good as a second pair of human MK1 eye balls from pair programming.
No need to pair program, you can always send a message to your colleague about the design of the upcoming code, especially if it’s going to impact them or if it’s an area that they’re more familiar with. Waiting till a PR for feedback is wrong IMO.
Code review is not for feedback, it’s for ensuring quality (many eyes on the output) and have a shared involvement in the evolution of the code. The time for feedback is earlier, once you have an idea of the solution.
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?
The functionally correct code could be rejected in PR for many reasons other than style:
1. Solution under-engineered/over-engineered.
2. Code is hard to read or comprehend.
3. Design/Archtecture lacking.
4. Principles decided upon by team not adhered to.
These are just some of the reasons I've rejected functionally correct code before.
To summarize, in any software engineering course you learn that there are other metrics used to evaluate code other than correctness (maintainability, readability, scalability, portability, efficiency etc.)
If the correctness check was vibecoded there's a good chance it was cheated. So maybe that, on top of the, you know, code review (see the sibling comment).
While PRs may have been used to correct style, that shouldn't have been their only or even main purpose. That's on whoever was using it that way, not on the concept of reviews.
Code architecture and technical design. You can have a solution that works fine, but are too complex or will impede future changes. Maybe you have code that has already been solved or your variables’ name are too generic. Maybe your modules are messy and your data structures are not modeled well.
> 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.
> first step should always be to run an AI against them
What if they write an agent which takes the feedback and resolves them with a new commit. Which again didn't do anything other than offloading more to humans who are reviewing.
> 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.
This assumes AI reviews are correct most of the time, if so, why do we need even humans. Why not have repository level code reviewer which is run immediately after code has been created?
regardless of where you move it, there is still a bottleneck: humans.
If you don't remove them, you will just pass the ball between agents and at the end of the day human still needs to review it.
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.
>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.
Either you were a head above the rest of the team and had the intellect to produce high quality value adding work, or then you were the "move fast break things" type of guy producing a lot of extra liability and work for others.
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 last few weeks. I'm a lot more comfortable saying "no" with a list of concerns when I suspect the code is AI-generated, and I see others doing the same. CLs that would be sitting around for days because no one wants to be the first to say, "this is bad, don't do this" now get quicker feedback.
The good thing is this feedback doesn't feel like as big a deal as it used to because people are less personally attached to code they generated in 30 minutes vs. code they hand crafted over a week. I had at least 2 LLM-generated PRs that were complete, correct, tested, and pre-reviewed by me, but I got feedback that they were going in the wrong direction. This would have been 8 hours of wasted effort a year ago, but now it's just an extra 30 minutes to rework the direction with LLM assistance.
> 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.
I get this feeling, too. I do however think the onus is on the developer to make something reviewable by their team members if they want a speedy review. Stacked PRs, scoping things down, properly structuring commits so you can review commit-by-commit for example.
I also think that "I spent a bunch of time on this" is not a valid reason for expecting an approval. It should hurt if you've produced a bunch of code that is way off target, even if it ends up implementing the feature. That's how I learned at least.
A proper way to go about large projects, in my opinion, is the same as with software development at large. Fail fast if possible. Draw up a crude boxes and arrows sketch or just discuss how you want the code to integrate with whatever already exists and invite the team to comment. If no one has anything to say, well then they can't complain later when you implement that approach. But if anyone cares then most likely valueable input will come that makes the end result better.
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".
It’s good that clankers are not afraid of throwing away code. The biggest problem with code generation (that is version controlled) is maintenance. It’s better to throw away questionable code rather than say eh, we don’t quite understand this part (and our agents can’t make a compelling story about it) but we spent a lot of effort on it and it apparently works so we better keep it.
.. only if you know what the code is doing, though. Often the requirements get scattered and lost to the winds and the code is the only record of its own idiosyncratic behavior. And yes, someone's depending on the bugs in it.
Fight fire with fire: point copilot/claude/codex to review their PRs. Prompt "Review the PR#XYZ which is vibe coded and presumably low-quality. Find all problems, big and small. Team guidelines at docs/conventions/styleguide.md, docs/conventions/architecture.md, docs/conventions/principles.md. Post inline comments to github".
Run several rounds of such reviews until the clanker fails to find problems.
Because the problems AI causes are fundamentally problems of good design. It has the same problems of large teams, but less politics. Do your design well ahead of time, and AI review, or a large team, will amplify what you can do. Potentially by a lot.
Do it badly (or like most companies: do it with bad knowledge of the problem or just don't do it at all) and both team and AI will make a mess of things. If the team is made up of inexperienced programmers, they won't even complain, in fact I've seen teams that like this to be happening. At least in AI reviews I've always seen "grumbling" (in the sense of what you might call mean comments)
Everybody values their own time more than other's.
The fix, imho, is for the reviewers to also use ai to review the code. However, the ultimate responsibility for the outcome(s) should be on the committer - you commit it, you own it, so to speak. If there's an incident, they need to be the one paged in the middle of the night. Bugs resulting from it will land on their desk.
Speak for yourself. I highly value other people’s time, to the extent that I should probably value my time higher than I do for my own sake.
Doing something that wastes other people’s time or makes more work for them than necessary makes me feel awful.
I’ve always worked in a way that respects other people’s time and I always tried to make sure I did everything I could to minimize the work I’m asking someone to do for me.
AI and companies reward sociopathic behavior. When he eventually complains to his boss that his work isn't being merged and it's been done for days/weeks/months that will filter up and look bad on the people holding him up.
I'm sure this person's manager knows that having trouble getting PRs reviewed can (but not always) be a signal of a deeper problem. It could be that no one one the team knows the domain, it could be that no one like the person, but most likely it's that the PRs are frequently bad and no one wants to bother.
The solution is that he spends more time scoping the size of the PR so that it’s reviewable and understands the code he’s submitting well enough to have discussions about it. And that he does so human to human so that they can come to mutual understanding.
Less WIP is better for the throughput. If you saturate all the review bandwidth you're just wasting your time creating more PRs, the time would be better spent helping others get their PRs merged.
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.
That's not how anything works. Even if he says he's going to take responsibility, when the customer call comes in at midnight you're going to be the one fixing his problems.
The reviewer gets to merge the PR so their name appears on all the great new features and they are credited for them. That would end his unfair behaviour of dumping effort onto other people.
I often hear people say lately, "why should I bother to read this, if you didn't even think it was worth writing?"
I've been thinking about this in art. Is it the end result that matters, or the process of creating it?
I once saw a hideous sculpture. Didn't like it at all. Then the video zoomed and I saw that the whole thing (quite massive) had been hand-built out of individual toothpicks, and suddenly I thought it was amazing.
Perhaps an even better example: I read a story of a man in india who carved a passage through a mountain, so there would be a shorter route from his remote village to the city. He did it by hand and it took him 20 years. We seem to have an instinctive admiration for heroic effort.
In business, generally only the end result matters. Although, the end result also includes the client's perception of how the product was made... (see also: fake fairtrade etc.) In a meaningful way, the perception, the story, is reality.
Part of art is the process of creating it. It’s not just the physical artifact, nor even just the completion of the final product. The inspiration, subject matter, the consideration of form, the initial concepts, the redesigns, the meaning or emotion the artist tries to impart, the beauty of the thing, the skills employed and further developed during the process, the choice of materials, the use of perspective, and how the work is presented are all part of the art.
This is mostly what it is for me too. We're all awash in an information deluge, and we need heuristics to keep from drowning. Human effort, proof-of-work if you will, is a heuristic that helps with the AI-generated part of the deluge.
> Is it the end result that matters, or the process of creating it?
One of the main reasons that art is valuable is in its ability to communicate emotions. Good art has the ability to serialize emotions within the artist and deserialize them within the mind of the viewer. It's not just "wow, this is a pretty picture", it's "wow, this is how another person sees the world, and now that I understand that, I feel an intimate connection with them".
> Is it the end result that matters, or the process of creating it?
I think this comment misses the point. Let's forget about AI and assume that there are three developers: A, B, and C. Now, A is supposed to make a PR, but instead they describe it to B, and B writes the code. C reviews the PR and gives feedback. A passes the feedback and the responses between B and C.
As you see, this is not easy for either B or C, and A is totally useless in this scenario. When you replace B with an LLM that doesn't get tired or bored, only C complains about the process.
I can't imagine working for a place that has a big bucket of PRs that either get reviewed or languish for some amount of time based on who feels like reviewing them. I'm not saying there's anything wrong with it, just that everywhere I've ever worked, there are expected features with priorities and timelines and some project manager or product person breathing down your neck to get them out the door.
In big software teams, the bottleneck is team communication. I've run big and small teams. If I want to speed things up, I remove people from the team. Everything gets easier. This has worked amazingly well every time I've done this over the past decades. Removing people doesn't have to mean firing them necessarily. Splitting teams is a good reflex. But of course the people you remove from a team are typically not the best performers. I was discussing this with a friend of mine who runs a small company. Exact same thing. He reduced the team size by 1 and the velocity went up almost instantly. This person was a bottleneck in the team and was slowing down people around him. After identifying the problem, solving it unblocked the rest of the team.
This was true long before AI. With AI the difference is just a lot bigger. It exposes team inefficiencies quite mercilessly. We have a big glaring issue with the current AI tools not being to suitable for usage by multiple users. All interactions are one on one. Which means hand offs between tools and people are bottle necked on people communicating with each other. So, any issues there with people delaying, gate keeping, etc. become very visible.
The sentiment of pushing back on AI is understandable but probably not a productive reflex. We need to find more effective ways on staying on top of massive amounts of changes. It's not going to slow down and insisting on manually reviewing all code is not going to be a long term sustainable way of developing software. It simply does not scale. I'd question the added value of manual PR reviews at this point. Are they finding real issues? Are we valuing those issues correctly? Could we come up with automated ways to find and fix those same issues? There are a lot of open questions about how we are going to do this. But no question about the notion that we need to up our game on this front.
Efficiency is not magic. Its bounded. Above and below limits the environment can sustain it, systems will destabalize. If All the Great White Sharks magically get more efficient at hunting over night ecosystem will collapse. Individuals and teams have never scaled at this speed to the levels they have. And there is no signal at system wide level that a sustainable limit has been crossed. So People will happily believe things are getting more efficient at individual/team scale while at system scale things get more fragile. This is why we ended up with central banks deciding interest rates and controlling money supply. Before that any one could print cash. They all thought they were great efficient geniuses.
The chimp troupe us not prepared for stuff that effects the entire system.
I’ve been making Codex and Claude get their work reviewed by most recent best performing model of their own family, and each other’s, for months.
On top of that, we have been running multi-model AI reviews on every PR through their respective GitHub integrations (Codex, Gemini, Copilot, Greptile, CodeRabbit).
They never fully overlap, and yet they somehow usually all miss the same things. The most significant improvement came from having agents commit their plan along with their work.
On the upside, it means I get to focus my reviews on different things.
> I'd question the added value of manual PR reviews at this point.
Yeah, why not reduce the team size to zero while you are at it?
These generalizations about software engineering have never been useful, IMO. Context is everything, there is no flow chart for building a perfect software process.
Although, I'd say you are absolutely delusional if you think we are universally beyond the point where manual review of pull requests is required.
> About six months later, it is his frequent bemoaning at the standup that their PR don't get reviewed, languishing in inattention
What irks me the most with this new trend is when people don't review the code themselves thoroughly enough and you're pointing out obvious flaws that you know that they should be aware of. LLMs can be such a great tool, but it's unfair to make people review your code before you've even seemingly looked at it yourself.
I think we're too nice sometimes. If a coworker has been sending stuff to review that's taking me more time than for them to create, surely that's an opportunity to discuss this?
I wonder if there is a tool that could equally waste their time. Like the worlds most pedantic code review bot that just gets the PR raising bot to spin wheels forever.
An interesting question to him and management might be what his own role is now and whether he's still needed. If he's not doing any reviews then you could yourself directly prompt the code and review.
The question I’ve seen here is responsibility. If you submit a PR that means that it was your best effort, and you’re willing to stand behind it to some degree. With AI, some people, when the scathing review comes back, just say “haha look at that stupid AI.” The reviewer might just as well run his own AI to do the review, but it may make huge errors as well. In that scenario, who is held accountable when there is a big bug or it degrades the quality of the code base?
Ultimately what it means to be a professional is that you are responsible for your work. That’s why you get a salary instead of being paid by the token.
Have you spoken to him about this? If he's clueless enough to send AI responses to human messages, he's probably clueless enough to not realise why people don't do that.
Fight fire with fire. Ask Fable to conduct an adversarial /ultareview of their PR and send the same wall of text back to them. If there are excessive defects, ask them in standup if they actually reviewed the PR themselves before sending it. If there aren’t maybe they are on to something. I think like in law, the human submitting the work is responsible for its quality, not the AI.
This is the point where you decide. It used to be low stakes and easy to care about the job you did for other people.
Do you want to put the same effort into your job when nobody else does, or should you reserve your thoughts and just feed it back into the LLM?
The LLMs are being advertised as output increasers but companies so far are using them as excuses to fire people instead of creating previously unbelievable things. It might be better to feed your coworkers output back in and use your thoughts to start the company you thought you never had time for.
I'm not sure what the right vocabulary would be to describe this, but this sounds more like the calculations behind nuclear war than a healthy collegiality or cooperative work relationship. This sets up a competition to determine a loser based on resource scarcity, not a way to achieve mutual goals to advance the organization's goals.
You are thinking of "game theory" and it's what happens when your coworkers don't give a shit. And all it takes is one, both because they can degrade product quality faster than you can gate it or fix it and because the performance assessment techniques are about 3 years behind the state of LLMs and if they play, you have to also or you'll get shit on from such a height you won't even know what hit you.
And once you start playing the game, then one day - it doesn't take long - you wake up and ask yourself if this is how you want to spend 8 hours of your life monday through friday. I think a lot of us are saying no but now need to figure out where our money is going to come from. I don't have the answers.
In a previous job, we had this saying "killing penguins" we used when referring to throwing more computing resources (more GNU/Linux instances) than necessary at a problem. In today's landscape of indiscriminate AI spending, I bet we could repurpose the term to mean "actually negatively impacting the arctic biodiversity".
“Token Standoff.” The most efficient token consumer wins. This mutually assured time efficiency destruction is driven by management support of aggressive use of AI in an attempt to, in some combination, increase productive and constrain labor costs.
What I don’t understand is what value is the person adding to this equation? Put another way, what’s the difference between them feeding the wall of text to the LLM, and you feeding the wall of text to the LLM, bypassing them in the process entirely?
The role of the person in the equation is to take personal responsibility for the proposed change and review the changes prior to PR submission. You can't put AI on a PIP. It's acceptable to use AI as a coding assistant in 2026, but if a human is not reviewing what they submit and taking responsibility, their value is on par with a ChatGPT subscription.
The same as if they said it was copied from stack overflow, or if it’s wrong; “I think there’s a problem here, it’s XYZ”. If your peer ignores you and you were wrong, it was their call to make. If you were right - take it to them or the manager depending on how many times it’s happened.
Don’t ever write this in a professional environment. It’s childish ant achieves nothing other than pissing off the person it’s targeted at and probably the manager who now has to deal with a shitty behaviour complaint.
> Ask Fable to conduct an adversarial /ultareview of their PR and send the same wall of text back to them.
Not necessary. Use Haiku.
The response doesn't need to be good, it just needs to be substantial. Presumably the goal here is basically DoS of the problematic colleague through token limits.
I mean frankly this should just be part of the standard process. By the time any person is looking at it there's no reason it should not have gone through an AI review.
It's not always feasible of course but I think there is real, worthwhile discipline in trying to get change requests small and it matters more with agents. It's very easy to let it balloon into gazillions of files and lines.
I improved a similar issue by writing custom instructions for copilot that give it enough context to do PR reviews that are only 30% BS.
I asked other team members to run my custom instructions to perform a review with copilot before they submit...
Of course no one is doing it. It looks like the PRs I get are still straight from copilot. So I tend to run my review prompt. Cut out the 30% BS issues it "finds" and the rest is good.
why leave comments intended for your human colleague when they will only forward them to the bot?
why not speak directly to the bot yourself instead? then you can drop pretenses and get to the point
I find this to be a new variant of the old behavior where a colleague comments on a typo in a PR, and the team later moans about laborious back and forth for small nitpicks, instead of simply editing the typo right there (and perhaps leaving a note that they did so)
I had this happen to me twice. The first time I ignored it, second time I responddd with “I could have asked ChatGPT myself but I asked you”. Never happened again.
"why are you such a drag on team morale?", "why are you invalidating your colleagues learning experiences?" "Next time you do this, HR will have to step in" etc etc.
Because it doesn't matter what you say to the bot. You might as well have a conversation with yourself about the PR.
The bot isn't making decisions. It's not choosing to submit extensive PRs with bad code. The colleague is the one who needs to actually learn something here, and the problem is that confronting him about it directly is widely considered to be bad form. This is, of course, a deeply unhealthy aspect of our corporate culture. We need to be more open to honest communication, even when it's either uncomplimentary of one of the people involved, or counter to the prevailing opinions within the company.
"I'm writing tons of code, and the process is stumbling where the guy whose job it is to review code isn't reviewing it."
"I'm not reviewing code."
Sometimes I wonder: how does someone go and think so much about their coworkers, and never once think about how they themselves look?
Even if I sympathize with the people complaining about their poorly chosen GitHub-based workflow - whose purpose is to let pull requests languish, for the most part - and how they stumble when overwhelmed with solutions. It's obvious to me, that the people who complain the loudest about the anti-sociality of LLM authored code in their precious harmonious low-effort workplace status quo: they are projecting.
Imagine you are a restaurant reviewer. Your job is unquestionably to go to restaurants, order and eat food, and write a review. The restaurant's job is to provide you food to eat and review.
You go to a new restaurant, and order some dishes, and one of the plates your server brings out is a big ol pile of dog shit.
Who's being anti-social in this situation? The restaurant is doing its job and all they're asking is that you do yours. On the other hand, you have certain expectations about what you order from the restaurant and they're not being met. Who's anti-social?
I cannot think of a single actual food critic that would consider it acceptable for a restaurant to serve a dish for review that they went to the restaurant next door to get. If the critic wanted to eat at/review that restaurant they would simply have gone there instead.
what is the point? this whole restaurant analogy is completely fictitious and happens nowhere, and the scenario i'm describing is happening all the time... why not just talk about the not imaginary scenario?
The person who "writes" code is also supposed to review their own work, and answer for that. If they won't do that - well - they should be fired. But if you have weak or uninvolved leadership, then the team's only rational recourse is to shun them.
It’s much more effort to verify that code is correct than it is to produce it. This is the case even for human-written code, and now that we face a torrent of ok-looking probably-usable AI generated code, the problem is compounded infinitely.
If someone’s using AI to generate a large quantity of actually-tested, actually-good code then that’s one thing. If they’re generating a fire hose of slop and demanding that others do the actual human time-consuming work of validating that code then that person is the problem. It’s hard to tell which is the case here.
This no longer works when bad faith actors will push code straight from LLMs with little review, and respond to your comments with LLM responses. They will constantly leave you with the responsibility of verifying the output. You are the human in their loop. This is a brutal asymmetry. In the past, at least you knew a person probably spent more time handwriting code than you will spend reviewing it. This no longer applies, now the reviewer can easily spend more time than the author.
The thing that makes it scale is to default to "no" and require the other party to convince you of "yes". Just put the burden of proof where it belongs.
If they don't manage, then that's their problem.
Communicating this in a way that is viable for a business scenario certainly comes with its own difficulties, but that is a solvable problem.
In fact, you can use AI to stress test your communication there.
Just throw what you want to say at the AI but don't tell it that it is you who wrote it. Then tune the input until it stops saying that you're the problem and starts agreeing with you.
Highly recommend. It's a perfect emotion-driven cargo-culting normie simulator that never calls HR on you.
Did you not read what I said, they will use LLMs to spam proof onto the human reviewer. Just endless replies with LLM generated answers until you yield and approve the PR.
Because we're all on call for the service, and tragedy of the commons exists. That coworker isn't paying the cost, everyone else is paying a fraction of it, and it builds over time.
This 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 review, and based on the issues I find I doubt they are even looked over first beforehand.
I understand that the information may be accurate, even helpful at times, but feeling like I'm constantly talking to an AI chat bot all the time gets tiring. And I don't appreciate having to double-check everyone else's AI generated responses for them.
I've seen this, too. There is a workplace personality that sees the job as a 2-player game between themself and the corporation. They think the game is to min-max their effort to personal career benefit, and they don't care how much it inconveniences anyone else.
Before AI they had to actually put in work, or at least play games of trying to steal credit from other people without getting noticed. Now that AI appeared, they see it as the ultimate way to take credit for work they didn't do: Put everything into Claude, let it do the work, copy and past output back to someone else. Minimum effort invested, maximum visibility achieved.
It will continue as long as they think they're getting away with it. If managers aren't willing to intervene, or worse if they encourage this due to the volume of output that seems to be appearing, it's only going to get worse.
I’m conflicted after reading this comment, because I think I would be that personality in my workplace, largely because I believe that’s the only sane position to take as a worker with ~0 power over the decisions made that can entirely destabilise your life.
On the other hand, my priority isn’t maximising my personal career benefit, but the collective benefit of my team, so I suppose I either see it more as a 2v1 sorta game, or perhaps my “player” is an amalgam of myself and my teammates. Playing this way, outsourcing everything you do to an LLM is the worst move, because you lose the touchpoints that tell you where the friction is in your team.
I think everyone should be looking to balance their work effort against the payout of the job. They should also be changing jobs when the effort to reward ratio starts to become unfavorable compared to other jobs on the market.
The problem with the personality above is that the person isn't playing like a team (like you said) but as an individual maximizing their own visibility while loading their coworkers up with the review effort. They found an asymmetry to abuse (they generate text easily, coworkers get a lot of extra work to review it). They don't care what it costs their coworkers. They just like that it makes them look good.
> They should also be changing jobs when the effort to reward ratio starts to become unfavorable compared to other jobs on the market.
The problem here is that all tech companies look alike. Take for example the interview process (copied by almost any company out there that thinks they are google). Another example: the under/meets/above expectations BS. And now the most recent example of “token usage as sign of productivity”.
So, it’s getting tremendously difficult to simply switch jobs that offer something different
My experience couldn't be more different. The tech companies I've worked for in the past 10 years have been so completely different from each other, from interview process to company culture, that I can't agree that all tech companies are the same.
You can also look to change to different roles (product management, even sales) or jump to a different career completely.
There are options if you look. You're not going to find a dream job that pays $600K for 4 hours of no-pressure work per day and perfect coworkers, but there are a range of job options with tradeoffs along the compensation-effort pareto front.
Whenever I try to articulate this issue to people during more casual AI discussions, I always refer to “study guides” in college.
I don’t know how many of y’all did these, but I’m sure I wasn’t the only person. At my undergrad it was very common for a group of students to all to get together, compare notes from lectures and readings, and basically come up with a group study guide of sorts. People were given specific sections to share, you didn’t just send all of your notes - usually 2 people per section’s take on that portion. You could always tell who just copy and pasted their shorthand (usually indecipherable) and who actually took the time to edit it/clean it up. This was at a time when almost everyone did it on laptops.
The people who took the time to make their portion(s) digestible for others were asked back, the others weren’t.
Either that, or call them / walk up to their desk and pick a point from the wall of text and ask them to explain what they mean by it. Then watch them turn red as they have no idea what the message they sent to you means.
Sure, some people have no self awareness. In that case you can change your approach, if you are a manager or otherwise invested in the company you can put pressure on them to increase the quality of their work and to own the things they submit. Bring up specific examples of poor quality work, errors in documents/messages, etc.
Or if you don't care you can just ignore this persons messages.
I got sent a 6-page spec document with a footnote that says "this spec was created with AI, so it may have nonsensical sections. Feel free to fix them."
I had someone submit a PR that was 3000 lines of shell scripts. Totally useless crap. I tried repeatedly asking him why he made particular choices and it was so painfully obvious that he had absolutely no idea and was just inventing bullshit answers. I would rather he have just said "I don't know, Claude added that", then tell obvious lies to my face.
And that's the point where you can stop to hide your true opinion, no? "How am I supposed to review a thing the supposed author didn't even read or understand himself?"
I tried this when my skip level boss sent us a wall of text from ChatGPT that didn’t make any sense. He didn’t care. He said it was “just an idea”. He likely spent all of 5 minutes on it, while we spent a collective 15 hours dealing with it, before finally going to him and calling it out.
He’s sent a couple more emails like that since. I don’t even bother to read them once I see the format.
This feels like a BOFH response but I'm strangely not opposed to it; If you generate something, you should own it ... regardless of what tool you used to generate it.
I've had a colleague call it out 'Is this AI slop? Please write your opinion'. I don't think I could do that myself, but I really appreciate that they were drawing attention to it
Management, responding to someone who takes your advice to "ignore it": "So we've noticed that there's this guy who is doing tons of work, and you have chosen to do no work?"
Communicate with your boss. "I'm ignoring this guy's slop because he's spewing slop, but not actually doing his job, and if I stop to deal with all of it, I won't be able to do my job".
Yes, "not actually doing his job". If he's sending you un-reviewed, un-filtered, untouched AI output, that's not doing his job.
100% agreed. I've shared output I didn't fully understand, didn't feel good good about it, and now I really try to digest, understand, and be able to actually talk about it if I expect other people to do the same. I hope in time your coworker comes to similar realizations.
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.
I can't imagine my opinions just being AI slop that I've parroted. Surely you embellish just a little? Claude's so often bone-headed about things, this horrifies me. Gemini's worse. Even when the model agrees with me, it starts making me wonder if I'm not somehow wrong.
I had a new colleague on the team, who I had to on-board. I gave him a few simple tasks, just to get him into the whole setup. He literally copy/pasted my task description into Claude and asked it to complete the task. To begin with, I didn't suspect this, so when he asked for more help, I gladly wrote up a detailed explanation with more information and detail for him to learn. Little did I know, he never read it but put it directly into Claude. Not even sure how I should handle it, but my first instinct was to get extremely annoyed.
Maybe this is just how things are going to be. But in that case, I'm done spending my time being a helpful idiot talking indirectly to a robot through another person.
> Not even sure how I should handle it, but my first instinct was to get extremely annoyed.
My first instinct would be to have a /very/ direct conversation with that person and their manager, and the follow-on would be to escalate it further leading to their termination. That sort of behavior is unprofessional in the extreme, even in the era of AI.
"Demons are deceptive by nature, and typically speak with humans for a specific purpose, such as securing mercy or lowering vigilance. They treat language as a tool, using words without truly grasping their meaning. ..."
It surprises me how many people have voluntarily relegated their entire job to LLM Prompter. If your work is indistinguishable from that of a machine, what’s to stop your boss cutting out the middleman and using the machine directly? I would have thought that people would be trying their hardest to prove their worth in this new world we’re in.
I actively support “my boss” to run Claude Code. I offered them to help and made jokes it’s so easy these days they might as well just call Claude Code themselves. I’ve shown I could plop in their documents of feedback and Claude fixed the issues.
I have worked with non-tech employees to set up Claude to help them do small tasks. I’ve helped to review and improve completely vibe-coded projects by such employees.
I’m not sure what my role will be, but I fully embrace that my traditional role of writing code is gone.
It's even worse when everyone around you is using it. How can you keep up? Companies face the same dilemma: investors, competitors, and users already use AI and have factored it into their expectations.
AI is supposed to make people 100x more productive. We know it doesn't because nobody remade Windows in 6 months or Photoshop in 1 month. It's just memorized more common cases, that's all. You used to not be able to oneshot a three.js game, now you can, but that's only because it's memorized more three.js games, not because it's more intelligent.
Even if there's a lot of noise there's clearly something real there. People are shipping more working products than was previously possible, they're debugging faster than was previously possible, and various other things. I mean you can go fishing for things to confirm your skepticism if you want but it's pretty clear to me.
Sure, but that doesn't mean that you can't filter signal from noise.
So the actual problem statement is not "how do I keep up" but "how do I correctly tune my filter", which is solvable.
The biggest challenge there I think is that many people are not prepared for just how sharp and uncompromising that filter needs to be, but that too is solvable.
If you're not going to experiment at all you're not going to be able to do that. Agentic coding was basically a joke the first time I tried it. Now it isn't.
having worked in tech and now running my own company..
the honest truth is that maybe 10-20% of SWE (at best) are “good”. sure it is harsh but i won't lie. if you're good you'll probably relate.
the rest kind of suck.
i’ve never gotten anything lower than Exceeds Expectations in my career so I’ve seen how awful some engineers were. i’ve seen how amazing a tiny minority were and i made them my mentors.
these days i have a simple policy.
if they cannot think, they are fired. why waste resources (time and money) on someone who can’t use their brain? i’d rather give AI credits to someone who uses their brain.
thinking is the humans job. the ai needs to execute on what the human thought of, improved, planned.
Everybody talks about finding that mythical 10X but in my recent hiring experience it's more like there's a whole bunch of 0Xs and the trick is finding the actual 1Xs among them.
All my experience in trying to hire developers has been wading through an endless stream of people who were just useless.
Me: I want to represent a 2d grid, what data structure should we use?
Them: A string?
This was someone applying for senior engineer. Others I've had filled their CV with SQL related acronyms. But couldn't explain what a foreign key was and then stubbornly insisted that at their current corp they would never ever use foreign keys in their SQL database!
I've had senior engineer when asked how to check if we had a 2d array with an item at x,y tell me if anything is on the same column or row, they couldn't do it, couldn't even verbalise how to approach it.
"Web Developers" who didn't know the difference between GET and POST. Web Developers that have never heard of PUT or what it would be used for.
I have a question I usually ask which is "How would you convert a Julian yyyy-ddd date string to a military yyyy-mm-dd date string?" (I explain how a Julian date works if they aren't familiar with it.)
The answer that almost guarantees I'll hire you is "there's got to be a library function for that, so I look in the manual". Almost as good is somebody whiteboarding how they'd convert ddd to mm-dd (and then account for leap years, etc.)
I get a disturbing number of people who say things like "I would communicate with the person asking for this to see what they're really intending blah blah"
My favorite answer was on a phone interview where he just hung up and wouldn't answer when we called back.
> I get a disturbing number of people who say things like "I would communicate with the person asking for this to see what they're really intending blah blah"
Sounds like they know this question is a “gotcha” question but just misinterpreted which direction you were going with it.
Some will ask a question like this expecting you to treat it like a puzzle and outline how you’d solve it as-is; others ask it as a way to probe how you’ll deal with strange or misguided requests (the case you noted as disturbing); and others yet will ask it to see how you’d practically solve it (your intention).
Seems like a bad interview question without context regarding kind of answer you’re looking for.
No, it's a pretty good interview question because it tells me if somebody's instinct is to reinvent the wheel or not. What I didn't expect was how many people couldn't say how a wheel even works.
People are not generally answering interview questions based on instinct, but rather based on what they think the interviewer wants to hear to get the job. I would have interpreted this is as a leetcode style algo question and started by treating it as such, even though IRL my first instinct would be "get a lib that does it". Awful, awful strategy.
It appears that either answer would be accepted, and so I'm fine with it. If it really is there is one correct answer then I'm against this. This feels like a problem where a good enough solution can be done in the time of an interview if you do it by hand (though if anyone knows about dates they will expect there is a lifetime of fixing special cases left if you don't use the library)
I prefer fizz-buzz as a question because it is obvious there isn't a library. It is also a problem you should be able to do in an interview. It has enough weirdness that there is no best answer, despite having several workable paths you could try.
Its not. Any interview question where you are looking for a specific answer is already suspect, but especially if you don't properly provide context for the question in what you would expect, things become a shit show.
If you would ask someone to write a piece of code, and a part of the problem is this conversion, then you would be right to expect they reach for a library, but even if they don't you would be giving them the opportunity to explain themselves, and judge the explanation, not the answer. Also, if your test is "does this person reach for a library at the right time", you could do a lot less esoteric and confusing by just asking them to add 10 days to a date. If you just ask this one specific problem, it is likely they assume you are looking for them to demonstrate the skills involved in actually solving the problem, i.e. leetcode.
This is also why some people give you the blabla answer, because it is indeed very unlikely that someone needs to do this legitimately. This is because its a toy problem. Someone's professional reaction to the problem in isolation should indeed be: this is weird, I've never been asked something like this, what's up?
Finally, even though the question is terrible, I would still rate the "whatsup?" response higher than the "leapyear" response. I would want a developer to triple check that this problem needs solving, before they would solve it themselves.
Finally finally, if there's one answer to one question that, when answered trivially in a way literally taught in most basic programming courses (use the standard library / a third party library), makes them a "guaranteed hire", I also have significant doubts about the level of talent you are bringing in, as any experienced interviewer will tell you that qualified people will get important questions wrong, and unqualified people will get important questions right.
I understand that this reaction might be quite harsh, and I know better than anyone that its hard and time consuming to do good interviews, but please consider that you are rejecting people who may be very confused and sad by this way of rejection.
But that's why the context of the question is important. It's not clear from your comment, but I'd give a different answer if the question was strictly academic in nature (reinventing the wheel) or focused on practical work realities (use a library).
Even using a library isn't that practical. It may be the zeitgeist in JavaScript but that doesn't mean it's actually a good idea. Nobody remembers left-pad? If you're writing Java or Python then checking if your date class can already do it is a good idea.
Someone else said it on HN a couple years ago...Something about how there's no such thing as a 10x engineer, but there are a LOT of 0.1x engineers and a few 2x.
The absolute worst is someone that tries to brand themselves as a 10x engineer by constantly using programming terms like "dynamic programming", "polymorphism", "recursion" and the like, but they're really a 0.1x engineer because they don't truly understand what any of those are and when they should actually be using them, and so try to shoehorn them in when they don't need them while also not understanding them, and end up writing low-quality crap.
Took too long for management to get rid of that guy.
Also now is it 1x in individual productivity or >=1x in team productivity. As anyone multiplying teams productivity by less than one is bad. Probably lot worse than actual 0x.
Someone who produces absolutely nothing and have no impact has cost, but is still better than someone who produces net negative. And the people who solely act as interface between LLM and whatever might fall to later category.
It's the Pareto principle of course, as well as the normal distribution. Many firms have been able to succeed in the market just by hiring only good engineers over average ones.
yeah but these days it is even more important to filter out bads
and even at "good" companies you have people who can game the system to get in, and then they struggle to get anything done on time or be responsible for taking on and completing any initiatives bigger than a single task on a bigger scope.
Indeed. You really need to find people who don't want to play politics and instead get stuff done. I'm still not sure how to hire for these sorts of people in the age of AI, where people even cheat in interviews. Maybe probation programs? Have multiple people work for a month or two and cut those who don't succeed.
this is what I've been doing, and obviously I have a startup so I need to double-ensure that I don't onboard any bads. you can start people off as contractors too.
I still think a single in person LC style (doesn't have to be LC per se, could be domain specific) logical thinking/reasoning exercise is useful. I want to ensure the person can actually put 2 and 2 together and think. This is just a fast filter.
If they seem like they can think, then I like to do 2-3 systems design interviews. I'll try to give them something related to things I like, such as graph structures, writing a complex query that needs to be dynamically generated, or something related to infrastructure or how they'd do something that I've already done. After all, this is MY project they're joining.
So far that has worked well.
Few more things -
I like to test if they are a humble type (they can work on a team putting ego on the side - the mission is our number 1 priority). if they say they know something that i know and asked, then they can be sure I'm going to drill them on it. if it turns out they lied, i'm not wasting more time. Thanks for your time, take care. This is very important to me. Just say you don't know, it isn't a big deal because ever since like 1994 that has not been an issue. You can just learn things online, and AI makes that even faster. I am never afraid to say I don't know something, and I've asked plenty of "dumb" questions (while doing some due diligence first) so I don't really mind.
Can they handle information overload? I am the type of person who has multiple branches in my head of actions I can take next, so while I may appear stressed I'm really not. Can they keep up? Our goal as software engineers should be to come up with solutions that solve the problem in a way that makes building on it simpler in the future. My goal is simplicity and effectiveness. So I'll see if they can keep up, and eventually reduce the work to be done into atomic pieces. This is a fun exercise because it is collaborative and we get to bounce ideas fast back and forth.
Finally, I like to let them use their favorite tools, including AI tools (codex, claude, some ppl have esoteric custom stuff which is cool), to solve a problem together. It might be code related, it might not. Really depends on my mood. I like to see how they work and what sort of output they can come up with. This filters out people who only ask AI stuff, instead of having some framework they've already developed to be effective.
Honestly I don't know how to scale this process. I'm not really going to feel bad either about firing fast, ultimately this is a business and I don't want customers to suffer because we have some issues internally.
At the same time, I wonder if I even need to build out an org with 100s of people. That was an inefficiency (look at all the layoffs), and it is traumatic.
If I can find a few great people who can be supercharged and turbocharged and electrified with AI, then they can take on & own bigger responsibilities. My number 1 goal is to ensure they're with me on the mission, and after that all things seem to sort of fit into place.
Firing fast works both ways. If I joined your company and I thought you fired someone too fast I would leave, not because I might get fired, but because I've seen where that kind of leadership takes things.
thats fine you can leave. it’s probably for the best for us. that’s why the mission is so important and requires a great filter.
mass effect 2 is my favorite game ever. it is all about putting together the team, and ensuring you work with each one of them to get their whole loyalty.
each member is a badass, in their own regard. it’s also a video game and it’s linear unlike real life. but the mission is super important to me.
and when others have their own passions they want to express and carry out via fulfilling the mission, that’s super key imo.
so far it’s worked out fine. people get the fast firing thing. they know if someone isn’t onboard with carrying out the mission they also don’t want to be burdened.
like we are seriously helping people in an underserved industry. it’s insane.
i hate working with mids and bads, they are going to bring everyone else down. so i want to work with the best people i can get. they don’t need to be MIT grads paper weight types. they just need to be mission oriented and focused.
Might not be solveable. At some point the effort in finding that someone might be larger than the benefit you get from just using the second, third, fourth best. Or using some flawed approximation hiring mechanism. There's just so much noise now. And it hits the good job seekers too.
What I find strange is how rarely LLM output is distributed alongside the LLM input, especially outside of code repos. Why can't I rerun the prompt that resulted in your work next year, when models have gotten better? Are people ashamed of their prompts? Ashamed of having used AI? i unno
Prompt used to generate this message: "Create a comment for Hacker News which bemoans the lack of AI prompts being shared with the stuff it creates. Speculate on the reasons and create a call for engagement. Use quantum hyperthinking. End with a typo to prove your humanity."
Most of my AI usage amounts to "read this ticket and do the work", the ticket documents the requirements, a better model could, I suppose, do a better job?
If the high school project has been improved by many engineers over a few years it likely is complex enough that a senior engineer cannot rewrite it for a reasonable cost. It isn't clear if next years models will be enough better that they can rewrite it for a reasonable cost. If they are they can probably extract the requirements and special cases from the code.
Following my analogy, the high school project would have been continuously extended by high schoolers passing the project on from class to class each year, rather than "improved by many engineers". The "engineers" (future models) don't get the project until currently models have had their way for a while. I think that makes the "rewrite from scratch" plan a whole lot more compelling.
In any human relationship, nobody wants to be the one who noticeably makes more effort to communicate, keep in touch, resolve conflicts, and so on. The idea of reciprocity and fairness are deeply entrenched in our minds, and that of many other social animals. If they don't care about me, why should I care about them? It's the iterated prisoner's dilemma again – freeriding is equivalent to defecting.
I'd say it's because we're tasking ourselves with dumb stuff. No one half-asses building a shelter that keeps their family alive, or throwing a new favorite bowl on the pottery wheel. But instead of that we're writing posts for Facebook etc etc so we can (???) profit. So of course we want bots to do this all this dumb stuff, and of course we get dumb results.
For some things, yes. But I'm half-assing some really cool stuff right now. Made a scraper to pull my city's meeting minutes, agendas, recordings, made transcripts. Regex for "Flock", found every mention, passed those files into a cheap model (DeepSeek V4), had an understanding of who in my city is down with building the surveillance state and who isn't. I've got research on everyone, and had emails drafted for each one based on what they said. Quotes and figures and all. I lightly polished each email and fired 'em off. Already got some replies back. Plenty more in the quiver too (pulled and analyzed CSVs of FOIA'd datasets).
If they're gonna spy on me with AI cameras, I can oppose them with AI research. :)
Did you use some stuff like https://github.com/CouncilDataProject or roll your own? Been curious about how to integrate local knowledge like this since local news seems to have lost the niche.
I rolled my own. I hadn’t heard of this one, but I looked into stuff like OpenStates (now privately for-profit owned, ugh). My city just uses a Wordpress site so it’s structured enough. I’m looking at building something to ingest cities with Granicus and one other big local government meeting recorder via API whose name I forget. That should get decent coverage. There’s no way to catch the long tail of every local government’s recording process. Some cities people will just have to do manually. But it’s easy enough with LLM help.
> I've got research on everyone, and had emails drafted for each one based on what they said. Quotes and figures and all.
Please tell me you did the work to validate that the quotes and figures were not made up by the cheap model. These things make stuff up all the time, you absolutely cannot rely on them without validating the output yourself.
Yep, I manually listened to the meeting recordings (easy to find the spots based on the transcript timestamps) for any quotes. There are also meeting minutes and agendas with supporting docs to corroborate against (e.g. for dollar amounts). They really don’t make stuff up all the time if you root them in data.
Nope, I used a minute fraction of the technology they have, along with open records as is my right in this country, to stand up for my Fourth Amendment right to travel without creeps stalking my every move. I need to make my specific framework a bit more generic and then I'll put it here on HN. Or just offer a platform where people can bring an OR key and it can run on their city.
Citizens monitoring their government is literally THE foundation of democracy (ok, maybe voting comes before it, but then you have to monitor who you voted for to see if they’re doing what you voted for).
A couple of weeks ago I essentially failed the Turing test (took to be an AI). I found it a bit annoying, so I built Possibly Made By A Human. It tracks your keyboard use (not the content, ms between keystrokes etc) and produces a signature for you. It can of course be spoofed, but that also takes some effort.
This is one of the coolest tech things I've seen in a while. Can you explain how the "Check a document" works? I'm not sure I understand how you would check if the timing aligns based only on the text content.
It's a very poorly written way of saying that instead of storing your text it uses a hash of your text to sign. When you want to check the signature you only need to hash the text to check, again without touching the server.
This 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.
This isn't unique to code or AI. In creative writing courses, we were asked to give thoughtful critiques of (human written) stories and excerpts, and often I felt as if I were doing more work than the original author. If you can't be bothered to review your manuscript, or at least run it through a spellchecker, why should I waste my time on it?
If the agent does everything for you it means it can do everything for the next person. At that point you're replaceable and have no value in your field. Learn things deeply even if you use AI because its the deep knowledge workers that will keep getting hired.
> Learn things deeply even if you use AI because its the deep knowledge workers that will keep getting hired.
The problem is that this realistically is only applicable and actionable to a subset of the labor pool, and that subset is decreasing.
There are a lot of people who discovered that their "deep knowledge" and "deep skill" wasn't as deep as they thought (read: "deep" enough to make them irreplaceable to their employer). People are generally pretty good at overestimating their value.
The depths of knowledge required to beat Claude will only grow with time. "Deep" knowledge will become everyday normal knowledge, and will eventually offer no competitive advantage whatsoever. Continuous education takes a lot of effort and money, and returns are ever diminishing.
The volume of LLM output is effectively infinite. Therefore, it is not worth my time or effort reading a single syllable of it. I will not read (nor correct) LLM output, since if I did, I would quickly be doing nothing else with my life. And since LLM output is infinite, but I am finite, my efforts would still be completely without results, comparatively speaking.
I find that I actively filter all "computer generated" attempts to contact me: Mailing lists, "engagement" notifications, ect, is pretty much ignored. I only respond to human-initiated contact.
This is especially the case with cold outreach from recruiters: I get a lot of poor AI-generated outreach from recruiters, which are time-consuming on my part to engage with.
At one point, I was thinking that if any of my customer send me a snail mail with an actual physical stamp on it, we will call the customer immediately and solve their problem.
Atlassian's in-built AI assistant for JIRA will generate a task description with a complete SDLC task breakdown, requirements and deliverables.
While the person creating the task will need to provide some details and modify some of the generated text (if they bother to read it) - the sheer verbosity and the fact it's clearly generated just makes you not want to engage with it.
There's a lot of art out there that is totally uninteresting, at least to me, because it feels like the artist put little effort or thought into it or or maybe even into honing their skills.
But if the art instead beems with intention and effort, chances are that it will be interesting. And in order for anyone to create something so brimming with signs of effort, they must have cared about the piece, the message, the artform, or something along the process. This post talks about effort and attention, but you could phrase it as a question of reciprocal "caring". If you want me to care, show me that you even care yourself.
It is getting harder and harder to suss out what is genuine though.
He was handed a gameboy before he could walk, but it didn’t lessen his humanity. He was handed a smartphone before middle school, but his humanity remained intact. He started calling the “people” he met on social media his friends, and humanity didn’t suffer. But alas, using AI is a bridge too far.
I think I've been following this subconsciously as LLM artifacts reached some threshold of pervasiveness across the work I do. If I can sense (maybe eventually I won't be able to because of how capable the technology becomes?) that what I'm reading is wholly regurgitated out by an LLM, I automatically care less and feel inclined to respond in kind by generating an artificial response in return.
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.
It really depends. In many cases, you absolutely shouldn’t.
In some however, you should. For instance, yesterday I sent a lengthy email in a language I barely speak threatening legal action against a business. I had an LLM translate/write it as it’s a language Google translate makes a mess of, every time.
So in that case, you’d be advised to read it lest you end up in court.
If you are operating a business in a part of the world where you expect to engage in the court system, you should hire someone that is fluent in the language spoken in that part of the world to act on your behalf. If you cannot afford to do so, or refuse to do so, why would anyway take your legal threats seriously?
I've been writing technical documentation and architecture docs that no one ever reads for years. I now write those same documents using ai in a fraction of the time. No one reads those either but they are memorialized so that no one can bitch about tribal knowledge.
A somewhat related experience: I asked for advice on Twitter about something and got two unhelpful AI-generated responses (from accounts I have never heard of / don’t follow) and no human responses. The thing is that I already asked multiple frontier AIs the same question and didn’t get a satisfying answer. I specifically went to Twitter because AI did not have the answers I was looking for. Providing an AI answer to a human question assumes that the asker hasn’t already done their homework and tried asking an AI.
This isn’t sufficient, it needs to be “if you are asking for assumption of accountability, demonstrate human effort.”
In my experience, people who make requests like this don’t care about your attention, they only care about getting you on the hook for something. Your application of attention as a requirement for that is irrelevant to them.
I use AI as an editor on informational writing all the time and it's good at pointing out flaws in what I wrote. But I don't really love reading a document that's obviously in the voice of Claude if you're asking for my opinion on it. But it kind of depends on the writing -- a change request description, most people are too lazy to do better than the AI would, and there are other kinds of documentation that normally just wouldn't get done. But like for a design doc where you're asking me to pore over it now even though I don't necessarily get anything out of it it's distasteful when I see phrases that are obviously from AI.
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 added to our PRs. So now I'm sometimes getting hallucinated BS responses from "human" reviews.
This makes me absolutely SURE that the general public is fucked and that we're going to start seeing huge AI generated fuckups on a regular basis. If people in this industry, basically experts compared to the general public, are misusing this tech in such seemingly obvious ways, imagine the ways non technical people will misunderstand and misapply it. Of course, with the help of overhyped BS from everyone hyping and selling it.
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.
Yep, it's bad. It's too easy to press the publish button without double-checking the outputs. Programming has always been about discipline, and now it's even more so.
Many artist and content creator is now asked to show the "behind the scene" or a full session recording, which nobody care enough to check. This is frustrating and demotivating the artist.
Expect the same demotivating effect on the software contributor.
If you think reading _forwarded_ AI response are cheap, you can run your own LLM. It is the same amount work on you
This has been my rule since the moment generative AI hit the scene. If you're not willing to put in the effort to create the thing, why should I put in effort to consume it?
If the requester stops applying common sense, the reviewer has to apply more of it, and there's a finite review budget. I will deal with requests on a lowest review effort-first basis, just like you did on the other side.
This is just an old engineering principle of work amplification. For an input of x you shouldn’t routinely do nx. If you do you’ll get flooded. Debounce, throttle, load shed, improve throughput and latency. Lots of solutions. Just map it to the problem and apply.
In the past you had coworker who produced volumes of code. Same principle.
> For human code review requests, I always review my AI-generated code first.
I remember a time in the ancient past (2025 maybe) that your PR was your responsibility, whether or not you typed it with your meat fingers or cranked it out of the Giant Plagarism Machine. It’s absurd to think that the above quote is now something approaching controversial.
That's not correct. If human attention requires human effort, that forces human effort all the way down the chain, with no machine output being possible.
You can't say "you can't feed me machine output directly". Machine output is meant to reduce the cognitive load for human processing.
If your colleague is forwarding AI output directly to you, that means they think the AI has reduced the cognitive load for you, and also you are the best person to process that output, instead of them.
You just need to change your perception about the purpose of AI.
More and more I'm generating AI emails, often to people outside the company and often to do with technical issues / integrations we have / APIs. So far I don't think the people I'm emailing are really using AI as human responses are, well, lacking. What would be great is new email conventions for different communication pathways.
Human -> Human (think we have this sorted)
AI -> Human
AI -> AI
If you are doing AI -> Human, then you need to be curating the response and understanding what it is saying, also, make sure its not leaking internal details or committing you to have phone calls/video chats (it does that). This works really well for the most, and humans respond with requested content. Quite often my AI debugs problems with their systems which I know little about. But humans do odd things like send screen shots of logs rather than text (they also leak internal details of their systems they potentially shouldn't). I used to tell people the content is partly AI, but now I just send the curated email without mentioning AI.
For AI -> AI you kind of want a hand over document as an attachment to an email. Only thing here is making sure there's no injection of security risks. But quite often instead of getting a human response to my AI generated emails, it would actually be nicer to hear from their AI which could give a better context/details. It would be really nice to be able to go, can you have your AI talk to my AI :) (security is a major issue here)
AI is able to read input from AI. Humans are able to read input from humans. Also AI is pretty good in reading input from humans. So we don't really need AI -> AI. Just output for humans and you are fine. You can still attach details and this is true for both AI and humans. So human output should be the goal for everyone and everything.
? you missed the point, ironically showing the problem with human responses :) humans are super bad at providing information, they concentrate on singular things, especially if they think they have a point / suspect they know what the problem is, but if they are wrong their response doesn't have enough to go on, so you have back and forth.
If you are trying to do AI -> Human communication you should be publicly flogged. Don't waste people's time with garbage you can't be bothered to write
Just send them the prompt instead, let them see how little effort you care to place into communicating with them
Why this suddenly becomes urgent? For long time we had automatic emails with "thank you" which weren't written by humans, why something is different today?
It's not just about being annoyed - it's very practical.
If the creator exerted human effort, they'll be able to maintain it. They can take responsibility for it. Even if the value of the 100% AI generated artifact is amazing, and the "creator" of it can't actually maintain it, then what's the point?
It's similar to scenarios I've seen where a brilliant ML person comes into an org, trains a model, that seems to solve an important problem. Invariably when that person leaves the org, the ML model stops being used, the team falls back on older / technically worse methods. But the team can be responsible / own it in a way they couldn't the brilliant one-off work.
I once received an internal defect report from my product's QA team. It was long and obvious that what they did was feed the error log into an LLM and ask it to diagnose. It was total nonsense.
I reported it to my manger and stated that I will not have my time wasted this way. She was delighted to have this ammo because we have a long standing beef with our QA for not putting in due diligence. LLMs are like candy for them.
I think this is because a lot of people think more is more. Wow look at all the detail and bullet points! No one on the receiving end actually wants that though. When I use AI to write, it's to boil it down to the minimum bits needed. I wish more people would use it that way.
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.
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!
Meh. Just this week, I've had two Sonnet 4.8 agents generate, in parallel, a 2000 line wall of brittle bullshit, and a well architected solution with 20% of the amount of code, to the same problem, from the exact same initial context, and very similar prompts. Come on, they can do poor quality work too.
We developers understand this when we are forced to read slop, and most of us recognise it in art and music.
I wonder if we forget that people using unthinking, default interfaces in AI generated apps might start to feel the same way: “it feels like no care was taken here so why should I give it my time?”
When I read things like this, I wonder how, exactly, people have time for this sort of thing these days.
Lots of companies are led by people who think that GenAI should increase productivity and are going to make damn sure that it is. There's no room to figure out things like "etiquette" for how to pass along AI-generated content to coworkers.
Perfect. I find myself applying the same principle to online discussion boards and comment threads. Humans post a question looking for other human input and get replies saying "I asked Gemini and it said...". I find that ignorant and rude when the context is a request for human insight.
Not true for HR. Despite their name, which is a complete mislead - except handling humans as resources -, nothing human exists there, robotic approaches are the norm there.
So feel free to use AI to pimp your resume, they will use AI to process it.
Now you have to add typos and not use completely standard elements of style that some people have been using for ages, like emdashes and "it's not X, it's Y"
If somebody throws a slop PR at me, I'd love to review it with them. I'd ask them to take me through it and explain everything until I understand exactly what they did and why. Either it will make them avoid me in the future, or it will open their eyes to how important it is to understand what you are submitting for review. I probably won't have to do it twice.
It did in many corners, there are some interesting designs on r/stablediffusion, and regular people too are using them to make posters and invitation cards for example.
If "putting a random seed into a set of swappable character parts" counts as "generative art" then it sure made a ton of money when people cared about hying NFTs.
> when [sending AI generated content to teammates], I take care to clearly label what is AI generated
Reading AI-generated text for hours every day, it's obvious to me.
I take care to make my messages easily readable. I don't care if they're AI-made, as long as they're short.
I'm a very verbose person, and if I don't make an effort at being concise, I'm just as annoying as the average AI.
Being flooded with AI text every day has made me appreciate brevity because I'm exposed to so little of it.
With half a dozen people who don't read or listen to half of what the others do, slop + cognitive drift is a bad cocktail.
It's just not as big of a problem on my own projects, because the ideas that get fed to the slop-machine are not that different from one day to the next.
---
> For human code review requests, I always review my AI-generated code first.
For human code review requests, I always review ANY code I submit first.
This is partly because it's the agreed-upon culture where I work now.
And partly because the codebase is not robust enough for slop.
I have hobby projects where this does not apply. I spend half of my time in those projects building hard guardrails.
---
> Keeping AI generated content clearly labeled and demonstrating human effort helps show consideration for teammates
I actually like the shamelessness, because it's honest.
So often this year when I ask "why did you do X?" pointing at a line, my colleague doesn't know.
Because they didn't really write that line, and they didn't really internalise the choices made.
When my colleague sends me a text dump from Claude, I know that my role is just being a sub-agent.
Demonstrating human effort: I'd like to see more of it.
One way is to spend more time owning "cognitive debt" as part of the daily cycle.
Brevity is the big disaster of human-generated text since the rise of the phone as default device and the appearance of Twitter. To discuss matters with sufficient depth and nuance, one often has to write a few solid paragraphs.
If people are now wincing at longform text because they automatically assume it was LLM-generated, then that bodes ill.
To add to this, there seems to be an inability to process metaphor and simile in the younger generations. Likely as a result of the same deficit. They've become very literal, and often mistake anything that's well written for AI slop.
There's a sweet spot between AI slop and 144 characters. I can tell within a few sentences whether there's a human on the other end getting to the point, or an AI dancing around the point and finding 3 different ways to say the same thing.
I feel like I live on a different planet to many on HN.. Any time I've dabbled with the current roster of LLMs for work tasks (I'm a game programmer). They are utterly useless, complete waste of time. Definitely not something that seems promising and warrants more time invested.
Big source of my depressive feelings today come from this. I see people online quite excited about AI output, nobody cares anymore. This was supposed to be a tool to elevate the quality of work, not vomit things out and put out fires like Orks trying to land a flaming plane with no wheels.
This headline has been seeing some popularity. But it's never made any sense. This is just the labor theory of value, applied to documents.
The labor theory of value doesn't work for documents any more than it works for anything else. If I do something that's easy for me, and it's valuable to you, you'll still want it. If I do something that's difficult for me, it will be less valuable to you, because the difficulty I have with it implies that what I produce will be of lower quality.
This is all equally true of automatically-generated documents. If they're valuable, people will want to read them. Whether it was unpleasant for someone to create them isn't a factor.
So where is this slogan coming from? Are people just afraid to admit that the documents they're getting are valueless?
The problem is that I don't know before I read a doc whether or not it will be useful and valuable.
If someone wants me to spend my time and attention on something they have shared, I would like them to demonstrate that they put a proportionate amount of time and effort into its production.
> If someone wants me to spend my time and attention on something they have shared, I would like them to demonstrate that they put a proportionate amount of time and effort into its production.
First: why? How does that help you?
Second: Is that actually true? Do you ever watch videos that a friend recommends to you? Even if the amount of time and effort your friend put into producing that video is zero? Do you ever read anything that a friend recommends? Even if they didn't write it?
How much time and effort, in your estimation, did jjfoooo4 put into producing this article on tombedor.dev?
I think the point is that automatically-generated documents by LLM is lower quality the manually-generated ones or at least guaranteed lower quality than automatically-generated + manually-reviewed.
Therefor if you are not putting human effort on the document it is low-value.
We have seen this before when big data started to be a thing, tons and tons of reports being auto-produced weekly (or even daily), but even if they contain relevant information they are low-value because no one can take action on so much information.
I am offering a product (via MCP) that interacts with LLMs and user data. Every single day I get user support emails to my inbox written by their LLMs with LLM hallucinations. If the user (a human) would have read them before, that would save me a lot of time and anger!
Your post sounds logical at the first glance, but has nothing to do with the reality. The topic title is totally on point! If the user would put human effort in it, I wouldn't get those crappy emails.
If you get a document from someone and they say "I have no idea if this has any value and I couldn't be arsed to check," it's not unreasonable to presume that it probably has no value.
Most OSS should adopt DKMS-style extensions systems so that people can code and distribute their own solutions to problems. Then it doesn't really matter, right? If the end user is using Claude to fix stuff in your shit, extensions make it irrelevant what "code owners" think.
This reminds me of a Pre-LLM-slop era issue I had with a process that a co-worker had created via a shared script that would automate combining many dependabot PR’s into one consolidated PR.
The script was excellent because it simplified the review process for a single repo (that had many competing dependsbot PR’s) and it also happened to do this across increasingly many many different repo’s simultaneously.
Funny thing is, however, that it also created a team dynamic where who ran the script became almost a race because the effort in creating x pr’s didn’t correspond at all to the effort required to review x pr’s.
The optics were also lopsided since the script would operate on the runner’s local machine and so it would have seemed as if the person who made all these PR’s was highly efficient at producing when in fact it was the reviewer doing the majority of the work.
Also reviewing represented a chunk of a developer’s day so it would affect other actual work the developer was tasked to do anyways.
In an agile workplace points (correctly or not) completed are attributed only to the code creator with no points at all being shared by those who reviewed the work, and rightfully so I’d argue because tangentially reviewers can also tend to just click “approve” (or slap a LGTM) without much effort into critiquing a piece or giving a thoughtful review. Why? It slows down the introduction of the feature (the PM won’t like that, why would you slow down the process eh? You grumpy goose), it messes with team dynamic (you may end up offending those who you review, who also happen to be the one who you need to review your work, who then may be petty or worse, mud slow to review your own PR’s), it takes additional time to provide reviews that seem as if you even read the PR or don’t come off as flippant (did you provide examples or a suggested refactor or detailed reasons), and it takes context because you may be working currently on a totally different project (regardless of your experience/authority in the PR’ed repo), so giving an honest review may sacrifice even more time to first review the purpose of the PR and how that lands in the context of the target repo(s) and then sacrifice the time necessary to reorient yourself to the task you previously had in process. With all this…that “approve” button becomes sooooo tempting.
It’s funny because fast forward some of the ways I battle increasingly prolific AI generated material is through GitHub’s CoPilot bot. I ask it to do the review first and when it gives the review there is none of that dynamic because it wasn’t me who levied the criticism and also it’s not me who is trying to block code integration (so no grumpy goose or team dynamics problems). Having a bot do preliminary checks almost does what git hooks did for team dynamics way back when automation of linting, testing, style, etc was introduced as a common part of the review process. And I say “almost” because a)sometimes the critiques from the bot are wrong and b) the critiques aren’t necessarily deterministic, so just because they are there or not doesn’t mean you are truly relieved of that portion of the review process (for better or worse).
So this post is talking about at work but I think the principle goes well beyond that. Think of all the AI chatbots you have to deal with to get through to customer service at a company. Or get through ATS systems in hiring. If it isn't already the case, this will probably replace or supplement TAs marking assignments.
The problem is that AI makes these interactions too cheap for the party that already has disproportionate power. The cost for them to add another layer, another hurdle, another set of questions, etc is essentially zero. Yet everyone who wants to get through that system has to pay in a human cost.
I just thought of another good example. In the pandemic auditions in Hollywood went virtual for obvious reasons. But this never went away. Now, you might say it's convenient to not have to spend hours driving to Burbank for a 5 minute audition but anecdotally the taped audition seems to be much more work. It requires a lot of prep and more tech for good sound and audio. There are people who help people tape auditions, which has really just added another layer. Plus, instead of only locals, anyone anywhere can submit an audition so where you might've had 30 people previously, now you have 150.
And what happens to those profesionally-produced auditions? They get submitted and the casting director might pick 5 randomly to even look at. If there isn't already, there will also be an AI system that filters those auditions.
At least previously you got 5 minutes of actual time from a casting director, the actual director, etc. So it's actually way more inefficient for you now. Plus, if you're lucky enough to be looked at and they like you, you probably have to go for an in-person audition anyway so what's happened here? You've just added another layer and way more work.
Companies think they're "winning" here by saving labor but I think that's short-sighted. What'll end up happening is AI agents will rise to help people on the other side of that. You can think of using AI to cheat on school assignments as an example of that.
So what will we end up with? AI agents inundating AI systems, which just adds a whole bunch of inefficiency.
I have only made this letter longer because I have not had the time to make it shorter.
The argument that "using AI to generate text is disrespectful because it took no effort to write" misses the point. Respect for the recipient is measured by whether the message serves the recipient's needs, not how it is produced. Similarly, any errors are the senders responsibility, and not the fault of the tools they used.
I agree that the bottom line really ought to be usefulness; if it's useful and doesn't waste my time, it's fine if you received it by the use of seer stones for all I care.
However, I don't blame anybody for having red lines like this:
1. Don't send me a big long string that is merely LLM output resulting from pasting a trivial prompt + text I already have access to (or my own words!). I know about Claude too, and if that's what I wanted I'd have done it myself.
2. Don't throw an AI-generated argument at me that you don't even fully understand.
3. If you're preparing information for me, and it's overly verbose and wastes my time, I'll be twice as mad if it's obvious AI than if it's obviously human. This is basically the article's point. The asymmetry of wasting an hour of my time reading a bunch of crap that took 15 seconds of your time should make it clear why this is antisocial behavior.
My opinion is there is a category error in the discourse on AI. It treats ai assisted output as other than human. AI is a human tool. AI output is human output.
I increasingly find that I don't care whether I am talking to an anonymous AI or an anonymous human, and believe that we will increasingly stop caring.
Because why not? AI will simply on average be nicer to talk to than most humans, with clearer thinking and better arguments, less contradictions, and easier to comprehend.
I don't know how humans could compete with that (but it also does not seem all that horrible, given that it will be available to every human.)
This is not to say that this idea is uncomplicated or comfortable, in different ways. Just that I think it's true and that it might even be good.
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 soulless. There’s only so much bland and soulless most people can take in their life before they start to get fed up.
When everything feels the same, nothing is interesting anymore.
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 writing for the past years. Why would that stop now? It's reasonable to assume that the makers also know about bad writing, dislike it, and thus the models will get trained to get even better at it.
Eventually how will you be able to tell? You won't. You can't. And that goes for the rest of us. And I suspect everything will just feel somewhat nicer.
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.
AI is seen as unique innovation, but in terms of the real purpose it serves, it is the logical extension of something like Doordash. "I don't like people. I don't even want to call one on the phone to order a pizza. Make me a tool that lets me avoid that, please."
Let me pose an alternative narrative. Rather than interacting with humans being intrinsically unpleasant (though for some people it is far more unpleasant than others), the technology is lowering your threshold for discomfort, step by step.
"Don't expend more effort than they are" has actually long been a good principle to have internalized. Someone done only cursory research before asking a question on a mailing list? Give a cursory answer. Someone obviously spent hours trying to figure things out on their own? Give them a good chunk of your time. Someone on HN responding to you with single-sentence responses? Either don't respond, or respond in kind. Someone obviously engaging with your ideas and taking time to explain their position? Take time to engage with their ideas too.
I've had this same policy since before AI. I kind of formalized it for myself (and this team) after enough instances of "I'm trying to do X. It's not working. Help." type messages.
You need to put as much effort into the question as you expect someone to put into the answer.
It's not "fairness" or "AI" or anything else, it's that doing this any other way fundamentally fucks up the team dynamics.
You have a problem. You want someone's help. If the cost to you is effectively nil (or negative, since you're asking someone to do your job for you), but the cost to the other person is non-zero, then incentives aren't lining up here. Pretty quickly that person is going to start carrying too much load and become a bottleneck.
It can also mask that the context of the work is too concentrated in one person, and does little to nothing to help build that elsewhere in the team.
The other end of this is exactly what you're saying--put as much effort into the answer as they put into the question. You're not doing anyone a service by taking their low effort input and giving them high effort output, least of all yourself. If someone asks "how do I X", that's low effort. If you happen to know the answer off the top of your head, spare a few sentences to explain or point them where in the code they need to be. If you don't know, don't go track it down for them.
I’d add that it’s basic respect and decency for your fellow humans who are paying for the attention with their own life.
> after enough instances of "I'm trying to do X. It's not working. Help." type messages.
Related to this, I will never for the life of me understand why people think it's okay to say "I get an error" without saying what the error is.
I don't expect a non-technical person to understand the error, but I do expect a non-technical person to know that what the error message is is useful to the person trying to help you and to proactively provide the contents of the error message, even if it's a shitty cell phone picture of the error.
I don’t formalize anything that extreme for my teams because I can’t diagnose people, but I know that things like anxiety, imposter syndrome and a whole wack of things that aren’t related to work get involved. It’s acceptable to ask for help. I like to know what people have tried but sometimes they don’t know how to start. And that’s a great place to start.
I guess we all have different styles but some may be more inclusive than others.
How the problem and request are presented matter. "I don't know where to start" is a different problem than "I've done nothing, just solve this for me." And how someone shows an effort was made will vary person to person, so I agree a strict formalized set of rules doesn't make sense. The concept boils down to "expect people to put forth some effort of their own"
"Teams" are also going to have different dynamics than "strangers on a help forum."
These kinds of principles are sensible at their core, and I am a big proponent of the mindset, but the main problem as a sibling comment pointed out in a way is that this assumes that everyone is striving for an honest and accurate correlation between display of effort and value, and that everyone is looking deep enough into and behind that display to recognize the true value behind it. But actual effort, let alone value, is not always clearly visible or honestly displayed, and the perception of it is also subject to your own biases.
You could say that people have the responsibility to demonstrate that they put in the effort and created value, but then you get the situation where people naturally optimize perception of effort or value over actual effort or value, because in the end that is what is rewarded. Then you can also say that people also have the responsibility to look a bit closer before estimating real value, but that takes more effort and people naturally strife towards efficiency. I would guess that the problem today is that the balance between these two is off, and we're doing too much of the former and too little of the latter.
an honest and accurate correlation between display of effort and value
Hmmm. Your choice of words here has just sparked a realization for me.
Before you said this, I was completely on board with the original post. But in juxtaposing effort with value, it illustrates that we're basing the idea on the Labor Theory of Value. That idea seems intuitive, and Adam Smith wrote about it 250 years ago. But it turns out that LTV is very wrong. Economists showed that effort does NOT impart value.
Labor theory of value is a Marxist idea, not an Adam Smith idea. Internet Marxists sometimes point to a passage in The Wealth of Nations to suggest that Smith also supported a labor theory of value, but this is—in the most generous interpretation—a misreading. Smith says that the value of a thing can be measured by how much labor it can be exchanged for: an exchange theory of value, not a labor theory of value (which says the value of a thing is based on how much labor it takes to create).
I mostly agree with your criticism of my post. I was being generous trying to avoid being inflammatory here, since I know there are readers that strongly support socialist ideas (in the strict sense, not just the "safety net" sense). It was certainly Marx that pushed it so hard.
But researching this a bit, I find that it still predates Marx. I find:
Sir William Petty, 1662: "If a man can bring to London an ounce of Silver out of the Earth in Peru, in the same time that he can produce a bushel of Corn, then one is the natural price of the other."
More important, it seems that David Ricardo (a big name in economic history), in 1817 latched onto what Smith had written and states it quite definitively.
Use value or exchange value?
I’d push back on this, I think people have a very intrinsic sense of what is valuable and often if you think it’s “perception” of value being rewarded, it’s just that you value something different than that person.
Even in performative scenarios, like say someone gets promoted at work over another person because they are a great “performer” and always make noise, whereas the other actually delivers - they’re being promoted because the promotion is defensible and legible for their superior. That is true value for them, just not to another viewer.
I experienced a similar interaction recently, where this principle was hard to apply, when I was emailing with a CTO / hiring manager who had some "deeper" screening questions. It was essentially:
1. HM: AI generated email with "tailored" questions
2. Me: AI assisted response with answers (I confess)
3. HM: AI generated email with a "thoughtful" response + invite
4. Me: AI generated "thank you & looking forward" response ...
Looking back at the thread, I have to laugh and cry at the same time. It's so obvious and sad.
> Someone on HN responding to you with single-sentence responses? Either don't respond, or respond in kind.
"I have made this longer than usual because I have not had time to make it shorter." - Blaise Pascal.
The length of the response doesn't indicate effort.
This is true if you're writing a letter about a difficult topic.
For HN comments, 99.9% of the time, a short comment is a low effort one and should be disregarded.
on the other hand, when I see a long post here I assume it’s yet another ego-driven tirade and skip past it.
> yet another ego-driven tirade
I tried to recall the last time I saw what I felt was an ego-driven tirade on HN comments, and I'm currently drawing a blank. There's a lot of what's called "performative erudition", and there is the occasional lengthy diatribe, but I would call neither one of those ego-driven tirades.
long, low: copypasta; rant; sales; slop.
(brevity, purposeful /s).
For him, the cost of editing was much larger. Condensing your writing in his time meant rewriting it more concisely, requiring strictly more time than collecting his thoughts as he went.
With LLM's, we are in a new state of the world: it can expand any one sentence off hand remark in an essay.
You seem to be talking about how one can expand information into useless babbling, whereas you are responding to a comment about condensing information into true essence.
This is about human attention and what is worth getting it. Both points are very important and valid.
Sure; I was using shorthand. Sometimes a whole edifice of ideas rests on one shaky one; and if you can challenge that one the whole thing falls apart. But even being able to identify the shaky one demonstrates engagement. That's really the key.
There are obvious exceptions to that rule. Laconic phrases are short but have a lot to them, while AI slop is long while having very little to it. But it's a decent rule of thumb when considering the middle of the bell curve.
Couldn't agree more.
> Give a cursory answer
That may be enough in some cases.
Sometimes people are not looking for fully fleshed out high-effort answers. They want a pointer (to documentation, or a repo) to get going from someone more experienced.
Google search may throw up too much information and it is hard to make a choice. A one sentence answer from an expert may be enough to set them on the right path.
From the other side, there have been brief tutorials for many years about how to ask useful questions in a technical forum. Making hundreds of other people fish for details about your case is poor form.
https://www.freecodecamp.org/news/how-to-ask-good-technical-... is a pretty good example.
Going back more than two decades is ESR’s “How to Ask Smart Questions”. http://www.catb.org/~esr/faqs/smart-questions.html
AI has collapsed the cost of producing content while leaving the cost of reviewing, verifying higher imho. This has inverted the economics of collaboration. Reviewer attention, not output volume, is now the scarce resource, this happened with my engineering teams (PR reviews) and is now happening in my world in Product.
In some cases there's also no preparation or verification happening at all, which massively inflates the productivity gains of AI. Lots of VCs and investors asking companies to move into "trust the AI" mode.
I once consulted for a company in the content marketing business that was one of the largest and fastest growing startups of its country. The content production in itself was "cheap", a dollar for 500 words. But it collapsed, due to the unbearable amount of people required to review
Now virtually all content is generated by AI and the old customers don't have anyone to verify anymore.
Companies are made of people who are shitty to each other but trust machines blindly.
This has been my policy for a couple of decades. When somebody posts just a bare link (especially if it's to a video), I refuse to click. If it's not worth your time to introduce why something is relevant, then it's not worth my time to go figure that out.
> Either don't respond, or respond in kind.
!
<https://quoteinvestigator.com/2014/06/14/exclamation/> ?
> Someone on HN responding to you with single-sentence responses? Either don't respond, or respond in kind.
Or, depending on the context, perhaps give a thorough enough answer with citations that it should either answer questions on the topic fully or explain where anyone interested in the topic can do their own research, such that if the question is asked again one could just link to your previous post.
This might not satiate a poster if they're dumb enough, but it's worth remembering that the post will be searchable and usable for reference by other people.
Yup. The most concise version I've heard of this, which I find useful for many situations, is:
"If it isn't important to you, it isn't important to me."
"Use your brain before you use mine"
It takes considerable energy to train models and run inference. You can't dismiss AI generated content as "low effort", but you can dismiss it as a wasteful diversion.
That's like saying that low effort human-generated posts are worth your time because the phones and computers they're writing on take a lot of time and effort to build from scratch.
The person copy-pasting an AI response is generally not the person who trained said AI. Even if the total amount of effort is fairly large, the amount of effort put in by the person you're actually interacting with, is generally small.
Back when people would train Markov bots on IRC that was actually something novel for the first 30 minutes and you could appreciate it because they put in the work
You can’t take credit for other people’s work to displace the absence of your own
Way to miss the point. Bob on the other side of the room didn't train the model
@dang it's too bad the most interesting single comment in this whole thread is grayed out. as much as i love reading the same thing written 1,200 different ways, maybe the whole system needs to be revisited
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 I have been thinking. It's not that I reject AI content, but it takes _effort_ to review and weed out any mistakes. When your thoughtful reviews that take an hour(because the PR is typically large, and you want to be _right_ when you're pointing out a hallucination) gets an AI-generated response with AI-generated amendments, It doesn't feel _nice_. I feel dismissed and it has continuously trained me to subconsciously avoid his PRs. After all, the team is fully onboarded with AI, so it's not like there is a lack of PRs to review.
It looks like the sentiment isn't just isolated for me.
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 place meaningful guardrails on LLMs, and help them maintain a reasonable quality bar.
> 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 mix in unrelated drive-by fixes? How easy is it to deal with you once you have received comments? Do you address them promptly? Do you give your reviewers credit (if not praise) for their help? Do you give back by doing code reviews yourself with high quality feedback? There are lot of things you can do to streamline things and give code reviews the place in a teams workflow that it deserves.
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?
> 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
> 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.
Yeah, that's fair. I have spent most of my career on high-pressure teams within FAANG, where we aggressively managed-out anyone who wasn't making the grade. And now in the startup world, we apply a very aggressive hiring bar.
I'm not sure how much I'd enjoy working on teams who were routinely producing PRs that were in bad shape.
How many teams did you see?
On your original claim, I have seen engineers put up 5x more PRs simply because they paid less attention to the quality or put less thought on each one of them.
I have seen people put up 5x more quality PRs too. But as long as they follow the good practice of doing a code review for every PR they put up (or 2 if you require 2 per PR), they got their stuff through quickly as well.
> your process ought to catch both of those well before the PR stage
We have multiple points where mistakes of any sort can be caught, and code review is one of them.
Yes, most architectural issues should be caught earlier, but some will only become evident in code: some by the dev themselves, others by reviewers.
This is only a problem if you mostly catch architecture issues at code review phase.
Not my experience and especially for juniors reviews were an excellent tool to learn and get mentored.
> But for high quality work [a code review is] indispensable.
The argument here is that all code reviews are done with attention and care, but quality of a code review is highly dependent on the reviewer and the team’s review process, and in the real world the quality of reviews pretty much follow the same distribution curve as, say, agile project management: For the time invested in reviewing, a handful of teams get excellent utility from them, most teams get little benefit, and a sad few actually cause harm.
If most code reviews provide only a little benefit at base for most teams, recommending that most teams should also delay shipping quality work is going to sound a lot like bad advice.
> 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, “<<slaps roof>> 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.
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.
I agree about how you can reciprocate for a good code review, but I'd just add that for me, code review is also fun — when done for a fellow human who I might be teaching.
It is definitely very grunt-like for an LLM.
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.
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.
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"
I have seen many a PR where it is obvious it is an exploratory work: eg. figuring out how to use an external dependency that is imperfectly or incorrectly documented, etc. (You can claim this should be done ahead of time, but experience tells me you need to code it to learn it)
The emotional toll there is real, but this is exactly the moment when you expose the knowledge of that external dependency to the unbiased party that is the reviewer.
I like combining approvals to satisfy the urge for completion and closure, with a request for fast-follow refactor to better match the newly discovered model of interaction. (The worst code review experience I have seen is when a reviewer accepts it as-is and does a fast follow refactor themselves, depriving the author of the opportunity to learn and remain an expert in that area)
A discussion ahead of the implementation can also bias the two parties to that discussion and have them overlook the same implementation issue: many things you only understand once you start implementing.
If you have these parties review each other's code, I agree that rarely brings much value.
I think the best way to understand our experience with reviews is to stop and say: in a few sentences, what do you expect out of a quality code review? (sounds like nothing in your case, but I am curious)
Agreed. But those things are not mutually exclusive.
Agree. All the subtleties of how a high trust environment work are hard to enumerate
Depends on the change. Certainly most PRs don't need feedback before the PR is ready - the task is too obvious, and there's little to feed back on before there's any code.
For bigger changes, of course you need feedback on designs. But that could easily be in the form of draft PRs.
I definitely would push back on anything that required feedback before PRs. That's way too much process. Just going to slow you down for no benefit.
> 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
> I've worked with people who consider themselves 'prolific humans'. Someone always has to tidy upp later, and its never them
I run both infrastructure and security - that means a lot of relatively self-contained PRs to infrastructure-as-code and dependency management systems. I'm also the team lead, which makes me responsible for a lot of throwaway prototyping, as well as cleaning up anyone else's mess...
Yes, the prolific-but-damaging engineers are all too common in corporate. But particularly in startup land, you tend to find your high-performers wearing a lot of hats at once.
My experience is that it's even worse: they've already produced enough code that the codebase matches their taste and theirs alone.
So in essence you have one guy working at 4x and e.g. four other getting just 0.7x - net effect is still positive, but everyone save for that one person is miserable.
Mind you, the 4x dev doesn't necessarily have to be particularly talented - they only need to get their foot in the door before anyone else.
Back during the ZIRP days you could immediately tell that this is the case in a team by staff rotation alone. Nowadays people understandably cling to their jobs, so you might now know until it's too late.
> … and its never them
IME, it’s because they lack the experience to have the Taste one develops as a senior engineer. “This works, and is somewhat understandable” is as far as they get. Little to no understanding of how this solution could fit better in the codebase.
There's also those that burn themselves out, and John Carmack!
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 rationalize performance differences by demeaning others, this says more about you than the prolific people.
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.
Sure but if PRs get rejected, nobody has to "tidy upp (sic) later".
That's not prolific, that's just producing slop, with AI otherwise.
I'm just tired of developers pretending that low output is some sort of silver bullet for quality, and high-output is automatic slop. Neither are true. In 99% of cases, low output doesn't correlate with anything positive. High-output can naturally go either way, but slop doesn't make one "prolific".
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)
As someone who often submits significantly more PRs (without using AI) than teammates, it's not exactly a skill delta. Yes that helps but it's often only a piece of the puzzle. The other ingredients include motivations and culture. In such cases, something else is the driving force, such as posturing for promotion, stability, etc. My current team is massively low performing. Management pays some lip service to all the problems, but also runs things in a way that discourages high performance. It's not a good fit for me, as I want to tackle challenges head on, improve the environment, be productive, embrace change. I'm also very comfortable with the code base as well as the code review process, but I'm surrounded by "seniors" who do not know how to code review, and who are happy to drag their feet and spin their wheels for months before pushing out small PRs that hurt my brain. How can that little work be shown after months, barely functional at best?
We had better management for a few months, and many on the team were actually quickly closing the skill gap with me, but we had another shuffle and things are stupid once more.
So I'd offer that's option 3. (There's always a third option to any suggested either-or fallacy.)
It could also potentially be that GP is making atomic PRs, while everyone else is just making 5000-line PRs with multiple responsibilities that just gets merged with "LGTM".
But of course HN has to with the most uncharitable interpretation.
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.
> you place all burden on high performers
If their PRs don't get merged they don't perform. It is trivial to overload your coworkers with secondary tasks due to your "high performance".
> If their PRs don't get merged they don't perform. It is trivial to overload your coworkers with secondary tasks due to your "high performance".
We're all aware that a huge portion of the busywork that makes a team successful is not actually reflected in their upwards-facing deliverables (increasing test coverage, improving infra, adopting new tools/methodologies, preemptive security patching, etc). Your actual high performers, if you have any, are doing all that stuff in addition to their regularly-scheduled duties.
If management weren't at least tacitly on board with this arrangement, your high performers would go work somewhere else. So my experience is that good managers don't tend to see this your way.
Yeah I agree. I was trying to makee the point that it is quite easy to make yourself blocked by others and it is a deep skill to get other stuff done while blocked anyway, like say cleanups and tests etc.
To make myself clear:
Reviewers have comments which were not addressed by the PR author - author not allowed to do other work.
No such comments, especially no reviews - author can do other work.
I have been championing this mindset since well before LLMs. It is an admittedly controversial opinion, but one I hold strongly.
Code reviews are a productivity tax. No truly effective team would rely on them. The fact that so many software teams view them as indispensable just shows how few effective software teams there are in our industry.
They are akin to a quality check step in manufacturing. Part of what Deming did in revolutionizing manufacturing was eliminating the step in favor of a holistic quality metric owned by all participants and enforced with rigorous statistical process controls. As you say, we in the software industry have all the pieces (autoformatters, tests, benchmarks, etc) to operate this way, but it seems our organizational and management dynamics combat this shift at every turn.
Relevant: When this conversation comes up at work, I like to share Avery Pennarun's post about the review tax: https://apenwarr.ca/log/20260316
> owned by all participants
How does this work in practice? In my experience, any metrics owned by a group inevitably languish and are largely ignored.
Anything you want to improve needs a DRI.
As a prolific PR author, I've found how I communicate has a major factor on how well and quickly people respond to PRs. I've recorded my lessons at https://epage.github.io/dev/pr-style/.
I have always considered Kent Beck understood this the best, the scaling for code reviews as you go to reduced release timeframes is to pair program, that brings the number of people reviewing it down but also increases the understanding for the reviewer. Comprehensive end to end tests are more a replacement for manual quality assurance for regressions.
I am not sure there is a good analogue for reviews in the AI world. The human operating the AI should obviously review everything produced but that is clearly not as good as a second pair of human MK1 eye balls from pair programming.
No need to pair program, you can always send a message to your colleague about the design of the upcoming code, especially if it’s going to impact them or if it’s an area that they’re more familiar with. Waiting till a PR for feedback is wrong IMO.
Code review is not for feedback, it’s for ensuring quality (many eyes on the output) and have a shared involvement in the evolution of the code. The time for feedback is earlier, once you have an idea of the solution.
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?
The functionally correct code could be rejected in PR for many reasons other than style:
1. Solution under-engineered/over-engineered. 2. Code is hard to read or comprehend. 3. Design/Archtecture lacking. 4. Principles decided upon by team not adhered to.
These are just some of the reasons I've rejected functionally correct code before.
To summarize, in any software engineering course you learn that there are other metrics used to evaluate code other than correctness (maintainability, readability, scalability, portability, efficiency etc.)
As said already: readability and maintainability of the code (closely related) are two most important values a code review can get you.
If the correctness check was vibecoded there's a good chance it was cheated. So maybe that, on top of the, you know, code review (see the sibling comment).
While PRs may have been used to correct style, that shouldn't have been their only or even main purpose. That's on whoever was using it that way, not on the concept of reviews.
Code architecture and technical design. You can have a solution that works fine, but are too complex or will impede future changes. Maybe you have code that has already been solved or your variables’ name are too generic. Maybe your modules are messy and your data structures are not modeled well.
vibe check
> 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.
You have some assumptions here
> first step should always be to run an AI against them
What if they write an agent which takes the feedback and resolves them with a new commit. Which again didn't do anything other than offloading more to humans who are reviewing.
> 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.
This assumes AI reviews are correct most of the time, if so, why do we need even humans. Why not have repository level code reviewer which is run immediately after code has been created?
regardless of where you move it, there is still a bottleneck: humans.
If you don't remove them, you will just pass the ball between agents and at the end of the day human still needs to review it.
> 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.
>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.
Either you were a head above the rest of the team and had the intellect to produce high quality value adding work, or then you were the "move fast break things" type of guy producing a lot of extra liability and work for others.
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 last few weeks. I'm a lot more comfortable saying "no" with a list of concerns when I suspect the code is AI-generated, and I see others doing the same. CLs that would be sitting around for days because no one wants to be the first to say, "this is bad, don't do this" now get quicker feedback.
The good thing is this feedback doesn't feel like as big a deal as it used to because people are less personally attached to code they generated in 30 minutes vs. code they hand crafted over a week. I had at least 2 LLM-generated PRs that were complete, correct, tested, and pre-reviewed by me, but I got feedback that they were going in the wrong direction. This would have been 8 hours of wasted effort a year ago, but now it's just an extra 30 minutes to rework the direction with LLM assistance.
> 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.
I get this feeling, too. I do however think the onus is on the developer to make something reviewable by their team members if they want a speedy review. Stacked PRs, scoping things down, properly structuring commits so you can review commit-by-commit for example.
I also think that "I spent a bunch of time on this" is not a valid reason for expecting an approval. It should hurt if you've produced a bunch of code that is way off target, even if it ends up implementing the feature. That's how I learned at least.
A proper way to go about large projects, in my opinion, is the same as with software development at large. Fail fast if possible. Draw up a crude boxes and arrows sketch or just discuss how you want the code to integrate with whatever already exists and invite the team to comment. If no one has anything to say, well then they can't complain later when you implement that approach. But if anyone cares then most likely valueable input will come that makes the end result better.
If they put effort into the code- they will put effort into guiding the reviewer through it.
Like : Here is the ticket, this was the goal. I set out by beginning here- but encountered problems x y z I then refactored to accomplish. Finally..
You just dont drop a blob from orbit.
Ironically, ai could generate that quite well from existing documentation (ticket, tasks and prompts) + https://marketplace.visualstudio.com/items?itemName=vsls-con....
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".
It’s good that clankers are not afraid of throwing away code. The biggest problem with code generation (that is version controlled) is maintenance. It’s better to throw away questionable code rather than say eh, we don’t quite understand this part (and our agents can’t make a compelling story about it) but we spent a lot of effort on it and it apparently works so we better keep it.
.. only if you know what the code is doing, though. Often the requirements get scattered and lost to the winds and the code is the only record of its own idiosyncratic behavior. And yes, someone's depending on the bugs in it.
Fight fire with fire: point copilot/claude/codex to review their PRs. Prompt "Review the PR#XYZ which is vibe coded and presumably low-quality. Find all problems, big and small. Team guidelines at docs/conventions/styleguide.md, docs/conventions/architecture.md, docs/conventions/principles.md. Post inline comments to github".
Run several rounds of such reviews until the clanker fails to find problems.
And what do you do if that works?
Because the problems AI causes are fundamentally problems of good design. It has the same problems of large teams, but less politics. Do your design well ahead of time, and AI review, or a large team, will amplify what you can do. Potentially by a lot.
Do it badly (or like most companies: do it with bad knowledge of the problem or just don't do it at all) and both team and AI will make a mess of things. If the team is made up of inexperienced programmers, they won't even complain, in fact I've seen teams that like this to be happening. At least in AI reviews I've always seen "grumbling" (in the sense of what you might call mean comments)
It sounds like one potential interpretation of his behavior is that he values his own time more than your time.
I wonder if that's occurred to him.
Everybody values their own time more than other's.
The fix, imho, is for the reviewers to also use ai to review the code. However, the ultimate responsibility for the outcome(s) should be on the committer - you commit it, you own it, so to speak. If there's an incident, they need to be the one paged in the middle of the night. Bugs resulting from it will land on their desk.
The reviewers aren't a shield/safety net.
Speak for yourself. I highly value other people’s time, to the extent that I should probably value my time higher than I do for my own sake.
Doing something that wastes other people’s time or makes more work for them than necessary makes me feel awful.
I’ve always worked in a way that respects other people’s time and I always tried to make sure I did everything I could to minimize the work I’m asking someone to do for me.
Well its obviously infeasible as during the time of the incident it is not yet known what is wrong and who caused it.
Is it even actually good to get to a point of blaming someone for an incident?
> Everybody values their own time more than other's.
This is false, you’re just oblivious to people who grew up in conditions that would make them that way.
AI and companies reward sociopathic behavior. When he eventually complains to his boss that his work isn't being merged and it's been done for days/weeks/months that will filter up and look bad on the people holding him up.
At that point then disable merge checks and let them merge without a review. If there is a problem it's on them
This is my current strategy, it's working great. Half the team has been fired for slop and the other half got fired for not doing anything.
I'm sure this person's manager knows that having trouble getting PRs reviewed can (but not always) be a signal of a deeper problem. It could be that no one one the team knows the domain, it could be that no one like the person, but most likely it's that the PRs are frequently bad and no one wants to bother.
Or, I might say, why review the PR. Get Claude to do it? Why do I need to spend my time and attention and this person does not?
Well, what's the solution here, he should ship less stuff?
The solution is that he spends more time scoping the size of the PR so that it’s reviewable and understands the code he’s submitting well enough to have discussions about it. And that he does so human to human so that they can come to mutual understanding.
Less WIP is better for the throughput. If you saturate all the review bandwidth you're just wasting your time creating more PRs, the time would be better spent helping others get their PRs merged.
> Well, what's the solution here, he should ship less stuff?
The solution is in the title - he wants human attention, he needs to demonstrate human effort.
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.
The solution is to merge more of his PRs on the condition that he takes at least partial responsibility for any resulting problems.
That's not how anything works. Even if he says he's going to take responsibility, when the customer call comes in at midnight you're going to be the one fixing his problems.
The reviewer gets to merge the PR so their name appears on all the great new features and they are credited for them. That would end his unfair behaviour of dumping effort onto other people.
OR - he gets a review for every review he does.
I often hear people say lately, "why should I bother to read this, if you didn't even think it was worth writing?"
I've been thinking about this in art. Is it the end result that matters, or the process of creating it?
I once saw a hideous sculpture. Didn't like it at all. Then the video zoomed and I saw that the whole thing (quite massive) had been hand-built out of individual toothpicks, and suddenly I thought it was amazing.
Perhaps an even better example: I read a story of a man in india who carved a passage through a mountain, so there would be a shorter route from his remote village to the city. He did it by hand and it took him 20 years. We seem to have an instinctive admiration for heroic effort.
In business, generally only the end result matters. Although, the end result also includes the client's perception of how the product was made... (see also: fake fairtrade etc.) In a meaningful way, the perception, the story, is reality.
Part of art is the process of creating it. It’s not just the physical artifact, nor even just the completion of the final product. The inspiration, subject matter, the consideration of form, the initial concepts, the redesigns, the meaning or emotion the artist tries to impart, the beauty of the thing, the skills employed and further developed during the process, the choice of materials, the use of perspective, and how the work is presented are all part of the art.
I don't think it's a matter of process vs end result. I just want to feel that a human with taste judged that it was worth my attention.
If a human put some effort into it, that's a signal.
This is mostly what it is for me too. We're all awash in an information deluge, and we need heuristics to keep from drowning. Human effort, proof-of-work if you will, is a heuristic that helps with the AI-generated part of the deluge.
Your boss cares only about the end result. Good engineers care about the process too
> Is it the end result that matters, or the process of creating it?
One of the main reasons that art is valuable is in its ability to communicate emotions. Good art has the ability to serialize emotions within the artist and deserialize them within the mind of the viewer. It's not just "wow, this is a pretty picture", it's "wow, this is how another person sees the world, and now that I understand that, I feel an intimate connection with them".
> Is it the end result that matters, or the process of creating it?
I think this comment misses the point. Let's forget about AI and assume that there are three developers: A, B, and C. Now, A is supposed to make a PR, but instead they describe it to B, and B writes the code. C reviews the PR and gives feedback. A passes the feedback and the responses between B and C.
As you see, this is not easy for either B or C, and A is totally useless in this scenario. When you replace B with an LLM that doesn't get tired or bored, only C complains about the process.
I like this rule of thumb: Spend more effort producing the work than it takes for someone else to consume it.
I like this rule and hopefully adhere to it myself often enough.
I can't imagine working for a place that has a big bucket of PRs that either get reviewed or languish for some amount of time based on who feels like reviewing them. I'm not saying there's anything wrong with it, just that everywhere I've ever worked, there are expected features with priorities and timelines and some project manager or product person breathing down your neck to get them out the door.
In big software teams, the bottleneck is team communication. I've run big and small teams. If I want to speed things up, I remove people from the team. Everything gets easier. This has worked amazingly well every time I've done this over the past decades. Removing people doesn't have to mean firing them necessarily. Splitting teams is a good reflex. But of course the people you remove from a team are typically not the best performers. I was discussing this with a friend of mine who runs a small company. Exact same thing. He reduced the team size by 1 and the velocity went up almost instantly. This person was a bottleneck in the team and was slowing down people around him. After identifying the problem, solving it unblocked the rest of the team.
This was true long before AI. With AI the difference is just a lot bigger. It exposes team inefficiencies quite mercilessly. We have a big glaring issue with the current AI tools not being to suitable for usage by multiple users. All interactions are one on one. Which means hand offs between tools and people are bottle necked on people communicating with each other. So, any issues there with people delaying, gate keeping, etc. become very visible.
The sentiment of pushing back on AI is understandable but probably not a productive reflex. We need to find more effective ways on staying on top of massive amounts of changes. It's not going to slow down and insisting on manually reviewing all code is not going to be a long term sustainable way of developing software. It simply does not scale. I'd question the added value of manual PR reviews at this point. Are they finding real issues? Are we valuing those issues correctly? Could we come up with automated ways to find and fix those same issues? There are a lot of open questions about how we are going to do this. But no question about the notion that we need to up our game on this front.
Efficiency is not magic. Its bounded. Above and below limits the environment can sustain it, systems will destabalize. If All the Great White Sharks magically get more efficient at hunting over night ecosystem will collapse. Individuals and teams have never scaled at this speed to the levels they have. And there is no signal at system wide level that a sustainable limit has been crossed. So People will happily believe things are getting more efficient at individual/team scale while at system scale things get more fragile. This is why we ended up with central banks deciding interest rates and controlling money supply. Before that any one could print cash. They all thought they were great efficient geniuses. The chimp troupe us not prepared for stuff that effects the entire system.
I’ve been making Codex and Claude get their work reviewed by most recent best performing model of their own family, and each other’s, for months.
On top of that, we have been running multi-model AI reviews on every PR through their respective GitHub integrations (Codex, Gemini, Copilot, Greptile, CodeRabbit).
They never fully overlap, and yet they somehow usually all miss the same things. The most significant improvement came from having agents commit their plan along with their work.
On the upside, it means I get to focus my reviews on different things.
Honestly, we should make a world that is enjoyable and productive for humans. Not relentlessly optimizing for agents.
> I'd question the added value of manual PR reviews at this point.
Yeah, why not reduce the team size to zero while you are at it?
These generalizations about software engineering have never been useful, IMO. Context is everything, there is no flow chart for building a perfect software process.
Although, I'd say you are absolutely delusional if you think we are universally beyond the point where manual review of pull requests is required.
Make the team size one person. Thats the fastest you can work. Zero means no work, and not doing anything is the quickest solution.
We can also slow down (or keep old pace) and still ship quality.
A bit sick and tired of arguments like yours
> About six months later, it is his frequent bemoaning at the standup that their PR don't get reviewed, languishing in inattention
What irks me the most with this new trend is when people don't review the code themselves thoroughly enough and you're pointing out obvious flaws that you know that they should be aware of. LLMs can be such a great tool, but it's unfair to make people review your code before you've even seemingly looked at it yourself.
I think we're too nice sometimes. If a coworker has been sending stuff to review that's taking me more time than for them to create, surely that's an opportunity to discuss this?
I wonder if there is a tool that could equally waste their time. Like the worlds most pedantic code review bot that just gets the PR raising bot to spin wheels forever.
That might teach those people a lesson.
An interesting question to him and management might be what his own role is now and whether he's still needed. If he's not doing any reviews then you could yourself directly prompt the code and review.
The question I’ve seen here is responsibility. If you submit a PR that means that it was your best effort, and you’re willing to stand behind it to some degree. With AI, some people, when the scathing review comes back, just say “haha look at that stupid AI.” The reviewer might just as well run his own AI to do the review, but it may make huge errors as well. In that scenario, who is held accountable when there is a big bug or it degrades the quality of the code base?
Ultimately what it means to be a professional is that you are responsible for your work. That’s why you get a salary instead of being paid by the token.
Have you spoken to him about this? If he's clueless enough to send AI responses to human messages, he's probably clueless enough to not realise why people don't do that.
Better yet, get Claude to speak to him about it.
Fight fire with fire. Ask Fable to conduct an adversarial /ultareview of their PR and send the same wall of text back to them. If there are excessive defects, ask them in standup if they actually reviewed the PR themselves before sending it. If there aren’t maybe they are on to something. I think like in law, the human submitting the work is responsible for its quality, not the AI.
> Ask Fable to conduct an adversarial /ultareview of their PR and send the same wall of text back to them.
This won't help. Your wall of text will just get fed right back into the LLM.
This is the point where you decide. It used to be low stakes and easy to care about the job you did for other people.
Do you want to put the same effort into your job when nobody else does, or should you reserve your thoughts and just feed it back into the LLM?
The LLMs are being advertised as output increasers but companies so far are using them as excuses to fire people instead of creating previously unbelievable things. It might be better to feed your coworkers output back in and use your thoughts to start the company you thought you never had time for.
It will help if your wall of text cost less tokens than theirs, they will run out before you do if you have the same company quota per person.
I'm not sure what the right vocabulary would be to describe this, but this sounds more like the calculations behind nuclear war than a healthy collegiality or cooperative work relationship. This sets up a competition to determine a loser based on resource scarcity, not a way to achieve mutual goals to advance the organization's goals.
You are thinking of "game theory" and it's what happens when your coworkers don't give a shit. And all it takes is one, both because they can degrade product quality faster than you can gate it or fix it and because the performance assessment techniques are about 3 years behind the state of LLMs and if they play, you have to also or you'll get shit on from such a height you won't even know what hit you.
And once you start playing the game, then one day - it doesn't take long - you wake up and ask yourself if this is how you want to spend 8 hours of your life monday through friday. I think a lot of us are saying no but now need to figure out where our money is going to come from. I don't have the answers.
In a previous job, we had this saying "killing penguins" we used when referring to throwing more computing resources (more GNU/Linux instances) than necessary at a problem. In today's landscape of indiscriminate AI spending, I bet we could repurpose the term to mean "actually negatively impacting the arctic biodiversity".
We are all throwing penguins at each other.
When someone submits PRs fulky made by Clade any "cooperative work" is out the door
“Token Standoff.” The most efficient token consumer wins. This mutually assured time efficiency destruction is driven by management support of aggressive use of AI in an attempt to, in some combination, increase productive and constrain labor costs.
AI isn’t making developers more productive – it’s making them busier - https://leaddev.com/ai/ai-isnt-making-developers-more-produc... - June 11th, 2026
https://en.wikipedia.org/wiki/Brandolini%27s_law
Mutually Assured Distraction.
Caveman consume fewest token win office token war.
Also, make sure your wall of text prompts Claude to be extra verbose to really burn through that quota of theirs.
Now I'm wondering how hard it'd be to zipbomb their context window?
(And _now_ I'm wondering how hard it'd be to forkbomb their agentic workflow?)
More like they will climb even higher on the lighting-dollars-on-fire leaderboard.
Try to automate the adversarial PR review-rebuttal loop "for productivity", so the back-and-forth between the AIs can run over night.
What I don’t understand is what value is the person adding to this equation? Put another way, what’s the difference between them feeding the wall of text to the LLM, and you feeding the wall of text to the LLM, bypassing them in the process entirely?
The role of the person in the equation is to take personal responsibility for the proposed change and review the changes prior to PR submission. You can't put AI on a PIP. It's acceptable to use AI as a coding assistant in 2026, but if a human is not reviewing what they submit and taking responsibility, their value is on par with a ChatGPT subscription.
Peer review, in this case, “did you use AI to review your change and address its feedback”.
It helps in that it offloads the code review burden you'd otherwise be doing.
As a last resort, do the code-review with a live pair programming session.
If they can't explain their own code then it is by default a bad pull request.
At the end of the day, everyone's time is being wasted on tokens and on the increasing cognitive complexity of AI generated code.
So if they say "idk Claude did it", what would you write in the PR review box?
REJECTED: Engineer does not understand what they wrote.
> Engineer does not understand what they wrote.
"""""wrote"""""
Feels like the title of a blog post someone will write
Ah, like this one? https://crabby-rathbun.github.io/mjrathbun-website/blog/post...
The same as if they said it was copied from stack overflow, or if it’s wrong; “I think there’s a problem here, it’s XYZ”. If your peer ignores you and you were wrong, it was their call to make. If you were right - take it to them or the manager depending on how many times it’s happened.
A teammate that can't write (or at least, can't explain) "their own code"
Actively drags down the morale and productivity of their team (because everyone is getting flooded with AI slop PR's)
AND costs far too much money relative to everyone else doing actual work? (token usage)
By god they sound like management material
"Author of this pull request has not yet reviewed code and does not understand it. This PR was submitted prematurely, probably by accident.
Please, check whether you accidentally submitted other unreviewed code - and close such PRs for now and reopen once reviewed."
Don’t ever write this in a professional environment. It’s childish ant achieves nothing other than pissing off the person it’s targeted at and probably the manager who now has to deal with a shitty behaviour complaint.
> Ask Fable to conduct an adversarial /ultareview of their PR and send the same wall of text back to them.
Not necessary. Use Haiku.
The response doesn't need to be good, it just needs to be substantial. Presumably the goal here is basically DoS of the problematic colleague through token limits.
Use DeepSeek or MiMo. You get best bang for the buck on your response.
I mean frankly this should just be part of the standard process. By the time any person is looking at it there's no reason it should not have gone through an AI review.
It's not always feasible of course but I think there is real, worthwhile discipline in trying to get change requests small and it matters more with agents. It's very easy to let it balloon into gazillions of files and lines.
I improved a similar issue by writing custom instructions for copilot that give it enough context to do PR reviews that are only 30% BS.
I asked other team members to run my custom instructions to perform a review with copilot before they submit...
Of course no one is doing it. It looks like the PRs I get are still straight from copilot. So I tend to run my review prompt. Cut out the 30% BS issues it "finds" and the rest is good.
why leave comments intended for your human colleague when they will only forward them to the bot?
why not speak directly to the bot yourself instead? then you can drop pretenses and get to the point
I find this to be a new variant of the old behavior where a colleague comments on a typo in a PR, and the team later moans about laborious back and forth for small nitpicks, instead of simply editing the typo right there (and perhaps leaving a note that they did so)
yeah I have this happen to me. I occasionally get screenshots of claude sent to me!
I had this happen to me twice. The first time I ignored it, second time I responddd with “I could have asked ChatGPT myself but I asked you”. Never happened again.
"why are you such a drag on team morale?", "why are you invalidating your colleagues learning experiences?" "Next time you do this, HR will have to step in" etc etc.
There's no justice in this world.
I’d you’re not willing to stand your ground and have a direct conversation with your co worker then there’s no solution to it.
Because it doesn't matter what you say to the bot. You might as well have a conversation with yourself about the PR.
The bot isn't making decisions. It's not choosing to submit extensive PRs with bad code. The colleague is the one who needs to actually learn something here, and the problem is that confronting him about it directly is widely considered to be bad form. This is, of course, a deeply unhealthy aspect of our corporate culture. We need to be more open to honest communication, even when it's either uncomplimentary of one of the people involved, or counter to the prevailing opinions within the company.
let's take the two stories to management:
"I'm writing tons of code, and the process is stumbling where the guy whose job it is to review code isn't reviewing it."
"I'm not reviewing code."
Sometimes I wonder: how does someone go and think so much about their coworkers, and never once think about how they themselves look?
Even if I sympathize with the people complaining about their poorly chosen GitHub-based workflow - whose purpose is to let pull requests languish, for the most part - and how they stumble when overwhelmed with solutions. It's obvious to me, that the people who complain the loudest about the anti-sociality of LLM authored code in their precious harmonious low-effort workplace status quo: they are projecting.
Imagine you are a restaurant reviewer. Your job is unquestionably to go to restaurants, order and eat food, and write a review. The restaurant's job is to provide you food to eat and review.
You go to a new restaurant, and order some dishes, and one of the plates your server brings out is a big ol pile of dog shit.
Who's being anti-social in this situation? The restaurant is doing its job and all they're asking is that you do yours. On the other hand, you have certain expectations about what you order from the restaurant and they're not being met. Who's anti-social?
He's not bringing you a pile of dog shit. He's bringing you some food he went to the restaurant next doors to get. How do you review it?
I cannot think of a single actual food critic that would consider it acceptable for a restaurant to serve a dish for review that they went to the restaurant next door to get. If the critic wanted to eat at/review that restaurant they would simply have gone there instead.
His point, exactly.
what is the point? this whole restaurant analogy is completely fictitious and happens nowhere, and the scenario i'm describing is happening all the time... why not just talk about the not imaginary scenario?
So he’s redundant. You call Uber Eats and you don’t pay a salary for that.
The person who "writes" code is also supposed to review their own work, and answer for that. If they won't do that - well - they should be fired. But if you have weak or uninvolved leadership, then the team's only rational recourse is to shun them.
It’s much more effort to verify that code is correct than it is to produce it. This is the case even for human-written code, and now that we face a torrent of ok-looking probably-usable AI generated code, the problem is compounded infinitely.
If someone’s using AI to generate a large quantity of actually-tested, actually-good code then that’s one thing. If they’re generating a fire hose of slop and demanding that others do the actual human time-consuming work of validating that code then that person is the problem. It’s hard to tell which is the case here.
why not just approve the PRs with little more than a cursory glance?
One of two things will happen:
1. Things start breaking, proving AI generated code sucks and the individual spamming these PRs is incompetent.
2. The code works fine and reviews are unnecessary for anything other than liability concerns.
Some of us actually take the "engineering" in "software engineering" seriously.
That includes taking responsibility and accountability so that the software doesn't become a sad and dangerous mess.
If we want to be an engineering discipline, just yoloing in production is not going to cut it.
This no longer works when bad faith actors will push code straight from LLMs with little review, and respond to your comments with LLM responses. They will constantly leave you with the responsibility of verifying the output. You are the human in their loop. This is a brutal asymmetry. In the past, at least you knew a person probably spent more time handwriting code than you will spend reviewing it. This no longer applies, now the reviewer can easily spend more time than the author.
Oh but it does.
The thing that makes it scale is to default to "no" and require the other party to convince you of "yes". Just put the burden of proof where it belongs. If they don't manage, then that's their problem.
Communicating this in a way that is viable for a business scenario certainly comes with its own difficulties, but that is a solvable problem.
In fact, you can use AI to stress test your communication there. Just throw what you want to say at the AI but don't tell it that it is you who wrote it. Then tune the input until it stops saying that you're the problem and starts agreeing with you.
Highly recommend. It's a perfect emotion-driven cargo-culting normie simulator that never calls HR on you.
Did you not read what I said, they will use LLMs to spam proof onto the human reviewer. Just endless replies with LLM generated answers until you yield and approve the PR.
Because we're all on call for the service, and tragedy of the commons exists. That coworker isn't paying the cost, everyone else is paying a fraction of it, and it builds over time.
just fire him lol sounds like a nightmare
Human PR review is a process smell
This would sound crazy in 2025 or prior, but I'm on board.
It's silly to have humans reviewing code that a human didn't even write.
This 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 review, and based on the issues I find I doubt they are even looked over first beforehand.
I understand that the information may be accurate, even helpful at times, but feeling like I'm constantly talking to an AI chat bot all the time gets tiring. And I don't appreciate having to double-check everyone else's AI generated responses for them.
I've seen this, too. There is a workplace personality that sees the job as a 2-player game between themself and the corporation. They think the game is to min-max their effort to personal career benefit, and they don't care how much it inconveniences anyone else.
Before AI they had to actually put in work, or at least play games of trying to steal credit from other people without getting noticed. Now that AI appeared, they see it as the ultimate way to take credit for work they didn't do: Put everything into Claude, let it do the work, copy and past output back to someone else. Minimum effort invested, maximum visibility achieved.
It will continue as long as they think they're getting away with it. If managers aren't willing to intervene, or worse if they encourage this due to the volume of output that seems to be appearing, it's only going to get worse.
I’m conflicted after reading this comment, because I think I would be that personality in my workplace, largely because I believe that’s the only sane position to take as a worker with ~0 power over the decisions made that can entirely destabilise your life.
On the other hand, my priority isn’t maximising my personal career benefit, but the collective benefit of my team, so I suppose I either see it more as a 2v1 sorta game, or perhaps my “player” is an amalgam of myself and my teammates. Playing this way, outsourcing everything you do to an LLM is the worst move, because you lose the touchpoints that tell you where the friction is in your team.
I think everyone should be looking to balance their work effort against the payout of the job. They should also be changing jobs when the effort to reward ratio starts to become unfavorable compared to other jobs on the market.
The problem with the personality above is that the person isn't playing like a team (like you said) but as an individual maximizing their own visibility while loading their coworkers up with the review effort. They found an asymmetry to abuse (they generate text easily, coworkers get a lot of extra work to review it). They don't care what it costs their coworkers. They just like that it makes them look good.
> They should also be changing jobs when the effort to reward ratio starts to become unfavorable compared to other jobs on the market.
The problem here is that all tech companies look alike. Take for example the interview process (copied by almost any company out there that thinks they are google). Another example: the under/meets/above expectations BS. And now the most recent example of “token usage as sign of productivity”.
So, it’s getting tremendously difficult to simply switch jobs that offer something different
My experience couldn't be more different. The tech companies I've worked for in the past 10 years have been so completely different from each other, from interview process to company culture, that I can't agree that all tech companies are the same.
You can also look to change to different roles (product management, even sales) or jump to a different career completely.
There are options if you look. You're not going to find a dream job that pays $600K for 4 hours of no-pressure work per day and perfect coworkers, but there are a range of job options with tradeoffs along the compensation-effort pareto front.
Whenever I try to articulate this issue to people during more casual AI discussions, I always refer to “study guides” in college.
I don’t know how many of y’all did these, but I’m sure I wasn’t the only person. At my undergrad it was very common for a group of students to all to get together, compare notes from lectures and readings, and basically come up with a group study guide of sorts. People were given specific sections to share, you didn’t just send all of your notes - usually 2 people per section’s take on that portion. You could always tell who just copy and pasted their shorthand (usually indecipherable) and who actually took the time to edit it/clean it up. This was at a time when almost everyone did it on laptops.
The people who took the time to make their portion(s) digestible for others were asked back, the others weren’t.
If you're self aware of this, you're probably already ahead of 95% of others in similar shoes.
That is their job. Their job is whatever gets rewarded, and that's what gets rewarded, apparently.
Instinctively I think the move is to ignore it. I guess that would look different in different contexts.
Obviously you have to communicate with your coworkers. But I think the solution has to essential be: "Im not going to read that."
Either that, or call them / walk up to their desk and pick a point from the wall of text and ask them to explain what they mean by it. Then watch them turn red as they have no idea what the message they sent to you means.
I think you're over-estimating how much some people care.
I have had coworkers say "Oh I don't know, Claude added that" in response to questions like that without even a hint of shame or self-reflection.
Sure, some people have no self awareness. In that case you can change your approach, if you are a manager or otherwise invested in the company you can put pressure on them to increase the quality of their work and to own the things they submit. Bring up specific examples of poor quality work, errors in documents/messages, etc.
Or if you don't care you can just ignore this persons messages.
I got sent a 6-page spec document with a footnote that says "this spec was created with AI, so it may have nonsensical sections. Feel free to fix them."
I had someone submit a PR that was 3000 lines of shell scripts. Totally useless crap. I tried repeatedly asking him why he made particular choices and it was so painfully obvious that he had absolutely no idea and was just inventing bullshit answers. I would rather he have just said "I don't know, Claude added that", then tell obvious lies to my face.
And that's the point where you can stop to hide your true opinion, no? "How am I supposed to review a thing the supposed author didn't even read or understand himself?"
I tried this when my skip level boss sent us a wall of text from ChatGPT that didn’t make any sense. He didn’t care. He said it was “just an idea”. He likely spent all of 5 minutes on it, while we spent a collective 15 hours dealing with it, before finally going to him and calling it out.
He’s sent a couple more emails like that since. I don’t even bother to read them once I see the format.
This feels like a BOFH response but I'm strangely not opposed to it; If you generate something, you should own it ... regardless of what tool you used to generate it.
I told something like “your value lies in reviewing the output yourself before sharing it, not in calling Claude. I can also use Claude.”
I've had a colleague call it out 'Is this AI slop? Please write your opinion'. I don't think I could do that myself, but I really appreciate that they were drawing attention to it
Management, responding to someone who takes your advice to "ignore it": "So we've noticed that there's this guy who is doing tons of work, and you have chosen to do no work?"
Communicate with your boss. "I'm ignoring this guy's slop because he's spewing slop, but not actually doing his job, and if I stop to deal with all of it, I won't be able to do my job".
Yes, "not actually doing his job". If he's sending you un-reviewed, un-filtered, untouched AI output, that's not doing his job.
And you also have people who out an idea in ChatGPT or Claude, come back with bunch of documents and think they have created a business.
I hope he's thought out his next vocation, since he's so eager to automate his current one.
100% agreed. I've shared output I didn't fully understand, didn't feel good good about it, and now I really try to digest, understand, and be able to actually talk about it if I expect other people to do the same. I hope in time your coworker comes to similar realizations.
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.
Suggest to him to automate what he's doing.
I can't imagine my opinions just being AI slop that I've parroted. Surely you embellish just a little? Claude's so often bone-headed about things, this horrifies me. Gemini's worse. Even when the model agrees with me, it starts making me wonder if I'm not somehow wrong.
I had a new colleague on the team, who I had to on-board. I gave him a few simple tasks, just to get him into the whole setup. He literally copy/pasted my task description into Claude and asked it to complete the task. To begin with, I didn't suspect this, so when he asked for more help, I gladly wrote up a detailed explanation with more information and detail for him to learn. Little did I know, he never read it but put it directly into Claude. Not even sure how I should handle it, but my first instinct was to get extremely annoyed.
Maybe this is just how things are going to be. But in that case, I'm done spending my time being a helpful idiot talking indirectly to a robot through another person.
I always get "Foreign Object" by the Mountain Goats stuck in my head wheb I deal with people like that...
(Track 31):
https://themountaingoats.bandcamp.com/track/foreign-object-j...
> Not even sure how I should handle it, but my first instinct was to get extremely annoyed.
My first instinct would be to have a /very/ direct conversation with that person and their manager, and the follow-on would be to escalate it further leading to their termination. That sort of behavior is unprofessional in the extreme, even in the era of AI.
> Not even sure how I should handle it, but my first instinct was to get extremely annoyed.
Have you watched Frieren? Just keep a distance from them.
https://frieren.fandom.com/wiki/Demon
"Demons are deceptive by nature, and typically speak with humans for a specific purpose, such as securing mercy or lowering vigilance. They treat language as a tool, using words without truly grasping their meaning. ..."
It surprises me how many people have voluntarily relegated their entire job to LLM Prompter. If your work is indistinguishable from that of a machine, what’s to stop your boss cutting out the middleman and using the machine directly? I would have thought that people would be trying their hardest to prove their worth in this new world we’re in.
I actively support “my boss” to run Claude Code. I offered them to help and made jokes it’s so easy these days they might as well just call Claude Code themselves. I’ve shown I could plop in their documents of feedback and Claude fixed the issues.
I have worked with non-tech employees to set up Claude to help them do small tasks. I’ve helped to review and improve completely vibe-coded projects by such employees.
I’m not sure what my role will be, but I fully embrace that my traditional role of writing code is gone.
I, for one, welcome our new AI overlords...
Well, if everyone is telling you they want you to adapt AI, then it's rational to see just how much of your job you can get it to do for you.
It's even worse when everyone around you is using it. How can you keep up? Companies face the same dilemma: investors, competitors, and users already use AI and have factored it into their expectations.
AI is supposed to make people 100x more productive. We know it doesn't because nobody remade Windows in 6 months or Photoshop in 1 month. It's just memorized more common cases, that's all. You used to not be able to oneshot a three.js game, now you can, but that's only because it's memorized more three.js games, not because it's more intelligent.
Keep up with what?
We've already established that most of it is noise. You don't need to keep up with producing noise.
Even if there's a lot of noise there's clearly something real there. People are shipping more working products than was previously possible, they're debugging faster than was previously possible, and various other things. I mean you can go fishing for things to confirm your skepticism if you want but it's pretty clear to me.
Sure, but that doesn't mean that you can't filter signal from noise.
So the actual problem statement is not "how do I keep up" but "how do I correctly tune my filter", which is solvable.
The biggest challenge there I think is that many people are not prepared for just how sharp and uncompromising that filter needs to be, but that too is solvable.
If you're not going to experiment at all you're not going to be able to do that. Agentic coding was basically a joke the first time I tried it. Now it isn't.
You seem to be arguing against something I did not say?
I don't know man, claude fable literally exceeded my expectation and its totally not a noise
feels like its becoming reality that we as a human don't need to this anymore
having worked in tech and now running my own company..
the honest truth is that maybe 10-20% of SWE (at best) are “good”. sure it is harsh but i won't lie. if you're good you'll probably relate.
the rest kind of suck.
i’ve never gotten anything lower than Exceeds Expectations in my career so I’ve seen how awful some engineers were. i’ve seen how amazing a tiny minority were and i made them my mentors.
these days i have a simple policy.
if they cannot think, they are fired. why waste resources (time and money) on someone who can’t use their brain? i’d rather give AI credits to someone who uses their brain.
thinking is the humans job. the ai needs to execute on what the human thought of, improved, planned.
Everybody talks about finding that mythical 10X but in my recent hiring experience it's more like there's a whole bunch of 0Xs and the trick is finding the actual 1Xs among them.
This!
All my experience in trying to hire developers has been wading through an endless stream of people who were just useless.
Me: I want to represent a 2d grid, what data structure should we use? Them: A string?
This was someone applying for senior engineer. Others I've had filled their CV with SQL related acronyms. But couldn't explain what a foreign key was and then stubbornly insisted that at their current corp they would never ever use foreign keys in their SQL database!
I've had senior engineer when asked how to check if we had a 2d array with an item at x,y tell me if anything is on the same column or row, they couldn't do it, couldn't even verbalise how to approach it.
"Web Developers" who didn't know the difference between GET and POST. Web Developers that have never heard of PUT or what it would be used for.
I have a question I usually ask which is "How would you convert a Julian yyyy-ddd date string to a military yyyy-mm-dd date string?" (I explain how a Julian date works if they aren't familiar with it.)
The answer that almost guarantees I'll hire you is "there's got to be a library function for that, so I look in the manual". Almost as good is somebody whiteboarding how they'd convert ddd to mm-dd (and then account for leap years, etc.)
I get a disturbing number of people who say things like "I would communicate with the person asking for this to see what they're really intending blah blah"
My favorite answer was on a phone interview where he just hung up and wouldn't answer when we called back.
> I get a disturbing number of people who say things like "I would communicate with the person asking for this to see what they're really intending blah blah"
Sounds like they know this question is a “gotcha” question but just misinterpreted which direction you were going with it.
Some will ask a question like this expecting you to treat it like a puzzle and outline how you’d solve it as-is; others ask it as a way to probe how you’ll deal with strange or misguided requests (the case you noted as disturbing); and others yet will ask it to see how you’d practically solve it (your intention).
Seems like a bad interview question without context regarding kind of answer you’re looking for.
No, it's a pretty good interview question because it tells me if somebody's instinct is to reinvent the wheel or not. What I didn't expect was how many people couldn't say how a wheel even works.
People are not generally answering interview questions based on instinct, but rather based on what they think the interviewer wants to hear to get the job. I would have interpreted this is as a leetcode style algo question and started by treating it as such, even though IRL my first instinct would be "get a lib that does it". Awful, awful strategy.
It appears that either answer would be accepted, and so I'm fine with it. If it really is there is one correct answer then I'm against this. This feels like a problem where a good enough solution can be done in the time of an interview if you do it by hand (though if anyone knows about dates they will expect there is a lifetime of fixing special cases left if you don't use the library)
I prefer fizz-buzz as a question because it is obvious there isn't a library. It is also a problem you should be able to do in an interview. It has enough weirdness that there is no best answer, despite having several workable paths you could try.
Nope, not remotely awful. I've made great hires from it, which is its point.
Its not. Any interview question where you are looking for a specific answer is already suspect, but especially if you don't properly provide context for the question in what you would expect, things become a shit show.
If you would ask someone to write a piece of code, and a part of the problem is this conversion, then you would be right to expect they reach for a library, but even if they don't you would be giving them the opportunity to explain themselves, and judge the explanation, not the answer. Also, if your test is "does this person reach for a library at the right time", you could do a lot less esoteric and confusing by just asking them to add 10 days to a date. If you just ask this one specific problem, it is likely they assume you are looking for them to demonstrate the skills involved in actually solving the problem, i.e. leetcode.
This is also why some people give you the blabla answer, because it is indeed very unlikely that someone needs to do this legitimately. This is because its a toy problem. Someone's professional reaction to the problem in isolation should indeed be: this is weird, I've never been asked something like this, what's up?
Finally, even though the question is terrible, I would still rate the "whatsup?" response higher than the "leapyear" response. I would want a developer to triple check that this problem needs solving, before they would solve it themselves.
Finally finally, if there's one answer to one question that, when answered trivially in a way literally taught in most basic programming courses (use the standard library / a third party library), makes them a "guaranteed hire", I also have significant doubts about the level of talent you are bringing in, as any experienced interviewer will tell you that qualified people will get important questions wrong, and unqualified people will get important questions right.
I understand that this reaction might be quite harsh, and I know better than anyone that its hard and time consuming to do good interviews, but please consider that you are rejecting people who may be very confused and sad by this way of rejection.
But that's why the context of the question is important. It's not clear from your comment, but I'd give a different answer if the question was strictly academic in nature (reinventing the wheel) or focused on practical work realities (use a library).
Even using a library isn't that practical. It may be the zeitgeist in JavaScript but that doesn't mean it's actually a good idea. Nobody remembers left-pad? If you're writing Java or Python then checking if your date class can already do it is a good idea.
> My favorite answer was on a phone interview where he just hung up and wouldn't answer when we called back.
Heh ... yeah well I wish I had it to do that.
However, you are asking gotcha questions.
Someone else said it on HN a couple years ago...Something about how there's no such thing as a 10x engineer, but there are a LOT of 0.1x engineers and a few 2x.
The absolute worst is someone that tries to brand themselves as a 10x engineer by constantly using programming terms like "dynamic programming", "polymorphism", "recursion" and the like, but they're really a 0.1x engineer because they don't truly understand what any of those are and when they should actually be using them, and so try to shoehorn them in when they don't need them while also not understanding them, and end up writing low-quality crap.
Took too long for management to get rid of that guy.
Also now is it 1x in individual productivity or >=1x in team productivity. As anyone multiplying teams productivity by less than one is bad. Probably lot worse than actual 0x.
Someone who produces absolutely nothing and have no impact has cost, but is still better than someone who produces net negative. And the people who solely act as interface between LLM and whatever might fall to later category.
It's the Pareto principle of course, as well as the normal distribution. Many firms have been able to succeed in the market just by hiring only good engineers over average ones.
yeah but these days it is even more important to filter out bads
and even at "good" companies you have people who can game the system to get in, and then they struggle to get anything done on time or be responsible for taking on and completing any initiatives bigger than a single task on a bigger scope.
Indeed. You really need to find people who don't want to play politics and instead get stuff done. I'm still not sure how to hire for these sorts of people in the age of AI, where people even cheat in interviews. Maybe probation programs? Have multiple people work for a month or two and cut those who don't succeed.
this is what I've been doing, and obviously I have a startup so I need to double-ensure that I don't onboard any bads. you can start people off as contractors too.
I still think a single in person LC style (doesn't have to be LC per se, could be domain specific) logical thinking/reasoning exercise is useful. I want to ensure the person can actually put 2 and 2 together and think. This is just a fast filter.
If they seem like they can think, then I like to do 2-3 systems design interviews. I'll try to give them something related to things I like, such as graph structures, writing a complex query that needs to be dynamically generated, or something related to infrastructure or how they'd do something that I've already done. After all, this is MY project they're joining.
So far that has worked well.
Few more things -
I like to test if they are a humble type (they can work on a team putting ego on the side - the mission is our number 1 priority). if they say they know something that i know and asked, then they can be sure I'm going to drill them on it. if it turns out they lied, i'm not wasting more time. Thanks for your time, take care. This is very important to me. Just say you don't know, it isn't a big deal because ever since like 1994 that has not been an issue. You can just learn things online, and AI makes that even faster. I am never afraid to say I don't know something, and I've asked plenty of "dumb" questions (while doing some due diligence first) so I don't really mind.
Can they handle information overload? I am the type of person who has multiple branches in my head of actions I can take next, so while I may appear stressed I'm really not. Can they keep up? Our goal as software engineers should be to come up with solutions that solve the problem in a way that makes building on it simpler in the future. My goal is simplicity and effectiveness. So I'll see if they can keep up, and eventually reduce the work to be done into atomic pieces. This is a fun exercise because it is collaborative and we get to bounce ideas fast back and forth.
Finally, I like to let them use their favorite tools, including AI tools (codex, claude, some ppl have esoteric custom stuff which is cool), to solve a problem together. It might be code related, it might not. Really depends on my mood. I like to see how they work and what sort of output they can come up with. This filters out people who only ask AI stuff, instead of having some framework they've already developed to be effective.
Honestly I don't know how to scale this process. I'm not really going to feel bad either about firing fast, ultimately this is a business and I don't want customers to suffer because we have some issues internally.
At the same time, I wonder if I even need to build out an org with 100s of people. That was an inefficiency (look at all the layoffs), and it is traumatic.
If I can find a few great people who can be supercharged and turbocharged and electrified with AI, then they can take on & own bigger responsibilities. My number 1 goal is to ensure they're with me on the mission, and after that all things seem to sort of fit into place.
Firing fast works both ways. If I joined your company and I thought you fired someone too fast I would leave, not because I might get fired, but because I've seen where that kind of leadership takes things.
thats fine you can leave. it’s probably for the best for us. that’s why the mission is so important and requires a great filter.
mass effect 2 is my favorite game ever. it is all about putting together the team, and ensuring you work with each one of them to get their whole loyalty.
each member is a badass, in their own regard. it’s also a video game and it’s linear unlike real life. but the mission is super important to me.
and when others have their own passions they want to express and carry out via fulfilling the mission, that’s super key imo.
so far it’s worked out fine. people get the fast firing thing. they know if someone isn’t onboard with carrying out the mission they also don’t want to be burdened.
like we are seriously helping people in an underserved industry. it’s insane.
i hate working with mids and bads, they are going to bring everyone else down. so i want to work with the best people i can get. they don’t need to be MIT grads paper weight types. they just need to be mission oriented and focused.
Might not be solveable. At some point the effort in finding that someone might be larger than the benefit you get from just using the second, third, fourth best. Or using some flawed approximation hiring mechanism. There's just so much noise now. And it hits the good job seekers too.
What I find strange is how rarely LLM output is distributed alongside the LLM input, especially outside of code repos. Why can't I rerun the prompt that resulted in your work next year, when models have gotten better? Are people ashamed of their prompts? Ashamed of having used AI? i unno
Prompt used to generate this message: "Create a comment for Hacker News which bemoans the lack of AI prompts being shared with the stuff it creates. Speculate on the reasons and create a call for engagement. Use quantum hyperthinking. End with a typo to prove your humanity."
FMFL. I'm going to build a paper-based social network where non-handwriting is prohibited. Like in the 70s.
You should. Then I could start my SHWAAS business offering unbreakable encryption for it.
(Shitty Handwriting As A Service).
There are handwriting physical bots too, or even AI image generators for "handwritten" text.
Most of my AI usage amounts to "read this ticket and do the work", the ticket documents the requirements, a better model could, I suppose, do a better job?
> Why can't I rerun the prompt that resulted in your work next year, when models have gotten better?
Because you could also just point the better model at the generated code and tell it to improve it, so why save the prompt too?
Because improving a high schoolers project is probably not as good of an idea as giving the original task to a senior engineer.
If the high school project has been improved by many engineers over a few years it likely is complex enough that a senior engineer cannot rewrite it for a reasonable cost. It isn't clear if next years models will be enough better that they can rewrite it for a reasonable cost. If they are they can probably extract the requirements and special cases from the code.
Following my analogy, the high school project would have been continuously extended by high schoolers passing the project on from class to class each year, rather than "improved by many engineers". The "engineers" (future models) don't get the project until currently models have had their way for a while. I think that makes the "rewrite from scratch" plan a whole lot more compelling.
I think this is a gap in the tooling (Git, VCS, and forges) and the Zed people are working on this
https://zed.dev/blog/introducing-deltadb
For your next prompt, tell it to end with a hateful and offensive tangent to prove its humanity, since LLMs have those "safe guards".
I don't know if writing the URL will get me banned but someone had this idea for licenses at plus<N word>.com
In any human relationship, nobody wants to be the one who noticeably makes more effort to communicate, keep in touch, resolve conflicts, and so on. The idea of reciprocity and fairness are deeply entrenched in our minds, and that of many other social animals. If they don't care about me, why should I care about them? It's the iterated prisoner's dilemma again – freeriding is equivalent to defecting.
I'd say it's because we're tasking ourselves with dumb stuff. No one half-asses building a shelter that keeps their family alive, or throwing a new favorite bowl on the pottery wheel. But instead of that we're writing posts for Facebook etc etc so we can (???) profit. So of course we want bots to do this all this dumb stuff, and of course we get dumb results.
For some things, yes. But I'm half-assing some really cool stuff right now. Made a scraper to pull my city's meeting minutes, agendas, recordings, made transcripts. Regex for "Flock", found every mention, passed those files into a cheap model (DeepSeek V4), had an understanding of who in my city is down with building the surveillance state and who isn't. I've got research on everyone, and had emails drafted for each one based on what they said. Quotes and figures and all. I lightly polished each email and fired 'em off. Already got some replies back. Plenty more in the quiver too (pulled and analyzed CSVs of FOIA'd datasets).
If they're gonna spy on me with AI cameras, I can oppose them with AI research. :)
Did you use some stuff like https://github.com/CouncilDataProject or roll your own? Been curious about how to integrate local knowledge like this since local news seems to have lost the niche.
I rolled my own. I hadn’t heard of this one, but I looked into stuff like OpenStates (now privately for-profit owned, ugh). My city just uses a Wordpress site so it’s structured enough. I’m looking at building something to ingest cities with Granicus and one other big local government meeting recorder via API whose name I forget. That should get decent coverage. There’s no way to catch the long tail of every local government’s recording process. Some cities people will just have to do manually. But it’s easy enough with LLM help.
> I've got research on everyone, and had emails drafted for each one based on what they said. Quotes and figures and all.
Please tell me you did the work to validate that the quotes and figures were not made up by the cheap model. These things make stuff up all the time, you absolutely cannot rely on them without validating the output yourself.
https://arstechnica.com/staff/2026/02/editors-note-retractio...
https://www.loweringthebar.net/2026/06/its-finally-happened-...
Yep, I manually listened to the meeting recordings (easy to find the spots based on the transcript timestamps) for any quotes. There are also meeting minutes and agendas with supporting docs to corroborate against (e.g. for dollar amounts). They really don’t make stuff up all the time if you root them in data.
Love this. Thanks :)
You created the surveillance state to fight the surveillance state lol
Edit: it's a joke people
Nope, I used a minute fraction of the technology they have, along with open records as is my right in this country, to stand up for my Fourth Amendment right to travel without creeps stalking my every move. I need to make my specific framework a bit more generic and then I'll put it here on HN. Or just offer a platform where people can bring an OR key and it can run on their city.
I grant the lol-concept, but citizens monitoring their government is extremely different from governments monitoring their citizens.
Citizens monitoring their government is literally THE foundation of democracy (ok, maybe voting comes before it, but then you have to monitor who you voted for to see if they’re doing what you voted for).
THE foundation of democracy...
...is "Rule of Law" IMO
Indeed. One is expected in a healthy democracy, the other is essential for a totalitarian state.
It used to be called journalism
We just need bots to read all these facebook posts and then we can put the phone down and go back to doing something real.
My last post [0] has proof-of-work: video evidence of my physical notes. How many people are willing to draft a complete essay on pen and paper first?
[0] https://abner.page/post/are-we-harold-bloom/
Ah this is clever! Feels very cosyweb. I'd be delighted if not caught on
David Graeber's Bullshit Jobs in action.
I was just thinking about this. LLMs are nothing if not easy litmus tests for identifying bullshit jobs.
Play silly games, win silly prizes
Oligarchs gotta pay rent on those data centers somehow.
The serfs will till and sow the server fields!
Yes, I worked with a guy (not for long) who had two modes of interaction:
"it didnt work" - providing neither the code nor the error
"I ran this" - dropping 500 lines of code into slack, not specifying where he ran it, what line it broke or what the error was
Either mode required 15 iterative questions to get to a useful state of information.
A couple of weeks ago I essentially failed the Turing test (took to be an AI). I found it a bit annoying, so I built Possibly Made By A Human. It tracks your keyboard use (not the content, ms between keystrokes etc) and produces a signature for you. It can of course be spoofed, but that also takes some effort.
Actually made by a human, signature: https://possiblymadebyahuman.com/7PuEdZs1i1
This is one of the coolest tech things I've seen in a while. Can you explain how the "Check a document" works? I'm not sure I understand how you would check if the timing aligns based only on the text content.
Thanks! I had a lot of fun doing it.
The signature includes a hash of the text, done at the browser so that the server does not have to see the content.
Ah, okay! Would you mind explaining what does "comparing wording, not exact text" mean?
It's a very poorly written way of saying that instead of storing your text it uses a hash of your text to sign. When you want to check the signature you only need to hash the text to check, again without touching the server.
a solution waiting for a chrome extension :)
I wrote it! I just haven't told anyone yet (nor tested it :-) This is a fun side-project, I don't have much time to play with it.
https://chromewebstore.google.com/detail/possiblymadebyahuma...
This 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.
This isn't unique to code or AI. In creative writing courses, we were asked to give thoughtful critiques of (human written) stories and excerpts, and often I felt as if I were doing more work than the original author. If you can't be bothered to review your manuscript, or at least run it through a spellchecker, why should I waste my time on it?
If the agent does everything for you it means it can do everything for the next person. At that point you're replaceable and have no value in your field. Learn things deeply even if you use AI because its the deep knowledge workers that will keep getting hired.
> Learn things deeply even if you use AI because its the deep knowledge workers that will keep getting hired.
The problem is that this realistically is only applicable and actionable to a subset of the labor pool, and that subset is decreasing.
There are a lot of people who discovered that their "deep knowledge" and "deep skill" wasn't as deep as they thought (read: "deep" enough to make them irreplaceable to their employer). People are generally pretty good at overestimating their value.
Right, like I hope your deep knowledge wasn't something you can just ask Claude!
The depths of knowledge required to beat Claude will only grow with time. "Deep" knowledge will become everyday normal knowledge, and will eventually offer no competitive advantage whatsoever. Continuous education takes a lot of effort and money, and returns are ever diminishing.
I mentally switch off the moment I see an AI vibecoded landing page or article or video
I don't care what your offer is - if you can't even be bothered to even dress up your stuff for me, a human, I'm not going to consume it
The volume of LLM output is effectively infinite. Therefore, it is not worth my time or effort reading a single syllable of it. I will not read (nor correct) LLM output, since if I did, I would quickly be doing nothing else with my life. And since LLM output is infinite, but I am finite, my efforts would still be completely without results, comparatively speaking.
(6 month old repost: <https://news.ycombinator.com/item?id=45936352>)
I thought this would apply to marketing / SPAM.
I find that I actively filter all "computer generated" attempts to contact me: Mailing lists, "engagement" notifications, ect, is pretty much ignored. I only respond to human-initiated contact.
This is especially the case with cold outreach from recruiters: I get a lot of poor AI-generated outreach from recruiters, which are time-consuming on my part to engage with.
At one point, I was thinking that if any of my customer send me a snail mail with an actual physical stamp on it, we will call the customer immediately and solve their problem.
And no one has mentioned Rovo yet.
Atlassian's in-built AI assistant for JIRA will generate a task description with a complete SDLC task breakdown, requirements and deliverables.
While the person creating the task will need to provide some details and modify some of the generated text (if they bother to read it) - the sheer verbosity and the fact it's clearly generated just makes you not want to engage with it.
There's a lot of art out there that is totally uninteresting, at least to me, because it feels like the artist put little effort or thought into it or or maybe even into honing their skills.
But if the art instead beems with intention and effort, chances are that it will be interesting. And in order for anyone to create something so brimming with signs of effort, they must have cared about the piece, the message, the artform, or something along the process. This post talks about effort and attention, but you could phrase it as a question of reciprocal "caring". If you want me to care, show me that you even care yourself.
It is getting harder and harder to suss out what is genuine though.
He was handed a gameboy before he could walk, but it didn’t lessen his humanity. He was handed a smartphone before middle school, but his humanity remained intact. He started calling the “people” he met on social media his friends, and humanity didn’t suffer. But alas, using AI is a bridge too far.
Love the principle, preach!
I think I've been following this subconsciously as LLM artifacts reached some threshold of pervasiveness across the work I do. If I can sense (maybe eventually I won't be able to because of how capable the technology becomes?) that what I'm reading is wholly regurgitated out by an LLM, I automatically care less and feel inclined to respond in kind by generating an artificial response in return.
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.
Good rule to apply to companies too. If someone sics AI on me through their customer service line, I feel totally free to sic AI right back at them
Why should I bother to read something someone else has not bothered to write?
It really depends. In many cases, you absolutely shouldn’t.
In some however, you should. For instance, yesterday I sent a lengthy email in a language I barely speak threatening legal action against a business. I had an LLM translate/write it as it’s a language Google translate makes a mess of, every time.
So in that case, you’d be advised to read it lest you end up in court.
Did you bother to read the resulting translation?
If you are operating a business in a part of the world where you expect to engage in the court system, you should hire someone that is fluent in the language spoken in that part of the world to act on your behalf. If you cannot afford to do so, or refuse to do so, why would anyway take your legal threats seriously?
I've been writing technical documentation and architecture docs that no one ever reads for years. I now write those same documents using ai in a fraction of the time. No one reads those either but they are memorialized so that no one can bitch about tribal knowledge.
I interacting with others, I still read through the entire post and its arguments.
And I write my replies before, I often have a LLM check for any errors or miss thing.
LLM can help me catch blind spots or mistake.
I think LLMs can't replace our own thinking. For me, an LLM is good tools for discuss ideas and talk me more knowledge.
My english is bad, but can help the LLM tto translate paper, help me quick get the infomation.
I like face to face talk with others, Can help me triggers deep thinking and funny
A somewhat related experience: I asked for advice on Twitter about something and got two unhelpful AI-generated responses (from accounts I have never heard of / don’t follow) and no human responses. The thing is that I already asked multiple frontier AIs the same question and didn’t get a satisfying answer. I specifically went to Twitter because AI did not have the answers I was looking for. Providing an AI answer to a human question assumes that the asker hasn’t already done their homework and tried asking an AI.
If someone manages to devise a way to prove something was written by a human they will make a lot of goola
around my workplace we say if you're copy/pasting llm output, you're indicating an llm can do your job.
This isn’t sufficient, it needs to be “if you are asking for assumption of accountability, demonstrate human effort.”
In my experience, people who make requests like this don’t care about your attention, they only care about getting you on the hook for something. Your application of attention as a requirement for that is irrelevant to them.
I use AI as an editor on informational writing all the time and it's good at pointing out flaws in what I wrote. But I don't really love reading a document that's obviously in the voice of Claude if you're asking for my opinion on it. But it kind of depends on the writing -- a change request description, most people are too lazy to do better than the AI would, and there are other kinds of documentation that normally just wouldn't get done. But like for a design doc where you're asking me to pore over it now even though I don't necessarily get anything out of it it's distasteful when I see phrases that are obviously from AI.
We just agreed on our team that we’re not posting AI-generated text into comms with humans.
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 added to our PRs. So now I'm sometimes getting hallucinated BS responses from "human" reviews.
This makes me absolutely SURE that the general public is fucked and that we're going to start seeing huge AI generated fuckups on a regular basis. If people in this industry, basically experts compared to the general public, are misusing this tech in such seemingly obvious ways, imagine the ways non technical people will misunderstand and misapply it. Of course, with the help of overhyped BS from everyone hyping and selling it.
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.
Yep, it's bad. It's too easy to press the publish button without double-checking the outputs. Programming has always been about discipline, and now it's even more so.
Yup, I always phrased this as “if you can’t be arsed to write it, I won’t read it”
<begin devil's advocate>
This is extra work on human.
Many artist and content creator is now asked to show the "behind the scene" or a full session recording, which nobody care enough to check. This is frustrating and demotivating the artist.
Expect the same demotivating effect on the software contributor.
If you think reading _forwarded_ AI response are cheap, you can run your own LLM. It is the same amount work on you
</end devil's advocate>
This has been my rule since the moment generative AI hit the scene. If you're not willing to put in the effort to create the thing, why should I put in effort to consume it?
Related - this was posted in march: https://stopsloppypasta.ai/en/
If the requester stops applying common sense, the reviewer has to apply more of it, and there's a finite review budget. I will deal with requests on a lowest review effort-first basis, just like you did on the other side.
This is just an old engineering principle of work amplification. For an input of x you shouldn’t routinely do nx. If you do you’ll get flooded. Debounce, throttle, load shed, improve throughput and latency. Lots of solutions. Just map it to the problem and apply.
In the past you had coworker who produced volumes of code. Same principle.
(Human) Attention is all you need.
> For human code review requests, I always review my AI-generated code first.
I remember a time in the ancient past (2025 maybe) that your PR was your responsibility, whether or not you typed it with your meat fingers or cranked it out of the Giant Plagarism Machine. It’s absurd to think that the above quote is now something approaching controversial.
That's not correct. If human attention requires human effort, that forces human effort all the way down the chain, with no machine output being possible.
You can't say "you can't feed me machine output directly". Machine output is meant to reduce the cognitive load for human processing.
If your colleague is forwarding AI output directly to you, that means they think the AI has reduced the cognitive load for you, and also you are the best person to process that output, instead of them.
You just need to change your perception about the purpose of AI.
More and more I'm generating AI emails, often to people outside the company and often to do with technical issues / integrations we have / APIs. So far I don't think the people I'm emailing are really using AI as human responses are, well, lacking. What would be great is new email conventions for different communication pathways.
If you are doing AI -> Human, then you need to be curating the response and understanding what it is saying, also, make sure its not leaking internal details or committing you to have phone calls/video chats (it does that). This works really well for the most, and humans respond with requested content. Quite often my AI debugs problems with their systems which I know little about. But humans do odd things like send screen shots of logs rather than text (they also leak internal details of their systems they potentially shouldn't). I used to tell people the content is partly AI, but now I just send the curated email without mentioning AI.For AI -> AI you kind of want a hand over document as an attachment to an email. Only thing here is making sure there's no injection of security risks. But quite often instead of getting a human response to my AI generated emails, it would actually be nicer to hear from their AI which could give a better context/details. It would be really nice to be able to go, can you have your AI talk to my AI :) (security is a major issue here)
AI is able to read input from AI. Humans are able to read input from humans. Also AI is pretty good in reading input from humans. So we don't really need AI -> AI. Just output for humans and you are fine. You can still attach details and this is true for both AI and humans. So human output should be the goal for everyone and everything.
tries to pass slop, complains about quality of replies
? you missed the point, ironically showing the problem with human responses :) humans are super bad at providing information, they concentrate on singular things, especially if they think they have a point / suspect they know what the problem is, but if they are wrong their response doesn't have enough to go on, so you have back and forth.
If you are trying to do AI -> Human communication you should be publicly flogged. Don't waste people's time with garbage you can't be bothered to write
Just send them the prompt instead, let them see how little effort you care to place into communicating with them
Or in other words: https://noslopgrenade.com/
god whenever I hear/see "genuinely" I get so triggered
I've thought this for a while, and I summarise it as: If you want me to take time to read it, you should take the time to write it.
its the old rule of reciprocity. If you want to receive something, you should match the effort
Can you tell if its written by AI or not? I will read it once I get the answer
Why this suddenly becomes urgent? For long time we had automatic emails with "thank you" which weren't written by humans, why something is different today?
I found these e-mails always impolite. I knew perfectly well, that they were an automated response that only causes work on my end.
But this HN submission also highlights something else: AI content should be labelled. It is not always obvious that an AI has produced a PR.
It's not just about being annoyed - it's very practical.
If the creator exerted human effort, they'll be able to maintain it. They can take responsibility for it. Even if the value of the 100% AI generated artifact is amazing, and the "creator" of it can't actually maintain it, then what's the point?
It's similar to scenarios I've seen where a brilliant ML person comes into an org, trains a model, that seems to solve an important problem. Invariably when that person leaves the org, the ML model stops being used, the team falls back on older / technically worse methods. But the team can be responsible / own it in a way they couldn't the brilliant one-off work.
I have publicly stated that if you can't be bothered to write, I can't be bothered to read.
I once received an internal defect report from my product's QA team. It was long and obvious that what they did was feed the error log into an LLM and ask it to diagnose. It was total nonsense.
I reported it to my manger and stated that I will not have my time wasted this way. She was delighted to have this ammo because we have a long standing beef with our QA for not putting in due diligence. LLMs are like candy for them.
I think the real problem is that AI quality falls short of the wild promises.
Labeling what is "AI" would be like highlighting in an email what I'm obligated to say by HR, my boss, etc. It doesn't make anything less boneheaded.
Human effort was already low before AI and now it's even lower. Garbage in, garbage out.
I think this is because a lot of people think more is more. Wow look at all the detail and bullet points! No one on the receiving end actually wants that though. When I use AI to write, it's to boil it down to the minimum bits needed. I wish more people would use it that way.
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!
Lossy expansion of information.
Nah on the receiving end an AI makes a summary of it.
AI having poor quality is a bad take like over a year ago.
Meh. Just this week, I've had two Sonnet 4.8 agents generate, in parallel, a 2000 line wall of brittle bullshit, and a well architected solution with 20% of the amount of code, to the same problem, from the exact same initial context, and very similar prompts. Come on, they can do poor quality work too.
Depending on what you or another means by "quality", it may not have any at all.
Obligatory Marketoonist: https://marketoonist.com/2023/03/ai-written-ai-read.html
AI generated output is rudeness.
We developers understand this when we are forced to read slop, and most of us recognise it in art and music.
I wonder if we forget that people using unthinking, default interfaces in AI generated apps might start to feel the same way: “it feels like no care was taken here so why should I give it my time?”
> "no"
Sometimes human effort doesm't have to be complicated though (concise communications)
When I read things like this, I wonder how, exactly, people have time for this sort of thing these days.
Lots of companies are led by people who think that GenAI should increase productivity and are going to make damn sure that it is. There's no room to figure out things like "etiquette" for how to pass along AI-generated content to coworkers.
“I forwarded your AI’s email to mine for training and I assume it will be incorporated into future outputs. Appreciate the inputs!”
can't believe meatfingers.com has been registered (dormant)...
I strongly believe any platform that wants to avoid turning into slop pile needs to 1. enforce marking any AI generated content as such
2. allow people to filter out the AI content if they want
3. enforce draconic punishments for violation of 1
We might arrive at the moment where this is regulated by law.
Perfect. I find myself applying the same principle to online discussion boards and comment threads. Humans post a question looking for other human input and get replies saying "I asked Gemini and it said...". I find that ignorant and rude when the context is a request for human insight.
human attention is all you need
Not true for HR. Despite their name, which is a complete mislead - except handling humans as resources -, nothing human exists there, robotic approaches are the norm there.
So feel free to use AI to pimp your resume, they will use AI to process it.
s/demonstrate/perform/g
Now you have to add typos and not use completely standard elements of style that some people have been using for ages, like emdashes and "it's not X, it's Y"
This should be a rule in the advertising industry.
How about reviving key signing parties?
Yes
If somebody throws a slop PR at me, I'd love to review it with them. I'd ask them to take me through it and explain everything until I understand exactly what they did and why. Either it will make them avoid me in the future, or it will open their eyes to how important it is to understand what you are submitting for review. I probably won't have to do it twice.
Maybe this is why generative art never really took off.
That said, roguelikes are awesome. So there is definitely a place for simulated effort.
It did in many corners, there are some interesting designs on r/stablediffusion, and regular people too are using them to make posters and invitation cards for example.
If "putting a random seed into a set of swappable character parts" counts as "generative art" then it sure made a ton of money when people cared about hying NFTs.
Real effort, surely? Simulated reward.
> when [sending AI generated content to teammates], I take care to clearly label what is AI generated
Reading AI-generated text for hours every day, it's obvious to me.
I take care to make my messages easily readable. I don't care if they're AI-made, as long as they're short.
I'm a very verbose person, and if I don't make an effort at being concise, I'm just as annoying as the average AI.
Being flooded with AI text every day has made me appreciate brevity because I'm exposed to so little of it.
With half a dozen people who don't read or listen to half of what the others do, slop + cognitive drift is a bad cocktail.
It's just not as big of a problem on my own projects, because the ideas that get fed to the slop-machine are not that different from one day to the next.
---
> For human code review requests, I always review my AI-generated code first.
For human code review requests, I always review ANY code I submit first.
This is partly because it's the agreed-upon culture where I work now.
And partly because the codebase is not robust enough for slop.
I have hobby projects where this does not apply. I spend half of my time in those projects building hard guardrails.
---
> Keeping AI generated content clearly labeled and demonstrating human effort helps show consideration for teammates
I actually like the shamelessness, because it's honest.
So often this year when I ask "why did you do X?" pointing at a line, my colleague doesn't know.
Because they didn't really write that line, and they didn't really internalise the choices made.
When my colleague sends me a text dump from Claude, I know that my role is just being a sub-agent.
Demonstrating human effort: I'd like to see more of it.
One way is to spend more time owning "cognitive debt" as part of the daily cycle.
Brevity is the big disaster of human-generated text since the rise of the phone as default device and the appearance of Twitter. To discuss matters with sufficient depth and nuance, one often has to write a few solid paragraphs.
If people are now wincing at longform text because they automatically assume it was LLM-generated, then that bodes ill.
To add to this, there seems to be an inability to process metaphor and simile in the younger generations. Likely as a result of the same deficit. They've become very literal, and often mistake anything that's well written for AI slop.
There's a sweet spot between AI slop and 144 characters. I can tell within a few sentences whether there's a human on the other end getting to the point, or an AI dancing around the point and finding 3 different ways to say the same thing.
It is also the soul of wit!
"poisoning the well"
Welcome to the age of slop.
I feel like I live on a different planet to many on HN.. Any time I've dabbled with the current roster of LLMs for work tasks (I'm a game programmer). They are utterly useless, complete waste of time. Definitely not something that seems promising and warrants more time invested.
Big source of my depressive feelings today come from this. I see people online quite excited about AI output, nobody cares anymore. This was supposed to be a tool to elevate the quality of work, not vomit things out and put out fires like Orks trying to land a flaming plane with no wheels.
And kitchen knives aren't supposed to be stuck in people.
This headline has been seeing some popularity. But it's never made any sense. This is just the labor theory of value, applied to documents.
The labor theory of value doesn't work for documents any more than it works for anything else. If I do something that's easy for me, and it's valuable to you, you'll still want it. If I do something that's difficult for me, it will be less valuable to you, because the difficulty I have with it implies that what I produce will be of lower quality.
This is all equally true of automatically-generated documents. If they're valuable, people will want to read them. Whether it was unpleasant for someone to create them isn't a factor.
So where is this slogan coming from? Are people just afraid to admit that the documents they're getting are valueless?
The problem is that I don't know before I read a doc whether or not it will be useful and valuable.
If someone wants me to spend my time and attention on something they have shared, I would like them to demonstrate that they put a proportionate amount of time and effort into its production.
> If someone wants me to spend my time and attention on something they have shared, I would like them to demonstrate that they put a proportionate amount of time and effort into its production.
First: why? How does that help you?
Second: Is that actually true? Do you ever watch videos that a friend recommends to you? Even if the amount of time and effort your friend put into producing that video is zero? Do you ever read anything that a friend recommends? Even if they didn't write it?
How much time and effort, in your estimation, did jjfoooo4 put into producing this article on tombedor.dev?
I think the point is that automatically-generated documents by LLM is lower quality the manually-generated ones or at least guaranteed lower quality than automatically-generated + manually-reviewed.
Therefor if you are not putting human effort on the document it is low-value.
We have seen this before when big data started to be a thing, tons and tons of reports being auto-produced weekly (or even daily), but even if they contain relevant information they are low-value because no one can take action on so much information.
I am offering a product (via MCP) that interacts with LLMs and user data. Every single day I get user support emails to my inbox written by their LLMs with LLM hallucinations. If the user (a human) would have read them before, that would save me a lot of time and anger!
Your post sounds logical at the first glance, but has nothing to do with the reality. The topic title is totally on point! If the user would put human effort in it, I wouldn't get those crappy emails.
If you get a document from someone and they say "I have no idea if this has any value and I couldn't be arsed to check," it's not unreasonable to presume that it probably has no value.
Most OSS should adopt DKMS-style extensions systems so that people can code and distribute their own solutions to problems. Then it doesn't really matter, right? If the end user is using Claude to fix stuff in your shit, extensions make it irrelevant what "code owners" think.
This reminds me of a Pre-LLM-slop era issue I had with a process that a co-worker had created via a shared script that would automate combining many dependabot PR’s into one consolidated PR.
The script was excellent because it simplified the review process for a single repo (that had many competing dependsbot PR’s) and it also happened to do this across increasingly many many different repo’s simultaneously.
Funny thing is, however, that it also created a team dynamic where who ran the script became almost a race because the effort in creating x pr’s didn’t correspond at all to the effort required to review x pr’s.
The optics were also lopsided since the script would operate on the runner’s local machine and so it would have seemed as if the person who made all these PR’s was highly efficient at producing when in fact it was the reviewer doing the majority of the work.
Also reviewing represented a chunk of a developer’s day so it would affect other actual work the developer was tasked to do anyways.
In an agile workplace points (correctly or not) completed are attributed only to the code creator with no points at all being shared by those who reviewed the work, and rightfully so I’d argue because tangentially reviewers can also tend to just click “approve” (or slap a LGTM) without much effort into critiquing a piece or giving a thoughtful review. Why? It slows down the introduction of the feature (the PM won’t like that, why would you slow down the process eh? You grumpy goose), it messes with team dynamic (you may end up offending those who you review, who also happen to be the one who you need to review your work, who then may be petty or worse, mud slow to review your own PR’s), it takes additional time to provide reviews that seem as if you even read the PR or don’t come off as flippant (did you provide examples or a suggested refactor or detailed reasons), and it takes context because you may be working currently on a totally different project (regardless of your experience/authority in the PR’ed repo), so giving an honest review may sacrifice even more time to first review the purpose of the PR and how that lands in the context of the target repo(s) and then sacrifice the time necessary to reorient yourself to the task you previously had in process. With all this…that “approve” button becomes sooooo tempting.
It’s funny because fast forward some of the ways I battle increasingly prolific AI generated material is through GitHub’s CoPilot bot. I ask it to do the review first and when it gives the review there is none of that dynamic because it wasn’t me who levied the criticism and also it’s not me who is trying to block code integration (so no grumpy goose or team dynamics problems). Having a bot do preliminary checks almost does what git hooks did for team dynamics way back when automation of linting, testing, style, etc was introduced as a common part of the review process. And I say “almost” because a)sometimes the critiques from the bot are wrong and b) the critiques aren’t necessarily deterministic, so just because they are there or not doesn’t mean you are truly relieved of that portion of the review process (for better or worse).
Obligatory Silicon Valley reference [1].
So this post is talking about at work but I think the principle goes well beyond that. Think of all the AI chatbots you have to deal with to get through to customer service at a company. Or get through ATS systems in hiring. If it isn't already the case, this will probably replace or supplement TAs marking assignments.
The problem is that AI makes these interactions too cheap for the party that already has disproportionate power. The cost for them to add another layer, another hurdle, another set of questions, etc is essentially zero. Yet everyone who wants to get through that system has to pay in a human cost.
I just thought of another good example. In the pandemic auditions in Hollywood went virtual for obvious reasons. But this never went away. Now, you might say it's convenient to not have to spend hours driving to Burbank for a 5 minute audition but anecdotally the taped audition seems to be much more work. It requires a lot of prep and more tech for good sound and audio. There are people who help people tape auditions, which has really just added another layer. Plus, instead of only locals, anyone anywhere can submit an audition so where you might've had 30 people previously, now you have 150.
And what happens to those profesionally-produced auditions? They get submitted and the casting director might pick 5 randomly to even look at. If there isn't already, there will also be an AI system that filters those auditions.
At least previously you got 5 minutes of actual time from a casting director, the actual director, etc. So it's actually way more inefficient for you now. Plus, if you're lucky enough to be looked at and they like you, you probably have to go for an in-person audition anyway so what's happened here? You've just added another layer and way more work.
Companies think they're "winning" here by saving labor but I think that's short-sighted. What'll end up happening is AI agents will rise to help people on the other side of that. You can think of using AI to cheat on school assignments as an example of that.
So what will we end up with? AI agents inundating AI systems, which just adds a whole bunch of inefficiency.
[1]: https://www.youtube.com/watch?v=Y1gFSENorEY
Was it Blaise Pascal who wrote:
I have only made this letter longer because I have not had the time to make it shorter.
The argument that "using AI to generate text is disrespectful because it took no effort to write" misses the point. Respect for the recipient is measured by whether the message serves the recipient's needs, not how it is produced. Similarly, any errors are the senders responsibility, and not the fault of the tools they used.
I agree that the bottom line really ought to be usefulness; if it's useful and doesn't waste my time, it's fine if you received it by the use of seer stones for all I care.
However, I don't blame anybody for having red lines like this:
1. Don't send me a big long string that is merely LLM output resulting from pasting a trivial prompt + text I already have access to (or my own words!). I know about Claude too, and if that's what I wanted I'd have done it myself.
2. Don't throw an AI-generated argument at me that you don't even fully understand.
3. If you're preparing information for me, and it's overly verbose and wastes my time, I'll be twice as mad if it's obvious AI than if it's obviously human. This is basically the article's point. The asymmetry of wasting an hour of my time reading a bunch of crap that took 15 seconds of your time should make it clear why this is antisocial behavior.
Indeed, yet the sender is relying on me to find the errors.
what's stopping someone to feed it to an llm and say 'make it simpler' and maybe run it twice.
Exactly. What I want is not effort. It is quality. The sweat of your brow is just gross salt water.
Use whatever tool does the job, and own it if you use the wrong tool and it sucks.
If you use AI to write your communications I don't want to work with you
In a few years, you might not have any team members to work with! Tools like Slack MCP are ubiquitous at my company.
It will be a very sad day if I ever get laid off via Slack and the message is suffixed with "Sent by @Claude"
My opinion is there is a category error in the discourse on AI. It treats ai assisted output as other than human. AI is a human tool. AI output is human output.
I increasingly find that I don't care whether I am talking to an anonymous AI or an anonymous human, and believe that we will increasingly stop caring.
Because why not? AI will simply on average be nicer to talk to than most humans, with clearer thinking and better arguments, less contradictions, and easier to comprehend.
I don't know how humans could compete with that (but it also does not seem all that horrible, given that it will be available to every human.)
This is not to say that this idea is uncomplicated or comfortable, in different ways. Just that I think it's true and that it might even be good.
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 soulless. There’s only so much bland and soulless most people can take in their life before they start to get fed up.
When everything feels the same, nothing is interesting anymore.
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 writing for the past years. Why would that stop now? It's reasonable to assume that the makers also know about bad writing, dislike it, and thus the models will get trained to get even better at it.
Eventually how will you be able to tell? You won't. You can't. And that goes for the rest of us. And I suspect everything will just feel somewhat nicer.
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.
It's the argument from misanthropy again!
AI is seen as unique innovation, but in terms of the real purpose it serves, it is the logical extension of something like Doordash. "I don't like people. I don't even want to call one on the phone to order a pizza. Make me a tool that lets me avoid that, please."
Let me pose an alternative narrative. Rather than interacting with humans being intrinsically unpleasant (though for some people it is far more unpleasant than others), the technology is lowering your threshold for discomfort, step by step.
have you considered that you're just progressively lowering your threshold for discomfort?