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.

▲

Fraterkes 2 hours ago | parent | 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 3 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.