upvote

points

by miltonlost17 hours ago |
comments
upvoteby whstl16 hours ago|
next
[-]
Not advocating that people should follow this but:

As someone that loves cleaning up code, I'm actually asking the vibe coders in the team (designer, PM and SEO guy) to just give me small PRs and then I clean up instead of reviewing. I know they will just put the text back in code anyway, so it's less work for me to refactor it.

With a caveat: if they give me >1000 lines or too many features in the same PR, I ask them to reduce the scope, sometimes to start from scratch.

And I also started doing this with another engineer: no review cycle, we just clean up each other's code and merge.

I'm honestly surprised at how much I prefer this to the traditional structure of code reviews.

Additionally, I don't have to follow Jira tickets with lengthy SEO specs or "please change this according to Figma". They just the changes themselves and we go on with our lives.

reply
upvoteby grvdrm14 hours ago|
parent|
[-]
Favorited. I was talking to someone (non-dev) yesterday who prototypes with Claude and then goes back/forth with the lead engineer to clean it up and make it production worthy (or at least more robust). I like that model.
reply
upvoteby MSFT_Edging16 hours ago|
prev|
next
[-]
Just started work on a project. Greenfield and "AI accelerated". PRs diffs are in the range of 10s of thousands of lines. In the PR, it is suggested to not actually read all the code as it would take too long.
reply
upvoteby jmccaf16 hours ago|
parent|
[-]
If you push a change, or you approve, you're responsible for the change and its effects later. Regardless of size. If change is too big, tell your teammates its too big to review and to refactor to bite-size with their great coding agents. Use AI models also for review of large changes, consider a checklist . Setup CI and integration tests (also can be AI assisted)
reply
upvoteby JTbane11 hours ago|
parent|
next
[-]
Agreed, and something will go wrong (as every junior has experienced). You cannot lay blame on the AI when git blame shows your name.
reply
upvoteby MSFT_Edging12 hours ago|
parent|
prev|
[-]
Oh there's plenty of CI, linting, etc. Half of which is not properly plumbed in.
reply
upvoteby arcanemachiner6 hours ago|
parent|
[-]
Yeah, but look at all those green tests!
reply
upvoteby kelzier16 hours ago|
prev|
next
[-]
I thought the de facto policy was that the individual remains responsible in a team context.
reply
upvoteby notpachet16 hours ago|
parent|
[-]
Sweet summer child.
reply
upvoteby jbxntuehineoh16 hours ago|
prev|
[-]
based. our CEO has made it clear that we're expected to use LLMs to shit out as many features as we can as quickly as we can, so that's exactly what I'm doing. Can't wait to watch leadership flail around in a year or two when the long term consequences start to become apparent
reply
upvoteby red75prime15 hours ago|
parent|
next
[-]
> when the long term consequences start to become apparent

Choose your own story!

and then a) programmers become relevant again and slowly fix all this crap, b) Claude 7.16 waltz through fixing things as it goes.

reply
upvoteby eloisius15 hours ago|
parent|
prev|
[-]
You'll just get laid off and they'll be onto the next hype cycle as visionaries.
reply