Marktmannen wiki Coderen met AI

Compound Engineering

Laatst bijgewerkt

TL;DR: Werkcyclus van zes stappen (Brainstorm→Plan→Work→Simplify→Review→Compound) waarbij de laatste stap kennis vastlegt in het systeem, zodat elk volgend project sneller en beter wordt; de engineer verschuift van typen naar plannen, reviewen en het systeem verbeteren.

Compound Engineering is een AI-native engineeringfilosofie waarbij elke eenheid werk de volgende eenheden makkelijker maakt — in plaats van moeilijker.

Ontwikkeld door Every.to, die vijf producten runnen met voornamelijk één-persoon engineeringteams.

Het kernidee

Traditionele codebases worden moeilijker over tijd. Na 10 jaar vecht een team meer met het systeem dan dat het erop bouwt — elke nieuwe feature is een onderhandeling met de oude.

Compound Engineering draait dit om: features leren het systeem nieuwe capaciteiten aan. Bugs fixen elimineert hele categorieën van toekomstige bugs. Patronen worden tools voor toekomstig werk.

De hoofdloop

Brainstorm → Plan → Work → Simplify → Review → Compound → Herhaal

Volgens de README (oktober 2026) telt de kernlus zes stappen; de oudere Every-gids beschreef er vier (Plan → Work → Review → Compound). Brainstorm en plan schrijven nu samen aan één "unified plan" dat groeit van requirements naar implementatieplan.

Tijdsverdeling: 80% aan Plan + Review, 20% aan Work + Compound.

1. Brainstorm

Denk een feature of probleem door via interactieve vragen en leg alleen de requirements vast, nog vóór het implementatieplan (/ce-brainstorm).

2. Plan

Transformeer een idee naar een blauwdruk (/ce-plan). - Wat wordt er gebouwd? Waarom? Welke beperkingen? - Hoe werkt vergelijkbare functionaliteit? Welke patronen bestaan er? - Wat zeggen de framework-docs? Wat zijn best practices? - Welk aanpak? Welke bestanden moeten veranderen? - Klopt dit plan? Is het compleet?

3. Work

Uitvoering volgt het plan (/ce-work). De agent implementeert, de developer monitort. - Zet isolatie op (git worktrees of branches) - Agent implementeert stap voor stap - Draai validaties na elke wijziging (tests, linting, type checking) - Track voortgang; pas plan aan bij problemen

Als je het plan vertrouwt, hoef je niet elke regel code te bekijken.

4. Simplify

Verfijn de vers geschreven code op helderheid en hergebruik, vóór de review (/ce-simplify-code).

5. Review

Vang problemen vóór ze live gaan. Nog belangrijker: leg learnings vast (/ce-code-review). - Meerdere gespecialiseerde review-agents parallel, getoetst aan het plan; standaard alleen rapporteren, lokaal toepassen doe je expliciet - Prioriteer bevindingen: P1 (must fix), P2 (should fix), P3 (nice to fix) - Resolve bevindingen, valideer fixes - Leg patronen vast — documenteer wat fout ging om herhaling te voorkomen

6. Compound ⭐

De meest kritieke stap. Hier accumuleren de winsten (/ce-compound schrijft naar docs/solutions/; de volgende /ce-brainstorm en /ce-plan lezen dat als basis). - Leg de oplossing vast: Wat werkte? Wat niet? Wat is de herbruikbare inzicht? - Maak het vindbaar: YAML frontmatter met juiste tags - Update het systeem: Voeg nieuwe patronen toe aan CLAUDE.md, maak nieuwe agents - Verifieer het leren: Zou het systeem dit automatisch opvangen volgende keer?

Traditionele development stopt na de review. De compound-stap bouwt een systeem dat steeds beter features bouwt.

Bestandsstructuur

project/
├── CLAUDE.md                    # Patronen en instructies (groeit mee)
├── .compound-engineering/
│   └── config.yaml              # Projectconfig, aangemaakt door /ce-setup
└── docs/
    ├── solutions/               # /ce-compound output (learnings)
    └── plans/                   # /ce-brainstorm + /ce-plan: één unified plan
  • docs/solutions/ en docs/plans/ zijn de standaardmappen. Is docs/ in je project al inhoud, dan verplaats je alle CE-mappen onder één root met de instelling docs_root.
  • De oudere gids noemde ook docs/brainstorms/ en een todos/-map met bestanden als 001-ready-p1-fix-auth.md; de README noemt die niet meer — brainstorm en plan delen nu één planbestand.

De Plugin

Compound Engineering is beschikbaar als plugin voor Claude Code. Installeren doe je in een Claude Code-sessie:

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Draai daarna /ce-setup in je project: dat meldt optionele tool-mogelijkheden en maakt .compound-engineering/config.yaml aan als die ontbreekt.

Al geïnstalleerd? Ververs eerst de marketplace en update dan pas de plugin; alleen /plugin update houdt je op de oude versie (de plugin is omgebouwd naar een layout met alleen skills).

Omvang (README, oktober 2026): 36 skills, draait op 14 agent-hosts, waaronder Claude Code, Cursor en Codex (in Codex roep je skills aan met $ce-plan in plaats van /ce-plan). De Every-gids noemde eerder 26 agents, 23 commando's en 13 skills; die gids loopt achter op de plugin.

Kernlus-commando's

Commando Werking
/ce-brainstorm Interactieve vragen om een feature of probleem door te denken; schrijft een unified plan met alleen requirements
/ce-plan Verrijkt idee of requirements tot een implementatieklaar plan
/ce-work Voert het plan uit, met verificatie, commits en shipping
/ce-simplify-code Verfijnt de nieuwe code op helderheid en hergebruik vóór de review
/ce-code-review Multi-agent review tegen het plan vóór merge; rapporteert, lokaal toepassen is expliciet
/ce-compound Legt de learning vast in docs/solutions/
/lfg Volledige pipeline hands-off (zie hieronder)

Volgens de (oudere) Every-gids draaide de review met 14+ gespecialiseerde agents (security, performance, data, quality, frontend) en de compound-stap met 6 parallelle subagents; of de huidige versie zo werkt, is niet bevestigd.

Rond de lus

De README groepeert de 36 skills; een greep: - Rond de lus: o.a. ce-strategy en ce-compound-refresh - Op aanvraag: ce-ideate (nog niet weten wat te bouwen), ce-debug (starten vanuit een bug), ce-pov (een onderbouwd oordeel), ce-doc-review (plannen en specs reviewen), ce-explain - Git-workflow: o.a. ce-commit, ce-commit-push-pr, ce-worktree, ce-resolve-pr-feedback - Compound Packs (experimenteel): mappen met voorschrijvende regels (lokaal of als vastgepinde git-repo) om kennis over alle repo's van een organisatie te delen; planning baseert zich erop, review handhaaft ze.

/lfg: volledige pipeline in één commando

Start /lfg ná /ce-brainstorm, zodat het plant tegen echte requirements in plaats van een prompt van één regel. Het kiest de route naar een geverifieerde werkbron (een plan, of een ce-debug-fix bij een bugmelding), werkt die af, vereenvoudigt, draait code review en past de fixes toe, legt learnings vast, draait browsertests en commit. Met een git-remote pusht het, opent een PR en bewaakt CI met een begrensde herstellus; het merget niet zonder jouw akkoord. Zonder remote stopt het bij lokale commits. De Every-gids sprak van autonoom draaien "met 50+ agents".

De vijf ontwikkelingsstadia

Waar zit jij in je AI-adoptiescurve?

Stadium Beschrijving Bottleneck
0 Handmatige development zonder AI Jij
1 AI als slimme referentie (copy-paste) Jij
2 Agentic tools met regel-voor-regel review Jij
3 Plan-first, PR-only review ← Compound Engineering begint hier Plan-kwaliteit
4 Idee naar PR (één machine) Execution-snelheid
5 Parallelle cloud-uitvoering (meerdere apparaten) Compute

Stap 2→3 is de sleutelovergang: je vertrouwt het plan genoeg om de agent te laten implementeren zonder supervisie en reviewt alleen het PR-eindresultaat.

Overtuigingen om los te laten

Oud geloof Werkelijkheid
Code moet met de hand worden geschreven Wie typt — mens of agent — maakt niet uit; goed code maken wel
Elke regel moet handmatig worden gereviewd Bouw systemen die issues vangen in plaats van elke stap te bewaken
Oplossingen moeten van de engineer komen Engineers brengen smaak — welke oplossing past dit systeem en team
Code is het primaire artefact Een systeem dat goede code produceert is waardevoller dan één stuk briljante code
Eerste pogingen moeten goed zijn 95% garbage rate op eerste poging; itereer snel genoeg dat je derde poging klaar is vóór de eerste klaar was

Overtuigingen om te adopteren

  • Extraheer smaak naar het systeem — schrijf voorkeuren in CLAUDE.md, bouw gespecialiseerde review-agents, voeg slash-commando's toe. Een keer gedocumenteerd, elke keer toegepast.
  • De 50/50-regel — 50% van engineering-tijd aan features, 50% aan systeemverbetering (review-agents maken, patronen documenteren, testgeneratoren bouwen). Systeemverbetering maakt toekomstig werk exponentieel sneller.
  • Vertrouw het proces, bouw vangnettten — als je de output niet vertrouwt, voeg geen menselijke review toe; voeg een systeem toe dat de stap betrouwbaar maakt.
  • Plans zijn de nieuwe code — het plan is het belangrijkste wat je produceert. Ideeën fixen op papier is goedkoper dan code fixen.

Drie krachtige review-vragen

Zelfs zonder een multi-agent review-systeem: 1. "Wat was de moeilijkste beslissing die je hier nam?" — dwingt de AI te onthullen waar de lastige delen zitten 2. "Welke alternatieven heb je afgewezen, en waarom?" — toont de opties die werden overwogen 3. "Waar ben je het minst zeker over?" — LLMs weten waar hun zwaktes liggen; je moet ernaar vragen

Best Practices

--dangerously-skip-permissions

Standaard vraagt Claude Code toestemming bij elke actie. De flag zet dit uit. Gebruik wanneer: - Je het plan vertrouwt en goede review-systemen hebt - Je in een veilige omgeving werkt (branch, worktree — niet productie) - Je velocity wil: zonder de flag verlies je focus door constant "y" te typen

Vangnettten als je de flag gebruikt: git als vangnet (git reset --hard HEAD~1), tests na implementatie, review vóór merge.

Vibe coding

Voor PM's, designers, of persoonlijke projecten die direct naar resultaat willen: - /ce-brainstorm [beschrijf wat je wil] → /lfg → wacht → controleer of het werkt → geef feedback - Review-agents, architectuurkeuzes en tests verlopen automatisch - Ideaal voor prototypes en UX-verkenning; niet voor productiesystemen

Team collaboration

  • Plan-goedkeuring: stilte is geen goedkeuring — expliciet aftekenen vóór implementatie
  • PR-eigenaarschap: wie het werk initieerde, bezit het PR — ongeacht wie (of wat) de code schreef
  • Human review focus: bij AI-review zijn mensen verantwoordelijk voor intent, niet implementatie: klopt dit met wat we bespraken?

Agent-native architectuur

Als een developer iets kan zien of doen, moet de agent dat ook kunnen:

Level 1: Bestandstoegang + tests + git commits
Level 2: Browsertoegang + lokale logs + pull requests
Level 3: Productielogs (read-only) + error tracking + monitoring
Level 4: Ticket-systemen + deployment + externe services

Elk capability dat je de agent onthoudt, moet jijzelf handmatig doen.

Verwante concepten

Bronnen

#werkwijze

Backlinks