If the AI tools are that effective, the maintainers can just use them themselves? That way they would have the full oversight on how it's done.

PRs with just the results and final code doesn't seem better even if we assume ai coding will be much faster.

▲

maiybe 5 hours ago | parent [-]

Integrating AI-assisted PRs into an existing team is a skillset all in itself.

The team is taking a pretty strong stance against external AI-assisted PRs, which makes you think they'd take a weak stance against internal AI-assisted PRs? It's hard to draw the exact line, but maybe?

For our team, the outcome is the PR, and you have to set up _a lot of testing infrastructure_ to prevent regressions. It's a skillset like any other.

It would be consistent with their actions that my belief is they are slow to adopt workflows that will accelerate them. Thus velocity will decrease.

▲

overgard 30 minutes ago | parent | next [-]

> Integrating AI-assisted PRs into an existing team is a skillset all in itself.

What exactly is this skillset? Why should AI created PR's be any different from other PRs?

To me this seems like a very sensible move.. they don't want to deal with bad code from uninvested contributors. I can't possibly see how that would harm them. If they want to use AI themselves, given their track record I trust they would do it tastefully.

	▲	maiybe 2 minutes ago \| parent [-]
		Quite simply, volume. Detailed human review is a serious bottleneck on code merging. Skillset includes how to make sure you can get quality code at speed without 100% in-depth human review. I wouldn't recommend merges without human eyes, but there is a spectrum of depth in review.

▲

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

Any resources for getting better at that skillset (high-velocity but largely stable ai-enhanced coding, if I understand you correctly)? I’m always pretty skeptical of these claims but I wouldn’t mind being proven wrong

▲

nemomarx 4 hours ago | parent | prev [-]

but their stated reasoning is that they do open PRs to train up new contributors and eventually get them into the community where they'll be more trusted. That doesn't suggest a hardline stance against the tools to me necessarily at least.

	▲	maiybe 4 hours ago \| parent [-]
		On one hand, you could be right! I am making inferences on low data, judging the Godot team based on some of their _strong_ design choices. I would have a better argument if I spent the time tracking the Github issues that seemed quite wild that we encountered while building in Godot. Top of mind (low evidence, sorry) GDScript as a base scripting language (later reversed by C#), refusal to add async/await for GDScript, others that have escaped me. What I am saying is squishy conjecture. On the other hand, they're training new contributors to make internal AI-assisted PRs by requiring them to make non-assisted PRs? That sounds unlikely but I suppose possible.