Skip to content

6 · Compound Engineering — Integrate into Real Work

A single agent session produces code, but the larger return comes from what each session leaves behind for the next one. Without that residue, every task starts from the same cold position and the agent never gets better at working in a given repository. This module covers how to fit agents into an existing software workflow so that each task lowers the cost of the next, and how to prepare a codebase so the agent succeeds more often.

The work an agent does well is the recurring work you already do: pull requests, code review, continuous integration, refactors, and incident response. Wiring agents into that work, and making the codebase ready for them, turns one-off sessions into ongoing returns. Every prior module ended by telling you to keep the artifact. This is the module where those artifacts stop being loose files and start paying a dividend.

Compounding is the point of all of this. A task that also produces a reusable skill or a sharper instructions file pays a dividend on every future task. A task that produces only code pays once.

Concept

Where agents fit in real work. The recurring rituals of a project, rather than one-off scripts, are where an agent returns the most: drafting and revising pull requests, running a first-pass code review, keeping continuous integration green, carrying out mechanical refactors across many files, and triaging an incident by reading logs and proposing a fix. Each of these recurs week after week, so each is a place where a well-driven agent gives back time repeatedly.

Making the codebase AI-ready. An agent succeeds more often in a repository that was set up for it. Walk Triage and ask what would raise the agent's hit rate:

  • a navigational CLAUDE.md (Module 1) so it opens the right file without grepping;
  • tests (Module 3.1) and an eval set (3.2) so "done" is checkable and the agent can self-correct;
  • harness maps and recurring workflows captured as skills (Module 4) so common moves have the right tools, permissions, and checks;
  • clear module boundaries so a change touches a small, nameable surface.

None of these depends on a smarter model. They are investments in the repository that make every future agent run land more often.

The compounding loop. Each task leaves an artifact. The artifact makes the next task cheaper. Over weeks, the success rate on a repository climbs, not because the model changed, but because the by-products of work already being done were kept and reused. This connects to the north-star metric of the course: a repository made AI-ready is one where the agent runs further before it needs you.

The difference between work that compounds and work that doesn't is whether the task feeds back into the next one. An artifact closes the loop; code alone is a straight line that pays once.

flowchart TB
    T["A task"]
    A["Leaves a reusable artifact<br/>skill · rule · test · gate · sharper CLAUDE.md"]
    N["The next task is cheaper<br/>and lands more often"]
    D["Code alone — pays once,<br/>the loop never starts"]
    T --> A --> N --> T
    T -.-> D

Guided Lab

The Practice Repo slice for this lesson is pending. For now, use the built Module 1-4 artifacts on Triage as a walkthrough: identify one artifact already created by the earlier labs, such as a CLAUDE.md rule, a test, a gate, or a skill, then write down which later task it should make cheaper. The full two-task Practice Repo loop lands with the compound slice.

On your own codebase, pick one ritual on your real repository (pull-request drafting, review, or a refactor) and run it through an agent this week. Capture one durable improvement to the repository while you are there, and write down what it should save you next time.

Keep the artifact

This is the module where the per-lesson artifacts become a system. The thing to keep here is the index of them: a skills/ directory, a sharpened CLAUDE.md, and a small library of specs and gates, together with the habit of asking at the end of every task what it left behind that makes the next one cheaper. Every prior module fed this one a piece; here they wire into a loop where each job improves the next.

Self-check

You did it right if your second task was measurably faster or more reliable because of what the first one left behind — and you can point at the specific artifact that did it. If the second task was no cheaper, the first one produced only code, and the loop hasn't started yet.

Recall

Before moving on: what should every completed task leave behind, and why does that matter more than the code itself?

Answer

A reusable artifact — a skill, a rule, a test, a sharper instructions file. It matters more than the code because the code pays once, while the artifact lowers the cost of every task that comes after it.