The 2-Edit Rule for AI-Drafted Docs: A Free-Tier Workflow That Keeps Humans Responsible

If you let a model draft your documentation, you need a rule that forces a human to actually reshape it—otherwise you are shipping a claim nobody signed. The 2-Edit Rule is one such mechanism: every section drafted by a model must be followed by at least two human-made line edits that are not part of the draft contract. This article shows why a rule based on observable edits beats trust, how to enforce it with a small CI script on free infrastructure, and where the rule falls apart.

The autopilot problem

When a model writes a paragraph that sounds exactly like your team’s style guide, the reviewer’s brain switches to autopilot. Many teams merge README changes that contain hallucinated function names, because the prose was convincing enough. Labels like <!-- AI-generated --> help, but they are passive. They tell a reviewer what to look at, not what to do.

The 2-Edit Rule changes that. For every document section that the model drafts, a human must introduce at least two non-trivial line changes before CI permits the merge. One edit proves the human actually read the section. The second edit proves they understood it well enough to correct, reorder, or extend it. The rule is deliberately minimal, but it creates a verifiable artifact: a diff that did not come from the model.

Why two edits, not one

A single edit can be a typo fix or a whitespace change. Two edits that survive a conversation with the model—for example, a corrected function signature and an added warning paragraph—are much harder to fake accidentally. You can tune the threshold to your team’s risk appetite; the key is that the rule is mechanical, not moral. It does not trust the reviewer’s self-report. It inspects the PR.

What the model may draft, what a human must own

The rule works best when you split the document into bands before generating anything:

Band	Content examples	Who owns it
1. Prose & structure	Explanation of a concept, section ordering, default examples	The model may draft, human may restructure
2. Code-adjacent facts	Function signatures, dependency versions, error codes	Human must verify and replace placeholders
3. Commitments	Security guarantees, performance claims, migration steps	Human must write or explicitly approve

In practice, this means the model writes band one freely, but for bands two and three it emits FIXME(<id>) markers instead of confident text. The CI script then counts human edits on those markers. You tell the model to use markers, and you tell your human reviewers that a merge without resolving them is a process failure.

A minimal free-tier pipeline using free model access

The pipeline has four moving parts: a scheduler, a model call, a PR, and a CI check. On a free server you can run all four without spending anything.

1. A scheduled job inspects the repository’s recent commits and selects files that need doc updates.
2. You call your model provider—for example, MonkeyCode’s free model access—to produce a first draft for those files. Mark every drafted section with a unique header like <!-- Draft: model-<id> -->.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

1. The draft is committed to a PR.
2. CI runs check-human-edits.sh, which fails if any Draft:-marked file has fewer than two human-authored line changes outside the marker lines.

The script itself is deliberately small:

#!/usr/bin/env bash
# check-human-edits.sh - fail if AI-drafted sections have <2 human edits
set -euo pipefail

threshold=${1:-2}
fail=0

# Find files touched by the PR (here: files changed vs main)
changed_files=$(git diff --name-only origin/main...HEAD)

for file in $changed_files; do
  [[ "$file" == *.md ]] || continue
  if ! grep -q "Draft: model-" "$file"; then
    continue
  fi

  # Count added lines that do not come from the model's watermark
  added_lines=$(git diff origin/main -- "$file" | grep '^\+' | grep -v '^\+\+\+' || true)
  human_edits=$(echo "$added_lines" | grep -v "Draft: model-" | grep -v '^\+<!--' | grep -v '^\+$' | wc -l)

  echo "File $file: $human_edits human edits"
  if [[ "$human_edits" -lt "$threshold" ]]; then
    echo "❌ Human must add at least $threshold meaningful edits to $file"
    fail=1
  fi
done

exit $fail

This is a starting point, not a universal solution. The script filters out lines that only add the model marker, comment markers, or blank lines. You will almost certainly want to exclude code fences and reuse your own comment conventions. But the shape is correct: you count added lines that are not branded.

Running the check on free infrastructure

The script runs in any POSIX environment. On GitHub Actions, a minimal workflow triggers on pull requests:

name: docs-edit-check
on: pull_request
jobs:
  check-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - run: bash check-human-edits.sh 2

The same YAML can run on a self-hosted runner or on MonkeyCode’s free server option if you prefer to keep your CI in one place. The only dependency is git.

Where the rule breaks

The 2-Edit Rule is not a magic gate. It fails when the human edits are fake—for instance, when a reviewer splits a line into two just to pass the count. To counter that, you can raise the threshold, require edits that contain at least one identifier from the surrounding code, or run a code-block compile check alongside it. For a brand-new project with no existing docs and no tests, the rule can feel like busywork: a two-line README might get meaningful human edits anyway, but a four-hundred-page API reference would need a different partitioning.

The rule also cannot tell whether a human’s edits are correct. It only proves attention. For that reason you still need example execution, link checking, and a real reviewer. Think of the 2-Edit Rule as a floor, not a ceiling.

Who should not use this

Do not use this rule if your team treats docs as a low-risk, quickly-iterated artifact that anyone can change freely—or if you have no model in the loop at all. If you do use it, pair it with a clear statement of what the model is allowed to draft: stable, reference-like text can be drafted fully; any behavioral promises, dependency versions, and security warnings must be owned by a human. The rule simply makes that ownership observable.

Wrapping up

The 2-Edit Rule converts the vague instruction “review the AI docs” into a countable CI gate. It works because it attacks the root failure mode of AI-assisted writing: fluent prose that nobody actually evaluated. Add a cheap model for drafting and a free CI minute for checking, and you have documentation that carries at least one human signature—two, if the team is honest.

That is a workflow worth trying when your next model-generated PR lands on your desk.