How one team made their AI coding workflow compound

Recording: https://www.loom.com/share/21ff1ade42ef4488b0bb920418b4392e

Every AI coding session your team runs produces good code and loses whatever context made it possible. The agent finishes its work, the engineer commits, the next session starts fresh. The reasoning behind the decisions stays in the heads of whoever happened to figure it out.

One ten-engineer team has been running a different pattern in production for several months. Every session ends by writing a structured markdown file into the repo. Over time those files build up 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 team, the agent walks them through the team's norms by reading the files it wrote last week.

The setup runs on two open-source Claude Code plugins, Compound Engineering and Superpowers. Berkan Hiziroglu, an A.Team AI engineer and AI Guild member, walked through the workflow at a recent AI Guild StackTalk. The AI Guild gathers A.Team's senior AI practitioners for recurring sessions like this one, where they show each other what's actually running on live client missions.

The plugins are open source and install in one line. The discipline that makes them compound is the part worth studying, and that's what follows.

The workflow, in detail

Three commands in Compound Engineering carry most of the work, and each one writes something the next session will rely on.

/ce-plan reads the existing repo, including any markdown files previous sessions have written, and produces a plan as a 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 in the repo.

Diagram 1. The Compound Engineering loop. Plan, work, compound, and the next session inherits all of it.

Berk runs this loop for most of his team's day-to-day work: bug fixes, small feature additions, refactors against one or two files. The setup adds friction at the start of each session because the plan has to be reviewed before code is written. The payoff comes from what's no longer being re-explained.

A few categories of file have accumulated in his team's repo over several months. Best-practice files for AWS CDK setup. A document on the order multi-region deployments need to follow. Retry-pattern rules for a third-party API that occasionally fails. A long set of conventions around how database migrations get written and approved. 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.

When the team uses Superpowers instead

Compound Engineering is single-agent. For large features, that ceiling matters. Berk has had sessions run for 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. A reviewer agent checks each diff before merge. The same six-to-eight-hour change finishes in roughly twenty minutes.

Berk reserves Superpowers for changes that touch multiple files and multiple subsystems. A small bug fix doesn't warrant it. A feature that touches authentication, billing, and a migration runner does. The two plugins compose without conflict 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.

Diagram 2. Superpowers fans out parallel sub-agents, each on its own branch, and gates the merge with reviewer agents.

Aligning humans on the plan before tokens are spent

Plan review is where the cheapest course corrections happen. Compound Engineering ships a smaller command for exactly this, called /ce-proof. It publishes the plan markdown to a shared URL. 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 that version.

Berk's team uses /ce-proof on anything that touches multiple services. Someone reviewing the plan often notices that a proposed change isn't necessary, or that an existing service can handle the work without the new code. Catching that before execution saves agent runtime, engineer review time, and PR cycles.

What this changes at team scale

Vineet Sinha, an A.Team solutions architect, has been running similar patterns on a separate mission and pressure-tested Berk's setup live. His question was the one most engineering leaders eventually ask: when a ten-engineer team adopts this discipline, what shifts?

The files are versioned and PR-reviewed like any other artifact in the codebase. When a third-party API the team had retry rules around got fixed upstream, an engineer opened a PR to remove the rule from the markdown file. The next session's agent behavior reflected the change automatically.

Diagram 3. Every session inherits what the last one learned. Onboarding shows up as a side effect.

The practical effect for the organization is that institutional knowledge stops being a function of who happens to be 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, this is the lever that matters most.

What to watch for

A few things to know going in.

The markdown pile grows. Hundreds of files accumulate over a few months. Berk's team runs /ce-compound on the compound files themselves every two months or so, 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. Occasionally the agent writes a SQL file containing a drop statement and executes the file as a script. The defense is reviewing the diff.

The compound file is load-bearing. Future sessions weigh the compound output heavily when planning. A bad pattern that lands in a compound file becomes a default for everything that follows. Berk reviews it like a PR review of his future agent.

Greenfield projects need more review than existing ones. The agent picks the stack, styling, auth approach, 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.

Use git worktrees for concurrent agents. Worktrees give each parallel agent a separate working directory. Berk typically has a handful of tabs open, each running an agent on a different feature.

Documentation belongs in the same repo as the code. Vineet tried splitting it into a separate repository on a multi-repo project and walked it back. The skills read from the local working directory by default, so moving the files means rewriting the skills.

A question for your own setup

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 the answer comes from a person, that knowledge is still living in heads. If the answer comes from a file the team has been writing into all year, that knowledge is compounding in the system. The teams getting the most from AI coding agents are the ones who've already worked out where institutional knowledge lives.

Compound Engineering and Superpowers make that question explicit at the level of every session.