QGIS Approves a Full Ban on AI Contributions

QGIS merged a proposal to prohibit AI contributions outright.

PR #387 in qgis/QGIS-Enhancement-Proposals, titled "Add QEP428: No ai contributions permitted", was merged by nyalldawson into qgis:master on Oct 7, 2026 PR #387. The merge brought in 2 commits from branch qep_428.

The proposal discussion was opened by nyalldawson on Sep 24, 2026. The PR description says it formally changes the AI policy to a strict "NOT ALLOWED" policy.

The repository also contains qep-408-ai-tool-policy.md QEP-408. That document says contributors may use any tools to craft contributions, but a human must stay in the loop and understand the work.

The two texts set different thresholds. One permits tool-assisted work under human oversight. The other disallows AI contributions entirely. For engineers who use QEPs, the formal proposals, as design records and merge rules, wording matters. A human-in-the-loop rule governs how work is produced. A NOT ALLOWED rule governs what source material is eligible at all.

A human-in-the-loop test asks reviewers to judge oversight and understanding. A prohibition asks them to judge provenance, where work came from. Neither can be decided from a diff alone, the line-by-line view of changes. Both depend on contributor declaration, clean commit history, and reviewer follow-through when origin is unclear. It is like checking ingredients, not just tasting the finished dish.

In my view, the practical weight now falls on workflow rather than wording. A strict ban is simple to state and harder to operate. The project needs to spell out how contributors attest origin, how reviewers handle uncertain patches, and how rework happens when rejection is on policy grounds rather than technical merit. Patch review, DCO-style sign-offs and CI checks can record intent, but they cannot verify how lines were first drafted. That leaves trust plus sampling, which works only if expectations are explicit before code arrives.

The broader context here is long-term maintainability. A large geospatial codebase adds support cost with every merged change. Reviewers must read it, debug it under field conditions, backport fixes to older releases, and explain behavior years later. Tighter input control reduces one kind of uncertainty. The trade is narrower intake, with some technically sound contributions excluded on origin and more drafting effort returned to the human author.

Worth flagging, there is a quiet upside. Clear exclusion rules can make accepted contributions easier to stand behind. When every merged line is attested as human-authored, debugging, refactoring and responsibility for regressions follow familiar paths. That does not remove quality risk, but it keeps accountability in one place.

In practical terms, what the public record shows so far is narrow. A new QEP number, a short branch merge, and a deliberate change in policy language. Implementation detail is not in the merge itself. For downstream packagers, plugin authors and enterprise teams tracking QGIS governance, the next signal to watch is documentation in contribution guides and reviewer practice, where policy becomes routine.