Marktmannen wiki Coderen met AI

Compound Engineering

Laatst bijgewerkt: 29-06-2026

TL;DR: Werkcyclus Plan→Work→Review→Compound waarbij de vierde 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

Plan → Work → Review → Compound → Herhaal

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

1. Plan

Transformeer een idee naar een blauwdruk. - 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?

2. Work

Uitvoering volgt het plan. 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.

3. Review

Vang problemen vóór ze live gaan. Nog belangrijker: leg learnings vast. - Meerdere gespecialiseerde review-agents parallel - 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

4. Compound ⭐

De meest kritieke stap. Hier accumuleren de winsten. - 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 stap 3. Stap 4 bouwt een systeem dat steeds beter features bouwt.

Bestandsstructuur

project/
├── CLAUDE.md                    # Patronen en instructies (groeit mee)
├── docs/
│   ├── brainstorms/             # /workflows:brainstorm output
│   ├── solutions/               # /workflows:compound output
│   └── plans/                   # /workflows:plan output
└── todos/
    ├── 001-ready-p1-fix-auth.md
    └── 002-pending-p2-add-tests.md

De Plugin

Compound Engineering is beschikbaar als plugin voor Claude Code:

claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering

Bevat: 26 gespecialiseerde agents, 23 workflow-commando's, 13 skills.

Core commando's

Commando Werking
/workflows:brainstorm Codebase-research + vragen clarificeren; output naar docs/brainstorms/
/workflows:plan 3 parallelle research-agents + spec-flow-analyzer → gestructureerd plan
/workflows:work 4 fasen: quick start (worktree) → execute → quality check → ship (PR)
/workflows:review 14+ gespecialiseerde agents parallel (security, performance, data, quality, frontend)
/workflows:compound 6 parallelle subagents → doorzoekbare markdown met YAML frontmatter
/lfg [feature] Volledige pipeline: plan → deepen-plan → work → review → resolve → browser tests → compound

/lfg: volledige pipeline in één commando

/lfg Add dark mode toggle to settings page ketent de volledige pipeline samen, pauzeert voor plangoedkeuring, en draait dan autonoom 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: - /lfg [beschrijf wat je wil] → 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

#methodologie #filosofie

Backlinks