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.