Your Team Is Building With AI. Nobody Wrote Down How.

Your people are already building with AI. Some are getting great results. Some are shipping code nobody reads. The difference usually comes down to habits nobody wrote down. Let me catch you up on what a few practitioners figured out, and what you should copy.

Pick the tool for the job, not one tool for everything

One writer built the same expense tracker app with three Claude models and got three very different runs. Fable 5 finished the whole production-ready app in a single prompt, all five features working on the first pass. Opus 4.8 needed one follow-up to fix a CSV bug. Sonnet 5 took several tries, missing a filter connection, then botching headers, dates, and mobile layout.

The lesson is not "Fable wins." It is routing. Use the strongest model for complex, multi-table work. Use a mid-tier model for balance. Use the cheap, fast one for simple features. Your team should have a written rule for which model to reach for, based on task difficulty, so people stop defaulting to whatever they opened last.

Two files that carry your standards into every session

AI agents forget everything between sessions. Open a fresh chat and the agent has no idea what you are building or what your stack is. It guesses. Most guesses are wrong.

The fix is writing context down in files that live in your repo. Nick Babich splits this into two: CLAUDE.md as the operating manual and DESIGN.md as the design source of truth. One tells the agent how to work, the other tells it what the product should look and feel like. Google's Conductor extension does the same thing with a conductor/ folder holding product goals, tech stack, and per-language style guides.

The payoff is onboarding. As the Conductor walkthrough puts it, any teammate who clones the repo has the full project context immediately, no onboarding conversation needed. Your standards travel with the code instead of living in someone's head.

Plan first, or pay for it later

Context-driven tools force an order: build context, spec the feature, plan the work, then write code. Conductor writes a phased checklist in a plan.md and asks you to read it before it commits a single line. Get the scope wrong there and it is cheap to fix. Catch it mid-build and it costs you.

Dex Horthy, who coined the term context engineering, backs this with a warning. His team tried shipping code no human reviewed, and four months later threw the whole system out. Production broke, and Opus 4.1 could not find the root cause. It took days to trace a wrongly routed primary key, then three weeks to re-onboard humans to a codebase nobody had ever read.

His middle path is the one to steal: find where an hour of planning saves four hours of implementation, invest there, then let the agent generate code without reviewing every line. Horthy says that moves teams two to three times faster than hand-writing everything.

The dumb zone is real, and so are the limits

Horthy has a rule of thumb worth teaching. The less of the context window you fill, the better the output. Push a model too far and it hits the "dumb zone," where it starts doing stupid things like deleting your .env file. For a 1M window he stops around 300 to 400K. He also flags a tell: when the model says "you're completely right," the session is poisoned and you should start fresh instead of arguing with it.

That same discipline saves money. Claude Code enforces two throttles, a rolling 5-hour window and a weekly cap, and they drain based on conversation length, model choice, and tool use. Batch related requests, match the model to the real difficulty, and split heavy work into fresh contexts. These are the same habits, just seen from the billing side.

The deep cut

The scary failure is not slow code, it is code that works until it doesn't and nobody can fix it. Horthy's team spent three weeks re-learning a codebase no human had read. That is the bill for skipping review, and it lands months after the speed felt great.

So write down the one line your team keeps skipping: which steps a human must read before merge. Horthy's people still read every one of their four nightly agent PRs before merging. Design and architecture stay human. Boilerplate can run on autopilot. Draw that line explicitly, put it in your CLAUDE.md, and hold to it. That single rule is worth more than any model choice.

Three questions for your team

1. Do we have a written model-routing rule, so people know when to reach for the strong model versus the cheap one, instead of guessing?
2. Where does our CLAUDE.md and design context actually live, and does a new hire get it the moment they clone the repo?
3. Which steps must a human review before merge, and is that line written down, or are we trusting people to know it?