Two Pockets, One Doc: A Draft-Budget Workflow for AI-Generated Documentation

The bottleneck in AI-assisted documentation is not generation; it is the review queue. A model can rewrite a paragraph in seconds, but a human still decides whether that paragraph is true, useful, and safe to ship. In practice, teams do not fail because the model wrote too much; they fail because they reviewed too much generated prose and too few real decisions. A draft budget solves this by labeling sections before the first prompt is sent.

A draft budget is a per-document rule that assigns every section to one of two pockets: model may draft or human must own. The model fills its own pockets and nothing else. The human reviews only the owned sections and the seams between pockets. This is different from an ownership matrix, which describes who approves content; a draft budget describes what content the model is allowed to produce at all.

In this workflow I use MonkeyCode's free model access and the free server option to run small drafting iterations without a compute budget. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The Draft Budget Artifact

The core artifact is a small YAML file that reads like a contract between you and the model. It names each section, its owner, the allowed output shape, and the prompt template. Here is a realistic example for a library that describes a JavaScript data-masking utility:

version: 1
sections:
  quick-start:
    owner: model
    prompt: "Write a 3-line code example that masks an email with maskData(). Output only code."
    accepts: code
  error-matrix:
    owner: model
    prompt: "List the five most common maskData() errors and a one-line fix for each. Use bullets."
    accepts: bullets
  performance-rationale:
    owner: human
    forbid: "Do not mention benchmarks, trade-offs, or measured latency."
    requires: human-drafted
  security-note:
    owner: human
    forbid: "Do not suggest workarounds for built-in limitations."
    requires: human-drafted
acceptance:
  max_model_sections: 2
  min_human_owned_ratio: 0.3

A Small Script That Enforces the Budget

The file only helps if something reads it. This Python script turns the budget into a prompt queue and a post-generation check. It does not call any API; it prints the exact prompt for each model-owned section and marks the rest as human-owned.

import sys
import yaml

def load_budget(path):
    with open(path) as f:
        return yaml.safe_load(f)

def build_queue(budget):
    queue = []
    for name, spec in budget["sections"].items():
        if spec.get("owner") == "model":
            queue.append((name, spec["prompt"]))
        else:
            queue.append((name, None))
    return queue

if __name__ == "__main__":
    budget = load_budget(sys.argv[1])
    for name, prompt in build_queue(budget):
        if prompt:
            print(f"# {name}\n{prompt}\n")
        else:
            print(f"# {name}\n[HUMAN-OWNED] draft your own text.\n")

After generation, a second check ensures the model did not wander into a human-owned section. You can implement this as a GitHub Action that greps for forbidden markers, or as a lint rule that verifies [HUMAN-OWNED] placeholders were replaced only by a human. The exact mechanism matters less than the invariant: if a diff touches a human-owned section, the author field must be a human, not the model.

The Five-Step Workflow

1. List the sections and assign owners. Start with the table of contents, not with a blank prompt. Mark examples, repetitive error lists, and command references as model. Mark rationale, trade-offs, security notes, and anything with legal weight as human.

2. Write section-level prompts with output shapes. A prompt like write a page about masking is a blank page, not a pocket. Give the model a section name, a length, and an allowed format: code block, bullet list, or a short paragraph. The budget YAML above is an example of this discipline.

3. Generate model-owned sections on the free tier. Because the drafting loop is small and iterative, you do not need a paid remote session. MonkeyCode's free server option places the agent in a sandbox, and the free model access covers the quick-start and error-matrix pockets.

4. Run the boundary check. Paste the generated output back into the document, then run the script that verifies no model-owned section contains forbidden terms and no human-owned section was filled by the agent. This step fails loudly instead of leaving you to guess who wrote what.

5. Review only the human-owned seams. Your review time is now spent on decisions, not prose: Is the trade-off honest? Does the security note include the right caveat? Does the performance rationale reflect measured evidence? Those are the only sections that require deep attention.

Limitations and Who Should Not Use This

This workflow assumes you can label sections before a single draft exists. That is easy for reference documentation, API guides, and migration notes; it is hard for exploratory writing where the best structure emerges only after the text exists. If you are writing a design proposal that changes shape during drafting, a rigid budget will slow you down.

The budget also does not verify factual correctness. A model-owned example can still be wrong, and a human-owned rationale can still cite fake numbers. Pair this workflow with the executable-docs gate from earlier work in this series, where every code block is run before merge. For security advisories, legal disclaimers, or anything where a single wrong word creates liability, do not let the model produce prose at all; keep the entire document in the human pocket.

A draft budget is not a permission slip for the model to be lazy. It is a permission slip for you to stop reviewing the parts that do not decide the product's truth. When you move the review from prose to decisions, documentation stops being a bottleneck and starts being a fast, low-risk output channel.

Comments

[Marcus Kim]

Treating the YAML as a generation boundary rather than just an approval matrix is the sharp distinction here. The quick-start and error-matrix pockets fit constrained output shapes, while keeping the performance rationale and security note human-owned puts judgment where evidence and liability live. I'd make provenance machine-verifiable at the section level-perhaps with stable section IDs and generated-content metadata-because grepping forbidden terms or trusting an author field gets brittle after edits or copy-paste; executable code-block checks should remain separate, since ownership alone says nothing about correctness.