Working with AI is a personal skill. Working with AI as a team is not.

Executive summary
Individual engineers build up valuable AI knowledge that evaporates when chat sessions end, forcing every new engineer and project to start from scratch. The fix is context as code: versioned markdown files in the repository (an AGENTS.md, reusable SKILL.md workflows, AI review instructions, and existing specs) that diff, travel, and get reviewed like any other code. To scale this, organizations need a centrally managed "company floor" of standards every project inherits automatically, distributed through tooling like our internal Nimbus scaffold and kept fresh through context harvesting. Teams can start today with a single AGENTS.md and one skill file, reviewed like code, so their best engineers' knowledge finally outlasts the conversation that created it.

We Made the Right Way the Default: meet Nimbus

A few years ago we started building Nimbus, an internal tool to standardize how our engineering teams start and structure cloud projects. It has since been used on over 250 of them: 250 repositories where the right way of working was the default from day one. The goal was not to write guidelines. It was to make the right way of working, the default way of working. If a standard is baked into the project template, you don't need to guide anyone to follow it. It's already there.

Nimbus solved a real problem. And now we want to use the same approach to standardize and share how AI-native work actually gets done. The challenge is that AI has introduced a version of this problem with no natural forcing function.

What matters now is not just code structure or infrastructure conventions. It is how you work with AI. What context do you give the agent? Which workflows actually work? What the agent needs to know about your project to be useful. Unlike code conventions, there is nothing that forces you to write this down. No linter fails. No test breaks. So it doesn't happen. The knowledge lives in chat windows and disappears when the session ends.

The engineer who has spent weeks figuring out how to work effectively with AI on your codebase has built up something valuable. But nobody asks, nobody makes time for it, and the next engineer starts from scratch. We call this context evaporation.

This is the real AI adoption problem. Not that people aren't using the tools. They are. But the knowledge they build up evaporates when the session ends. It never becomes an organizational asset.

The fix is the same one Nimbus was built around.

Context that never leaves the chat

Most AI adoption efforts focus on the wrong thing. Companies buy licenses, run training sessions, and publish guidelines. These things have value. But they don't solve the evaporation problem.

The engineer who built that impressive workflow will move on to another project. Or another company. The context he built up (the mental model, the refined approach, the lessons from what didn't work) goes with them. Or disappears into an archived chat thread.

The only way to fix this is to make context a first-class artifact. Not a wiki page. Not a Slack message. A versioned file that lives in the repository, travels with the project, and gets reviewed like code.

This is what we call context as code.

Context as code

The idea is simple. Everything an AI agent needs to work effectively on your project goes into files in the repository: the architecture, the conventions, the decisions and why they were made, the workflows that work.

In practice, this means a few specific things:

• An AGENTS.md at the root of the project. This is the entry point for any AI agent. It describes the project, stack, structure, and boundaries. It tells the agent what to do and what to never touch.
• Skill files (SKILL.md). Reusable guided workflows for recurring tasks. A skill for writing unit tests. A skill for updating documentation. A skill for reviewing a pull request. Each skill encodes a process that once lived in someone's head. Because skills are plain Markdown, they can be shared and reused across projects, not just within a single project.
• AI review instructions. A configuration that tells an AI code reviewer what to look for, what matters on this project, and what the team has decided about style and architecture. Every pull request is reviewed against these standards before human eyes land on it, catching the things that drain reviewers' energy so humans can focus on what actually needs judgment. And because the instructions live in the repo, they improve alongside the codebase: as the team's standards evolve, so does the reviewer.
• Existing specification documents. PRDs, ADRs, OpenAPI specs, architecture designs, data models. These were already good engineering practices. They are also excellent AI context. You probably have some of these already. Put them where the agent can find them.

None of this requires new tooling. These are markdown files. They diff cleanly, they live in version control, they are reviewable in any pull request, and anyone on the team can read and improve them.

flowchart TD
 A[AGENTS.md] --> D[AI Agent]
 B[Skills] --> D
 C[Specs · ADRs] --> D
 D --> E[Code · PRs · Decisions]
 E -->|Context harvesting| A

Context flows into the agent from the repo, and back out from each session into the repo. We call that last part context harvesting — more on that later.

Documentation and AI context are the same thing

You probably don't need to start from scratch.

A README that explains the architecture. An ADR that captures why you chose Postgres over MongoDB. A runbook that walks through a deployment. If your team already has these, you already have AI context. You just haven't pointed an agent at them yet.

This matters because it changes the framing. Building AI context is not a new workstream. It is an extension of the documentation discipline you should already have. The agent reads the same files your new engineers read on day one. If those files are good, the agent gets good context. If they don't exist, the agent starts blind. So does every new engineer.

The same logic applies to reusable assets. Traditionally, those were code and configuration: boilerplate templates, pre-configured pipelines, shared Terraform modules. Skills and context files now serve the same purpose, in plain markdown. No schema, no build step. They encode how to work rather than what to build, and they travel between projects as easily as copying a file.

You need a floor, and you need to keep raising it

Individual projects maintaining their own context is a start. But it doesn't scale well. Every new project starts from scratch. Conventions diverge. The approaches your senior engineers figured out on one project never carry over to the next.

The durable solution is a shared floor: a set of standards every project inherits automatically, and that gets raised over time.

The company floor is the set of standards that every project gets by default: linters, security checks, pre-commit hooks, CI pipeline templates, and shared Terraform modules. And now, AI context files too: skills, review instructions, a base AGENTS.md. It is not managed on a project-by-project basis. It is managed centrally and distributed automatically. When a new project is created, the floor is already in place. When the floor is updated, existing projects can pull in the changes.

We built this into an internal scaffolding tool called Nimbus. Nimbus predates AI tooling. It was built to standardize how teams start and structure cloud projects. When AI coding tools arrived, we didn't need a new enforcement mechanism. We extended the existing one. An AGENTS.md, shared skills, and review instructions became the next layer of the project template, generated alongside the Terraform configuration and CI pipeline.

The key mechanism is reinit. When the Nimbus template evolves, projects can pull in the changes via a 3-way merge. Your local customizations are preserved. The company floor stays current. This is the difference between a one-time scaffold and a living standard.

Senior engineers now have a new surface

Senior engineers have always been the carriers of institutional knowledge. When you don't know why a decision was made, you ask them. When you need to understand how a system really works, they walk you through it. This is valuable, but it doesn't scale. The knowledge lives in their heads, surfaces in code reviews and messaging threads, and disappears when they move on.

AI-native practices change this. Instead of answering the same architecture questions repeatedly, a senior engineer can encode that knowledge into an AGENTS.md, a skill, or an ADR. Once it's in the repo, every engineer on the project benefits from it, and so does every AI agent working on your team.

The impact shifts from the project level to the organizational level. From "I helped this team today" to "I shaped how every team works from now on." That is a different kind of contribution, and it deserves recognition and protected time.

The context should grow back

One problem remains. These files get written, and then they go stale. The architecture changes. New patterns emerge. The skill that was accurate six months ago no longer reflects how the team works. This is the documentation problem, reappearing in a new form.

This is hard, and we haven't fully solved it. The company floor stays current through reinit. But the project ceiling (the team-maintained context) requires active upkeep.

Some of this is just documentation hygiene: updating context files when architecture changes, retiring skills that no longer apply, reviewing them in pull requests like any other file. That should be part of how a functioning team works, regardless of AI tooling.

The direction we are exploring is called context harvesting. After a significant development session, an agent analyzes the code changes and the conversation that led to them, and proposes updates to the project's context files. What did the team learn? What decisions were made? What patterns emerged that should be captured?

Some AI tools already do something like this internally. Claude's memory consolidation, for example, automatically distills sessions into persistent notes. We want the same behavior, but pointed at the repo: an "autodream" that runs at the end of a session, reads the diff and the chat, and opens a pull request with proposed context updates for a human to review and merge.

This closes the feedback loop. Context flows into the agent from the repo. Knowledge flows back out of the session into the repo. Over time, the context gets sharper rather than stale.

This is not built yet in the way we want it. But the direction is clear.

What to do if you don't have Nimbus?

You don't need a scaffolding tool to start. You need a decision.

Start with one project. Add an AGENTS.md. Write down what the project is, how it's structured, what the conventions are, and what an agent should never do. Spend an hour on it. Ask your best engineers what they know about the project that isn't written down anywhere, and write that down too.

Then add one skill. Pick the most repetitive task your team does with AI (writing tests, reviewing PRs, updating documentation) and write a SKILL.md that encodes how you do it.

Review both files in your next pull request. Treat them like code.

The goal is not a perfect context system from day one. The goal is to break the habit of letting knowledge evaporate into chat windows. Once the files are in place, they will improve. Once they improve, people will use them. Once people use them, the organization starts to learn.