Bitcoin Open-Source Contribution in the Age of AI

A patch can compile, pass its tests, and still miss what a project needs. It might solve only part of a problem, repeat something that already exists, or introduce behaviour that its tests never check.

That has always been true in software development. AI adds another question: when a tool writes some or all of the code, what is the person submitting it contributing?

AI-generated code can be part of a legitimate open-source contribution. Its value depends on the problem it solves, the work done to verify it, and the rules of the project receiving it. Writing every line yourself is not the only way to contribute, but submitting a change still means taking responsibility for it.

Bitcoin Core offers a useful example. Its policy welcomes AI as a coding tool, provided it adds value and respects the community’s time. Contributors must understand their changes, be capable of writing the code themselves, and explain their work in their own words.

That approach leaves room for AI to help with development while keeping human understanding and judgement central to the process.

A contribution is more than the code

Open-source projects need more than new features. They also need people to investigate bugs, test proposed fixes, improve documentation, and review other contributors’ work.

Bitcoin Core’s contribution guidelines make this especially clear. The project welcomes peer review, testing, and patches, and identifies in-depth review and testing as development bottlenecks. For someone getting started, carefully testing an existing pull request can be a valuable contribution in its own right.

This gives us a broader way to think about contribution. The value lies in helping the project improve, whether that means writing an implementation, finding a flaw in one, or providing evidence that a change behaves as intended.

Suppose a developer investigates a bug, uses AI to explore possible fixes, and submits a patch. The generated code is one part of the work. The developer may also have reproduced the problem, checked the proposed solution, added a useful test, and explained why the approach fits the codebase.

Those activities matter. Counting how many lines the developer typed would tell us very little about the quality of the contribution.

A pull request is still a proposal, though. Maintainers and reviewers need to establish whether the change is correct, useful, and suitable for the project before it can be merged.

Where AI can help

AI tools can support several parts of that process. They can help a developer navigate unfamiliar code, explore an error, draft a test, or compare possible implementations. They can also generate a substantial patch across multiple files.

For developers learning to contribute, this can make an unfamiliar project easier to approach. An explanation of a function or a suggested starting point may help someone move from being unsure where to begin to having a concrete question to investigate.

The benefit depends on how the developer uses the output. A generated explanation can guide further reading, but its claims still need to be checked against the code. A proposed fix can give the developer something to test, but it does not establish that the underlying problem has been solved.

Imagine an AI assistant generates both a bug fix and a test. The test passes. That is useful evidence, but the developer still needs to ask whether the test would fail without the fix, whether it captures the reported problem, and whether the implementation affects other behaviour.

The same mistaken assumption can appear in both the generated code and its test. Examining them together is part of the developer’s work.

Used thoughtfully, AI can help people explore solutions and spend more time evaluating them. That evaluation is itself an important part of contributing.

What responsibility remains with the developer?

When AI produces part or all of an implementation, some of the developer's effort may shift from writing code to examining, testing, and refining the output. The need for technical judgement remains.

A contributor should understand what a change does, why it is needed, and how its behaviour has been verified. They should be able to explain their decisions and investigate questions raised during review. If a reviewer identifies an edge case or suggests a different approach, the contributor needs to engage with that feedback and determine how to proceed.

Bitcoin Core sets these expectations out in its AI policy. It welcomes AI as a coding tool, provided its use adds value and does not waste the community's time. Contributors must know the programming language, understand the surrounding code and the effects of their changes, and be able to explain their pull requests in their own words. The policy also rules out pull requests opened or driven by autonomous agents.

The Linux kernel's AI coding-assistant guidance establishes related requirements. Human contributors must review AI-generated code, ensure licensing compliance, provide their own Signed-off-by certification under the Developer Certificate of Origin, and take responsibility for the contribution. The guidance also requires an Assisted-by tag for contributions prepared with AI assistance.

These policies differ in their details, but both retain responsibility with the human contributor.

That expectation is especially relevant for developers learning to contribute to open source. AI can help explain unfamiliar concepts and suggest ways to approach a problem. But understanding develops through examining code, checking assumptions, testing behaviour, and working through feedback. Accepting a generated explanation or implementation without questioning it can leave gaps in that understanding.

The goal is not to avoid AI assistance. It is to use it without losing the ability to evaluate the work it produces.

Different projects draw different boundaries

There is no universal policy for AI-generated contributions. Some projects permit AI assistance under specific conditions, some restrict autonomous submissions, and others prohibit LLM-generated content in the spaces they govern.

A September 2026 research preprint by Andre Hora, Romain Robbes, and Stefano Zacchiroli provides a useful overview. The researchers analysed 281 written AI contribution policies drawn from the 2,000 most popular GitHub repositories and 36 additional well-known projects and organisations.

Among the policies examined, 83.3% permitted or encouraged AI use in code contributions, while 14.9% prohibited it. The study also found that 67.3% required a high level of human involvement and 48.8% required disclosure of AI use.

These figures describe the policies in the researchers' sample, not every open-source project. The paper is currently under review at ACM Transactions on Software Engineering and Methodology, so its findings should be treated as preliminary research rather than established consensus.

Even with that qualification, the findings illustrate an important distinction: permission to use AI does not mean every contribution produced with it will be accepted.

The differences become clearer when we examine individual projects. Bitcoin Core permits AI-assisted coding while requiring contributors to understand and explain their work. The Linux kernel permits AI-assisted development under requirements covering human responsibility, licensing, and attribution.

Zig's code of conduct takes a stricter position in the spaces it governs: the Zig organisation on Codeberg, the project's development Zulip chat, and the #zig IRC channel. Its policy prohibits LLM-generated code and prose, as well as using LLMs for editing, translation, brainstorming, and finding bugs in those spaces. The rules do not automatically govern every independent Zig community.

These differences matter because a developer cannot assume that a practice accepted in one project will be acceptable in another. Disclosure requirements also vary. Some projects require contributors to identify AI assistance, while others do not impose the same obligation.

For anyone preparing a contribution, the practical step is to read the target project's guidelines before starting work. If AI use is restricted, understand the restriction before using the tool. If disclosure is required, follow the project's instructions. Where the rules are unclear, ask a maintainer rather than assume that a particular use is acceptable.

The project receiving the contribution determines whether it meets its requirements. AI use alone does not settle that decision.

Why submission quality matters to maintainers

The question also concerns the people who must review and maintain the resulting work.

Maintainers need to assess proposed changes, examine tests, consider an implementation's effects, and decide whether it belongs in the project. These tasks require time and technical judgement, particularly in projects where much of the maintenance work depends on volunteers.

AI can make it easier to generate a proposed change, but a larger volume of submissions does not automatically mean more useful contributions. If a patch contains untested assumptions, duplicates existing functionality, or cannot be adequately explained by its submitter, reviewers may have to spend time establishing what the change does before they can assess its value.

The Linux kernel's guidance on reporting security bugs illustrates this problem in a related context. It notes that a significant fraction of reports submitted to the security team originate from AI-assisted code reviews, and that some reports are too inaccurate or poorly prepared to be useful. The guidance asks reporters to verify their findings, provide a tested reproducer, and present the relevant information clearly.

These are requirements for security-bug reports, not a general policy on accepting AI-generated patches. Still, the example shows why generating a plausible result is not the same as producing something ready for another person to evaluate.

An AI-assisted patch that has been carefully checked, tested, and explained can be easier to review than a poorly prepared contribution written entirely by a human. The burden depends on the quality of the submission, not simply on which tool was used to produce it.

Projects have responded in different ways, including restricting autonomous submissions and establishing expectations for pull-request quality. These measures can help protect limited review time, but they also involve a trade-off. Rules drawn too broadly may discourage developers who could make valuable contributions with appropriate guidance and oversight.

For maintainers, the challenge is to encourage useful participation while keeping submissions possible to evaluate. For contributors, opening a pull request begins the review process; it does not end their work.

What this means for developers contributing to open source

For developers using AI, responsible contribution begins before a pull request is opened.

• Understand the problem. Use AI to explore unfamiliar concepts or possible solutions where helpful, but establish what the software needs before settling on an implementation.
• Check the project's rules. Read its contribution guidelines and any policy covering AI use, testing, licensing, disclosure, or autonomous agents.
• Examine the generated code. Review the output, investigate assumptions you cannot verify, and test the change against the problem it is intended to solve. Consider behaviour beyond the most obvious case.
• Be ready to explain your decisions. Describe what the change does, why you chose the approach, and what testing supports it. Engage with review comments and revise the implementation where necessary.
• Disclose AI use when required. Follow the project's instructions, since there is no single disclosure convention that applies everywhere.

These practices cannot guarantee that a pull request will be accepted. Maintainers may decline a technically sound change because it does not fit the project's priorities, duplicates existing work, or would be better addressed another way. But the practices help ensure that the contributor has done the groundwork needed for meaningful review.

For developers still building their skills, AI can be useful in the learning process. The important thing is to use it to develop a better understanding of the codebase and the problem, rather than to bypass the work of understanding either.

So, does AI-generated code count as an open-source contribution?

AI-generated code can form part of a legitimate open-source contribution. Using AI does not automatically invalidate the work, just as writing every line manually does not automatically make a contribution valuable.

Generated code can contribute meaningfully when it addresses a real need, meets the project's requirements, and has been adequately evaluated by the person submitting it. That person must also fulfil the responsibilities expected of a contributor, including understanding the change, testing it, and engaging with review. Some projects impose additional requirements or prohibit certain forms of AI-generated work altogether.

The answer therefore depends on both the proposed change and the rules of the project receiving it. A contribution permitted under one project's policy may be prohibited under another's.

AI changes how code can be produced. It does not remove the need to establish whether that code is useful, appropriate, and ready to become part of a project. For developers who want to contribute to open source, the task is to use available tools while building the judgement and understanding needed to stand behind the work they submit.