Feature Doc Generator in Practice: 9 Days to 15 Minutes

Let me tell you about a Tuesday at one of our customers — a mid-market payments company, about forty engineers, shipping to enterprise clients who demand a spec sheet and a test matrix with every release. I'll keep them anonymous, but the numbers are theirs, measured before and after they put the Feature Doc Generator into production.

Before, a Tuesday like this one meant a documentation fire drill. After, it means a fifteen-minute review. Here's the whole arc.

The before: a release held hostage by its own paperwork

The feature was a payment-retry system with configurable backoff. Engineering finished it on a Thursday. The customer's contract required a PRD, an updated spec sheet, a requirements-to-tests matrix, and a client-facing PDF before the feature could be enabled for their largest account. Standard enterprise gating.

So the release didn't ship Thursday. It entered documentation limbo:

• A PM spent Friday and Monday reconstructing the requirements by reading pull requests and interviewing the two engineers who built it — pulling them off next sprint's work to do it.
• A technical writer spent most of Tuesday turning those notes into a spec sheet, then chasing down the three edge cases the PM's notes glossed over.
• Someone in QA hand-built the test matrix in a spreadsheet, mapping requirements to test cases from memory and a Jira filter. Two requirements got mapped to tests that didn't actually cover them. Nobody caught it.
• The client PDF went out Thursday of the following week. By then a hotfix had already changed the backoff ceiling from five attempts to three. The PDF said five. It shipped anyway, because redoing it meant another week.

Total: roughly nine business days of elapsed time, four people, and a customer-facing document that was wrong on the day it was delivered. That last part is the one that keeps solutions engineers like me up at night, because a wrong spec in an enterprise contract isn't an embarrassment — it's an escape that can become a support incident, a trust problem, or worse.

The after: the same feature, run as a Mission

The next feature they built, they documented differently. A PM opened the Feature Doc Generator portal and typed one line: "Generate the PRD, spec sheet, test matrix, and customer PDF for the payment-retry feature merged this sprint."

Then she watched it work.

The observation rail lit up in real time. The Code Agent read the retry handler straight from the repository. The History Agent pulled the pull-request thread where the backoff ceiling was debated and surfaced why it landed at three attempts, not five — context the human-written PRD had missed entirely the first time around. The Test Agent walked the test suite and mapped each requirement to the tests that actually exercised it, flagging one requirement that had no covering test — a gap the hand-built spreadsheet had papered over months earlier. The Report Agent assembled all four artifacts.

Fifteen minutes in, she had drafts. Every claim in them traced back through the observation stream to a specific commit or test, so reviewing wasn't a rewrite — it was a spot-check. She read it, fixed two sentences of tone, and approved.

The part that isn't about speed

The nine-days-to-fifteen-minutes headline is the easy sell. But the outcome I actually care about is the two errors the Mission caught that humans had missed: the requirement with no covering test, and the backoff ceiling the old PDF got wrong. Those aren't productivity wins. Those are escapes avoided — the kind of defect that surfaces six weeks later as a customer complaint and a scramble.

The Test Agent didn't get tired on a Tuesday afternoon and map a requirement to a plausible-looking test. It read the suite and reported what was actually there, including the uncomfortable gap. That's the quiet value of generating documentation from the source instead of from memory: the source doesn't round up, doesn't misremember, and doesn't skip the edge case it argued about three weeks ago.

Where the human stays in the loop

I want to be clear that this is not "the robot published to your customer." It isn't. Reading the repository, the history, and the tests happens autonomously because it's read-only and reversible — there's nothing to gate. But the moment the Mission wants to publish the customer-facing PDF externally, it stops and routes an approval into the decision queue. The reviewer gets a magic-link email, opens the drafted artifact, and approves or rejects. Nothing leaves the building without a human hand on it.

That boundary is what makes teams comfortable running this on live releases. The autonomy is aimed at the tedious, reversible reading-and-drafting work; the judgment call — "is this right, and are we ready to send it" — stays with a person. In practice the reviewer spends their fifteen minutes on exactly that judgment, instead of on the archaeology that used to consume the fifteen days.

The compounding win

Here's what changed for that team over the following quarter. Because regenerating a document is now a fifteen-minute Mission run, they stopped treating docs as a one-time deliverable and started regenerating them on every meaningful change. The hotfix that would have left the old PDF wrong? Now it triggers a re-run, a quick review, and a re-publish. The spec is current because keeping it current is nearly free.

That's the shift. Documentation stopped being a bottleneck at the end of a release and became a byproduct of it. The PMs are back on their roadmaps. The writer edits for clarity instead of hunting for facts. And the enterprise client gets a spec sheet that describes the product they're actually running.

If you want the business case for why this matters at the leadership level, Harry's companion piece — well, mine — why it matters lays it out, and Trevor's how it works opens up the architecture under the hood. This is what shipped business applications built on autonomous AI workers look like when they land on a real team: not a demo, a Tuesday that used to hurt and doesn't anymore.