Artificial intelligence has quietly become part of everyday open source development. AI-generated patches are appearing in small GitHub repositories, package updates, system libraries, kernel-adjacent projects, and enterprise software. This is no longer a hypothetical discussion about the future of software engineering—it’s today’s reality.

Most maintainers are not trying to ban AI. They understand that modern development tools have evolved, just as compilers, static analyzers, IDEs, and automated testing once transformed programming. The real concern isn’t whether contributors use AI. The concern is whether they understand the code they submit.

That distinction may sound subtle, but it changes everything.

Open Source Has Always Been Built on Trust

Successful open source projects don’t function because every line of code is perfect. They function because maintainers trust the people contributing to them.

When someone submits a patch, they implicitly make several promises:

• they understand what the code does;
• they understand why the change is necessary;
• they are prepared to answer questions during review;
• and they are willing to maintain that code if problems appear later.

AI does not remove any of those responsibilities.

In fact, it makes them even more important.

A maintainer reviewing a pull request isn’t simply evaluating whether the code compiles. They’re trying to determine whether the contributor understands the design decisions behind the implementation. If the review turns into the maintainer reverse-engineering AI-generated logic because the author cannot explain it, the review process breaks down almost immediately.

The person opening the pull request becomes little more than a courier for generated code instead of an engineer standing behind their work.

The Software Freedom Conservancy Wants to Clarify Responsibility

The recent guidance published by the Software Freedom Conservancy (SFC) isn’t an attempt to prohibit AI-assisted development. Instead, it reinforces a principle that has existed in open source for decades: the contributor—not the tool—is responsible for every line submitted.

Whether code is handwritten, copied from documentation, generated by an AI assistant, or adapted from another project is largely irrelevant.

Ownership remains with the person pressing “Submit Pull Request.”

If that code later introduces regressions, security vulnerabilities, licensing issues, or maintenance headaches, reviewers expect the contributor to participate in fixing them.

AI cannot answer review comments.

AI cannot investigate production failures.

AI cannot become the long-term maintainer of your feature.

Only the human contributor can.

Why This Matters More for Linux Than Almost Anywhere Else

Few communities illustrate this principle better than Linux.

Kernel development has always demanded unusually high standards for code quality and contributor accountability. Maintainers regularly reject patches that technically work if the implementation lacks sufficient explanation, documentation, or testing.

Imagine submitting a scheduler optimization that passes every benchmark on your workstation but introduces a race condition on NUMA systems under heavy load six months later.

Eventually someone discovers the regression.

Someone has to explain why the algorithm behaves that way.

Someone has to analyze memory ordering.

Someone has to debug synchronization issues.

If the original contributor doesn’t understand how the code was generated, the burden shifts entirely onto the maintainer—and that’s exactly what maintainers are trying to avoid.

The problem becomes even more serious in critical infrastructure.

A helper function generated by AI inside a small utility may never cause problems.

The same style of generated code inside:

• a filesystem,
• a cryptographic library,
• an authentication framework,
• a package manager,
• or the Linux networking stack

can create years of technical debt and expose millions of downstream systems to unnecessary risk.

Open source software doesn’t stay isolated. One accepted commit may eventually ship inside enterprise Linux distributions, cloud platforms, embedded devices, routers, medical equipment, and industrial control systems.

The consequences scale far beyond the original repository.

The Supply Chain Gets More Complicated

Modern software supply chains are already difficult to audit.

Organizations increasingly depend on Software Bills of Materials (SBOMs), reproducible builds, package signing, provenance tracking, and vulnerability databases to understand exactly where their software comes from.

AI introduces another layer of complexity.

If generated code becomes common throughout dependency trees, organizations will eventually ask difficult questions:

Who originally authored this implementation?

What model generated it?

Was it manually reviewed?

Was it modified afterward?

Can its origin be documented?

Today there are few standard answers.

Tomorrow regulators, enterprise customers, and security teams will likely demand them.

Code Review Is Becoming Less About Syntax and More About Understanding

Review practices are already evolving.

Rather than simply checking formatting or coding style, reviewers increasingly focus on understanding the author’s reasoning.

Instead of asking whether code passes tests, maintainers ask questions such as:

“Why was this algorithm chosen over the simpler alternative?”

“Can you explain why this locking strategy is safe?”

“What edge cases did you test manually?”

“How does this behave under concurrent workloads?”

“Why is this complexity justified?”

These questions aren’t designed to make contributors uncomfortable.

They’re designed to establish confidence.

Maintainers aren’t just reviewing code.

They’re reviewing whether they can trust the engineer behind it.

If AI helped generate the implementation, contributors should be prepared to defend every decision exactly as if they had typed every character themselves.

Enterprise Development Faces Additional Challenges

For organizations working in regulated industries, AI-generated code introduces questions that extend well beyond software engineering.

Banks, healthcare providers, aerospace companies, government agencies, and critical infrastructure operators already maintain detailed records covering:

• software provenance,
• vulnerability management,
• licensing compliance,
• code ownership,
• security audits,
• and software supply chain documentation.

AI-assisted development adds another dimension to that documentation.

Compliance teams will increasingly need to answer questions about where generated code originated, whether it was independently reviewed, and how it fits into existing governance processes.

Without clear audit trails, organizations expose themselves to legal uncertainty as much as technical risk.

Projects Will Adopt Different Policies

There is unlikely to be a universal rule for AI-assisted contributions.

Some projects will introduce explicit disclosure requirements.

Others will simply treat AI like any other development tool and evaluate only the final result.

Some maintainers may request commit trailers such as Assisted-by, while others may prefer a short explanation inside commit messages or pull request descriptions.

Many projects may never formalize any policy at all.

Instead, they’ll continue relying on the traditional review process.

If the contributor demonstrates understanding, the patch moves forward.

If they cannot explain the implementation, it probably won’t.

AI Doesn’t Lower the Standard—It Raises It

Ironically, AI may make code review more demanding rather than less.

Generated code often looks polished.

It usually follows formatting conventions.

It compiles.

Sometimes it even includes documentation.

But maintainers increasingly understand that polished syntax is not the same thing as engineering judgment.

The easier it becomes to generate thousands of lines of convincing code, the more valuable human understanding becomes.

Reviewers are no longer evaluating whether code looks correct.

They’re evaluating whether the contributor genuinely understands why it is correct.

The Bottom Line

The Software Freedom Conservancy’s recommendations don’t introduce a new philosophy for open source.

They reinforce one that has existed for decades.

If you submit the patch, you own the patch.

It doesn’t matter whether AI wrote 5%, 50%, or 95% of the implementation.

You are responsible for its correctness.

You are responsible for its maintenance.

You are responsible for answering review comments.

You are responsible when the bug report arrives six months later.

AI will continue improving, and its role in software development will only expand. The challenge for open source is not preventing developers from using these tools. The challenge is ensuring that engineering responsibility remains firmly attached to the humans submitting the code.

Because maintainers don’t merge AI-generated patches.

They merge contributions from people they trust.