Every AI coding session forgets what the last one learned
AI coding produces good code and throws away the context that made it possible. Context engineering is how you keep it. Here's a team that runs the discipline in production.
Every AI coding session your team runs produces good code and loses whatever context made it possible. The agent finishes, the engineer commits, the next session starts fresh. The reasoning behind the decisions, why retries work the way they do, which deploy order is safe, what the migration rules are, stays in the head of whoever happened to figure it out. Run that pattern across ten engineers for a year and the gains never accumulate. Each session pays to relearn what the last one already knew.
The discipline that fixes this now has a name: context engineering. Prompt engineering is about phrasing a single request well. Context engineering is about what the model can see before it answers: the accumulated decisions, conventions, and hard-won judgment of the team, made available on every run. Get it right and each session starts smarter than the last. Get it wrong and you are paying frontier-model prices to repeat yesterday's mistakes.
The short version: capture what each AI coding session learns as a structured file in the repo, have the next session read those files before it writes any code, and review them like any other artifact. The knowledge compounds in version control instead of evaporating into commit history. Everything below is one team's production implementation of exactly that.
One ten-engineer A.Team team has run this pattern in production for several months. Berkan Hiziroglu, an A.Team AI engineer and AI Guild member, walked through it at a recent AI Guild StackTalk, the recurring session where A.Team's senior practitioners show each other what's actually running on live missions.
What context engineering looks like in a repo
Every session ends by writing a structured markdown file into the repo. Over time those files build into a record of how the team actually works: the AWS CDK deploy ordering, the retry behavior for a flaky third-party API, the rules around database migrations. The next session reads them before it touches any code. When a new engineer joins, the agent walks them through the team's norms by reading the files it wrote last week.
None of this lives in Notion or Confluence. It lives in version control, gets PR-reviewed when it changes, and gets read by the agent on every new session. That last property is what makes it context engineering rather than documentation: the knowledge is wired into what the model sees, not filed somewhere a human has to remember to check.
The team runs it on two open-source Claude Code plugins, Compound Engineering and Superpowers. Compound Engineering takes its name and shape from the loop Kieran Klaassen documented at Every: plan, work, review, compound, built on the principle that each unit of engineering work should make the next one easier rather than harder. Both plugins install in one line. The discipline that makes them compound is the part worth studying.
The loop that compounds
Three commands in Compound Engineering carry most of the work, and each one writes something the next session relies on.
/ce-plan reads the existing repo, including any markdown files previous sessions wrote, and produces a plan as its own markdown file.
/ce-work executes the plan. Single agent, same session.
/ce-compound runs at the end. It distills what the session did, captures any new conventions the engineer settled on, and writes a shorter markdown file into a separate folder.
Diagram of a single-agent workflow where every step writes markdown for the next session to read. Five connected boxes flow left to right: /ce-plan (plan a feature, agent asks ~10 questions) → Review (you read the markdown plan) → /ce-work (execute the plan, single agent) → Test + Iterate (loop back to plan if something's off) → /ce-compound (distill what was learned into markdown). A red "Iterate" arrow loops from Test + Iterate back to /ce-plan. A green arrow points from /ce-compound down to a box containing "thoughts / plans / + thoughts / best-practices / + compound files," with a note that these are committed to git so the next session reads all of it before asking a single question.
Berk runs this loop for most day-to-day work: bug fixes, small features, refactors against one or two files. It adds friction at the start, because the plan gets reviewed before code is written. The payoff is everything that no longer has to be re-explained. Over several months his team's repo accumulated best-practice files for AWS CDK setup, a document on multi-region deploy ordering, retry-pattern rules for a third-party API, and a long set of conventions for how migrations get written and approved. The agent reads all of it on every session.
When one agent isn't enough
Compound Engineering is single-agent, and for large features that ceiling matters. Berk has had sessions run six to eight hours on a single complex change.
Superpowers handles the same shape of work differently. The plan gets broken into tasks, each task spins up a sub-agent on its own git branch, the sub-agents run in parallel, and a reviewer agent checks each diff before merge. The same six-to-eight-hour change finishes in roughly twenty minutes.
Workflow diagram showing a heavier parallel sub-agent process reserved for big features. The flow moves left to right: Brainstorm (multi-turn Q&A to pin down scope) → Plan (task list with acceptance criteria) → Dispatch (one sub-agent per task, each on its own branch). Dispatch fans out to four parallel sub-agents working on feature/auth, feature/billing, feature/migration, and feature/api. The branches then converge into Reviewer agents (which gate every change before merge) and finally into Merge (single branch, ready to ship).
Berk reserves it for changes that touch multiple files and subsystems. A small bug fix doesn't warrant it; a feature that touches authentication, billing, and a migration runner does. The two plugins compose because they share markdown conventions. The team will sometimes plan in Compound Engineering, hand the final plan to Superpowers for execution, and run /ce-compound at the end to capture what was learned.
Align the humans before you spend the tokens
Plan review is where the cheapest course corrections happen. Compound Engineering ships a smaller command, /ce-proof, that publishes the plan to a shared URL where anyone with the link can suggest edits in real time, the way a Google Doc accepts comments. The engineer accepts what they want, pastes the final version back into the agent, and execution begins from there.
Berk's team uses it on anything that touches multiple services. A reviewer often notices that a proposed change isn't necessary, or that an existing service can already do the work. Catching that before execution saves agent runtime, engineer review time, and PR cycles.
What changes at team scale
Vineet Sinha, an A.Team solutions architect running similar patterns on a separate mission, pressure-tested the setup live with the question most engineering leaders eventually ask: when a ten-engineer team adopts this, what actually shifts?
I'd argue it's more important on a team. The markdown files hold how the team does things: our migration rules, our retry patterns, our region-aware deploy steps. A new engineer joins, runs /ce-plan, and the agent already knows the team's norms. You don't have to onboard them on the conventions twice.
The files are versioned and PR-reviewed like any other artifact. When a third-party API got fixed upstream, an engineer opened a PR to remove the retry rule from the markdown, and the next session's agent behavior reflected the change automatically.
Diagram showing how AI coding sessions compound over time. Three sequential boxes labeled Session 1, Session 2, and Session 3 connected by arrows. Session 1 is greenfield where the agent asks a lot of questions and you answer, producing 1 markdown file. Session 2 reads the session-1 plan plus compounds files, asks fewer questions, and produces 3 markdown files. Session 3 knows the team's migration rules, retry patterns, and deploy steps, producing 6 markdown files. A horizontal arrow at the bottom labeled "Time → Less explaining, more shipping" reinforces that each session inherits everything the last one learned.
The effect for the organization is that institutional knowledge stops being a function of who's in the room. The team's accumulated judgment runs against every new task, applied by the agent, version-controlled, and reviewed like code. For an engineering org under pressure to scale AI capability without scaling headcount, that's the lever that matters most.
What to watch for
Five things worth knowing before you adopt the pattern:
The markdown pile grows. Hundreds of files accumulate over a few months. Berk's team runs /ce-compound on the compound files themselves every couple of months, merging stale and redundant entries.
Hooks help, but agents route around them. Berk's shell hook denies drop, delete, push, and deploy. Most attempts get blocked, but occasionally the agent writes a SQL file containing a drop statement and runs the file as a script. The defense is reviewing the diff.
The compound file is load-bearing. Future sessions weigh it heavily when planning, so a bad pattern that lands in one becomes a default for everything after. Berk reviews it like a PR review of his future agent.
Greenfield needs more review than brownfield. On a new project the agent picks the stack, styling, auth, and database, and most of those decisions need active review. On an existing codebase, half are already captured in CLAUDE.md and the compound files.
Keep the docs in the repo with the code. Vineet tried splitting them into a separate repository on a multi-repo project and walked it back; the skills read from the local working directory by default.
The takeaway
Three months from now, when an engineer joins one of your teams and asks why a particular service handles retries the way it does, where does the answer come from? If it comes from a person, that knowledge is still living in heads. If it comes from a file the team has been writing into all year, it's compounding in the system.
The teams getting the most out of AI coding agents aren't the ones with the best prompts. They're the ones who worked out where institutional knowledge lives, and wired it into what the agent sees on every run. That's context engineering, and it's the difference between AI coding that gets faster over time and AI coding that resets every morning.
The A.Team builders behind this ship production AI for enterprises every day. Hire senior AI engineers →
A.Team's senior AI practitioners ship production AI systems that hold up and improve over time. This field report came from an A.Team AI Guild StackTalk.
Frequently asked questions
Context engineering is the discipline of managing what an AI model can see before it answers, so its output reflects the accumulated decisions and conventions of your team rather than starting from zero each time. In practice it means capturing what each session learns as structured files, storing them in version control, and feeding them back to the model on every run. It's the layer that turns one-off AI output into knowledge that compounds.
Compound engineering is a framework, coined by Kieran Klaassen at Every, for AI-assisted development where each unit of work is designed to make the next one easier instead of adding complexity. It runs a plan, work, review, compound loop: the final compound step documents what the session learned and codifies it for reuse, so the codebase and the AI's understanding of it both improve over time. It's one concrete way to practice context engineering, and there's an open-source Claude Code plugin by the same name.
Prompt engineering is about how you phrase a single request. Context engineering is about everything the model can see around that request: prior decisions, team conventions, retry rules, deploy ordering, and the reasoning behind them. A good prompt helps one answer; good context makes every answer inherit what the team already worked out. As base models improve, the phrasing matters less and the context matters more.
Write what each AI coding session learns into structured markdown files committed to the repo, and have the next session read them before it writes code. Review those files in pull requests like any other artifact, so a change to the team's conventions is versioned and deliberate. When a new engineer joins, the agent reads the files and already knows the team's norms, so onboarding on conventions happens as a side effect rather than a separate effort.
Only if the knowledge lived in that person's head. When a team practices context engineering, the reasoning behind its decisions lives in version-controlled files the agent reads on every session, not in individual memory. An engineer leaving takes their future contributions, but the conventions they helped establish keep running against every new task.
How to know your AI actually works
A principal engineer who's run evals at scale on the three questions every AI system has to answer, and why the teams falling behind are short on discipline, not tools.
How to evaluate Toptal: A structural checklist
Toptal's core strength is individual-contributor vetting, and their 48-hour candidate turnaround is real. Evaluate Toptal on four structural questions: the shape of the engagement you need, the timezone overlap, the total cost over the engagement window, and what happens if the first match isn't right. Answer those four and the decision becomes clear.
How to evaluate Turing: A structural checklist
Turing is an AI-powered staff augmentation marketplace with a large global talent pool and a fully automated vetting funnel. Evaluate Turing on four structural questions: whether the engagement needs a managed layer or is self-managed, whether the fully automated pre-screening is sufficient for your quality bar, what the total engagement cost is including the embedded platform margin, and what happens if the first match isn't a fit after the trial window closes.
Hire expert talent through A.Team
A.Team's network of 11,000+ vetted senior builders, with under 2% of applicants accepted. Engagements are time-and-materials with transparent per-builder pricing; your team manages day-to-day, and a dedicated Team Success contact runs the kickoff and stays close throughout. Describe the work and get a matched shortlist within 72 hours of the scoping call.
Talk to A.Team