Summary

  • On 6 August 2026, the IETF Tools Team warned that large AI-assisted pull requests could exhaust its capacity if maintainers continued reading every submitted line. It discussed contribution requirements, contributor trust and a possible lower-review route for low-impact code, but said that model was still under discussion.
  • The organization-wide guide merged on 25 August took the conservative step. All contributions still enter a queue for one or more maintainers to read every line, and AI-generated code must satisfy the same requirements for explanation, reviewable commits, tests, dependencies and policy fit.
  • The guide assigns a human continuing responsibility without making a false authorship claim. The person behind an AI contribution must understand its purpose and fit, understand the human-readable explanation and commit to fixing later problems.
  • If IETF Tools later reduces human review by impact class, it should publish a review-boundary receipt identifying the classifier, affected system, evidence, actual review depth, machine role, merge authority, maintenance owner, escalation and rollback conditions.

The rule that survived the warning

The most consequential sentence in the IETF Tools Team’s August update describes a defence becoming a vulnerability.

The Team expected large, ambitious pull requests for most of its systems to arrive with AI assistance. Its established practice was to read every submitted line. If the volume and scale of contributions rose fast enough, the update said, that practice could become a denial-of-service against the reviewers themselves.

That is not a report of an attack. It does not say a malicious contribution disabled a service, that an AI patch corrupted IETF data, or that maintainers had already stopped reading code. The 6 August Tools update identifies a capacity asymmetry: generation can be cheap for a contributor while safe assimilation remains expensive for the institution that will operate and maintain the result.

Three weeks later, the public rule did not disappear.

The contribution guide frozen at the 25 August commit says that every IETF Tools contribution enters a queue in which one or more maintainers read every line of submitted code. The guide applies this rule to all contributions. AI-generated code is not placed in a separate lane and is not banned; it is accepted if it satisfies the same contribution requirements.

The commit record dates the change to 25 August and describes the additions as requirements agreed at the Tools retreat. At the evidence cutoff for this Article, the organization-wide guide on main had the same bytes as that fixed version. The current checked state therefore preserves the every-line promise.

The Executive Director’s 1 September report closes one more factual gap. It says the guidelines have been updated so the Team can review and safely incorporate large and AI-generated contributions without spending most of its time reviewing them. It does not say that the proposed low-review tier was adopted. Read together, the public records show a problem, a discussion and a first implemented response. They do not show a silent replacement of human review with machine review.

That sequence matters. Governance errors often begin when a proposed control is narrated as if it were already policy, or when an updated policy is described at the level of aspiration rather than exact text. Here the distinction is unusually visible: August discussed more than the Team eventually wrote into its guide.

The adopted answer changes the cost of submission

The guide’s first response to scarce review capacity is to make the submitter do more of the organizing work.

A pull request needs a human-readable explanation proportionate to its scale. It must be divided into commits small enough to review individually. It should follow the project’s existing style, be fully covered by tests that fit the project’s test strategy, and disclose and justify new dependencies. Code that would require a community policy decision must wait until that decision is resolved.

These are not decorative conditions. They move work to the actor who creates the review demand.

A large generated diff can look cheap because the contributor paid little marginal cost for each extra line. The maintainer sees a different price. Each line must be situated in a system with old assumptions, data models, production traffic, security boundaries and future maintenance. A test may pass while a database query scales badly. A dependency may solve one function while importing a new update and vulnerability burden. A locally tidy abstraction may duplicate core logic somewhere else. The guide names those risks: maintainability, efficiency, security, data integrity and placement of logic.

Small commits do not prove correctness. Tests do not prove absence of malicious behavior. A polished explanation may be wrong. But these requirements make a contribution reviewable as a sequence of claims rather than a mass of generated output. They also give maintainers a legitimate basis to reject work that would consume excessive effort merely to understand.

That rejection authority is part of the control, not a failure of openness. Open contribution does not create a right to externalize unlimited review cost. The IETF’s institutional interest is not the number of pull requests it can say it welcomed. It is the reliability of the systems it must continue to run after the contributor moves on.

The named human is a maintenance bond

The AI section of the guide is careful about responsibility, but it should be read precisely.

It requires the person behind the contribution to understand what the code is intended to do and how it fits the relevant IETF Tool. It specifically requires that person to have read and understood every line of the human-readable explanation. It also requires plain technical language rather than the characteristic jargon of an agent-generated explanation.

The guide does not say that the contributor must personally have written every line. Nor, in the passage at issue, does it say the contributor has attested to understanding every line of generated code. Turning the rule into either claim would make the public record stronger than its text.

The more important requirement comes next. The person is doing more than lending a name. They commit to fix problems that arise from the code. If they do not, the code may be removed and further contributions refused.

That is best understood as a maintenance bond. It cannot guarantee future availability or solvency, and it does not transfer ultimate responsibility away from the Team. But it makes one asymmetry harder to hide. A contributor cannot take the upside of landing an ambitious feature while leaving the entire downside to maintainers who never asked for its long-term complexity.

The guide also expects regular AI contributors to become known and trusted. Contributor history can be useful evidence. A person who repeatedly submits comprehensible, well-tested changes and returns to fix defects has supplied more information than a new account with one enormous diff.

Trust, however, is not a technical property of the code. It is evidence about a relationship. The current guide does not define a score, a tenure threshold, an exemption from line review or an autonomous merge right. Those absences are not defects while every contribution remains under the same public review rule. They become material if trust later changes the evidence required for a merge.

What August left unwritten

The August update contemplated a second response that the merged guide does not yet implement.

For AI-maintained codebases, it distinguished high-impact code from low-impact code. High-impact code would continue to receive full human review. Lower-impact code might instead be checked through the quality of its tests and/or an adversarial code review by another AI. The update described the entire approach as still under discussion.

This is a rational subject for discussion. Not every repository, component or change creates the same downside. A display-only page with a quick rollback is different from authentication, private meeting material, standards metadata, mailing-list state, financial data or the record of who held an IETF role at a particular time. Spending equal human effort on every change can be wasteful and can delay work with much greater consequences.

But “low impact” is not a fact that appears by itself. Someone chooses the unit being classified. Someone decides which consequences count. Someone judges test quality. Someone accepts an AI review as sufficiently adversarial. Someone decides that rollback is real rather than theoretical. And someone authorizes the merge.

That is the next governance boundary.

The decision is not simply human versus machine. A human may make a weak classification from an incomplete description. An AI system may find a cross-file defect a tired reviewer missed. A test suite may supply stronger evidence for one behavior than a manual reading can. The relevant question is which evidence supports which decision, who owns that decision and what happens when the classification proves wrong.

Without a record, the label can absorb the whole chain. A later incident is then described as “low-impact AI code failed,” even if the real error was that a human classified a data-writing migration as reversible, an outdated test environment missed production load, or a maintainer approved an exception because the review queue was full.

A review-boundary receipt

The Team does not need to publish prompts, credentials or exploit instructions to make a lower-review decision legible. It needs a compact, versioned receipt tied to the immutable contribution.

The first block should identify the repository, component, affected service or record surface, pull request and exact commits. It should disclose whether the contribution was human-authored, AI-assisted or predominantly agent-generated at a useful level, without pretending that a percentage of machine authorship can be measured perfectly.

The second block should name the accountable human contributor and the support commitment. It should then state the impact class, the consequences considered and the classifier. Security, data integrity, privacy, performance, availability, standards-record custody and reversibility should be explicit dimensions rather than one unexplained score. The receipt should carry the classification date and the policy version that made the route available.

The third block should list required and supplied evidence. Depending on the change, that may include the human plan, tests and coverage, dependency changes, performance results, security checks, data-migration proof, deployment stages and a demonstrated rollback. “Tests passed” is too coarse when the central decision is to rely on tests more heavily than line review. The reader needs to know which risk claims the tests actually addressed.

The fourth block should record the review performed, not the review intended. Which parts received line-by-line human inspection? Who reviewed them? Which surfaces did not? If another AI performed adversarial analysis, what class of tool was used, what inputs could it inspect and which findings remained open? The machine is an evidence producer. It is not the holder of merge authority.

The final block should identify the human merge approver, deployment owner and maintenance owner. It should describe the exception and escalation path, the conditions that force full human review, the monitoring period and the trigger for rollback or removal. If a contribution is later reclassified, the original decision must remain visible.

A routine contribution that receives the existing full review can produce a short receipt. The full version belongs to the exception. That keeps disclosure proportional and prevents the audit mechanism from becoming another denial-of-service against maintainers.

Another AI can challenge; it cannot inherit the downside

Adversarial AI review is attractive because it appears to scale with generation. One model writes code; another is asked to break it. The arrangement may expose inconsistencies, missing tests, suspicious dependencies or dangerous edge cases. The Executive Director’s report offers a concrete reason not to dismiss these tools: AI assistance reduced the diagnosis of two difficult Datatracker performance problems from what might have taken weeks or months to hours, with mitigation and later substantive fixes.

That report does not say AI caused the incidents. Nor does a successful diagnostic exercise prove that AI can authorize a merge. Diagnosis and accountability are different functions.

Two systems may share blind spots. They may rely on similar code patterns, incomplete repository context or the same mistaken requirements. An adversarial prompt can create useful friction without creating an independent principal. If the result is wrong, the model does not maintain the service, answer the incident, repair the data or explain the approval to the community.

For that reason, a machine review should be recorded as evidence with a bounded scope. The human decision-maker remains visible. “Reviewed by AI” cannot be the terminal state any more than “tests passed” can be a complete explanation of operational risk.

Operational authority must stay operational

The stakes are real because the Tools Team develops and operates applications supporting IETF work. Its systems help participants write, discuss and publish standards. A defect can affect availability, data integrity or the institutional record.

That importance does not turn the Team into a standards body within the standards body.

RFC 8711 gives the IETF Administration LLC responsibility for ongoing operations while stating that it has no authority over IETF standards-development activities. The contribution guide reflects the same boundary when it says code requiring a community policy decision should wait for that decision rather than embed it in software first.

A review-boundary receipt should preserve this separation. It can show who approved an operational implementation and under which evidence standard. It should not allow a code maintainer, trusted contributor or AI classifier to settle a disputed community rule by describing the implementation as low impact.

This is where Heng Lu’s Running-Code Primacy is useful if applied narrowly. Running systems and verifiable state should discipline institutional claims. That does not mean running code automatically outranks an explicit standards process. It means an administrative label should not be allowed to conceal the operational state, evidence and responsibility that actually made code run.

His account of the agency problem in internet governance adds the incentive question. The contributor can optimize for getting a feature accepted. A coding agent can optimize for producing a plausible solution. A reviewer can optimize for clearing a queue. A manager can optimize for backlog reduction. The operator and the community inherit the long tail. The receipt does not make incentives identical, but it prevents their owners from disappearing into a single phrase such as “AI contribution.”

Keep the current rule until the exception can be named

There is no evidence in the checked record that IETF Tools has lowered review, suffered a malicious AI contribution or violated its guide. The public evidence supports a more restrained conclusion.

The Team recognized that its old review economics might not scale. It adopted requirements that raise the quality and reduce the review cost of incoming work. It retained every-line maintainer review. It attached a human support obligation to AI-generated contributions. And it left the more consequential risk-tiered model under discussion.

That is a sound order of operations.

The next step should not be a broad promise that “AI will remain human-controlled.” It should be a precise record for the moment human review is reduced: what was classified, by whom, under which version, against which consequences, using what evidence, with which machine assistance, approved by which human and reversible under what conditions.

The problem began as a possible denial-of-service against scarce attention. Solving it should not create a less visible denial of responsibility.