upvote

points

by Gigachad13 hours ago |
comments
upvoteby derwiki12 hours ago|
next
[-]
That’s what I’ve been telling my PM: I don’t need your half-baked PR you one shotted from a prompt: put that prompt in GitHub Issues for the team to use later
reply
upvoteby ronnier10 hours ago|
parent|
[-]
This comment captures the essence of why HN is largely anti AI. They feel their security and roles as software devs starting to devalue. Non coders are encroaching on their turf. A PM can do now what mid level devs did before. As AI continues to advance there will be less of a need for devs and the pool size of devs will start to shrink, as it already has. I understand the human reaction to this. It’s a hard situation to watch us being replaced by a machine. Especially after sitting at the top of the comp ranking for so many years. It’s a scary time.
reply
upvoteby derwiki10 hours ago|
parent|
next
[-]
The PM doesn’t have a runtime environment to test the change. No access to create a PR. Zero verification was done and I was handed a .zip file

I don’t disagree with what you’re saying, but not all cases are created equal. If the PM could create a PR that was clearly verified, like we expect out of all the SWEs, I wouldn’t have a problem.

reply
upvoteby ronnier10 hours ago|
parent|
next
[-]
Understandable. Surprised that's not automated though. Would be worth the time to invest in that area, will save a lot of pain and time in the future. As we shift more to AI, testing is more important than ever and all of that can generally be automated.

Multiple companies I know of have internal tool websites that are the front end to the major AI companies and it has access to cut PRs so non devs are able to open PRs

reply
upvoteby derwiki9 hours ago|
parent|
[-]
Sure. Specifically I work on SOX restricted code, but the rest of the company has what you’re describing.
reply
upvoteby qwerpy10 hours ago|
parent|
prev|
[-]
PMs are doing demos to leadership where their change “just works”. The devs and maybe even the dev leads may protest that due diligence wasn’t done, but leadership is looking at the engineering cost center, axe in hand.
reply
upvoteby ahgask10 hours ago|
parent|
prev|
[-]
> It’s a scary time.

And that is why you felt you needed to boost the narrative and reinforce it so people are fired faster. Totally believable!

reply
upvoteby qwerpy10 hours ago|
parent|
[-]
Better than remaining in denial about it like most people on here.
reply
upvoteby sigotirandolas7 hours ago|
prev|
next
[-]
I agree. For bug fixes, just write a clear issue: how to reproduce it, what goes wrong, what's the root cause. As short and well written as possible, without AI fluff.

Once you get to that point, you can copy paste your issue into an LLM and get a fix close to the PR you would open, but so can the maintainers, so what's the point of opening a PR and adding more friction?

In fact discussing the issue is way more productive since it's just about the actual issue, root cause and tradeoffs without the debates on implementation details and nitpicks.

If you want to contribute major features, you need to befriend, discuss and agree with the maintainers, I don't think drive-by PRs ever worked for this.

reply
upvoteby nixpulvis11 hours ago|
prev|
next
[-]
This has always been true to a large extent. Unless you're cleared to carve out your own space of a project, or you're working off an already detailed issue/feature request.
reply
upvoteby LtWorf11 hours ago|
prev|
next
[-]
Do maintainers agree with this or do they feel you're just spamming them?
reply
upvoteby Gigachad56 minutes ago|
parent|
[-]
I've never seen a maintainer complain about receiving correct and well written bug reports. I don't just dump one liners or shower thoughts at them, and my text is all entirely human written and researched. I'll let the maintainers use AI to turn this in to a final code change since that skips the costly review steps.
reply
upvoteby einpoklum11 hours ago|
prev|
[-]
> The maintainer can then paste them in to an AI tool themselves and go back and forth faster than they could comment feedback to you and wait for changes.

My experience is that maintainers cannot do this. Or rather, that it is useless.

reply
upvoteby fn-mote11 hours ago|
parent|
[-]
I think we need to talk about the root issues then.

At “work”, non-open source, I see maintainers addressing usability issues they never would have touched before. I write the issue, the LLM does the rest.

In fact, last time I included a PR to fix some trivia, the AI said “let’s fix the root issue instead”, and did that. This was astounding to me. That team used to do nothing in the face of complaints / small bug reports. It used to be that without a PR you were ignored.

So what do you think is going on behind the experience with the maintainers? They don’t use AI? Or they are incompetent? Or…?

reply