When your team's knowledge is a person, an AI has nothing to cite

Two numbers in the same survey do not fit together. Developers now say that trusting an AI answer requires knowing where it came from, and they say the place they go for a specific answer is the person sitting next to them. A person is not a citable source. There is no path to open, no line to check, no version to compare against. Baalda exists because the gap between those two numbers is not a cultural problem, it is a storage problem: team knowledge that lives in heads and threads cannot be cited by anything, human or machine, and the only fix is to make it a file at an address.

What did the 2026 Stack Overflow survey actually find?

Stack Overflow published the results of its 2026 Developer Survey on 6 October 2026, run over seven weeks with more than 30,000 respondents.

The AI findings got the coverage. 73% of people who use AI coding assistants use them daily, a third of daily users are in them four or more hours a day, and 62% view AI at least somewhat positively, rising to 71% among daily users. Claude Code (66%) and GitHub Copilot (59%) lead the agents.

The two figures this post is about were quieter.

On trust, Stack Overflow's write-up says: "good context is trusted context, and to trust what the AI gives requires source attribution (93%)." The best sources of that trusted context, per the same survey, are project goals and requirements (85%) and code and docs (73%).

On where answers come from: "The places to look for specific answers are the people you work with (72%), the code (63%), and documentation (60%)." Stack Overflow itself is used by 24%. Separately, 83% still ask a search engine and 70% ask their AI, and of the people visiting Stack Overflow less for simple questions (64%), 16% say they visit more specifically to check the source behind an AI answer.

All of those are Stack Overflow's own numbers, published alongside the survey, as of 6 October 2026.

Why can an AI not cite the thing developers trust most?

Because 72% of the time the source is a colleague, and a colleague has no address.

Think about what the top three answer sources look like to a tool. Code (63%) is citable: a repository, a file, a line, a commit. Documentation (60%) is citable, assuming it exists and is current. People (72%), the biggest single source, are not citable at all. The knowledge is real, it is the most trusted thing on the list, and it is stored in a form nothing can point at.

This is why the 93% figure is harder than it sounds. It is not a request for footnotes. It is a request that every claim resolve to something the reader can go and look at. For public knowledge that is easy, which is exactly why Stack Overflow spent fifteen years being the answer. For the knowledge a team actually runs on, which deploy is safe on a Friday, why the auth provider was swapped in August, what the client said in the call nobody minuted, there is usually nothing to resolve to.

So when an AI answers a question about your own system, one of two things is true. Either it is working from code and docs, which are citable and are also the parts you already had. Or it is working from whatever got pasted into a prompt, and there is no source to attribute because the source was somebody's memory an hour ago.

What does a citable answer look like in practice?

It looks like a file path. Baalda is a team second brain: plain markdown files on your own disk, edited by several people at once in real time, with an AI reading and writing those same files over the Model Context Protocol. How MCP works for notes covers the protocol itself. The part that matters for attribution is what the tools hand back.

A search over the vault returns hits shaped like this:

{
  "docId": "note_7f2a",
  "title": "Deploy runbook",
  "relPath": "Team/Runbooks/deploy.md",
  "score": 0.78,
  "kind": "note"
}

And reading one returns the content next to its identity:

{
  "docId": "note_7f2a",
  "vaultId": "vault_19",
  "title": "Deploy runbook",
  "relPath": "Team/Runbooks/deploy.md",
  "permission": "edit",
  "revision": "rev_41",
  "content": "## Friday deploys\n..."
}

Three things follow from that shape, and they are the whole argument:

• The citation is a path, not an identifier. Team/Runbooks/deploy.md is a file a person can open in the app, on disk, or in any markdown editor. A vector store can give an agent a chunk id, which satisfies a developer only if that developer has access to the vector store and knows how to read it. A path satisfies anyone on the team.
• The cited thing is also the editable thing. If the answer is wrong, the fix is to open that file and change the line. There is no separate re-index step, no "the model learned it wrong", no second copy that disagrees with the first. The same revision that came back with the read can be passed as expectedRevision on a write, so an agent correcting the note fails rather than clobbering a teammate who edited it in between.
• `permission` comes back with every read. Access in Baalda is set per folder and per note, so a vault can hold one thing a contractor may read and another thing only two people may touch, and an agent reaches exactly what the person whose token it carries reaches. The citation is scoped to the reader, which is the only version of attribution that survives contact with a real company.

Search covers files too, not just notes. A hit carries kind: "note" or kind: "file", so the text extracted from a spreadsheet or a PDF in the vault ranks alongside the markdown and comes back with its own relative path. Baalda is open source under Apache-2.0, self-hostable, and free to run locally, with a paid Team plan for hosted sync. The files stay markdown on disk either way, which is what makes the path a durable citation rather than a link into somebody's product.

Where this does not help

A vault does not make the 72% write anything down.

That is the honest limit and it is a large one. Everything above gives attribution a target. It does not produce the content. If the reason your deploy knowledge is in one person's head is that nobody has twenty minutes to write it out, a notes application changes nothing about that, and a team that installs one and keeps working the way it worked will have an empty vault and the same problem. The survey's 60% who use internal documentation are presumably the teams who already solved the writing part.

Three more things it does not do:

• A path proves what the model read, not what it used. A tool result naming Team/Runbooks/deploy.md tells you that note was retrieved. Whether the sentence in the answer actually came from it, rather than from the model's training, is not something the protocol can establish. That is a real gap and nobody has closed it.
• A citation is not a correctness check. A confidently wrong note gets cited exactly as cleanly as a right one. What you gain is that the wrong thing now has an address, so it can be fixed once instead of being re-explained in five threads.
• For one person, this is overhead. Obsidian is also plain markdown on disk, and a local MCP server over an Obsidian vault gives an agent file paths just as well. It is free, the plugin ecosystem is far deeper, and if nobody else edits your notes the multiplayer and permissions machinery is weight you are carrying for nothing. The case for a shared vault starts at the point where the answer has to be the same for everybody.

What should a team change this week?

Pick the questions that currently get answered by a person, and give three of them a file.

Not a documentation project. Three notes. The one about how to deploy, the one about why the architecture is the way it is, and the one holding whatever is currently in flight. Put them in a folder the whole team can read, give the AI a token scoped to that folder, and then watch what it cites. The useful signal is not the answer, it is the path at the bottom of it: if an agent keeps answering your team's questions without naming a file, you have found the knowledge that only exists in conversation.

The survey says developers now want to know where an answer came from. The uncomfortable implication is that most of what a team knows has never had a where. A team second brain is the unglamorous version of the fix: not better retrieval, just knowledge that has a location, which several people can edit, and which an AI can point at when asked where it got that.