My experience lately is the best way to contribute to open source now is to just write detailed issues. 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.

▲

derwiki 4 hours ago | parent | 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

▲

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

▲

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

▲

ronnier 2 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

	▲	derwiki 2 hours ago \| parent [-]
		Sure. Specifically I work on SOX restricted code, but the rest of the company has what you’re describing.

▲

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

▲

ahgask 3 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!

	▲	qwerpy 2 hours ago \| parent [-]
		Better than remaining in denial about it like most people on here.

▲

nixpulvis 4 hours ago | parent | 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.

▲

LtWorf 3 hours ago | parent | prev | next [-]

Do maintainers agree with this or do they feel you're just spamming them?

▲

einpoklum 4 hours ago | parent | 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.

	▲	fn-mote 4 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…?