Compound Engineering: En praktisk guide

Jeg har brugt Compound Engineering dagligt siden sommeren 2025. Ikke som et koncept jeg læste om og tænkte “det lyder interessant.” Som den faktiske proces jeg følger når jeg bygger software med AI-agenter for rigtige kunder hos Primux.

Denne guide dækker hvad Compound Engineering er, hvorfor det virker, og præcis hvordan du implementerer det. Uanset om du bruger Claude Code, Cursor, Codex eller noget helt andet, gælder metoden.

Hvad Compound Engineering faktisk er

Kerneidéen er simpel: hver opgave du løser skal gøre den næste lettere, ikke sværere.

Traditionel softwareudvikling har et akkumuleringsproblem i den forkerte retning. Du tilføjer features, kompleksiteten vokser, kodebasen bliver sværere at arbejde med, og hver ny ting tager længere tid end den forrige. Teknisk gæld hober sig op. Viden lever i folks hoveder. Når nogen stopper, forsvinder konteksten.

Compound Engineering vender det om. Hver opgave du gennemfører, hver fejl du retter, hvert PR du reviewer, bliver permanent, genbrugelig viden som dine værktøjer og dit team automatisk kan anvende næste gang.

Konceptet kommer fra Kieran Klaassen, CTO hos Every. De kører fem produktionssoftwareprodukter, hver primært vedligeholdt af én udvikler, der betjener tusindvis af daglige brugere. Hans påstand: én udvikler med denne tilgang klarer det der tidligere krævede fem. Jeg har praktiseret det selv i måneder. Og det virker.

Loopet: Ideate, Brainstorm, Plan, Work, Review, Polish, Compound

Processen er en cyklus. Du kører den igen og igen, og hver rotation bygger på den forrige.

Da Kieran Klaassen opfandt begrebet, var loopet kort. I maj 2026 udvidede han det, i hans egne ord fra fire trin til otte. Grunden er værd at forstå: work-trinnet er blevet kedeligt, på den gode måde. Med en god plan og den rette kontekst skriver agenten nu pålideligt koden, kører testene og retter det åbenlyse selv. Så menneskets løftestang er flyttet ud til de to ender. Hvad er værd at bygge i første omgang (forrest), og føles det færdige produkt rigtigt (bagest).

Trevin Chow, medskaber af pluginnet, kalder det en sandwich: AI’en er fyldet i midten, mennesket er brødet i hver ende der holder det hele sammen. Midten bliver automatiseret. Men hvis arbejdet skal være godt, og hvis det skal føles som dit, skal du være til stede i begyndelsen og i slutningen.

Ideate → Brainstorm → Plan → Work → Review → Polish → Compound → (gentag)

Trin 0: IDEATE (valgfrit)

Det nyeste fronttrin. Ideate handler om at beslutte hvad der overhovedet er værd at bygge, før du beslutter hvordan. Det er trinnet hvor du forstår brugeren, produktet, de mærkelige edge cases og den ene ting der føles spændende nok til at bruge tid på.

/ce-ideate rammer søgefeltet ind, peger AI’en mod relevante kilder, genererer bredt på tværs af perspektiver og scorer kandidaterne på sikkerhed, effekt og kompleksitet. Du ender med nogle få retninger der er værd at undersøge, i stedet for én du tilfældigvis kom til at tænke på først. Spring det over hvis du allerede ved hvad du vil bygge. Brug det når du står med et tomt lærred.

Trin 1: BRAINSTORM (valgfrit)

Det her er trinnet de fleste springer over. Og det er det jeg ville ønske jeg var startet med tidligere.

Brainstorming er til når du har en vag idé, ikke et klart krav. Hvis du allerede ved præcis hvad du har brug for (“tilføj en ny authentication provider”), spring dette over og gå direkte til planlægning. Men hvis du tænker “vi har brug for en slags feature-afstemningsværktøj” eller “onboarding-flowet skal være bedre,” start her.

/ce-brainstorm forvandler din vage idé til en samtale. Den stiller spørgsmål indtil kravene er klare: Hvordan skal brugere logge ind? Én stemme per bruger eller flere? Hvordan skal ting sorteres? Du styrer retningen, og inden for få minutter har du et markdown-dokument med datamodeller skitseret, en liste over sider og en designretning.

Ved et Compound Engineering Camp blev det demonstreret live med én prompt: “Byg en FeatureBase-klon til intern feature request-afstemning.” Brainstorm-trinnet interviewede, der blev givet retning (“Jeg vil have en schweizisk designvibe med firkantet, sort, hvidt, Helvetica-agtigt”), og outputtet blev inputtet til planlægning. Fra en énlinjers idé til en struktureret spec på få minutter.

Kernen: brainstorming udfylder hullet mellem din vage idé og en detaljeret spec. Uden den beder du planlægningstrinnet om at gøre to ting på én gang.

Trin 2: PLAN

Her bruger du det meste af din tid. Forvent 70% tænkning, 30% handling. Det ratio overraskede mig også, indtil jeg oplevede det selv. En solid plan gør alt downstream næsten kedeligt. En sjusket plan skaber kaos.

Konkret gør planlægningen følgende:

• Undersøg kodebasen. Før du rører noget, forstå hvad der eksisterer. Læs de relevante filer. Forstå de mønstre der allerede er i brug.
• Undersøg velafprøvede mønstre. Se på hvordan andre projekter løser det samme problem. Tjek dokumentation. Find eksempler fra den virkelige verden.
• Skriv en detaljeret implementeringsplan. Ikke “tilføj auth.” Mere som: mål, foreslået arkitektur, specifik tilgang, filer der skal ændres, edge cases der skal håndteres, og succeskriterier.
• Bryd det ned. Komplekse opgaver deles op i klare, sekventielle trin som både du og en AI-agent kan følge.
• Jagt edge cases. Planlæggeren bør aktivt lede efter skridt en bruger kan tage som brainstormen ikke forudså.

Planen er din kontrakt med agenten. En vag plan producerer vag kode. En præcis plan producerer præcis kode.

Pluginnets planlægger gør ting en rå AI-prompt ikke gør. Den undersøger den eksisterende kodebase så den ikke genopfinder hvad der allerede er der. Den tjekker for eksisterende designmønstre der bør følges. Og den trækker fra compound-artefakter (gemte lektioner fra tidligere arbejde) for at undgå faldgruber.

Til kritiske opgaver er der en “deepen”-mulighed der sender 8-10 sub-agenter afsted, hver med fokus på et forskelligt aspekt af problemet. Jeg bruger det ikke til hver feature, men til komplekse migrationer eller arkitekturændringer er det tiden værd.

Modelvalg er vigtigt her. Brug Opus til planlægning. Den er stærkest til kreativt arbejde, udfyldning af huller og ræsonnering om arkitektur. Gem de hurtigere, billigere modeller til udførelse.

Trin 3: WORK

Eksekvér planen. Det er her AI-agenten løfter det tunge.

Hvis din plan er solid, er dette trin overraskende ligetil. Agenten følger planen trin for trin, skriver koden, kører testene og itererer indtil tingene passerer. Hvis planen har huller, markerer work-trinnet dem i stedet for at gætte. Det er en feature, ikke en fejl.

Hvad jeg har lært:

• Lad agenten arbejde. Lad være med at mikrostyre under udførelsen. Det var det planen var til.
• Brug worktrees. Kør arbejdet i et isoleret git worktree så agentens ændringer ikke forstyrrer din main branch før du er klar.
• Fokusér på beslutninger. Dit job under dette trin er at tage de værdifulde vurderinger agenten ikke kan tage. Arkitektur-trade-offs. Forretningslogik. Domænespecifikke valg.
• Brug hurtigere modeller. Planlægning kræver den bedste reasoning-model du har. Udførelse gør ikke. Skift til hurtigere modeller som Sonnet, Gemini Flash eller Codex til work-trinnet.

Når du er klar, kan du køre flere work-sessioner parallelt. Jeg kører typisk 2-3 agenter i hver deres worktree på samme tid. Det gør en kæmpe forskel.

Trin 4: REVIEW

Her sker kvaliteten. Hvis planlægning er det vigtigste trin, er review det næstvigtigste.

Review er ikke bare “virker det?” Det er en flerlags-vurdering:

• Automatiske tjek. Linters, type checkers, testsuiter. De fanger det åbenlyse.
• Manuel test. Brug faktisk featuren. Klik igennem UI’et. Hit API-endpointsene.
• Code review. Læs diffen som om du reviewer en juniorudviklers PR. For det er i bund og grund det du gør.
• Multi-perspektiv review. Compound Engineering-pluginnet kan køre flere specialiserede review-agenter parallelt: sikkerhed, performance, arkitektur, dataintegritet, mønsterkonsistens.
• Cross-model review. Lad forskellige modeller reviewe den samme kode. Du får forskellige perspektiver fra forskellige modeller, ligesom du får forskellige perspektiver fra forskellige menneskelige reviewere.
• Browser-test. Pluginnet inkluderer en test-browser-kommando der bruger en AI-drevet browser-agent til at klikke igennem interfacet og verificere at features virker.

Jeg reviewer hvert eneste PR mine agenter producerer. Hvert eneste. Det er ikke til forhandling. Agenten skriver god kode det meste af tiden, men “det meste af tiden” er ikke godt nok til produktion.

Den færdighed der betyder mest i denne nye verden er ikke at skrive kode. Det er at reviewe kode. At kunne spotte subtile fejl, arkitekturdrift og sikkerhedsproblemer i AI-genereret kode er en af de vigtigste færdigheder en udvikler kan have lige nu.

Trin 5: POLISH

Det andet nye trin, og det der bagest holder kvaliteten oppe. Review svarer på “virker det?”. Polish svarer på “er det godt?”.

Når koden teknisk har bestået reviewet, kommer mennesket ind igen. Du starter dev-miljøet, klikker dig igennem brugerflowet, kigger på designet, læser teksten og spørger om oplevelsen føles rigtig. Nogle gange virker alt teknisk, men produktet er stadig ikke godt nok. Så gør du det bedre. /ce-polish-beta hjælper med at finde og sætte de små ting i kø: hastighed, animationer, copy og visuelle skævheder, indtil det er klar til at sende.

Det her er præcis den ende af sandwichen AI’en ikke kan gøre for dig. Smag er menneskets job.

Trin 6: COMPOUND

Det er det her trin der får det hele til at virke på lang sigt. Uden det bruger du bare AI til at kode hurtigere. Med det bygger du et system der bliver smartere over tid.

Compounding betyder: tag det du lærte og dokumentér det permanent så det automatisk gælder næste gang.

I praksis ser det sådan ud:

• Opdatér din CLAUDE.md-fil. Det er “virksomhedshåndbogen” for din AI-agent. Når du opdager at et bestemt mønster virker godt, eller at en typisk fejl skal undgås, skriv det ned. Agenten læser denne fil ved starten af hver session. Men pas på: CLAUDE.md skal holdes kort og fokuseret. Når noget kræver mere plads, lav det som en skill i stedet.
• Skab genanvendelige skills. Hvis du løser et problem og løsningen er generaliserbar, pak den som en skill. Næste gang nogen på dit team møder det samme problem, er løsningen allerede der.
• Dokumentér mønstre, ikke bare rettelser. Ret ikke bare fejlen. Spørg: hvorfor skete det? Hvilken generel regel forhindrer det? Skriv den regel ned.
• Opdatér dine review-agenter. Hvis en reviewer burde have fanget noget men ikke gjorde det, opdatér reviewerens instruktioner.

Som Kieran Klaassen siger: “You have to teach your tools before they can teach themselves.” De 10 minutters investering i at dokumentere en lektion akkumulerer på tværs af alle fremtidige opgaver der rører det samme område.

Timing er afgørende. Kør compound-trinnet mens konteksten er frisk, lige efter noget går i stykker eller virker. Hvis du venter til efter dit AI-værktøj har komprimeret samtalen, mister du detaljerne. Eller som det hedder: “You don’t want to run it after compaction.”

Brug 30% af din tid på systemet

The Definitive Guide anbefaler 50/50 mellem featurearbejde og systemforbedring. I praksis kører jeg tættere på 70/30: 70% features, 30% systemarbejde som dokumentation, review-agenter, testgeneratorer, skills og CLAUDE.md-opdateringer.

Pointen er den samme uanset fordelingen. Systemforbedringer gør arbejdet progressivt hurtigere. Featurearbejde gør ikke. Hvis du bruger en dag på at bygge en review-agent der automatisk fanger en klasse af fejl, arbejder den agent gratis på hvert fremtidigt PR. Hvis du bruger en dag på at skrive features uden at forbedre systemet, er i morgen præcis lige så hårdt som i dag.

Hvis du ikke bruger betydelig tid på at gøre systemet smartere, lader du renters rente ligge på bordet.

Otte ting du skal glemme

At gå over til Compound Engineering betyder at slippe antagelser der gav mening før AI-agenter kunne skrive kode. Det er dem jeg selv faldt over:

1. “Kode skal skrives i hånden.” Det der betyder noget er vedligeholdelig kode der løser det rigtige problem. Ikke hvem der tastede den.

2. “Hver linje kræver manuelt review.” Automatiserede review-agenter kan fange de samme problemer. Dit job er at reviewe intentionen og tilgangen, ikke hvert semikolon.

3. “Løsninger skal stamme fra ingeniører.” AI kan researche og anbefale. Du tilføjer smag og vurdering. Det er nok.

4. “Kode er det primære artefakt.” Et system der producerer konsistent kode slår individuel brillans. Systemet er artefaktet.

5. “At skrive kode er kernejobbet.” At levere værdi er det der tæller. Planlægning, review og systemopbygning tæller lige så meget. Måske mere.

6. “Første forsøg skal være perfekte.” 95% af første forsøg har problemer. Iterér hurtigt i stedet for at pine over det første udkast.

7. “Kode er selvudtryk.” Kode tilhører teamet og brugerne. At løsrive sig fra “din” kode muliggør bedre feedback-loops.

8. “At taste er at lære.” Forståelse betyder mere end muskelhukommelse. At reviewe 50 PRs lærer dig flere mønstre end at skrive 5.

Hvor er du i dag?

Ikke alle starter samme sted. At vide hvor du er hjælper dig med at fokusere på det rigtige næste skridt.

Stadie 0: Manuel udvikling

Linje-for-linje kodning uden AI. Den traditionelle tilgang. Hvis det er dig, start med at vælge ét værktøj (Claude Code eller Cursor) og stil det spørgsmål før du koder.

Stadie 1: Chat-baseret assistance

Brug af ChatGPT, Claude eller Cursor til snippets og reference. Copy-paste af svar. Her er de fleste udviklere i dag. Begrænsningen: du er stadig flaskehalsen for hver linje kode.

Stadie 2: Agentiske værktøjer med linje-for-linje review

Claude Code eller Cursor Composer kan læse og skrive filer. Men du godkender hver handling. Du er stadig flaskehalsen, bare med en hurtigere maskinskriver.

Stadie 3: Plan-first, PR-only review

Her begynder Compound Engineering. Du samarbejder om en detaljeret plan, agenten implementerer uden opsyn, og du reviewer på PR-niveau i stedet for linje for linje. Planen erstatter mikrostyring. Reviewet fanger hvad planen overså.

Stadie 4: Idé til PR

Du giver idéen. Agenten håndterer kodebaseresearch, planlægning, implementering, test, selv-review og PR-oprettelse. Du reviewer og merger. Det er her jeg opererer de fleste dage.

Stadie 5: Parallel cloud-eksekvering

Flere agenter arbejder på flere features simultant på fjerninfrastruktur. Agenter kan proaktivt overvåge feedback og foreslå features. Det er her det er på vej hen. Der er dem der kører 25 parallelle agenter. Begrænsningen holder op med at være din opmærksomhed og begynder at være compute.

Spørgsmål der afslører problemer

Når du reviewer AI-output, fanger disse tre spørgsmål problemer som automatiske tjek overser:

1. “Hvad var den sværeste beslutning?” Det afslører de vanskelige steder hvor agenten måtte lave vurderinger. Det er de steder der mest sandsynligt har brug for menneskelig input.

2. “Hvilke alternativer afviste du, og hvorfor?” Viser om agenten faktisk overvejede muligheder eller bare gik med det første der virkede. Fanger dårlige arkitekturvalg tidligt.

3. “Hvad er du mindst sikker på?” Får AI’en til at indrømme sine egne svagheder. Overraskende effektivt. Det ærlige svar peger ofte direkte mod den kode der har mest brug for granskning.

Gør dit miljø agent-native

Hvis en udvikler kan gøre det, bør en agent også kunne. Det er “agent-native”-princippet, og det betyder mere end de fleste tror.

Niveau 1: Basal udvikling. Filadgang, kørsel af tests, git-operationer. De fleste setups har det.

Niveau 2: Fuldt lokalt. Browseradgang til test, læsning af logs, oprettelse af PRs. Her begynder det for alvor.

Niveau 3: Produktionssynlighed. Skrivebeskyttet adgang til logs, monitorering, error tracking. Agenten kan diagnosticere problemer uden at du copy-paster stack traces.

Niveau 4: Fuld integration. Tickets, deployment, eksterne services. Agenten kan gå fra en fejlrapport til et deployet fix med minimal menneskelig indgriben.

Hvert niveau låser mere autonomi op. Du behøver ikke springe til niveau 4 på dag ét. Men hver kapabilitet du giver agenten er én ting mindre du skal gøre manuelt.

Pluginnet og værktøjerne

Compound Engineering-metoden har et open source-plugin der implementerer hele workflowet.

Core-pluginnet

Hovedpluginnet skabes af Kieran Klaassen og Trevin Chow hos Every og ligger på github.com/EveryInc/compound-engineering-plugin. Det er vokset betydeligt: pluginnet leverer i dag 37 skills og 51 agenter, så det er langt mere end de håndfulde kernekommandoer du bruger dagligt.

Installér til Claude Code:

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

Du behøver ikke Bun til Claude Code. Det installerer direkte fra plugin-markedspladsen.

Installér til andre værktøjer (Cursor, Codex, GitHub Copilot, Factory Droid, Qwen Code, OpenCode, Pi, Gemini og Kiro):

# auto-detect og installér til alle installerede værktøjer:
bunx @every-env/compound-plugin install compound-engineering --to all
# ... eller målret et enkelt værktøj:
bunx @every-env/compound-plugin install compound-engineering --to codex
bunx @every-env/compound-plugin install compound-engineering --to gemini

Bemærk at kommandoerne nu bruger bindestreg, ikke kolon: det hedder /ce-plan, ikke /ce:plan. Hvis du har en ældre installation med kolon-syntaks, så kør /ce-update.

Kernekommandoerne der følger loopet:

Ud over kernekommandoerne ligger der specialiserede kommandoer som /ce-debug, /ce-doc-review, /ce-product-pulse, /ce-simplify-code, /ce-test-browser og /ce-resolve-pr-feedback. Kør /ce-setup én gang efter installation.

Laravel-specifik udvidelse

Jeg vedligeholder et Laravel companion-plugin på github.com/primux-dk/laravel-compound-engineering. Det tilføjer Laravel-specifikke agenter og skills:

Installér:

/plugin marketplace add https://github.com/primux-dk/laravel-compound-engineering
/plugin install laravel-compound-engineering

Kør derefter /laravel-setup i dit Laravel-projekt for at konfigurere alt.

Hvad det tilføjer:

• primux-laravel-reviewer reviewer kode efter Taylor Otwells konventioner
• data-integrity-guardian fanger migrations- og dataintegritetsproblemer
• data-migration-expert validerer ID-mappings, kolonneomdøbninger og datatransformationer
• github-code-researcher finder implementeringer fra den virkelige verden på GitHub via gh CLI
• PHP/Blade linting med Laravel Pint

Plus skills til Taylor Otwell-stil PHP, Livewire v4-mønstre, databasemønstre, Pest-test, Tailwind CSS v4 og Spatie-stil pakkeudvikling.

De to plugins arbejder sammen. Core-pluginnet leverer workflowet (plan, work, review, compound). Laravel-pluginnet leverer domæneekspertisen.

Din agents virksomhedshåndbog

Den vigtigste fil i Compound Engineering er CLAUDE.md (eller tilsvarende for dit værktøj). Det er det agenten læser før hver session. Det er den akkumulerede viden om dit projekt.

En god CLAUDE.md indeholder:

• Projektstruktur. Hvor tingene lever, hvordan kodebasen er organiseret.
• Konventioner. Navngivningsmønstre, arkitekturbeslutninger, kodestandarder specifikke for dit projekt.
• Typiske faldgruber. Ting agenten har gjort forkert før og bør undgå.
• Review-kriterier. Hvad der skal tjekkes under code review. Hvad der betyder mest i din kontekst.
• Domæneviden. Forretningsregler, regulatoriske krav, ting der ikke er åbenlyse fra koden.

Hver gang du gennemfører et Compound-trin og opdager noget der er værd at huske, kommer det i CLAUDE.md. Over uger og måneder bliver den fil genuint værdifuld. Det er institutionel hukommelse der ikke går ud af døren når nogen stopper.

Workflow i praksis

Sådan ser en typisk feature ud med denne proces:

Opgave: Tilføj brugerautentificering til en Laravel API.

Plan:

/ce-plan "Add JWT authentication to the API with login, register,
and token refresh endpoints. Use Laravel Sanctum. Include rate
limiting on auth endpoints."

Agenten undersøger kodebasen, tjekker eksisterende mønstre og producerer en detaljeret plan med filændringer, testkrav og migreringstrin. Jeg reviewer planen, justerer det der ikke passer til vores arkitektur, og godkender.

Work:

/ce-work

Agenten eksekverer planen i et isoleret worktree. Den opretter migrationer, modeller, controllers, form requests, tests og routedefinitioner. Det tager minutter, ikke timer.

Review:

/ce-code-review

Flere review-agenter undersøger koden:

• Laravel-revieweren tjekker konventionsoverholdelse
• Sikkerhedsrevieweren tjekker for auth-sårbarheder
• Dataintegritsrevieweren tjekker migrationen
• Performance-revieweren tjekker for N+1-queries

Jeg læser al feedbacken, tester endpointsne manuelt og retter det der skal rettes.

Compound:

/ce-compound

Jeg dokumenterer hvad der blev lært:

• “Sanctum token-udløb skal sættes i config, ikke hardcodes”
• “Rate limiting på auth-routes: 5 forsøg per minut for login, 3 for register”
• “Inkludér altid et refresh token-endpoint ved implementering af JWT auth”

De lektioner går i CLAUDE.md. Næste gang nogen på teamet bygger en auth-feature, kender agenten allerede vores konventioner.

Pluginnet er midlertidigt. Filosofien er permanent.

Noget de fleste værktøjsskabere ikke siger: compound engineering-pluginnet har en udløbsdato. AI-laboratorierne bygger allerede flere af idéerne direkte ind i deres værktøjer. Plan mode eksisterede for eksempel ikke i de fleste værktøjer da pluginnet først blev bygget. “Ideally, we delete the whole thing someday because it’s all built in. The point was always the philosophy, not the plugin.”

Jeg synes det er den rigtige indramning. Pluginnet er nyttigt i dag fordi værktøjerne ikke har indhentet det endnu. Men disciplinen med at planlægge før du koder, reviewe grundigt og dokumentere hvad du lærer? Den er permanent. Den virker uanset om du bruger Claude Code, Cursor, Codex eller hvad der kommer næste år.

Ingeniørens job skifter fra at skrive kode til at designe systemer der skriver kode og husker hvad de lærte. De mennesker der begynder at akkumulere nu, er dem der bliver svære at indhente senere.

Principper at huske

1. Gør hver opgave lettere end den forrige. Hvis din anden feature er sværere end din første, er der noget galt med din proces.

2. Dokumentér undervejs, ikke bagefter. “Det dokumenterer jeg senere” betyder “det dokumenterer jeg aldrig.” Skriv det ned under Compound-trinnet mens det er friskt.

3. Automatisér gentagne mønstre. Hvis du har lavet den samme type review tre gange, lav en review-agent til det. Hvis du har skrevet den samme boilerplate tre gange, lav en skill til det.

4. Byg genanvendelige komponenter. Ikke kun kodekomponenter. Skills, review-kriterier, planskabeloner. Hver generaliserbar løsning bør kunne ekstraheres.

5. Lær af hver iteration. Hver fejl er en lektion. Hvert code review-fund er et mønster. Hver fejlet test er en regel. Fang dem alle.

Start i dag

Hvis du vil prøve det her i dag:

1. Installér pluginnet. Start med core Compound Engineering-pluginnet til det værktøj du bruger.
2. Skriv en CLAUDE.md. Selv en basal med projektstruktur og konventioner. Den behøver ikke være perfekt. Den behøver at eksistere.
3. Vælg en lille feature. Start ikke med en massiv omskrivning. Vælg noget afgrænset: et nyt endpoint, en UI-komponent, en fejlrettelse.
4. Kør loopet. Planlæg ordentligt. Lad agenten arbejde. Review grundigt. Skriv ned hvad du lærte. Det er det.
5. Bliv ved med at akkumulere. Efter 10 cyklusser er din CLAUDE.md genuint nyttig. Efter 50 er den uundværlig. Efter 100 undrer du dig over hvordan du nogensinde arbejdede uden.

Metoden er ikke kompliceret. Det er disciplinen der betyder noget. Planlæg grundigt, review grundigt, og spring aldrig compound-trinnet over. Det er hele pointen.

Videre læsning

• Compound Engineering Gets an Upgrade af Kieran Klaassen (maj 2026, om udvidelsen til otte trin)
• Compound Engineering: The Definitive Guide af Every
• Compound Engineering: How Every Codes With Agents af Dan Shipper og Kieran Klaassen
• My AI Had Already Fixed the Code Before I Saw It af Kieran Klaassen
• Compound Engineering Camp: Every Step, From Scratch af Katie Parrott
• Compound Engineering Plugin (open source)
• Laravel Compound Engineering Plugin (min Laravel-udvidelse)

Relateret i ordbogen

Begreber fra denne guide - slå op for hurtige forklaringer:

• Agentic coding - kodning hvor agenten gør det meste
• Agentic Engineering - den bredere disciplin compound engineering hører under
• Claude Code - Anthropics terminalbaserede kodningsagent
• Cursor - den AI-først editor mange compound-flows kører i
• AI-agent - definitionen af det der laver arbejdet
• Ralph Loop - det iterative kodnings-mønster
• Vibe coding - kodning ved kun at beskrive intentionen
• Pair programming med AI - sådan parrer du med en model
• Prompt engineering - det færdighedsniveau der gør forskellen
• NemoClaw - ét konkret eksempel på en compound-engineering-stack