diff --git a/src/content/blog/technical/where-the-docs-as-code-workflow-stops.mdx b/src/content/blog/technical/where-the-docs-as-code-workflow-stops.mdx
new file mode 100644
index 000000000..b9db6b003
--- /dev/null
+++ b/src/content/blog/technical/where-the-docs-as-code-workflow-stops.mdx
@@ -0,0 +1,73 @@
+---
+title: 'Where the Docs-as-Code Workflow Stops'
+subtitle: Published July 2026
+description: >-
+  Docs-as-code solves the tooling problem for documentation. It can't tell you which docs break when code changes. Here's the gap and how to close it.
+date: '2026-07-28T00:00:00.000Z'
+author: Frances
+tag: Technical
+section: Use Cases
+hidden: false
+---
+import BlogNewsletterCTA from '@components/site/BlogNewsletterCTA.astro';
+import BlogRequestDemo from '@components/site/BlogRequestDemo.astro';
+
+Your team has been on docs-as-code for 18 months. Markdown files, Git repository, pull request workflow, CI pipeline that deploys on every merge to main. You followed the playbook.
+
+At a developer conference last month, three attendees separately asked about an authentication method your product dropped in version 3.2. They had all read it in your quickstart. The quickstart was in your repository, right next to the code that made it wrong.
+
+Docs-as-code gets documentation into the right tooling. That turns out to be the easier half of the problem.
+
+## What docs-as-code actually solves
+
+Docs-as-code is a set of conventions borrowed from software engineering: documentation lives in source control alongside the code, and changes go through pull requests with CI/CD deployment.
+
+These conventions solve real problems. Writers can submit pull requests that bundle a code change and its documentation update in the same diff. Reviewers see both together. CI can run link checks and linting before anything merges. Documentation gets the same version history as the code, with rollback capabilities.
+
+Before docs-as-code, documentation often lived in a separate wiki or help center, edited by whoever had access, with no useful history of what changed or why. Moving documentation into Git removes an entire class of organizational problems.
+
+But docs-as-code doesn't specify what happens between a code change and a documentation update. It assumes someone updates the docs when code changes. The mechanism for that is discipline.
+
+## Why discipline doesn't scale
+
+When an engineer merges a PR that deprecates an endpoint, they know the docs need updating. They're also immediately pulled into the next ticket. The update gets filed as "I'll get to it." The docs stay wrong.
+
+Teams add a documentation section to PR templates. Engineers check the box. Sometimes the doc gets updated; often it doesn't. The template creates the appearance of process without the substance.
+
+A dedicated documentation owner helps, but it shifts the problem rather than solving it. Now the writer has to discover that a change happened. They watch Slack and scan pull request descriptions, hoping to catch changes before they surface as support tickets. This is surveillance work, and it doesn't scale as the codebase grows.
+
+According to a Postman survey, 68% of developers cite outdated documentation as their top frustration with APIs. Most of those companies have a docs-as-code workflow.
+
+<BlogNewsletterCTA />
+
+## The synchronization problem
+
+Version control tracks that documentation changed. It cannot detect which documentation should change in response to a code modification.
+
+The two systems operate independently. There is no connection in the data model that links `src/auth/token.py` to `docs/authentication/getting-started.md`. Git knows both files exist and tracks their individual histories. A change to the first one doesn't register as relevant to the second.
+
+This is what docs-as-code leaves open. Proximity is solved: docs live next to code, versioned and reviewable. Synchronization remains manual: nothing tells you which docs broke when a PR merged.
+
+The result is a false sense of hygiene. The docs are in Git, so they feel maintained. That they're wrong isn't visible until a developer files a support ticket or an API integration fails.
+
+## Why this matters more now
+
+[Documentation drift](/blog/technical/documentation-drift-detection-problem) has always been a problem. The cost increased when AI coding assistants became a primary way developers interact with APIs.
+
+AI agents read your documentation and act on it. Unlike a developer, an agent doesn't get skeptical when something feels dated. It takes your docs at face value and generates code accordingly. The State of Docs Report 2026 found that technical writers are already responding to this shift: spending less time drafting and more time fact-checking and validating. The role has moved toward verification.
+
+But manual verification has the same discovery problem as manual updates. You can't verify a page you don't know is wrong. [Making docs accessible to agents](/blog/technical/agent-friendly-docs-necessary-not-sufficient) is table stakes. Accuracy is the actual competitive surface.
+
+A stale doc in your repository now affects every AI tool that ingests your codebase. The blast radius has grown from individual developers to every coding assistant those developers have installed.
+
+## Closing the loop
+
+The gap between a docs-as-code workflow and accurate documentation is a change detection problem. When code changes, something needs to identify which documentation that change affects.
+
+Version control can't do this. It tracks file history, not semantic relationships between files and the product behavior they describe. Closing the gap requires a layer that understands what your documentation says and whether those claims still hold.
+
+AI-powered documentation monitoring tools can detect these relationships automatically. When an endpoint is deprecated or a parameter is renamed, the tool identifies which pages reference it and surfaces them for review. The writer doesn't have to discover that anything changed. The change comes to them.
+
+Docs-as-code and automated change detection are complementary. The workflow gets documentation into Git with a proper review process. Automated detection closes the synchronization gap the workflow leaves open.
+
+<BlogRequestDemo />