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

If you are asking for human attention, demonstrate human effort

tombedor.dev

Post reply on HN
Print view View original

501–510 of 551 posts

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

#501

Post by andrekandre »

whstl wrote: post #463
monkeydust wrote: post #427

Earlier quoted context omitted.

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…

  > Now virtually all content is generated by AI and the old customers don't have anyone to verify anymore.
i see this first-hand at $company, where the pr's are so obtuse and descriptions are incomprehensible or just too long and gratuitous that thorough code review is also falling by the wayside and becoming more of a "rubber stamp"; this is what management is calling "productivity boost"...

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

#502

Post by necovek »

swiftcoder wrote: post #477
necovek wrote: post #417

Earlier quoted context omitted.

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

> in a few sentences, what do you expect out of a quality code review? (sounds like nothing in your case, but I am curious) From my perspective, there are three sorts of PRs: - One is very close to the final form of a particular change, and any feedback you get at that late stage is indicative of holes in your process. - Another is one where someone throws something up and says "hey, this is an experiment, can I get…

On the first category, what is a process you use which has no "holes" in it?

Does everybody produce completely readable, tested code every time? Perhaps that's just "style" to you when it is "maintainability" to me?

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

#503

Post by hypfer »

deadbabe wrote: post #459
hypfer wrote: post #170

Earlier quoted context omitted.

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

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.

Don't yield then.

Don't endlessly reply.

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

#505

Post by [deleted] »

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

Earlier quoted context omitted.

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

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

[deleted]

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

#506

Post by purpleflashing »

Sohcahtoa82 wrote: post #439
nucleardog wrote: post #379

Earlier quoted context omitted.

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

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

Because modern tech and modern tech support has a terrible UX in general built by engineers around their engineering heuristics.

By the time a non-tech user reaches the point of seeing an error they are cognitively overloaded and since the errors are pretty much incomprehensible to the users, the user doesn’t get the feeling of it being anything that’s tied to their actions. It’s just anxiety-inducing noise, it never registers as something that has a meaning, so even copying and pasting an error feels like a meaningless step that their overloaded and already anxious brains skip.

If errors are meant to be shared with tech support, the UX should reflect that (and some interfaces do that where you just have a button to send the crash report or smth). If errors are meant to give users agency to solve the problem on their own, the UX should reflect that too.

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

#507

Post by madaxe_again »

tristor wrote: post #359
madaxe_again wrote: post #202

Earlier quoted context omitted.

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?

Consumer dispute, not business - and yes, if it goes to court, of course I will hire a lawyer.

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

#508

Post by ayewo »

jillesvangurp wrote: post #163
niuzeta wrote: post #34

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

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

> If I want to speed things up, I remove people from the team. Everything gets easier.

How did you land on this approach? From someone you learned from or from a seminal book like Mythical Man Month [1]?

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

Shopify has also struggled with this and their solution is two-fold: move everything inside a monorepo they call World [2]. The do a number of things to make things legible for AI agents like e.g. having a comprehensive CI/CD system in place, documenting tribal knowledge in AGENTS.md which in aggregate turn out to also be good for humans new to the monorepo.

Then, they built an internal AI agent on top of this monorepo process that is useable from Slack. They call the AI agent River [3] and in this system all chatbot exchanges are public by default.

1: Fred Books was one of the first to point out that adding another team member to speed up a late project will produce the inverse effect of making that project later (because of coordination tax).

2: https://shopify.engineering/under-the-river

3: https://x.com/tobi/status/2053121182044451016

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

#509

Post by loglog »

skydhash wrote: post #290
PaulKeeble wrote: post #264

Earlier quoted context omitted.

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

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

Writing and reading design documentation can be slower than pair programming. On the other hand, info about code design also belongs into inline documentation or commit messages (in this order of preference), so the effort might not be wasted.

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

#510

Post by loglog »

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

Earlier quoted context omitted.

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

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

Bureaucracy gives you leverage against slop. Review seriously, but limit the time that you spend. This will stall the slop. When the culprit complains, tell your boss "I spend X hours per week on reviews. If you need more throughput, the PRs quality needs to improve."
Post reply on HN