Documentation drift detection
Your internal docs drift out of date the moment code changes — renamed flags, moved endpoints, dead examples. Design an agent that detects drift between code and documentation and proposes fixes. What can it verify mechanically versus what it should never claim to know, and how do its patches get reviewed? How would you measure whether docs actually got more trustworthy, and give the pitch that gets a doc-weary team to adopt it.
triage_doc_anchors(anchors: list[str], live_symbols: list[str]) → list[str][["symbol:MAX_RETRIES","flag:--dry-run","concept:why we shard by tenant"],["maxRetries","--dry-run","MAX_RETRIES_LIMIT"]]out["patch","fresh","human-review"][["endpoint:/v1/users","config:queue_size","rationale:tradeoffs of at-least-once"],["/v1/users","queueSize","queue-size"]]out["fresh","checklist","human-review"][["symbol:parseJd","symbol:parse_jd"],["parse_jd","parse_jd"]]out["patch","fresh"]Turn the fuzzy goal into a bounded agent task. Say what the agent reads, what it may do on its own versus draft for a human, and what it must never touch. Then earn the trust: how you’d verify it before rollout, and the pitch (the problem, what you built, why it matters).
Agent build: design the agent in plain language (or narrate it). The coach grades the decomposition, the guardrails, the verification plan, and the pitch.