From Mexico, I’ll admit something: on most projects I’ve worked on, the code moved faster than the docs, and the docs lost. Now that coding agents write a growing share of the code, that gap gets wider every week. On October 20, Mintlify launched Autopilot, a beta agent built for exactly that problem, and I think the design choices are worth a look even if you don’t use Mintlify.
What Autopilot does
Autopilot is available in beta on Mintlify’s Pro and Enterprise plans. It’s an always-on agent that reads your code and the context around it, drafts doc updates when something changes, and opens a pull request for your review. Mintlify describes three triggers: when code merges, it reads the diff and drafts the doc change; when the same support question keeps coming in, it writes the page that answers it; and when someone flags a mismatch in Slack, it picks up the thread and opens a PR. Pro plans connect your repos and Slack, while Enterprise can connect the full set of sources, including your project tracker, support tickets and feature flags.
Mintlify frames the problem with a number from its own 2026 State of Knowledge Report: only 24% of teams get product changes into their docs the same day, and 22% wait a month or longer. That’s a vendor-run report, so treat it as a direction, not a benchmark, but it matches what I’ve seen.
The guardrails are the interesting part
Autopilot doesn’t publish on its own. It opens a pull request, tags team members to review it and emails them, and in Mintlify’s words, “Nothing ships until someone on your team merges.” The Autopilot docs add that it commits to a new branch and never pushes directly to your deploy branch or the repository’s default branch. By default it suggests updates when your code changes and runs a once daily quality check.
There are no custom prompts to maintain. Mintlify says Autopilot has memory and learns your tone and voice, plus whether your team updates docs with every release or the moment something changes, from the PRs you review. Next on the list, according to the launch post, is learning from the edits reviewers make before merging, and a dashboard that shows what it’s doing.
Pricing is per outcome: each PR it opens or updates costs 250 credits, and runs that find nothing to update cost nothing, as the credits docs confirm. As Sig Advisory points out, the launch post doesn’t give a dollar price per credit, so you’ll have to check your own plan to know what a busy release week really costs.
My take
The best line I read about this launch came from Sig Advisory: “Out-of-date docs now mislead coding agents as well as people, because agents read your docs too.” That’s the real shift. A stale page used to confuse one developer for an afternoon. Now it can steer an agent into writing wrong code at scale, again and again.
I like the shape of this: the agent drafts, a human merges, and you only pay when it actually proposes something. That’s the pattern I’d want for any agent that touches shared knowledge. My caveats are the usual ones for a beta. A docs PR that reads well can still be wrong about behavior, so the reviewer has to know the code, not just the prose. And a flood of small PRs is its own kind of noise. If I were trying it, I’d connect one repo, review the first batch of PRs closely, and only then add support tickets and Slack.
Featured image: “Gyrocompass mg 8176” by Rama, Wikimedia Commons, CC BY-SA 2.0 FR. Cropped, resized to 1400×900 and lightly sharpened; the modified image is shared under the same license.
