enable Consistent AI Coding with Persistent Context Layers

An AI coding agent with a real codebase to read is a different animal from one spinning in an empty sandbox. Same model, same prompt — totally different output. The agent that wakes up to a tested component library, a config file declaring how things are structured, and a test suite that catches it when it drifts — that agent ships code you don't have to rewrite on Friday.

That's the actual enable. The context layer is the reason.

But every agent session in an ephemeral sandbox wakes up blank. No repo. No conventions. No history of how you wrote the last 50 components. So it improvises — and improvisation at scale is just entropy dressed up as velocity.

Here's the part that took me a while to internalize: "context" for a coding agent isn't chat history. It's not the previous turn. It's not memory across sessions. It's the files on disk that the agent can read. Every prompt is a fresh boot, and the only thing carried across turns is what the agent pulled into its window — which means the only thing carried across sessions is what the model can re-read when it starts.

What context actually is for an agent

Three things, in order of how often they get re-read:

1. The files it can see. Function signatures, types, existing patterns. Agents pattern-match more than they reason. Give them 50 examples of how you write a Button and the 51st comes out right; give them zero examples and the 51st is a fresh coin flip.
2. The tests. Tests are the only ground truth a model has. Test passes → code is correct. Test fails → code is broken. That's the entire feedback loop — and it's the part sandboxes almost never ship.
3. The convention files. CLAUDE.md, .cursorrules, AGENTS.md, a meaty README — anything that says "in this codebase, X". The agent reads these every session, when present. They're the only durable memory the model has.

Without those, the agent is doing freeform generation. Freeform generation looks magical in a 30-second demo and embarrassing in a 200-file repo.

Why sandboxed agents reset every session

The phrasing matters: they don't "forget" — they never persisted anything in the first place. A new run is a new process, often a tmpfs filesystem, no read access to last session's state. Even when the vendor offers a "memory" feature, it's usually a thin summary blob the model has to actively query, bounded by a context window, and quietly decayed by the third re-read.

A sandbox is built for the demo, not the second day:

/tmp/sandbox-7f3a/
├── src/
│   ├── App.tsx
│   └── components/
│       ├── Button.tsx      # didn't exist yesterday
│       └── Hero.tsx        # different style than last session
├── no tests
├── no CLAUDE.md
├── no .cursorrules
├── no design tokens
├── no git history
└── no node_modules committed

Every session, the agent reads "nothing" and writes "whatever." Iteration means: close the tab, lose the repo, start over, pray it makes similar choices.

This is the part that doesn't get talked about enough. The agent isn't dumb — it's reading from an empty shelf.

[[COMPARE: ephemeral sandbox state vs owned repo with shipped CLAUDE.md and .cursorrules]]

The cheap fix is files on disk

You don't need a vector store, a fine-tune, or a long-context ritual. You need ~600 bytes in the repo root:

# CLAUDE.md

## What this is
A SaaS dashboard, web + iOS + Android, shared component library.

## Code style
- Components live in src/components/<Name>.tsx
- Every component exports named, not default
- Variants come from a single variants object — no inline classNames
- Tokens come from @otfdashkit/tokens, never hardcoded hex
- Tests live in *.test.tsx next to the file they test

## What NOT to do
- Don't add new dependencies without asking
- Don't refactor code outside the files I name
- Don't invent a different file structure "for consistency"

## How to run
- pnpm test          # runs the test suite
- pnpm typecheck     # tsc --noEmit
- pnpm lint          # eslint .

Drop the same body into .cursorrules. Add an AGENTS.md. Now any agent that respects project rules — Claude Code, Cursor, Codex CLI, Aider, Continue — wakes up the same way every session. Six hundred bytes. The model changes; the conventions don't.

What an OTF kit actually ships

The same idea, carried further so you don't have to maintain the convention files yourself. A kit ships:

• The components. Around 200 of them, with the same name, props, and look rendering on web, iOS, and Android from one codebase. That's the visual + behavioral ground truth an agent pattern-matches against.
• The config files, pre-written. CLAUDE.md, .cursorrules, plus 20+ tested prompt files under ai/prompts/ for common tasks ("add a column", "wire a payment", "fix the type error on line 47"). They're not stubs — they're tested against Claude Code, Cursor, Codex CLI, and Aider before the kit ships.
• Design tokens that flip one theme across web and mobile from a single file. No more "wait, why is the button purple on iOS and blue on web."
• A 24-item design checklist the kit is gated against before release — so the agent has 24 fewer ways to drift.
• A production-shipping script that wires a custom domain, DNS, TLS, and a mobile build off one command.

The result: the agent that picks up an OTF kit has roughly the same mental model on day 1 as on day 200. It reads "tokens come from @otfdashkit/tokens", sees 200 examples of components following that rule, and writes the 201st the same way. The free MIT SDK on npm (@otfdashkit/ui, @otfdashkit/ui-native, @otfdashkit/tokens) is enough to put a kit-shaped context under any agent session you start.

Why this is the durable layer underneath the tool churn

Sandboxed tools — Lovable, Bolt, v0, Rork, the agent-browser demos — are genuinely great for the first 30 minutes. The model's loop is fast, the preview is convincing, you can show a client something by lunch. Where they bleed is session 4, when the agent rewrites a folder it shouldn't and you can't roll back, or session 12, when the demo project has drifted so far from the real one you'll never merge them.

Use them for the spike. Then move the work into a repo that has context the agent can read next session. That's the difference between a tool you used and a codebase you own.

[[CONCEPT: a context layer underneath every agent you pick]]

Pick the agent that shipped the best model this month. The conventions underneath should be the part that doesn't change when the model does.

What to do this week

1. Open the repo where you actually ship product. Does the root contain a CLAUDE.md, .cursorrules, or AGENTS.md? If not, that's the first 30 minutes.
2. Write three rules: where components live, how you style them, and what the test command is. Three bullets, no essay.
3. Commit them. Push. Next agent session, watch it follow them — and notice how different that feels from a blank-slate remix.

If you'd rather skip the blank-repo part, run an OTF kit's CLI — it ships a project with the components, the tokens, the config files, the prompt library, and the checklist already wired. Live demos at saas.otf-kit.dev for the web stack and fitness-preview.otf-kit.dev for the mobile one. The model changes next month. The shape underneath does not.