Engineering
The README describes a version of the code that no longer exists
A monthly list of statements in your docs that the code no longer supports.
What the worker does
An AI worker keeps technical documentation honest by comparing it against the code on a schedule. Each month it reads the documented setup steps, configuration keys and entry points through the GitHub connection, checks them against the current repository, and posts a list of statements that are no longer true with a file reference for each. Rewriting is proposed as a draft, never applied silently.
- Runs
- Monthly
- Connections
- GitHub, Notion, Google Drive
- Output
- A list of false statements
Documentation rots quietly and then all at once
A config key gets renamed. The setup section still names the old one, and it will keep naming it until a new engineer follows the instructions, fails, and asks in Slack. That question is the only detection mechanism most teams have, and it fires once per new hire.
Nobody rereads documentation against the code, because there is no moment when that becomes urgent and the work is dull in a way that resists volunteering.
The four checks that catch most of the rot
Named configuration keys
Every environment variable and config key mentioned in the docs, checked for existence in the repository. This one check finds the majority of failed onboarding.
Setup commands
The commands in the getting-started section, compared against the scripts and manifests that actually exist. A script renamed six months ago is still in three documents.
Referenced paths and entry points
File paths quoted in the docs that no longer resolve. Common after any restructuring, and invisible until someone follows the link.
Pages with no recent edits
Documents untouched for a long time while the code they describe changed often. Not proof of rot, but the right place to look first.
The two jobs, briefed separately
Auditing and drafting need different acceptance criteria, so they are usually two tasks.
| Job | What the worker delivers | What you do with it |
|---|---|---|
| The monthly audit | A list of statements that no longer match the code, each with a file reference | Decide which are worth fixing |
| The missing page | A draft written from the pull request description and the code itself | Edit it, then publish it as a versioned doc |
What this does not solve
It catches statements that contradict the code. It does not catch documentation that is accurate and useless, which is the more common failure: a page that describes every parameter and never says what the thing is for.
That problem needs a person who understands both the system and the reader, and no schedule fixes it.
Questions people ask
+Where should the documentation live for this to work?
Anywhere the worker can read: Polaris Docs, Notion, Google Drive, or markdown files in the repository through the GitHub connection. Docs kept inside Polaris get versioning and review comments, which makes the correction cycle shorter.
+Can the worker fix the documentation itself?
It delivers a proposed rewrite as a comment on the task, with the draft attached. Applying it is a human action, which matters because a statement that looks stale is sometimes documenting an intentional legacy path.
+How is this different from release notes?
Release notes describe what changed for the user in a specific release. This job checks whether long-lived reference documentation still matches the code, which is a different question and runs on a different schedule.
+What does a monthly audit cost?
It depends on the size of the documentation set, and the work log records the estimate line by line: pickup, searches, prose written and files produced. Billing is about $2 per human-hour delivered, and any line can be challenged from the log.
Related
The engineering work that is not writing code
Five jobs that sit between an engineer and the code, and what an AI teammate does with each.
You shipped twenty-three things and announced four
A draft built from what actually merged, plus a list of the changes nobody described.
Getting a process out of one person's head
The process exists. It is in someone's habits and in six months of Slack threads. A worker interviews and reads until it is on a page.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.
Connect Notion to Polaris
Notion decides what Polaris can see, page by page, because an internal integration only reaches what you explicitly share with it.
Hire an AI technical writer
The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.
Skill file
The capability an agent has, written down where a person can read and edit it.