# The best engineering orgs all guard this secret. Cerebras just published theirs. Now it has over 2.4M views.

> Cerebras's engineering post on building their internal knowledge base hit 2.4M views. Here's what they got right, what they missed, and how to build a knowledge base that compounds as your org grows - from someone who led knowledge management at Stripe and Uber.

- Date: 2026-07-24
- Author: Dave Nunez
- Tags: knowledge-management, engineering, company

---
A company knowledge base holds the IP, secrets, and tribal knowledge that makes up a company's DNA.
So why do our knowledge bases usually suck?

Cerebras published an excellent engineering post on how they built their internal knowledge base.
It garnered 2.4M views in its first week, which is more than double the views of Anthropic's [post](https://x.com/claudeai/status/2074244664199115201?s=20) on the history of Claude Code a week earlier.

![](https://falconer.com/api/file/s3/images/1784855872623-p8rajw.png)

There's increasing interest in constructing a great knowledge base for engineers and agents, but a lack of good examples to point to.

I led knowledge management at Stripe and Uber through hypergrowth.
I've seen the benefits of building a great knowledge base: faster onboarding, greater productivity, higher retention.
Despite the power of AI at our disposal, the average knowledge base is still a trash fire.
Yesterday's knowledge tools are not built for today's workflows.
[Falconer](https://falconer.com/) was founded as the AI-native knowledge base for AI-native workflows.

Our belief is that with the right approach, tools, and culture, you can make your knowledge base a compounding asset that allows you to move *faster* as your organization grows; not get bogged down in the sprawl of information.

In this post, I'll explain:

- why most knowledge bases suck
- how to construct the anatomy of a great knowledge base
- the cultural changes and sequencing of rolling out a great knowledge base

## I. Why most knowledge bases suck

The number one problem with knowledge bases is that there's no ownership.
Without accountability, it suffers.

Secondly, they're hidden.
You can reverse-engineer Stripe's world-class documentation or study Vercel's beautiful frontend design because they're public.
You can't tour another company's internal knowledge base.

### There are three common failure scenarios within a knowledge base:

- There's no information on the topic.

- There's missing or outdated information on the topic.

- There are conflicting pieces of information on the topic.

### Your knowledge base might suck if:

- information is scattered and out of date
- you often don't get the right answer from search
- most of your questions are answered by other people

ICs feel the pain long before managers do, because information naturally flows up the chain.
Managers hear complaints, but knowledge quality is notoriously hard to measure.

Like any engineering problem, you should measure the state of your knowledge base to see where the issues are and how you're improving over time.

Every hard problem needs to start with a quick dopamine hit to hook people into solving it.
The best engineers are typically masochists, so they get a dopamine hit from seeing where the problems are through data.

This is why Falconer built the first knowledge observability tool, [Knowledge Health](https://falconer.com/about/knowledge-health), to solve this exact problem.
Just plug in your sources and see where the fires are.

## II. How to construct a great knowledge base

### Start with the codebase

Cerebras picked a focused set of data sources for their knowledge base: code, wiki, incidents, Slack.

This is counter to the popular kitchen-sink company brain approach of connecting everything.
This approach is alluring because you get access to more information, but the quality of that information drops drastically.

Falconer believes in a strong knowledge graph, architected around your most reliable, authoritative source: the codebase.
It's structured, tested, and versioned.
LLMs love this context and knowledge graphs feast on it.

From there, we move up the ladder of sources.
Documentation is semi-structured and often unmaintained, not organized or tested the way code is.
Falconer turns this messy layer into an accurate and authoritative source with citations and auto-updates.

Slack is typically the most popular contribution source at any company, but also the noisiest, least structured, and most ephemeral.
Cerebras rightfully takes into account the conversation around any single message to gather context.

There are two important things Cerebras doesn't say about Slack.
First, knowledge typically gets trapped in DMs and scattered across channels.
The best approach is to store important information from Slack as documents, since it's the best collaboration surface for humans and agents.
Cerebras stores distilled knowledge chunks in a database, but that isn't a surface humans can browse, edit, and maintain.

### Re-think search

Great knowledge is useless if no one can find it.
Google has billions of queries *per day* to learn from.
But traditional search techniques don't work within organizations, because the data sets are small.
A wildly popular company page or search query might get a couple hundred hits in a week.
You cannot optimize search just from usage the way Google can, because the signal isn't there.

But engineers do constantly ask questions that rhyme, so query popularity within an org follows a power law.
You can see the bulk of search topics based on company priorities: release plans, goals, roadmaps, OKRs.
If you track popularity, you can bolster results and answer quality for 80-90% of searches.

Falconer is the only knowledge tool that believes in a powerful, yet simple and obvious principle: when you clean up the knowledge, you get much better results.
And it shows in the data:

![](https://falconer.com/api/file/s3/images/1784907480698-p8k1r.png "https://falconer.com/benchmarks")

### Use documents as a reliable source

Cerebras doesn't spend much time talking about docs, which seems like mostly just a Confluence wiki feeding the pipeline.
However, documents are still king!
Documents are where ideas are collaborated on, systems are architected, history is gathered, and where the company's future is defined.
Backlinks in docs tell the story of interconnectedness, and are increasingly where agents publish their artifacts and memories from coding sessions.
The opportunity is to treat documents as first-class data, with attribution, version control, citations, and accuracy.

This is where Falconer is built differently.
We start from those workflows to build documentation into an authoritative source, rather than a knowledge landfill like most wikis.

### Information architecture

Information architecture shapes the browsing experience for users and agents.
If your information is organized, it's easier to find and contribute to.
It's like the table of contents for your company.

### Knowledge graph over projects

Cerebras scopes results by project, which is a good start, but projects within growing companies are too fluid to depend on as a scope.
Projects are constantly being launched, shifted, and wound down.
A good knowledge graph supersedes projects dynamically by creating clusters of related teams, documents, and tasks.

### Invest in the authoring experience

A good authoring experience is the key to getting engineers to capture knowledge.
Some engineers like writing docs as code, which is also great for agents.
Some engineers like to write in a UI, which is ideal for simplicity and collaboration.

This is why Falconer supports both use cases: a Google Doc-like simple experience, and docs-as-code.
The best part is we built a two-way sync so you can edit documents in the UI with changes synced back to a repo.
And your agent can go nuts documenting in the repo, and they get synced back to a human-readable UI.

### Automate updates

Knowledge without automated maintenance is doomed to fail.
Imagine your code without tests, reviews, version control, and monitoring.
If something is worth writing down, it's worth keeping up to date.
But it's impossible to do this without the right tools.
When Stripe hit 10,000 people, we had 500,000 documents.

Falconer scans your documents for outdated information and *automatically* makes updates when code changes.
This is a critical piece to meet our goal of delivering perfectly accurate, perfectly complete documentation.

## III. The cultural changes and sequencing of rolling out a great knowledge base

Cerebras employees ask 15,000 questions a day, about 15 questions per person daily.
What's interesting is the list of questions they chose to illustrate the problem.
Not "how do I write a loop for my agent."
But questions that we all struggled with long before having access to AI:

- *Where do I find X?*
- *Who owns Y?*
- *What is Z?*

We constantly hear a few more gripes in this same vein from customers:

- *What did we decide*?
- *Who made the decision?*
- *Why did we decide this?*

These questions are getting even harder to answer because codebases are growing larger and there's less understanding of the code being generated.
No one wants to slow down and build *less*, but what we can do is improve our *understanding* of our systems and organizations.

There's an organizational number when, like clockwork, the pain of a poor knowledge base starts to become unbearable: [Dunbar's number](https://pmc.ncbi.nlm.nih.gov/articles/PMC8103230/#:~:text='Dunbar's%20number'%20is%20the%20notion,other%20individuals%20in%20the%20group).
You can hold about 150 stable relationships in your head, and right around 150 people is when an org stops knowing who's working on what.
I've watched it happen over and over without fail.

![](https://falconer.com/api/file/s3/images/1784855854049-xbgq7e.png)

### Create accountability

Unlike most parts of a company, knowledge base owners are non-existent, disempowered, or lacking the right tools.

Give the knowledge base a DRI, and ensure individual teams own their piece.

This is why we use the concept of "document owner."
This person sees and approves auto-updates to their documents, can see the issues across documents, and when they change teams or leave the company, their documents can have new owners assigned.

This creates accountability and prevents feedback from falling through the cracks.

### Use a phased approach

Cerebras allows teams to build connectors to the knowledge base.
That means the new knowledge base could launch without waiting for every team to migrate.
The teams that stay on their own connectors carry their own maintenance burden, which becomes motivation to migrate later to the core system.

For most companies, I recommend starting even smaller.
Start with one mission-critical team to overhaul their docs.
Timebox it to a two-week sprint.
The resulting docs will feel like night and day in comparison to other teams' docs.
Then everyone will follow suit with an example to follow.

This is why Falconer built all the pieces to overhaul your docs in one day:

- Generate the docs
- Organize the docs
- Monitor the docs
- Update the docs

## The single source of truth Holy Grail is within reach

At Uber and Stripe, and with Falconer customers today, we saw the full incentive loop of investing in a knowledge base.
Customers get features and fixes faster.
Managers get more productivity out of their teams.
ICs are blocked less often.
A good knowledge base creates a flywheel.

Cerebras references the holy grail as being a "single source of truth," but it rarely works in practice.
My philosophy is that if you introduce one thing, you must kill two things.
If anything, it silences the haters wanting to share the XKCD cartoon about creating a [universal standard](https://xkcd.com/927/).
Cerebras frames the core problem well.
Things change constantly.
People won't contribute through a surface that doesn't fit how they work.
Engineers want to leave feedback in PR comments, PMs want to comment in a Google Doc, managers hand out feedback in Slack.
If you make contribution painful, people will stop contributing.

The important tradeoff to make is providing the central system responsible for collecting, connecting, and maintaining all the knowledge.
[Falconer](https://falconer.com/) is in pursuit of the Holy Grail where there's one place to contribute *and* consume.