"You're using AI, aren't you? Then can't you make the schedule shorter?" Have you ever been at a loss for an answer when this question came up while discussing an estimate? It is true that writing has become faster. Yet the schedule does not shrink as much as expected because the bottleneck is not "writing."
The same structure has been put into words from the perspective of a programming language implementation.
Zig's Code of Conduct bans posting with LLMs
The programming language Zig has a section called "Strict No LLM / No AI Policy" in the Code of Conduct on its official site. The Code of Conduct covers the ziglang organization on Codeberg, the #zig IRC channel and the Zulip chat used for development. The current text, revised on May 24, 2026, prohibits the following.
- Posting LLM-generated content (whether code or prose)
- Paraphrasing LLM-generated content
- Editing with LLMs (including fixing spelling or grammar)
- Translating with LLMs (English is encouraged but not required, and you may write in your native language)
- Using LLMs to come up with ideas and sharing the results (even if you write the prose yourself)
- Using LLMs to find bugs
- Talking about having used chatbot or LLM services
As of November 2025, the same section appeared in the site's Code of Conduct and in the repository README in a short form: "Don't use LLMs for issues, pull requests or comments on the bug tracker (including translation)" (the README still has this form). Since May 2025, the issue template has carried a notice asking people not to write issues with Copilot or other LLMs. The May 2026 revision explicitly added paraphrasing generated content, fixing spelling or grammar, coming up with ideas, finding bugs and talking about LLM use. The text of the Code of Conduct gives no reasons; it only places a link to Asimov's short story "Profession" at the end of the section.
Note that the Code of Conduct governs only the spaces listed above. Whether you use AI in your own development with Zig is not covered by it.
The reasons the creator gave
The reasons were given by Zig's creator, Andrew Kelley, in an interview on JetBrains' YouTube channel (shared on a Zig forum on May 27, 2026). What follows is based on his statements as reported by InfoQ on September 23. Our editorial team has not been able to check the relevant parts of the video.
According to InfoQ, Kelley cited two factors: human capacity does not grow as the volume of code grows, and the quality of the resulting software declines. Kelley says such contributions are "invariably garbage" and, far from having no value, have negative value. They take up review time, and only after several rounds of exchanges does it become clear that the person who wrote them does not understand what is in them. They simply paste the reviewers' comments into a chat and send back the output. That is his explanation.
As something equally important, Kelley points to Zig's educational role. Because the time available for review is limited, he wants to identify whom to invest time in so that they grow into better programmers and better contributors, and who is a drive-by contributor. People who use AI are always in the latter group: they are not learning anything and will not join the core team later. Kelley calls this way of thinking about whom to bet limited review time on "contributor poker."
According to Zig's news post of June 16, 2026, core team members have so far been chosen only from among active contributors. Once on the core team, they are trusted with reviewing and merging pull requests. Taken together with Kelley's explanation, review is also time spent developing the people who will later be doing the reviewing. Beyond low quality, this can be read as pointing out that review, as an investment, has nowhere to pay off.
Zig moved its repository from GitHub to Codeberg on November 26, 2025. The migration announcement gave as its biggest reason that GitHub Actions bugs had backed up CI processing to the point that not even commits to the master branch were being checked, and it also said that it sees GitHub's push of the feature for writing issues with Copilot as one cause of violations of the Code of Conduct. In the interview, Kelley also said that nonprofit operations are more stable (InfoQ).
Where this matters for estimates
Mapped onto client development, Zig's maintainers are "the reviewing side." In a setup where only one or two people can review, the same constraint applies even more strongly.
Even if AI makes writing code three times faster, if the number of reviewers stays the same, what grows is the queue of work waiting for review. As the queue grows, things tilt toward one of two outcomes: reviews get thinner, or the schedule gets longer. Choose the former and you end up with the pattern covered in AI-written code that "rots" in six months.
In other words, what an estimate can shorten is mainly "implementation time"; "time to read and make judgments" remains. For example, in a project where implementation accounts for half of the effort, doubling writing speed shortens the whole by only 25% (a simple calculation example). If you say "we'll be faster because we use AI" without explaining this, you are setting yourself up for trouble later.
What to decide in advance
Deciding the following in advance, both in agreements with the client and in your internal process, makes things easier later (this is our editorial team's framework).
In estimates, put implementation and review on separate lines. If they are combined, you cannot explain which parts AI shortens and which it does not. If you separate them, you can say, with grounds, "implementation will shrink; review will not."
If only one person reviews, state that explicitly as a constraint. If you cannot add people, that sets the lower limit of the schedule. This is not a bargaining chip but a shared fact.
Narrow down what review looks at. Looking at everything with the same intensity becomes hard to sustain when the volume increases. Decide what a person must always look at and what to leave to machines. We covered how to build this into the process in Adding AI code review to client development, and how to separate types of comments in the two types of review comments that work.
Check the contribution policies of the OSS you depend on. Partway through a project, you may hit a bug in a dependency and send a report or a fix upstream. If that project has a policy like Zig's, the very act of reporting a bug that AI code review found, in text summarized by AI, runs against its code of conduct. Zig also prohibits using LLMs to translate into English, and instead says you may write in your native language. Build a step into the process where a person checks and a person writes. Where the line is drawn differs from project to project; we compared how OpenJDK, the Linux kernel's staging area and Rust draw it in When AI-generated code is delivered.
In-house, try "note it when you use it" before a ban
From here on, this is a different way of drawing the line from Zig's. Zig prohibits the use itself and also prohibits talking about having used it. It is not a policy of asking for disclosure. In client or in-house development where the writer and the reviewer are on the same team, however, our editorial team thinks you can start, before any ban, with a practice of having people note when they used it.
The reason is that the way you read changes. Code written by a person tends to retain traces of the writer's understanding: how variables are named, where comments are placed, how it relates to the previous commit. From these, reviewers infer "this person understands this part" and "this part looks doubtful," and allocate how closely they look.
Generated code looks uniformly polished throughout, which makes these traces hard to rely on. That is our editorial team's view. If you know it was generated, you can switch the order: check it against the specification first and review the writing style later.
Concretely, write one line in the pull request description stating which parts were generated. Note that we explained in When AI-generated code is delivered, mentioned above, why simply requiring disclosure as an acceptance criterion on the client side tends not to work well. What we mean here is disclosure used to decide the order of review within the same team.
Counterarguments that don't hold up
The comeback "just have AI do the review too" is only half right. Checking formatting, spotting obvious inconsistencies and detecting violations of coding conventions are the parts that are easy to leave to machines.
What does not hold up is the rest. Does this change match the specification? Does it run afoul of constraints the client mentioned? Will this structure cause trouble six months from now? Only people who know the context of the project can judge these. Just as Kelley sees review as an investment in developing people, the people who can make these judgments grow as they accumulate reviews; they do not increase in proportion to the volume generated.
What to do next
On a project in progress, measure the review wait time over the most recent month: the median time from when a pull request is opened until it is merged. If this number is longer than the time implementation takes, adding AI is unlikely to shorten the delivery date. We also covered how to look at the review queue in Managing the flood of AI-generated pull requests.
If you want to shorten it, what to work on is not the generation side but either the number of people who can review or how you narrow what review covers.
On September 28, 2026, we directly checked Zig's Code of Conduct (ziglang.org) and its change history, the README and issue template of ziglang/zig on Codeberg, and two Zig news posts (the migration to Codeberg on November 26, 2025, and the introduction of core team members on June 16, 2026). Kelley's statements are based on those quoted in InfoQ's report (September 23, 2026), and we also compared them with DevClass's report (June 1). We could not play the JetBrains interview video or obtain a transcript from this working environment, so we have not verified the statements against the video. As for when the policy section appeared, we confirmed in the change histories that a notice about LLMs was added to the issue template on May 23, 2025, and that the section appeared in the site's Code of Conduct and the README on November 22 of the same year. We have not been able to check the text that was on the GitHub wiki before that. The framework for estimates and process, and the ideas about disclosure, are our editorial team's views, not results from specific projects.
For designing development processes that incorporate AI, or for estimates that include your review setup, please consult GleamHub.
Sources
- Code of Conduct（Strict No LLM / No AI Policy） — Zig
- Code of Conduct change history (content/en-US/code-of-conduct.smd) — ziglang/ziglang.org (Codeberg)
- ziglang/zig (Contributing section of the README) — Codeberg
- Issue template notice (.forgejo/ISSUE_TEMPLATE/config.yml) — ziglang/zig (Codeberg)
- Migrating from GitHub to Codeberg — Zig
- Welcoming Our Newest Core Team Members — Zig
- News report: Andrew Kelley Interview: Why He Built Zig, Banned AI Contributions, and Moved Zig off GitHub — InfoQ
- News report: Zig creator seeks ‘uncompromising perfection’ before blessing 1.0 — DevClass
