I had this conversation three times last week. Two founder coffees, one sales call — all of them asked the same thing: "why not just point Claude Code at the codebase and ask?" I use Claude Code every day, so I get it. It is a fair question.
The same is true of Cursor, Copilot, Codex. AI coding agents have closed the gap between "the code exists" and "I understand the code." Asking one of them "how does this feature handle expired tokens?" is faster than reading the source.
But the question Specsight answers is a different question. And the artifact a spec produces is a different artifact from the answer a chat produces. That distinction is the whole post.
A chat answer is for the person asking
When I open Claude Code and ask "how does our magic-link sign-in handle expired tokens?", the answer lands in my terminal. It is mine. If a PM on the same team asks the same question tomorrow, she gets a slightly different answer — phrased fresh, picking different examples, surfacing edge cases in a different order.
That is fine for me, the engineer who already roughly knows the answer and just needs a refresher. It is not fine for a team trying to maintain a shared understanding of how the product works.
A spec is a single artifact everyone reads. The PM reading on Tuesday sees what the engineer wrote in Monday's release notes sees what the customer success manager pulled into a help article. There is no "what version of the answer did you get?" because there is only one version.
According to Atlassian's 2025 research, teams already waste 25% of their working week searching for answers that should already be documented. Routing those questions through a per-person chat instead of a shared spec does not reduce that waste. It just changes the format of the search.
A chat answers "now". A spec carries continuity.
Ask Claude Code today and it tells you how the product behaves today.
Useful — until you need to know what changed. A new customer success hire asks "did this feature work differently a year ago, because our help article describes the old version?" Claude Code cannot answer. It does not have the version of the code from a year ago. Even if it did, it would have no record of the conversation, the merge, or the decision to change it.
A spec carries that history. Specsight syncs after every release — the Scenario for that feature gets a changelog entry attached, with what changed, when, and which merge triggered it. A PM looking at the feature today can scroll back through six months of evolution and understand how it got here.
A chat is a snapshot. A spec is a record. They are not the same artifact.
Twenty engineers asking the same question is not a spec
This is the structural difference most people miss. Two engineers can both ask Claude Code "what happens when a user hits their plan limit?" Both get accurate, well-reasoned answers. Both then act on them — file a ticket, draft a help article, brief a customer. The answers are not identical. The downstream work is not identical either.
Now scale that. Twenty engineers, four PMs, three customer success managers, all relying on per-conversation answers. The result is not a documented product. It is twenty-seven slightly different versions of the product, held in twenty-seven separate chat histories.
Only 4% of companies consistently document their processes, according to BPTrends. The other 96% are not failing because they lack tools. They are failing because the tools they have do not produce shared artifacts. The output of a chat is for the person who typed the question. There is nothing for the rest of the organisation to read.
A spec is the shared artifact. Without one, every team conversation about the product starts from "let me check" — even though the answer exists, just not in a form anyone else can see.
We use AI to build the spec. The spec is what your team reads.
Here is the part I want to be precise about. Specsight is built on Claude. The full scan, the merge sync, the report generation — all of it runs the Claude Agent SDK against your codebase. I am not against running AI over your codebase. I am working on exactly that problem.
The difference is the output. When you ask Claude Code a question, the output is a chat. When Specsight analyses your codebase, the output is a structured set of Context/Action/Outcome scenarios the whole team reads. Same underlying technology, completely different artifact.
So: should you use Claude Code? Yes, every day. So should I. It is the right tool for "I, the engineer with the terminal open, need to understand this code right now."
It is the wrong tool for "the whole organisation needs to know what shipped last sprint, what it does today, and what changed since the version we briefed the sales team on three weeks ago." That job belongs to a spec. And a spec belongs to the team, not to the chat history of whoever asked first.
The demo project shows what a team-readable spec looks like — Context/Action/Outcome Scenarios generated from a real codebase, updated on every release, browsable by anyone. If you want to point Specsight at your own repository, start free.
