The next bottleneck after AI writes your code is reviewing the docs it writes A developer identified that document review, not code writing, is the new bottleneck in AI-assisted software development. To solve the imprecision of natural-language feedback on generated docs, they built MDXG Redline, a tool that anchors reviewer comments to specific text ranges in markdown and exports them as structured JSON. This allows AI agents to precisely locate and act on feedback, reducing ambiguity and round-trips. Coding agents draft specs, architecture docs, changelogs, and README updates in seconds — but a human still has to judge the quality of all that output. A year ago, the typical workflow was: you write a spec, you get comments, you revise, then you implement and get code review. Humans did most of the writing and coding. Now, agents produce first drafts of design docs, API references, runbooks, and onboarding guides — and they do it in seconds. Code implementation and code review can now be handled by agents, so those are no longer the bottleneck. What surfaced instead is the step right before: document review. A human has to read 2,000 lines of generated markdown and decide what's wrong. The writing part got dramatically faster. LLMs can assist with document review too, but compared to code implementation and code review, the human judgment required is still larger. This asymmetry compounds fast. Every agent-assisted project now has a stack of "needs human review" documents growing in a shared folder. If you're running multiple agent loops in parallel — one for the spec, one for the implementation plan, one for the test strategy — review becomes a pipeline stall. GitHub PRs remain the right tool when you need third-party review. But the step before that — the fast local self-review loop where you and your agent iterate on a draft — doesn't belong in a PR. Branching, diffing, and assigning reviewers is a lot of process for a first draft the agent wrote in seconds. The most common workaround today is to have the agent read the document and then fix things based on natural-language feedback: "The error handling in section 3.2 is too vague — be specific about what happens on timeout." This looks reasonable. The agent reads it, searches for something about error handling, and makes a change. But several things go wrong: Position is ambiguous. If section 3.2 has three paragraphs about error handling, which one did the reviewer mean? The agent guesses, and sometimes guesses wrong. Context is lost. The reviewer was looking at a rendered document — they saw the Mermaid diagram, the table layout, the code blocks with syntax highlighting. The prose feedback carries none of that visual context. Round-trips are vague. The agent applies a fix. Did it address the right spot? The reviewer pastes the updated draft back into the chat. No diff. No anchoring. Another round of guessing. The fundamental problem: prose feedback loses the structure the reviewer had in mind. The reviewer knows which text range they're commenting on — but that spatial information is discarded the moment they express it in natural language. What if the reviewer's comments came back as structured JSON, with every comment anchored to a precise location in the source markdown? That's what MDXG Redline https://github.com/oubakiou/mdxg-redline online demo https://mkdn.review/?url=https%3A%2F%2Fraw.githubusercontent.com%2Foubakiou%2Fmdxg-redline%2Frefs%2Fheads%2Fmain%2FREADME.md produces. The reviewer selects any text range in a rendered markdown document, leaves an inline comment, and on export the tool writes a JSON file like this: { "document": "api-spec.md", "docHash": "a1b2c3d4e5f6a7b8", "exportedAt": "2026-06-15T10:30:00.000Z", "comments": { "id": "f3a1c8b2", "quote": "The service retries up to 3 times", "comment": "Specify the backoff strategy — is it exponential? Fixed interval? This matters for downstream timeout config.", "headingPath": " 3. Error Handling", " 3.2 Retry Policy" , "sourceLine": 142, "created": "2026-06-15T10:28:11.000Z" } } Every comment carries: quote comment headingPath " 3. Error Handling", " 3.2 Retry Policy" , so the agent can navigate the document hierarchy sourceLine The actual export also includes blockId , startOffset , and endOffset — internal anchoring fields used for round-trip re-import into the next review round. The four fields above are the ones your agent needs. No guessing, no ambiguity. The agent reads the JSON, opens the source file, goes to line 142, and applies the feedback directly. The feedback JSON is a plain file on disk — any agent that can read JSON and edit files can consume it, regardless of framework or provider. MDXG Redline is designed around a review loop where an agent and a human pass a document back and forth: