For AI Code, the Choice Isn't Adoption or Ban, It's Process

Two things happened close together in July 2026, and they point in opposite directions.

Codeberg, the European non-profit git forge, put the question to a community vote. The result: 71% of voters approved banning repositories that are majority AI-generated, naming Claude and OpenAI Codex specifically. The stated reasons were legal and economic. Unclear copyright status of generated code exposes a host to liability. Abandoned AI-generated projects cost storage money. No technical threshold for "majority AI-generated" was defined, and no enforcement method was announced. Armin Ronacher, who created Flask, called it "very bad."

Around the same time, someone I worked with on a past freelance contract told me about the other end of the spectrum. At companies he knew, including in the financial sector, AI tooling was mandatory. Not encouraged, mandatory. My first instinct was skepticism. Mandatory AI use sounded like the kind of policy invented after the fact, a pretext dressed up as a rule. But it pushed me toward a question I could actually research: what is the verifiable industry position on required versus banned AI usage in 2026?

The short answer is that there is no such position. And that absence is the point.

Codeberg's vote is not a verdict on code quality. It is a hosting model protecting itself from liability and storage bills. Microsoft requiring its teams to move off Claude Code onto its own Copilot CLI by the end of June is not a verdict either. Microsoft owns GitHub and Copilot. A vendor standardizing on the stack it controls, around a fiscal year-end, is stack control, not a quality finding. The freelance anecdote is company-level policy I could not verify as any kind of standard. Three impulses, three local motives: liability, stack control, unverifiable policy. None of them answers whether AI-assisted coding, done with review, is good or bad engineering.

So where does the measurable risk actually sit? Not in "AI is dangerous." Not in "AI is fine." In code shipped without a human in the loop.

The strongest figure I can cite, read directly from the source, is Georgetown's CSET study from November 2024. Five models, 67 security-adversarial prompts in C, checked with a formal verifier. Roughly 48% of the generated snippets compiled but contained a flagged bug. About 30% passed verification. Read that the way the report asks to be read: a narrow, C-only, adversarial benchmark of raw model output. There is no review step in that pipeline. It measures the model, not a reviewed workflow.

The sharper illustration is Moltbook. A social network launched in January 2026 whose founder said he did not write a single line of code. Within three days, researchers found the production database exposed: roughly 1.5 million API tokens, around 35,000 email addresses, private messages. That is not a statistic about AI. It is a named product, a named absence of process, and a named consequence.

This is what the evidence supports. Adoption and ban are not the real axes. A ban does not fix unreviewed code, and a mandate only pushes more of it through the same gate. The fault line is process. Does the engineer who ships the code understand it? Did anyone review it before it went out? The CSET study, cited honestly with its scope, measures raw output with no review step. Moltbook is the same failure at product scale. Every mandate-or-ban example in this research was driven by something other than engineering quality.

So I stopped asking whether my tools are adopted or banned. I ask what my review loop is for code I did not write. For AI output, the answer needs to be at least as strict as for a contractor's code. Stricter, probably, because the output arrives fast and with more confidence than it has earned.

The frame that matters is not adoption versus ban. It is process versus no-process. Everything else is a policy debate about something else.