# Knowledge as code > Only one breakout AI use case is making a significant impact on knowledge work: coding, because code is versioned, tested, and machine readable. Treating company knowledge the same way, centrally stored, versioned, and observable, is how the rest of the organization gets that same leverage. - Date: 2026-09-10 - Author: Dave Nunez - Tags: knowledge-management, agents, company --- ![An open book spread showing the Knowledge as code essay rendered as a page on the left and its Markdown source with frontmatter on the right, on a dark Falconer background](/images/notes/knowledge-as-code-hero.webp) The capacity of a frontier model far outweighs an enterprise's ability to benefit from it. Only one breakout AI use case is making a significant impact on knowledge work: coding. Code is versioned, tested, and machine readable. So let's treat more areas of knowledge work like coding, starting with company knowledge itself. The approach of managing knowledge like code benefits the entire organization beyond just engineers. Knowledge is wisdom derived from information, such as all the lessons learned from building a company: customer calls, shipping product, code review, incident response, hiring, onboarding. A knowledge-as-code approach means knowledge that's: - centrally stored - versioned - observable ## The knowledge base Most work problems require transferring context from brain to brain, brain to machine, machine to machine, machine to brain. An MCP doesn't suffice if the underlying information is riddled with contradictions and inaccuracies. That information must transform into knowledge and be stored in a knowledge base of documents where agents and humans collaborate. Knowledge-as-code is the approach, and the knowledge base is its manifestation where humans and agents read and write to it. Documentation is a great place to store compressed knowledge. It's a living canvas for ideation and an archive for change management. Most importantly, it should be maintained. And you can only do that by treating knowledge like code. ## Centrally located knowledge With knowledge-as-code, everything that gets built, along with every relevant conversation with a customer or a teammate or an agent, gets reconciled and fed back into the knowledge base. That knowledge base is backed by a repo, accessible by an MCP, CLI, and API, giving humans and machines a single system to work across digital and physical worlds. Agents are geniuses, but they're clueless about your company. To answer a simple question without knowledge-as-code within an enterprise, an agent must search millions of documents and lines of code, flipping a coin many times along the way when that information is conflicting or out of date. A context graph alone on top of your sources just mixes all the outdated information and finds you an outdated answer. More tokens, more time, and the task still unsolved. If your knowledge base is curated and maintained, agents access the least amount of information needed to accomplish a task, achieving maximum accuracy, speed, and cost efficiency. ## Versioned knowledge If something is worth writing down, it's worth keeping up to date. But it's impossible to maintain your knowledge without versioning it. Relevant context within every employee's head should outlive them, and that history should be accessible to everyone at the company. Everyone wants to treat knowledge management as an information retrieval problem. But a tool that takes no responsibility for the correctness of the information it surfaces doesn't solve your problem. Documentation used to have one audience: a busy human foraging for information to accomplish a task. Now we have agents that read every character on the page. One thing these two audiences have in common is that they don't want wrong information. Knowledge-as-code means the knowledge base is tested for contradictions, inaccuracies, and gaps. ## Observable knowledge You can't improve what you can't see. Everyone knows what bad information looks like, but there's nothing you can do about it unless you know exactly what the issues are. Treating knowledge like code means applying observability and metrics to your knowledge health. Code is trusted more than docs, and that same trust can be built for a knowledge base by taking a similar approach to a code lifecycle: build, test, review, ship, monitor. With trust built through observability, teams use the knowledge base more instead of interrupting teammates in Slack, and the value of asynchronous communication compounds over time. ## Build like an owner Competition is a beautiful thing, which means that any model trained on publicly available information will be commoditized. You have no intelligence advantage if everyone in YC can buy the same frontier model. The only advantage is how you wield that model. The frontier pushes forward every six weeks, obsoleting the older models. Treating knowledge like code means you can benefit from new or fine-tuned models, instead of being stuck with the good-enough evals for your existing ones. When the friction of knowledge management dissolves, companies can move extremely fast. People can get accurate information instantly, build up their own knowledge, and share it back with the rest of the company. Decisions are made quickly, trust is built, and the company's history and special properties are preserved, even through constant, disruptive change.