# Mintlify Report Cited in Developer Post: Agent Requests Outpaced Human Page Loads on Its Sites

A community post by a developer who worked at LI.FI, Netlify, Flutterwave and Shardeum cites Mintlify's 2026 State of Knowledge Report for the claim that its sites logged 257 million agent requests in August against 131 million human page loads, and argues documentation accuracy should become part of shipping software.

Canonical URL: https://freelancenews.online/news/mintlify-report-cited-in-developer-post-agent-requests-outpaced-human-4906bdd4
Published: 2026-09-24T23:18:19.214Z
Updated: 2026-09-24T23:18:19.214Z
Source published: 2026-09-23T21:38:40.000Z
Event date: Not established
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

According to a developer post on dev.to, coding assistants — not people — are now the main consumers of product documentation, and a vendor report is used by the piece to gauge the scale of that change. Mintlify's 2026 State of Knowledge Report is cited by the author, who says they worked at LI.FI, Netlify, Flutterwave and Shardeum, for two numbers: 131 million human page loads against 257 million agent requests logged on Mintlify's sites during August, plus a survey result that just 7% of the companies polled had made every knowledge surface readable by agents. Since the item is a community post, the figures are the author's citation of a vendor report rather than independently verified numbers in the supplied evidence; the report itself is absent, so its methodology, sample and survey wording cannot be checked here.

That retrieval and accuracy constitute distinct problems is the post's core mechanism claim. According to the author, whenever a stale example gets served via a Model Context Protocol endpoint or Markdown, an incorrect method continues to be taught — and if content becomes simpler to retrieve, an error may grow simpler to repeat. The scenario used to illustrate this involves a change to an API authentication flow: engineering ships it, someone in DevRel updates the API reference, but a quickstart, a support article and an integration example still contain the outdated method. The author then asks: which version would a customer's agent locate?

That scenario is presented as a hypothetical rather than a documented incident, and the evidence does not name a specific product, release or date on which such a mismatch occurred. What the post does describe concretely is the author's own experience at four named companies, where documentation work depended on someone remembering the connections between a product change and the pages that describe it. The author states that this becomes harder to sustain as products grow, which is an argument about scaling rather than a measured result.

A product called Thally is also described in the post; the author says it links product repositories with the places teams explain their products, spots content that is affected, and opens pull requests backed by evidence, containing proposed updates, for a team to review. People and agents, it is described as serving, from the same source. No pricing, availability date, customer list, independent testing or third-party evaluation of that product appears in the evidence, so its capabilities remain the author's own description.

The editorial position advanced by the post is that a routine part of shipping software should be keeping product knowledge aligned, that a review of the instructions affected should be prompted by every meaningful product change, and that the evidence behind proposed updates should be shown. A qualification is added by the author: control over what gets published should remain with people, particularly where release timing, version support or product intent requires judgment. That is a stated preference about workflow, not a finding from the cited report.

For freelancers, designers and developers who maintain documentation, SDK guides or integration examples alongside client work, the practical tension the post identifies is that agent-readable content raises the cost of stale pages. If assistants increasingly read the same Markdown and MCP surfaces that humans do, an old quickstart is no longer just a page a visitor might skip; on the author's account it can be the version an automated reader selects. The post does not supply evidence that this happened to a named customer, so the implication should be treated as a risk the author is flagging rather than a demonstrated outcome.

The post's proposed remedy is procedural rather than technical: tie documentation review to the release process, require evidence behind proposed edits, and keep a human decision point before publication. The author frames the closing question for teams as whether someone following the published instructions can still succeed, and suggests that answer should factor into deciding whether a release is complete. Nothing in the evidence indicates this practice has been adopted at any named organization or measured against outcomes.

Several things remain unknown from the supplied material. The Mintlify report's publication details, survey population, sample size and question wording are not in the evidence, so the 7% figure cannot be assessed for scope. The August request and page-load counts are attributed to Mintlify's own sites, which is a vendor-specific measurement rather than an industry-wide one, and the post does not explain how agent requests were distinguished from other traffic. The Thally product's status, pricing and independent verification are likewise absent.

The post also does not address counterarguments or tradeoffs beyond the human-review point. It does not discuss what happens when a repository and a documentation platform disagree, how proposed pull requests are validated before a reviewer sees them, or what volume of review work such a process adds for small teams. Those gaps matter for freelancers and small studios, who often lack a dedicated documentation owner and would absorb any added review step themselves.

Read narrowly, the post is a workflow argument supported by one vendor's reported traffic figures and the author's experience at four companies. Read as a news event, it is thin: no release date, no version, no named customer and no independent verification are supplied. The defensible takeaway for this audience is the framing question rather than the numbers — whether the instructions a team publishes still work for whoever, or whatever, follows them — and that question can be asked without accepting the cited statistics at face value.

## Key points

- A dev.to author cites Mintlify's 2026 State of Knowledge Report for 257 million agent requests on Mintlify sites in August versus 131 million human page loads, and for a finding that only 7% of surveyed companies had made every knowledge surface agent-readable; the report and its method are not in the evidence.
- The post argues retrieval and accuracy are separate problems, using a hypothetical API authentication change that leaves the old approach in a quickstart, a support article and an integration example.
- The author describes Thally as connecting product repositories to documentation, identifying affected content and opening evidence-backed pull requests for review; no pricing, availability or independent testing is provided.
- The author's stated position is that documentation review should be routine at release time, with humans retaining control over publication where timing, version support or product intent requires judgment.

## Practical implications — editorial interpretation

Editorial interpretation: freelancers and small studios that maintain client documentation, SDK guides or integration examples may want to treat stale pages as a release risk rather than a backlog item, since the post's premise is that automated readers can surface an outdated example as readily as a current one. The evidence does not show this happening to a named customer, and the post offers no measurement of how much extra review work such a process adds, which is the main cost a solo practitioner would bear.

## Limitations and unknowns

The cited Mintlify 2026 State of Knowledge Report is not included in the evidence, so its survey population, sample size, question wording and publication date cannot be verified, and the 7% figure's scope is unknown. The 257 million agent requests and 131 million human page loads are attributed to Mintlify's own sites, a vendor-specific measurement, with no explanation of how agent traffic was classified. The API authentication scenario is hypothetical, not a documented incident. Thally's capabilities are described only by its author, with no pricing, availability date, customer list or independent evaluation. The post is a community contribution, so all claims are author assertions rather than independently verified facts.

## Sources

- [1] dev.to: The Future of Product Documentation
  https://dev.to/ekeneeze/the-future-of-product-documentation-2mn2
  Retrieved: 2026-09-24T23:18:02.162Z

## Claim references

- The author cites Mintlify's 2026 State of Knowledge Report for 257 million agent requests on Mintlify sites in August versus 131 million human page loads. [source 1]
- The same cited report is said to show that only 7% of surveyed companies had made every knowledge surface readable by agents. [source 1]
- The post argues an outdated example served through Markdown or MCP still teaches the wrong approach, so easier retrieval can make a mistake easier to repeat. [source 1]
- The author describes a hypothetical API authentication change where the old approach remains in a quickstart, a support article and an integration example. [source 1]
- The author says they experienced documentation work depending on someone remembering connections between product changes and content at LI.FI, Netlify, Flutterwave and Shardeum. [source 1]
- The author describes Thally as connecting product repositories with documentation, identifying affected content and opening evidence-backed pull requests for team review. [source 1]
- The author states people should retain control over what gets published when release timing, version support or product intent requires judgment. [source 1]