"I take full responsibility" is not a testing strategy.

Kernel maintainers clarified that AI-generated patches are acceptable, provided the submitter signs off and takes full responsibility for correctness, licensing, and any bugs. The AI is not the author of record. The human is. That much is a clean policy fix. The open question is whether 'takes responsibility' moves the correctness needle, because the kernel's existing test infrastructure was already doing most of that work on every patch, AI-generated or not.

Human review catches logic errors, missing null checks on the happy path, and style violations. It rarely catches concurrency bugs that only appear under specific lock orderings, integer overflows on inputs the reviewer did not think of, subtle undefined behavior the compiler will exploit, or ABI issues on an architecture the reviewer does not have. Those bugs live at the edges of the input space. The only reliable way to find them is to actually exercise the edges, which is what automated tests do.

Depth and breadth. KASAN finds memory bugs, KCSAN finds data races, lockdep finds deadlocks, syzkaller fuzzes the syscall interface, kselftest and LTP exercise user-facing behavior, all across five or more architectures and many config combinations. A patch has to survive the entire matrix. This is why kernel regressions from AI-generated patches, so far, look a lot like regressions from human-generated patches: they show up when the existing tests missed something, not when the AI 'did not understand'. The defect is almost always in the test matrix, not in the submitter's brain.

Any system that takes AI output and ships it to the real world faces the same gap. Code that writes to a production database. Agents that send emails. Social-posting tools that publish on behalf of a brand. The correct response is not 'trust the submitter' and it is not 'ban the AI'. It is 'put an automated verification matrix between the AI and the external effect, and log every artifact with enough detail to fix the matrix when it misses'.

For S4L, it is layered: pre-draft (dedupe against posts table, policy gate strips banned styles, context window check), post-draft (length, first-word, markdown, forbidden phrases, engagement_style enum tag), and post-publish (URL or 2xx returned, row written with tag, stats pass 6 hours later closes the learning loop). On failure, the row is marked, the lock is released, and the next run re-plans. No blind retries.

Because policy has to assign a human owner. If an AI-generated patch introduces a security hole, someone has to be reachable, revertable, and on the hook for the fix. 'Responsibility' is the social contract, not the verification method. The mistake is to read it as a substitute for testing. It is a complement. Tests do the catching; the human does the owning.

It is the space between what a submitter believes they understand and what the code actually does under inputs neither of them considered. A confident submitter plus an unverified patch is the highest-risk combination. The kernel's CI closes that gap mechanically, which is why the new AI-code policy is not as dangerous as it reads at first. Without the CI, 'I take full responsibility' reduces to 'please trust me', which is not a testing strategy.

Both, actually. S4L is a social autoposter whose core loop uses an LLM to draft comments. It is also built and maintained partly with AI assistance. Either way, the guardrails are the same idea as the kernel's: the artifact (a comment draft, a database row, a posted URL) passes through an automated verification layer before it is allowed to affect anything external, and every artifact is logged so the matrix can be tightened when a miss happens.