Context as Code
Most teams doing AI-assisted development are already saving the wrong file.
They commit the generated code. They archive it, protect it, run CI against it. And they let the context that produced it
Most teams doing AI-assisted development are already saving the wrong file.
They commit the generated code. They archive it, protect it, run CI against it. And they let the context that produced it evaporate: the CLAUDE.md that took forty tries to get right, the rules file that nobody remembers writing, the prompt living in someone's scrollback that somehow made everything work. When that person leaves, it leaves. Nothing in the repo explains how to get what they got.
They're saving the binary and deleting the source.
---
This isn't a new mistake. It just has a new shape.
We spent forty years learning how not to lose control of code. Version control so you can see what changed and why. Review so a second person catches the mistake. Tests so behavior does not silently drift. Modularity so one change does not break six things. Refactoring so the cruft gets cleaned instead of buried. None of that was obvious at first. People had to get burned enough times to build the discipline.
The lesson from those forty years is not "use git." It's that source artifacts need the full discipline stack because they have a specific set of properties: they have dependencies, they rot, they accumulate bugs, they drift, they can be well or badly organized. Get any of those wrong and the cost compounds quietly until it doesn't.
Context has every one of those properties.
A rule that says "follow the existing patterns" depends on the existing patterns being good. It breaks quietly when they aren't. A context file written for last quarter's architecture will confidently steer the model in the wrong direction this quarter, and nothing will warn you. One vague instruction produces a whole class of bad output across every file the model touches, and you won't find the cause by reading any of those files. Context accumulates cruft. It duplicates itself. It can be brilliantly or carelessly organized. It's software. We're just not looking at it that way yet.
---
There's one more property context has that code never did: it should be alive.
A good context file isn't a snapshot. It's a living document that knows what's true right now: the current architecture, the active constraints, the decisions made this sprint and why. Static context rots by definition. The moment you write it down and stop updating it, it starts steering the model toward a world that no longer exists.
This is where the "prompts as code" conversation has been failing. It treats context like source code frozen at commit time. But context is closer to configuration that needs to respond to the system it describes. The teams getting this right aren't just versioning their prompts. They're building pipelines that keep context synchronized with reality: pulling in current docs, injecting live state, parameterizing the parts that change so the parts that don't stay stable. Dynamic by design, not static by default.
The discipline stack still applies. You version it, review it, test it, modularize it. But the artifact you're managing is a template with inputs, not a file with answers.
---
There is a structural shift underneath all of this.
When generated code is the disposable layer, the build artifact you can regenerate cheaply and quickly, then context is the thing you actually author. The real source is moving up a level. The code is output. The context is the work.
Most teams haven't reorganized their practices around that inversion. They still treat the generated files as the artifact worth protecting and the context as notes. That's backwards, and the cost shows up exactly where you'd expect: in the engineer who is unusually good with these tools, whose results nobody else can reproduce, whose knowledge evaporates the day they leave. Their code is in the repo. Their context never was.
---
Context as code is just the decision to stop letting that happen.
Put the context in the repo. Review changes to it. Notice when it rots and fix it. Keep the dynamic parts dynamic: the context should describe the system as it is, not as it was. Treat a working prompt as something you earned and shouldn't have to earn twice. Build the same discipline around it that a previous generation built around code, for the same reasons, because the properties that made that discipline necessary haven't changed. Only the artifact has.
We already lived through this transition once. Most teams lost that race.
The ones who won were the ones who recognized what they were actually building before everyone else did.By Eduarda Ferreira