I hope you have a great time. I took a trip to the UK with my family this summer and Scotland was lovely. We didn’t manage to make it out to the Isle of Skye, but we did do a day trip out to the highlands and it was an experience I’ll never forget. Simultaneously desolate and beautiful.
score 1 · canonical
Your comment is a good one and I think does a good job of highlighting that current AI policies are drawing the boundary in a weird place.
I think the distinction many teams actually want to make is: was every line in this codebase read, understood, and accepted by a human or not?
There are valid arguments in both directions:
Codebases where the answer is “yes” mean that there is a human who is claiming some level of accountability and responsibility for the code. Not in a legal sense for most open source licenses, of course. But in a “can I trust that a person gave a shit about this?” sense. Humans bring a whole cloud of moral and social values with them and when a human accepts some code, it means we can more likely trust it in the large diffuse sense of the term “trust”.
It is more likely that the codebase will continue to be maintained in the future because people have already invested real effort into it.
Codebases where the answer is “no” can grow and add features much more rapidly. I don’t think anyone knows what the long-term maintainability of vibe-coded programs is yet, but at least short-term it seems like AI can whip up a whole lot of mostly working code really fast.
So I think really where the policy line should be drawn is at code review. Does a human review every line of code or not?
The challenge is that if you have a policy that says “yes” but don’t have a policy discouraging using AI to generate code, you will rapidly overload the reviewers. So the policy line gets drawn earlier at the point of authoring to try to avoid that. But I think then it runs into all of the problems that the parent comment here are talking about where it’s not clear if a contribution or bug report is “tainted” by AI or not.
I suspect there is another approach one could take here that is a little more mechanical about the code. Maybe have a rule that says all PRs above a certain line count are auto-rejected unless a previous design discussion with maintainers has occurred.
Of course, if you object to the use of AI on moral/ethical grounds, I also think it is valid to have a policy that outright rejects all contributions tainted with AI in any way. But I think that’s a somewhat different problem being solved than AI policies that are mostly trying to deal with not overloading human reviewers.
score 2 · canonical
Back when I was working at EA, the company went through a wave of organizing code into packages that could be shared by multiple game teams. This was generally a great thing and reduced the insane amount of NIH that existed before then.
However, every game team had its own Perforce repository, and there was no real mechanism or policy in place to update those packages. It was all just ad hoc whenever some random game team needed a fix from someone else’s version of a package, they would take it.
One of the last things I did before leaving EA was spend 9 months of my life doing nothing but migrating packages from one repo to another and getting teams on the latest version of stuff. I’m not saying that’s why I left EA. There were plenty of reasons. But it was definitely one of them.
score 1 · canonical
Thank you! :D
score 2 · canonical