Pure Code is my name for an approach to development in which a change’s purpose, design decisions, verification, and limits remain understood by people, recorded for the project, and available for future improvements—even when AI writes much of the implementation.

The word “pure” does not mean that every line was handwritten by a human, or that the code is free of defects. I want to distinguish a patch that is simply forwarded from an AI from a contribution that retains human judgment and the capacity to participate in what happens next. The subject is the code together with the process and experience behind it. That difference cannot be determined from the code’s text alone.

I began making personal notes about this idea around May 2025 while developing a collaborative development environment. That date describes my own thinking, not a claim of priority. My question has remained the same: when AI does more of the implementation, how can people continue to understand, choose, and grow with the projects they build?

“Pure Code” is the concept proposed in this essay. It is unrelated to the existing PureCode AI product.

The concern behind Contributor Poker

Loris Cro’s “Contributor Poker and Zig’s AI Ban”, published on April 29, 2026, gives this question an important context:

- Helping a first pull request reach a mergeable state can cost more than implementing the change directly.

- That investment can still be worthwhile when repeated collaboration develops a knowledgeable contributor and a lasting relationship.

- Cro reports that Zig’s experience with AI-assisted submissions has largely undermined that investment, through unusable patches, excessive changes, and unreliable follow-up discussions.

Simon Willison’s April 30 response asks a related question: what does a maintainer gain from reviewing an AI-generated patch that they could have asked their own model to produce? GIGAZINE covered the discussion on May 1. These later publications are separate from the date of my personal notes.

I share the concern about what grows through the relationship. My hypothesis is that a development environment can help preserve that growth when AI is involved. This does not contradict Zig’s account of its experience, nor establish that my proposal would solve Zig’s problem.

Each project decides what it accepts. Zig’s current rules prohibit LLM-generated code and prose, as well as uses such as editing and translation. Human review or a Pure Code record does not create an exception. Zig’s main development is hosted on Codeberg; the question here concerns contributions across open-source communities, rather than a claim about the volume of AI submissions across GitHub.

What should the project gain?

A contributor learning something is valuable, but it does not by itself justify a maintainer accepting the patch. The learning needs to support useful work: clearer investigation, informed revisions, and fewer problems that someone else must rediscover.

Open source is not defined as unpaid charity. The Open Source Definition addresses rights such as redistribution, source access, and modification, and permits commercial use and sale. The practical concern is how work is distributed: if faster implementation merely transfers unexplained investigation and correction to maintainers, it has not made contribution more sustainable.

The aim is to make the remaining review work smaller and clearer. A maintainer should not receive a pile of learning logs to inspect. Continuing involvement also need not mean a lifetime obligation to provide unpaid maintenance. Contributors can state what support they can offer and leave useful decisions and checks behind when they move on.

The same patch, two different contributions

Consider a hypothetical todo application whose completion state disappears after a restart. Two contributors submit the same fix.

The first forwards an AI-generated patch with “tests passed.” They cannot explain how the state shown on screen differs from the state saved on disk, why the change fixes the bug, or what might happen if saving fails. The maintainer inherits those unanswered questions.

The second also lets AI write most of the implementation. During the work, they learn that updating the interface and persisting a value are separate operations. They check that the completion state is restored after a restart, identify conditions they have not tested, and can decide what to investigate when a reviewer raises a concern.

When adding another saving feature later, the second contributor finds the earlier explanation, reuses the restart check, and records what the new result shows. The final diff in the first task can be identical, while the second contribution leaves understanding and verification methods that can participate in future work.

The expected understanding is proportionate: the submitted change, its assumptions and dependencies, its effects, and the limits of its checks. It does not require memorizing an entire codebase or rebuilding it without AI.

A lightweight contribution record

If Pure Code is to lead toward a shared standard, I would begin with a small contribution record linked to the change. Its purpose is to make the relevant decisions, checks, and unknowns available to other people. It would not classify a patch’s worth by which tool produced it or award a certificate of human understanding.

- Problem and purpose

- What the change addresses, and what is outside its scope.

- Design decisions

- Why this approach was chosen and which meaningful alternatives were set aside.

- AI involvement and human review

- What was delegated, what a person inspected, and which judgments they actually made.

- Verification

- The exact revision checked, reproduction steps, tests or commands actually run, and their results.

- Limits

- Untested conditions, known constraints, and unresolved questions.

- Continuity

- Review responses, follow-up changes, and information needed for a handoff.

A small correction may need only a few lines. A substantial design change may need more. Existing issue discussions, test results, and design documents can be linked rather than copied into another document.

A personal notebook has a different role. It can hold questions, failed attempts, learning goals, and unfinished thoughts. Only the parts needed to understand and review the contribution should be selected for external sharing. Full AI conversations and a person’s learning history should not become mandatory submission material.

Cleanroom, the environment I am building, is one implementation intended to support this cycle. No particular product or model should be a condition of Pure Code. The useful experience should remain available when a model, tool, or contributor changes.

A record is evidence, not proof of understanding

AI can generate design explanations, reflections, learning notes, and replies to reviewers as readily as it generates code. A detailed account cannot, by itself, establish that its submitter understands the change or will respond usefully in the future.

Human decisions, model interpretations, executed checks, and observed review responses therefore need to remain distinct. An AI saying that a test passed is different from a recorded execution tied to a revision. A passing test establishes a result under the tested conditions; it does not establish a person’s understanding, or prove that an earlier note caused an improvement.

Actual engagement can provide clues: reproducing a failure, reasoning about a different input, or explaining the reach of a reported defect. These clues can arise during ordinary collaboration. Requiring maintainers to administer a new examination for every contribution would undermine the purpose of reducing their workload.

The first pull request cannot establish a future relationship in advance. A record helps people trace what happened, what remained, and how it was used later. It does not eliminate uncertainty or automatically certify trust.

There is also a difference between personal work and external contribution. Within appropriate limits, someone can continue their own project and return to reflection later. Before submitting work to others, they should disclose what they do not understand or have not checked, so maintainers can decide whether the remaining work is worth taking on. Learning should not become a compulsory pause after every action, but unknowns should not be hidden at handoff.

Building on existing practices

Human accountability in AI-assisted contribution is not a new idea. LLVM’s AI Tool Use Policy permits AI tools while requiring contributors to review generated material, remain accountable, and answer questions about their work. It calls for disclosure of substantial generated content and advises newcomers to begin with small changes they understand. It also prohibits AI use for issues labeled “good first issue,” preserving those learning opportunities.

Other practices address different parts of contribution. SLSA provenance provides information for tracing how software artifacts were produced. The Developer Certificate of Origin records a contributor’s attestation concerning the origin of a contribution and their right to submit it under the relevant license.

Pure Code’s proposed emphasis is on the continuity of experience: decisions, understanding, and failures acquired through development and review should survive the immediate task and return to future contributions. It would complement existing practices, without replacing their requirements or guaranteeing security, correctness, or licensing rights.

What still needs to be demonstrated

Cleanroom already has mechanisms for retaining records, linking them, and bringing selected material into later work. Having those mechanisms is a different achievement from demonstrating better learning or lower maintenance costs. This essay does not present measured evidence of those benefits.

The outcomes I want to evaluate are more useful than the number of notes saved or lines generated:

- For maintainers: time spent establishing reproduction steps and explaining changes; repeated review issues; and defects discovered after merging.

- For contributors: whether earlier feedback is used in a related task, and whether they can reason about the problem under new conditions.

- For projects: whether checks and design reasons are reused, and whether useful history survives changes of people or models.

Any evaluation must distinguish the contribution of the record-and-reuse process from ordinary familiarity with a codebase or a more capable model. A working storage feature does not demonstrate that the loss of human experience has been solved.

What carries into the next contribution

The question I want Pure Code to make explicit is what remains with people and projects after AI-assisted work. A useful answer includes a contributor who can engage with the change, decisions that can be revisited, checks that can be repeated, and experience that can improve what happens next.

That requires more than saving conversations. The cycle is to retain relevant experience, find it when it matters, use it in another task, and record the new outcome. People should be able to choose what they want to understand and carry forward while the work continues.

I want AI to help produce software while people remain able to grow as its makers. Pure Code is a proposal for making that continuity visible and usable—and for testing whether it can make future contributions better for both contributors and the projects that receive their work.

Revised September 20, 2026. Linked project policies were checked on that date; the receiving project’s current rules always apply.