Comment by crjohns648 | Hacker News Reader

Comment by crjohns648 | Hacker News Reader

Parent Full thread

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

Half is a joke half not:

Not sure how you are working but we have this novelty idea where people have daily meetings like 15 mins each day to update each other which tasks they are busy with.

We also have refinement meetings where people are involved in clarification for each task so they are not surprised by requirements.

So we do planning meetings every two weeks. Each ticket is tied to the code in commit.

So by code review time anyone doing CR has all of the information in few clicks and some of it already in their head.

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.

Reply on news.ycombinator.com