Building Is Easy Now. Auditing Is the Hard Part (Especially Your Docs)

Building is easy now. Auditing is the hard part (particularly your docs).

At n8n's most recent In The Loop 2026 keynote, VP of Product and Design David Roberts made the point that building is now easy. The hard part is the auditing and evaluation.

When AI assistants and agents can generate complex code and multi-step workflows in seconds the engineering bottleneck shifts downstream. You're no longer spending the majority of your time looking at a blank editor trying to write the thing. You're spending your time checking that what's been generated actually works, makes sense and won't silently break production.

As n8n point out in their Production AI Playbook the current day standard is Generate → Validate → Act.

If you're in a technical documentation role or running a docs as code workflow then this change will probably feel all too familiar as it's exactly what's happened to documentation.

The New Documentation Bottleneck

For years, the hardest bit of documentation was actually getting someone to write the first draft. Engineers didn't like context-switching into writing Markdown (or AsciiDoc), and technical writers were absolutely swamped chasing down product updates.

The "writing" bit is pretty much frictionless these days. With LLMs, cursor-based AI editors and automated doc generators that can read your codebase you can turn a feature branch into 1,500 words of nicely formatted Markdown in about 30 seconds.

Creating the documentation is straightforward. The real bottleneck is in the review, editing and auditing.

It's so easy to generate prose that the number of documentation PRs has blown out in both frequency and volume. The problem with AI-generated, quickly written docs is that they have a very dangerous illusion: they always look right on first inspection. The Markdown renders correctly, the headings are all in place and the tone is confident.

Yet underneath that polish, you have:

• Subtle technical hallucinations or obsolete API parameters.
• Confusing user flows which sound perfectly logical in the prose but which in fact don't work.
• Edge cases that only a Product Manager, Support Lead or QA Engineer would ever come across.

Just as in software engineering where the value has moved from producing the draft to verifying the truth.

Why Traditional GitHub PRs Fail the Audit Test

Here's the catch: as far as documentation generation is concerned we're in the future, our review process is still very much in the raw code diff.

In a docs-as-code setup your docs live in GitHub (which is excellent for version control, CI/CD, keeping the docs close to the code etc). A GitHub Pull Request however is a very poor place in which to read and edit prose.

When you ask a PM, a designer, or even a fellow engineer to review a 500-line Markdown diff:

1. They're fighting with the syntax rather than actually auditing the content. The reviewers are getting bogged down by the raw Markdown tables, the MDX components, the frontmatter and the broken line wraps rather than actually asking whether the instructions make any sense at all.
2. Non-technical stakeholders are effectively locked out. The people who actually know the edge cases of the product (the support team, the product marketers, customer success) will often just completely avoid GitHub PRs as they find the whole branches/files/diff view thing to be quite intimidating. See why non-technical reviewers won't use GitHub.
3. Review fatigue kicks in. When reviewing is high friction, people skim. They'll do a quick "LGTM" to clear their queue, and inaccurate documentation gets shipped to production.

In their human oversight playbook n8n make a very important point about building effective review loops. If you want humans to actually catch the issues then you have to meet them in an interface that's designed for them to be able to understand it quickly. You don't meet them in a pile of raw system logs.

Removing the Barriers with DraftView

We built DraftView because if review is now the most important stage in the documentation lifecycle then it absolutely has to be the easiest stage too.

DraftView is a visual review layer for docs-as-code projects that takes the messy state of a GitHub PR and turns it into a clean, shareable review link. It does this without in any way interfering with your Git workflow.

• Read and edit in a familiar doc style interface: no more wrestling with raw Markdown diffs. DraftView presents your documentation in a clean way so reviewers can actually read it as the end user will. It makes any logical gaps or awkward phrasing very obvious.
• Instant native GitHub sync: reviewers can highlight text, leave comments and edit the prose all within the visual interface. Every single suggestion syncs back to the GitHub PR as a native suggested change. Developers can commit their fixes with a single click right in GitHub.
• A clean, authentic audit trail: removing friction doesn't mean removing governance. Everyone who reviews signs in via GitHub (respecting your private repo permissions) so every edit and comment is attributable to a real person in your PR history. Your audit trail is clean and your security team will be happy. Learn how to prove human review of AI-generated documentation.

Make Reviewing Your Superpower

When anyone can produce a page of documentation in seconds the teams that win aren't the ones who write the fastest. They're the ones who review the sharpest.

By taking away the syntactic friction of the raw GitHub diff you're enabling the right people to get into the conversation earlier, catching hallucinations and usability bugs before they get released and turning documentation review from a nightmare into a quick and collaborative process.

Ready to cut the friction out of your documentation reviews? Install DraftView on GitHub and turn your next docs PR into a clean visual review, or try it on any public PR first.