Write the spec like a regular doc — free to start, no credit card.
the specgit blog
When AI doubles the roadmap, the spec becomes the bottleneck
· the specgit team
Keep the spec next to the code
Write like a normal doc in GitHub. Saves are commits, comments are PR threads, publish is a merge — free to start.
Free to start, no credit card. Zero Content Retention — we never keep a copy.
The boss in this week's comic does the arithmetic out loud. AI makes the building twice as fast, so the team can run twice as many ideas without hiring anyone. Then he delivers the ideas, and they land on Jordan's desk as a leaning tower of blank paper.
Alex says the true thing under his breath. More ideas means more specs. Nothing about a faster code path makes it quicker to decide what an item means, get the engineers who will build it to agree, or keep that answer accurate two weeks later once the code has moved.
Where the AI capacity went
Plenty of teams got a real speed increase this year, and leadership spent it on the number of items rather than on shipping the current list sooner. That choice is what the comic is about. Generating an idea costs close to nothing now, so the pile grows to whatever a prompt can produce over lunch.
Definition and review did not get cheaper at the same rate. Someone still writes down what the thing does, hands it to people who know the system, and takes their edits. Double the items and you double the passes through that, with the same people who were already in the room.
What the doubled pile costs the person writing it
Every item on that stack turns into a small standing job for a PM or a doc writer:
The last one eats the week. When fifty documents need attention because the code moved underneath them, keeping them accurate is work nobody was hired for, and it is the first thing dropped when the pile doubles. Engineers stop trusting the docs and ask in chat instead, so the definition work gets redone out loud, one item at a time. We went further into how that drift starts in why product specs go stale.
- a document saying what the thing does and why
- a decision written somewhere an engineer will look
- a review from the people who will build it
- an edit every time the code changes underneath the words
A spec that rides the same review path as the code
Google Docs, Notion, and Confluence are fine places to write. The trouble arrives after you publish, because the product changes in the repo, and a document living outside the repo updates only when a person remembers to go do it. At twice the item count, nobody remembers. Raw GitHub puts the spec in the right place and asks a PM to learn branches and pull requests to change a sentence.
specgit is a visual editor on the docs already in your GitHub repo. You type like it is a normal document. Saving writes a commit. Comments become pull request review threads, so an engineer answers a question about the spec where they already answer questions about the code. Publishing is a merge that honors the approvals your repo requires. GitHub stays the source of truth, and we never keep a copy of your content, which we describe on privacy and security.
Once the spec sits on that path, a doubled backlog moves through the review the team runs anyway, and keeping the truth current stops depending on someone chasing edits by hand. Repo files are also context that coding agents pick up on their own, so an agent working in that repo reads the spec without anyone exporting it first. Docs in a separate workspace take extra work to get there.
You can open the editor on a repo for free with no sign-up from the demo, and pricing covers what a team costs when you want more people in it. If you are weighing this against your current setup, Notion versus GitHub for product specs and docs as code for product managers get into the details.