Agentbaserad AI och bygg-först-leverans

CAIREs leveransmodell är en agentbaserad pipeline från PRD till PR. En människa skriver en produktbeskrivning. Specialiserade AI-agenter tar hand om spec, tester, implementation, granskning och verifiering. Människan godkänner en skärmbild. Beräkningskapacitet är flaskhalsen — inte antalet anställda.

Från en mening till levererad mjukvara. Människan dyker bara upp på två ställen: när PRD:n skrivs, och när dossier-skärmbilden godkänns.

Det agentbaserade arbetsflödet är inte "AI-stöd för utvecklare". Det är leveransmodellen. Fyra åtaganden gör det tydligt.

Produktägare skriver PRD. Pipelinen tar den därifrån — spec, tester, kod, granskning, dossier, merge — utan att en människa sitter mitt i något steg.

Varje modellanrop går via en adapter. Valet av modell är konfiguration, inte kod. När en bättre eller billigare modell kommer är bytet en kvartalsöversyn — inte en refaktorering.

Mätningar efter merge trappar upp en funktion från 1 % till 100 %. Försämring rullar tillbaka flaggan. Beslutet är mekaniskt — människor behöver inte säga "okej, rampa det här".

Kassaflöde, intäkter och förbrukning är systemingångar. Orchestratorn vägrar starta en dyr körning om dagens budget är slut. Ingen behöver manuellt "dra åt svångremmen".

Varje arkitekturbeslut i pipelinen mäts mot en fråga: ger det fler funktioner per sekund, per dollar (och per token)? Absolutvärdet är medvetet litet. Det som räknas är trenden.

Klocktid från att en PRD tas in till att PR:n lagts in i main. Att korta den tiden betyder att parallellisera steg, cacha specifikationer och ta bort onödiga mänskliga rundor. Varje levererad funktion landar som en rad i .compound-state/agent-service.db med sin förflutna tid.

Total modellkostnad över alla åtta steg, per PR som lagts in i main. Billigare leverantörer, mindre modeller för enklare uppgifter, batch-API:er och prompt-cachning — varje hävstång pekar hit. Orchestratorn vägrar körningar vars beräknade kostnad skulle överskrida dagens budget.

Totala in- och ut-tokens i pipelinen, per PR som lagts in i main. Ju renare specifikation och ju snävare dossier-kontrakt, desto färre tokens bränner editorn på iteration. Tokens är en tidig indikator på kostnad.

En optimeringsagent (mathematician) läser genomströmningsloggen varje vecka och föreslår ändringar i modellvalet — annan modell per roll, annan batch-storlek, annan cachstrategi. CPO/CTO-agenten godkänner. Mätvärdet får bara förbättras.

Den här sidan följer mätvärdet. Nya vinster i modellval, nya agentpromptar, nya dossier-format — varje förbättring som lyfter funktioner-per-sekund-per-dollar landar här som en uppdatering.

Varje steg producerar en kontrollerad artefakt. Nästa steg vägrar starta utan den. Pipelinen är ett kontinuerligt flöde, inte en checklista — varje steg lämnar över ett typat resultat.

Återstart: verify och granskningsloopen kan skicka tillbaka till implement (max 3 cykler). Merge körs bara efter mänskligt godkännande — inte i den obevakade körningen.

Kontraktet är skarpt: ingen dossier, ingen merge . Varje stegs utdata är en typad, sparad artefakt som nästa steg läser — och som en människa, en revision eller en framtida agent kan spela upp.

Det agentbaserade arbetsflödet får inte människor att försvinna — det gör dem strategiska. Varje roll har en eller två snäva ställen att kliva in. Allt annat är mjukvara.

Definierar vad och varför Skriver PRD:n i wiki/plans/ med ett framgångsmått och explicita icke-mål. Godkänner (eller avvisar) dossier-skärmbilden före merge. Sätter den försämringströskel som skala-eller-släck bevakar efter merge. 💻

• Skriver PRD:n i wiki/plans/ med ett framgångsmått och explicita icke-mål.
• Godkänner (eller avvisar) dossier-skärmbilden före merge.
• Sätter den försämringströskel som skala-eller-släck bevakar efter merge.

Granskar — skriver inte Läser den autogenererade specifikationen och letar efter avvikelser från PRD:n. Bemöter P2-granskningskommentarer med motivering när agenten har fel. Underhåller agentpromptar och modelladaptern — kod om hur kod skrivs. 🛠️

• Läser den autogenererade specifikationen och letar efter avvikelser från PRD:n.
• Bemöter P2-granskningskommentarer med motivering när agenten har fel.
• Underhåller agentpromptar och modelladaptern — kod om hur kod skrivs.

Äger infrastrukturen Driftar Darwin (orchestrator-runtime), launchd-jobb och merge-kön. Bevakar genomströmningsloggen: kostnad per PR i main, funktioner per sekund per token. Godkänner modellbyten från optimeringsagentens (mathematician) veckoförslag. 🧪

• Driftar Darwin (orchestrator-runtime), launchd-jobb och merge-kön.
• Bevakar genomströmningsloggen: kostnad per PR i main, funktioner per sekund per token.
• Godkänner modellbyten från optimeringsagentens (mathematician) veckoförslag.

Skriver reglerna, inte testfallen Underhåller Gherkin-mönstren som Test-writer-agenten bygger ifrån. Granskar dossierns summary.json efter hoppade scenarier eller tomma Playwright-traces. Äger grinden "ingen dossier, ingen merge" — det enda orchestratorn inte kan hoppa över. 📈

• Underhåller Gherkin-mönstren som Test-writer-agenten bygger ifrån.
• Granskar dossierns summary.json efter hoppade scenarier eller tomma Playwright-traces.
• Äger grinden "ingen dossier, ingen merge" — det enda orchestratorn inte kan hoppa över.

Följer hävstången Följer hur kostnad per PR i main sjunker månad för månad medan modellvalet stramas åt. Följer funktioner-per-sekund-per-token som hävstångsmått — oberoende av rekrytering. Godkänner kvartalsvisa beslut om modellval; väljer inte modeller själv. 🔍

• Följer hur kostnad per PR i main sjunker månad för månad medan modellvalet stramas åt.
• Följer funktioner-per-sekund-per-token som hävstångsmått — oberoende av rekrytering.
• Godkänner kvartalsvisa beslut om modellval; väljer inte modeller själv.

Granskar spåret Inspekterar wiki/raw/dossiers/<funktion>/ på en PR i main — full Playwright-trace, skärmbild, konsollogg. Läser PRD-frontmatter för att koppla en levererad funktion tillbaka till den ursprungliga beskrivningen. Verifierar leverantörsoberoende genom att läsa konfigurationen för modellval — ingen leverantörsbindning att ärva.

• Inspekterar wiki/raw/dossiers/<funktion>/ på en PR i main — full Playwright-trace, skärmbild, konsollogg.
• Läser PRD-frontmatter för att koppla en levererad funktion tillbaka till den ursprungliga beskrivningen.
• Verifierar leverantörsoberoende genom att läsa konfigurationen för modellval — ingen leverantörsbindning att ärva.

Pipelinen riktar in sig på stadig produktutveckling — arbetet som i ett traditionellt team fyller standup-möten och sprintar. Större arkitektoniska drag får fortfarande en mänskligt ledd plan.

En ny banner, en ny sida, en formvariation. PRD:n namnger acceptansscenarierna; pipelinen skriver Vitest- och Playwright-tester; Editor implementerar; Verifier fångar skärmbildsdossiern.

PRD:n ramar in buggen som ett misslyckandescenario. Test-writer bygger om det till tester; Editor fixar; resolver-reviewer och perf-reviewer fångar N+1-försämringar innan PR:n öppnas.

Genomströmningsrad, KPI-ruta, dashboarddiagram. Specen namnger datakällan; tester verifierar formen; dossiern visar att mätningen renderas med realistisk seed-data.

Kvartalsvis: optimeringsagenten (mathematician) föreslår ett modellbyte utifrån kostnad, godkännandegrad och latens. CPO/CTO-agenten godkänner. En config-ändring; adaptern tar resten.

Granskningsomgång lik den här agentarbetsflödesgranskningen: hitta avvikelse, fixa dokumentet, kör yarn wiki:lint , leverera. PR:er som bara rör wikin använder samma åtta steg med en lättare verifiering.

Ett tänkt externt dataflöde beskrivs först i en PRD. Tester täcker gränssnittet och dossiern visar vad som faktiskt verifierats. Exemplet beskriver utvecklingsmetoden — inte en färdig integration eller produktkatalog.

Autonoma loopar utan skyddsräcken är hur AI-projekt bränner budgetar och levererar försämringar. Varje steg i pipelinen har skydd. Editor-agenten sitter i centrum, omgiven av mekanismer som kan sakta ner den, styra om den eller stoppa den helt.

Åtta oberoende skyddsräcken. Inget enskilt stoppar buggar ensamt; tillsammans gör de autonom leverans säker nog att människans enda obligatoriska handling är att läsa en skärmbild.

Editor kan inte leverera beteende som specifikationen inte namnger. Avvikelse mellan PRD och spec är i sig ett P2-fynd för verifier — och specifikationen är kort nog att rymmas i varje agents kontext, så avvikelse alltid går att bevisa.

MAX_ITERATIONS = 8 på editorns inre loop, plus max 3 återstartscykler från granskning eller Codex-feedback. När taket nås visar körningen felet för en människa — den mal aldrig vidare.

Den valfria flaggan PIPELINE_BUDGET_ENFORCEMENT (av i pilot, på när intäkterna är verkliga) stoppar fler modellanrop när kostnaden per körning skulle överskrida taket. I pilot är människan enda PRD-producenten, så kostnaden är implicit begränsad.

En grön CI-körning är nödvändig men inte tillräcklig. Dossiern — Playwright-trace, slutskärmbild, konsollogg och maskinläsbar sammanfattning — bevisar att funktionen faktiskt renderades. Granskare kan spela upp tracet; människan ser skärmbilden.

Samma pipeline, tre sätt att gå in. Välj vägen som passar stunden — en PRD i versionskontroll, ett formulär i Dashboard eller ett meddelande i Telegram. Varje väg ger samma dossier och samma merge-beslut.

Skriv wiki/plans/<funktion>-ÅÅÅÅ-MM-DD.md , skapa en isolerad worktree med ./scripts/git/worktree-add.sh , så körs pipelinen mot den grenen. Reviewer-subagenter granskar diffen, verifier fångar dossiern och merge-kön landar PR:n. Bäst för utvecklare som levererar i versionskontroll.

Klistra in en PRD-sökväg, klicka start och följ pipelinens framsteg på localhost:3010 . Dossiervisaren visar skärmbild, konsollogg och maskinläsbar sammanfattning direkt. Godkänn / Avvisa är en knapp — ingen omväg via GitHub. Bäst för produktägare som vill ha ett UI, inte ett CLI.

Skicka en PRD-länk till interface-agent . Samma backend kör pipelinen; dossier-skärmbilden skickas tillbaka till samma tråd. Svara godkänn så sker merge. Den lättaste vägen — ett meddelande och en bild. Bäst för grundaren som läser på telefonen mellan möten.

Pipelinen bygger på tre öppna mönster och en disciplin. Inget här är specialbyggt bara för att vara specialbyggt.

En dyr resonemangsomgång producerar specifikationen; många billiga redigeringsomgångar implementerar mot den. Ungefär 1/14 av kostnaden för att köra varje anrop på resonemangsmodellen — kostnadsdrivaren är editorn, inte arkitekten.

Vanligt språk är för oprecist för att styra flera agenter. Acceptansscenarier i Gherkin är korta nog att rymmas i varje agents kontext, precisa nog att bli fallerande tester — och sökbara med grep.

En grön CI-körning är nödvändig men inte tillräcklig. Dossiern — trace, skärmbild, konsollogg och maskinläsbar sammanfattning — bevisar att funktionen faktiskt renderades, i en riktig webbläsare, i det tillstånd specifikationen namngav.

Externa granskningsbotar (Codex, CodeRabbit) postar kommentarer efter varje push. Pipelinen hämtar dem, behandlar P1/P2 som fallerande tester och startar om editorn automatiskt. Disciplinen är obligatorisk.