There is a particular flavour of AI engineering content that can make anyone using Claude feel like they're falling behind. Subagents, parallel orchestration, prompt routers, evaluation harnesses, custom tool servers, multi-step reasoning loops. The implication is that to ship anything reliable, you need to master most of it.
I want to push back on that, gently. I've been building production AI work in Claude Code for clients, and I have never personally spawned a subagent. I don't write parallel orchestration code. I rarely think about prompt routing. What's actually carrying the weight in my workflows are two open-source frameworks I didn't write, and most of what makes them work is plumbing rather than wizardry.
This article is about both of them, why I picked them up at different points, and what changed when I decided to make them aware of each other.
Compound Engineering: where the hard coding got abstracted
I came across Compound Engineering first, through a recommendation from another AI engineer I know. It's a framework from Kieran Klaassen and the team at Every, distributed as a plugin for Claude Code. The framing they use is set out in Every's Compound Engineering guide, and the plugin itself is on GitHub.
The framing is that each unit of engineering work should make subsequent units easier, not harder, which is the opposite of how most codebases evolve. The mechanics are a loop. You brainstorm an approach, plan an implementation, do the work, review it through specialised review agents, and then run a 'compound' step that takes what you just learned and bakes it back into the project's instructions, solution documents, and review configurations. The next plan benefits from the last review. The next review catches what the last fix taught you.
When it first arrived in my workflow, I wasn't using it for greenfield builds. I treated it as a way to make ordinary coding tasks more pleasant, and the plugin has evolved a lot since then. What I gradually realised is that the loop abstracted a meaningful chunk of the deeper AI engineering practice. The subagent management, the review orchestration, the learnings retrieval, all of that happens behind the workflows. I don't have to spawn anything or wire anything up. I just run a plan or a review command and the system handles the rest.
That's the first piece of the answer to the 'do I need to learn all of this' question. The answer is no, because Compound Engineering already did it.
DOE: where natural language replaced agent reliability work
The second piece came later, through Nick Saraev's six-hour agentic workflows course on YouTube. At the time I was building an email marketing system, and what attracted me to the framework was simple. I wanted to be able to speak to the system in natural language. Tell Claude to send a sequence, fetch a campaign report, regenerate a draft, and have it understand which scripts to call and what to do with the results.
The framework Nick teaches in the course, known as DOE for Directive, Orchestration, Execution, makes that practical. You write directives as Markdown SOPs that describe the goal, the available scripts, the expected outputs, and the known edge cases. The LLM acts as the orchestration layer, reading the directive and choosing which scripts to call in which order. The scripts themselves are deterministic Python that does the actual work.
The piece of arithmetic that landed for me in the course was about how errors compound. If your agent has 90% accuracy at each step and your workflow has five steps, you get 59% end-to-end accuracy. Ten steps and you're at 35%. The fix is not to ask the model to be smarter. The fix is to give the model less to be wrong about. Push as much as possible into deterministic scripts, and let the LLM only handle the decisions that genuinely need judgment.
What appealed to me alongside the accuracy story was the self-healing loop. Something breaks, the agent reads the error, fixes the script, updates the directive with what it learned, and the system is now a bit stronger than it was before. That solved a class of agent reliability problem I had previously been managing manually.
Running them side by side
For a while I used both frameworks independently, and they worked fine that way. DOE was governing my operations work, the natural-language-driven email system and a few others. Compound Engineering was governing my coding work, the planning and reviewing of new features.
The friction, when I noticed it, was philosophical overlap rather than conflict. Both frameworks have their own version of 'catch a problem, fix it, document the lesson so the next pass benefits.' DOE writes that lesson back into the directive. Compound Engineering writes it back into solution documents and review-agent configurations.
Without the two systems being aware of each other, that meant two things. The same lesson could end up captured twice in different places, sometimes worded slightly differently, occasionally even contradicting each other. Learnings captured by one framework were also invisible to the other. Compound Engineering would write a solution document in docs/solutions/, and DOE would have no idea those notes existed when it ran a directive that touched the same area.
This is a small problem, but it is the kind of thing that gets paid for in small annoyances forever if you do not address it.
What I actually did to couple them
The integration was less interesting than it sounds. I did not change either framework. I just told each one where the other put its outputs and gave Compound Engineering's review agents enough context to understand DOE's three-layer architecture.
The concrete edits lived in a few files. The agent instructions in CLAUDE.md got updated to describe the three-layer split, the directive/orchestration/execution boundary, and the locations where each framework writes its learnings. Those instructions got mirrored to AGENTS.md and GEMINI.md so any AI tool a collaborator opens the project in operates inside the same architecture. Compound Engineering's local configuration picked up a project context section explaining the three layers, so the review agents stopped flagging deliberate design choices as bugs. The directive template also picked up a few notes about where to look for prior solution documents before drafting a new SOP.
I wrapped the whole thing into a project template I now spin up for new automation builds. I call it CEDOE, for Compound Engineering plus DOE. It is not a new framework. It is two existing frameworks already credited to their authors, with the bridge between them written down so I do not have to re-derive it on every project.
What changed once they were coupled
Honestly, less than I expected, in the best possible way.
The systems were already working well apart. Coupling them did not produce a dramatic transformation. What it did produce was a small, durable removal of friction. I stopped having to tell either framework about the existence of the other. When Compound Engineering finished a 'compound' step and wrote a new solution document, DOE was already configured to look at that directory before running directives in the same area. When DOE captured a new edge case in a directive, Compound Engineering's planning step picked it up the next time a plan touched that workflow.
The deeper benefit, harder to point at but easier to feel, was the reassurance that both systems were leaning on each other for the things each was best at. Compound Engineering does the heavy AI engineering work. DOE does the reliability layering. When I write a new directive, it can rely on Compound Engineering for the content-generation work. When Compound Engineering writes a review, it has visibility into the outputs of the DOE side of the system.
You could probably use both frameworks separately and be fine. Coupling them just creates the environment where you can be reasonably certain you are not creating the same thing twice, and that things which should be shared between the two systems do not get missed.
Why this matters for anyone using Claude
The reason I wanted to write this is that a lot of the AI engineering conversation right now treats reliable Claude output as something that requires deep technical knowledge. Mastering subagents. Knowing when to parallelise. Designing your own evaluation loops. Understanding context windows in fine detail.
Most of that knowledge is genuinely useful. The point I am making is narrower. You can ship production-grade Claude workflows without it, because Compound Engineering and DOE have done most of the abstracting for you. Compound Engineering handles the planning, building, reviewing, and learning loops without asking you to know how subagents work under the hood. DOE handles the reliability of multi-step workflows without asking you to think about probability compounding.
This matters for two audiences in particular. The first is automation developers who are not classical programmers, the no-code crowd who have been getting closer to coding over the last year as Claude has become more capable. The second is technical builders who are not specifically AI engineers and would rather not have to become one in order to ship.
For both groups, the takeaway is the same. You do not have to learn all of it to do reliable work. Find a runtime architecture you trust, find a build-time loop that captures what you learn, and configure them to know about each other. That is most of the practice.
If you are feeling overwhelmed by the breadth of AI engineering content out there, my honest advice is to leave the deep tricks alone for now. Pick up Compound Engineering and DOE, get them talking to each other, and let the abstractions do the heavy lifting. I have been running this stack for a while, I have never personally spawned a subagent, and the work is some of the most reliable I have shipped. There are worse problems to have.
