That’s pretty much the subtext of bans anyway. To guarantee undetectable use the contributor must treat gen code like a junior’s draft and refactor prior to PR. If it’s undetectable, the end result is the same from the maintainer’s perspective.
And it’s not a new approach. This has long been true for contributions containing “found” code; we define what’s allowed knowing we can’t actually enforce the rule against the most artfully obfuscated violations because, aside from achieving ostensibly the same result, having that tappable sign protects the project from a lot of BS down the line.
And we have to expect that trend will continue. I haven’t tested frontier capabilities since April but I know for a fact my local drafters are producing far fewer obvious smells than I remember seeing in frontier outputs even just last year.
Current frontier is likely still detectable by an experienced engineer, especially if they’ve seen enough gen code to recognize the patterns, but might otherwise be indistinguishable from junior-level work. That is, I wouldn’t be surprised if the current frontier models didn’t output ANY giveaway “slop” code or outright hallucinations. Symptoms might be more abstract like inelegant architectural decisions, obtuse alg/structure selection, or design choices that demonstrate no grasp of overall objectives.
My point was that from a project maintainer’s perspective, quality is more a side effect, and there’s no effective difference between no AI and no detectable AI. The actual point of a no-vibecode policy is (A) to communicate expectations, ensuring contributors know their PR must pass a sniff test, that their name is on it, so blind PR submission is never a safe choice, and (B) to have a bulletproof policy to refer to in retrospect if ever issues relating to AI use in the project arise.
Some projects are already quietly saying “just don’t tell people it’s AI” and to make it look indistinguishable, then get on with life.
Can’t say I have any good rebuttals against that tbh.
That’s pretty much the subtext of bans anyway. To guarantee undetectable use the contributor must treat gen code like a junior’s draft and refactor prior to PR. If it’s undetectable, the end result is the same from the maintainer’s perspective.
And it’s not a new approach. This has long been true for contributions containing “found” code; we define what’s allowed knowing we can’t actually enforce the rule against the most artfully obfuscated violations because, aside from achieving ostensibly the same result, having that tappable sign protects the project from a lot of BS down the line.
It’s getting harder to tell the difference though. Slop artists can still prompt their agent to follow the codebase’s existing style/format.
And we have to expect that trend will continue. I haven’t tested frontier capabilities since April but I know for a fact my local drafters are producing far fewer obvious smells than I remember seeing in frontier outputs even just last year.
Current frontier is likely still detectable by an experienced engineer, especially if they’ve seen enough gen code to recognize the patterns, but might otherwise be indistinguishable from junior-level work. That is, I wouldn’t be surprised if the current frontier models didn’t output ANY giveaway “slop” code or outright hallucinations. Symptoms might be more abstract like inelegant architectural decisions, obtuse alg/structure selection, or design choices that demonstrate no grasp of overall objectives.
My point was that from a project maintainer’s perspective, quality is more a side effect, and there’s no effective difference between no AI and no detectable AI. The actual point of a no-vibecode policy is (A) to communicate expectations, ensuring contributors know their PR must pass a sniff test, that their name is on it, so blind PR submission is never a safe choice, and (B) to have a bulletproof policy to refer to in retrospect if ever issues relating to AI use in the project arise.