Compound engineering: pętla, wtyczka i dowody

Compound engineering to metodyka wytwarzania oprogramowania z Every, w której każda jednostka pracy ma zostawić system lepiej przygotowany na następną: zaplanuj, wykonaj, zrecenzuj, a potem zapisz wnioski tam, gdzie przeczyta je kolejny przebieg. Czwarty krok jest całą metodą — pominięty, zostawia zwykłe programowanie ze wsparciem AI.

Ten sam błąd wraca trzeci raz w tym kwartale. Ktoś naprawił go w marcu, naprawa była poprawna, a rozumowanie za nią leży w wątku na Slacku, którego nikt nie znajdzie, i w transkrypcie agenta, który dawno zniknął. Nie jesteś wolny dlatego, że naprawa jest trudna. Jesteś wolny, bo system, w którym pracujesz, nie ma pamięci — i agent, któremu go oddałeś, też nie.

Właśnie ten problem nazywa compound engineering, a nazwa przyjęła się na tyle mocno, że wtyczka realizująca metodę przekroczyła 24 500 gwiazdek i 2000 forków w niecałe dziesięć miesięcy. To także metoda, przeciw której istnieje konkretny argument z recenzowanego badania — argument, którego prawie nikt piszący o compound engineeringu nie przywołuje. Poniżej obie połowy.

Co zyskujesz z pętli compound engineering

• Czterokrokową pętlę i jeden krok, który odróżnia ją od „programowania ze wsparciem AI”, plus trzy różne podziały czasu, które publikuje Every, i sposób ich czytania
• Zweryfikowaną listę tego, co wtyczka faktycznie dostarcza dzisiaj, oraz konkretne miejsca, w których jej własny przewodnik opisuje architekturę usuniętą z repozytorium
• Pięciostopniową drabinę adopcji, z przejściem, które ma znaczenie, i dwoma, które zespoły próbują pominąć
• Pomiar sugerujący, że compound engineering powinien pogarszać pracę agenta, powód, dla którego nie obala wtyczki, i właściwość projektowa rozstrzygającą, po której stronie wylądujesz
• Cztery reguły z wewnętrznego słownika wtyczki, które decydują, czy pętla kumuluje wiedzę, czy tylko zbiera pliki — żadnej z nich nie ma w materiałach marketingowych
• Cztery gotowe prompty uruchamiające pętlę bez instalowania czegokolwiek: zapis wniosku, audyt wyszukiwalności, audyt niezależności i kwartalna ablacja własnego magazynu wiedzy

Co compound engineering naprawdę obiecuje

Obietnica dotyczy drugiej pochodnej, nie pierwszej. Większość baz kodu z czasem twardnieje, bo każda funkcja jest negocjacją z poprzednimi. Compound engineering twierdzi, że da się to odwrócić: funkcje uczą system nowych umiejętności, naprawa błędu likwiduje całą kategorię zamiast jednego przypadku, a baza kodu staje się łatwiejsza do zmiany, im większa jest.

Kieran Klaassen, general manager Cory w Every, wprowadził pojęcie w sierpniu 2025 pod nazwą „compounding engineering”, gdy zastał pull request otwarty przez Claude Code z powołaniem na własne wcześniejsze recenzje — „zmieniono nazewnictwo zmiennych zgodnie ze wzorcem z PR #234, usunięto nadmiarowe testy zgodnie z uwagami do PR #219”. Nie chodziło o to, że AI napisała kod. Chodziło o to, że zapamiętała trzy miesiące gustu recenzenckiego i zastosowała go bez proszenia.

Pętla i krok, który sprawia, że kumuluje

1. Plan. Zrozum wymaganie, sprawdź w bazie kodu, jak działają podobne rzeczy, poszukaj na zewnątrz, zaprojektuj podejście, zweryfikuj spójność planu.
2. Praca. Odizoluj zmianę (worktree albo gałąź), wykonaj plan krok po kroku, po każdej zmianie odpal testy i kontrolę typów, adaptuj plan, gdy coś pęknie.
3. Recenzja. Kilku wyspecjalizowanych recenzentów bada wynik równolegle, ustalenia dostają priorytet P1/P2/P3, poprawki są nanoszone i weryfikowane.
4. Kumulacja. Zapisz, co zadziałało, a co nie, jako artefakt do odnalezienia, otaguj go, zaktualizuj instrukcje czytane przez agenta na starcie sesji i sprawdź, czy system złapałby to teraz sam.

Kroki od pierwszego do trzeciego zna każdy. Krok czwarty jest całą tezą: pierwsze trzy produkują funkcję, czwarty produkuje system, który następnym razem zbuduje funkcję lepiej. Sformułowanie Every jest w tej sprawie bezlitosne — pomiń krok czwarty, a zrobiłeś tradycyjną inżynierię, tyle że pisała AI.

80/20, 50/50 czy jedno i drugie?

Every publikuje trzy różne podziały czasu dla tej pętli, w dwóch dokumentach, i czytanie ich jako sprzeczności to błąd, którego warto uniknąć.

Podział	Zakres	Gdzie występuje
80% plan i recenzja, 20% praca i kumulacja	W obrębie jednej funkcji	Sekcja „main loop” przewodnika
80% planowanie i recenzja, 20% wykonanie	W obrębie jednej funkcji	Sekcja filozofii w README wtyczki
50% funkcje, 50% ulepszanie systemu	W skali całego tygodnia	Sekcja „beliefs to adopt” przewodnika

Pierwsze dwa to ta sama teza sformułowana luźno. Trzeci jest inną osią: nie o to, jak dzielisz jedną funkcję, tylko ile mocy przerobowej idzie na pracę, która nie produkuje żadnej funkcji — agentów recenzujących, udokumentowane wzorce, generatory testów. Tradycyjne zespoły wkładają jakieś 90% w funkcje i traktują resztę jako narzut, do którego wracasz, gdy masz wolną chwilę, czyli nigdy.

Notatka

Podział 50/50 jest tym nośnym i zarazem tym, który nie przeżyje zderzenia z roadmapą, jeśli nikt starszy stażem go nie obroni. Godzina na zbudowanie agenta recenzującego ma rzekomo oszczędzić dziesięć godzin recenzji w skali roku. Ta proporcja to twierdzenie, nie pomiar — ale kierunek zweryfikujesz tanio na własnym repo, licząc, ile razy tłumaczyłeś tę samą konwencję.

Czym wtyczka jest dziś, a co wciąż opisuje przewodnik

Workflow jest dostarczany jako wtyczka na licencji MIT. Tutaj artykuł zaczyna zarabiać na siebie, bo opublikowany przewodnik na every.to i repozytorium, do którego linkuje, rozjechały się — a przewodnik jest tym, co większość czyta najpierw.

Sekcja przewodnika „what’s in the box” wymienia 26 wyspecjalizowanych agentów, 23 komendy workflow i 13 skilli — a jedenaście linijek niżej, w tym samym dokumencie, drzewo katalogów opisuje ten sam folder jako „Domain expertise (14 skills)”. Linki do katalogów agentów i komend zwracają 404. Tak samo każdy link w głąb nich: agenci projektowi, których nazywa, pliki komend, na które wskazuje przy /plan i /compound. Podany adres marketplace, EveryInc/every-marketplace, przekierowuje dziś przez 301, bo repozytorium zmieniło nazwę.

Co repozytorium zawiera na 24 sierpnia 2026, w wersji 3.23.3:

Przewodnik mówi	Repozytorium ma
26 agentów w agents/	Brak katalogu agents/. 404.
23 komendy w commands/	Brak katalogu commands/. 404.
13 skilli (albo 14) w skills/	33 skille, każdy jako katalog z SKILL.md
14 agentów recenzujących uruchamianych przez /review	27 plików person recenzenckich, należących do ce-code-review i nieudostępnionych jako komponenty wtyczki
Claude Code, OpenCode, Codex	14 hostów agentowych, w tym Cursor, Kimi, Devin, Copilot, Qwen, Antigravity, Grok

To nie jest czepianie się nieaktualnego dokumentu. Architektura naprawdę się zmieniła i właśnie ta zmiana jest ciekawa. W obecnym projekcie zachowanie specjalisty nie jest samodzielnym agentem, którego instalujesz. Skill posiada własne persony recenzenckie jako wewnętrzne pliki promptów i wysyła generycznych subagentów zasianych ich treścią. Słownik wtyczki podaje powód wprost: skill jest wywoływany przez użytkownika i koordynuje, agent jest wysyłany i wykonuje wąskie zadanie, a wystawianie każdego specjalisty jako instalowalnego agenta rozdmuchiwało powierzchnię ponad wartość.

Praktyczna konsekwencja dla ciebie: /review uruchamiające „14 nazwanych agentów” nie jest już czymś, co obejrzysz albo nadpiszesz, edytując plik agenta. Persony leżą w skills/ce-code-review/references/personas/, a to skill decyduje, do których trafi zadanie.

Instalacja w Cursorze, Claude Code i Codeksie

Wszystkie trzy czytają to samo repozytorium; różni się tylko mechanika marketplace.

Cursor

W czacie Cursor Agent:

/add-plugin compound-engineering

Albo wyszukaj „compound engineering” w marketplace wtyczek. Grok Bot korzysta z twojego konta i biblioteki wtyczek Cursora, więc instalacja tutaj obejmuje i jego — nie instaluj osobno w Grok Bocie.

Claude Code

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

Jeśli miałeś już wtyczkę zainstalowaną, odśwież marketplace przed aktualizacją. Samo /plugin update zostawi cię na starej wersji — pułapka udokumentowana w notatkach o aktualizacji w repo.

Codex

codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin

Codex wywołuje skille przez $, nie / — czyli $ce-plan i $lfg. Przy niedomyślnym profilu odpal obie komendy z tym samym CODEX_HOME, bo krok marketplace tylko udostępnia wtyczkę, a to instalacja aktywuje skille dla danego profilu.

Potem uruchom raz /ce-setup w projekcie. Zgłosi, które opcjonalne możliwości narzędziowe są dostępne, zapisze .compound-engineering/config.yaml, jeśli go nie ma, i doda lokalną nadpiskę do gitignore. Domyślne foldery artefaktów to docs/plans/, docs/solutions/ i docs/brainstorms/; jeśli twój docs/ to już śledzona treść — jak na tej stronie — ustawienie docs_root przenosi je wszystkie pod jeden korzeń względny do repo.

Na którym szczeblu pięciostopniowej drabiny jesteś?

Najbardziej użyteczna sekcja przewodnika w ogóle nie dotyczy wtyczki. Compound engineering zaczyna działać dopiero na trzecim szczeblu, a zespoły, które czytają o wieloagentowej recenzji, siedząc na drugim, albo rezygnują, albo przeskakują i tracą zaufanie do narzędzi.

Szczebel	Co robisz ty	Co robi agent
0	Piszesz każdą linijkę. Research z dokumentacji i Stack Overflow.	Nic
1	Pytasz model czatowy, wklejasz to, co przydatne	Generuje fragmenty do wklejenia
2	Narzędzia agentowe z dostępem do plików; zatwierdzasz każdą akcję	Czyta i edytuje, ale za twoją zgodą
3	Wspólnie tworzycie szczegółowy plan, potem odchodzisz	Implementuje bez nadzoru, wynikiem jest PR
4	Opisujesz wynik; recenzujesz PR; scalasz	Bada, planuje, implementuje, recenzuje się sam, otwiera PR
5	Sterujesz równoległą pracą skądkolwiek	Wielu agentów pracuje w chmurze nad niezależnymi funkcjami

Na szczeblu 2 zatrzymuje się większość programistów, i nie z powodu możliwości narzędzi — tylko dlatego, że zatwierdzanie linijka po linijce sprawia wrażenie staranności. Przejście na szczebel 3 jest tym, które się liczy, i jest przejściem zaufania, nie narzędzi: przestajesz recenzować naciśnięcia klawiszy, a zaczynasz dokument planu i pull request.

Uwaga

Drabinę warto potraktować dosłownie w jednej sprawie: nie przeskakuj. Każdy szczebel buduje model mentalny potrzebny na następnym. Zespół, który skacze z drugiego prosto do /lfg, dostaje pull request na 40 plików z planu, którego nikt nie przeczytał, nie umie wskazać, której części nie ufać, i wyciąga wniosek, że autonomiczni agenci nie działają. W rzeczywistości usunął recenzję planu — jedyny krok szczebla 3, który czyni szczebel 4 czytelnym.

Dla porządku, co pełna autonomia obejmuje, a czego nie: /lfg łączy plan, implementację, upraszczanie, recenzję, nanoszenie kwalifikujących się poprawek, testy przeglądarkowe, commit, push, otwarcie PR i pilnowanie CI w ograniczonej pętli napraw. Wprost nie scala, i może skończyć z niedokończonymi wątkami, gdy budżet napraw się wyczerpie. Bez zdalnego repozytorium zatrzymuje się na lokalnych commitach. Sformułowanie przewodnika — „wręcza ci PR gotowy do scalenia” — jest wobec tych wątków optymistyczne.

Jak naprawdę wygląda zapisany wniosek

Czwarty krok to ten, przy którym wszyscy kiwają głową i go pomijają, więc warto zobaczyć, czym właściwie jest artefakt. ce-compound zapisuje jeden dokument na rozwiązany problem do docs/solutions/ i klasyfikuje go na jedną z dwóch ścieżek, dających inną strukturę sekcji:

• Ścieżka błędu — Symptomy, Co nie zadziałało, Rozwiązanie, Dlaczego to działa, Zapobieganie. Dla błędów builda, padających testów, błędów runtime, problemów wydajnościowych i integracyjnych.
• Ścieżka wiedzy — Kontekst, Wskazówka, Dlaczego to ma znaczenie, Kiedy stosować, Przykłady. Dla wzorców architektonicznych i projektowych, decyzji narzędziowych, konwencji, praktyk pracy.

Trzy mechanizmy warto ukraść, nawet jeśli nigdy nie zainstalujesz wtyczki.

„Co nie zadziałało” jest sekcją pierwszej kategorii. Nieudane podejścia to najdroższa część śledztwa i pierwsza rzecz, która wyparowuje. Wniosek zapisujący samą odpowiedź wysyła następną osobę w te same trzy ślepe uliczki.

Nakładanie się jest punktowane przed zapisem nowego dokumentu. Subagent porównuje kandydata z istniejącymi wnioskami w pięciu wymiarach — sformułowanie problemu, przyczyna źródłowa, podejście do rozwiązania, wskazane pliki, reguły zapobiegania. Cztery lub pięć trafień oznacza aktualizację istniejącego dokumentu zamiast tworzenia drugiego. Dwa lub trzy — zapis i oznaczenie do konsolidacji. Bez tego magazyn wiedzy zamienia się w dwa dokumenty o tym samym błędzie, które po cichu się nie zgadzają.

Wyszukiwalność jest sprawdzana przy okazji zapisu. Każdy przebieg pyta, czy AGENTS.md albo CLAUDE.md projektu naprowadziłby przyszłego agenta na docs/solutions/. Magazyn wiedzy, na który nic nie wskazuje, to magazyn, którego nie ma. To najczęstszy sposób, w jaki próba wdrożenia compound engineeringu przewraca się bezgłośnie: dokumenty powstają, nic ich nie czyta, a pół roku później ktoś kasuje folder, bo wygląda na porzucony.

Wskazówka

Gotowy prompt do zapisania wniosku bez wtyczki:

We just solved a non-trivial problem in this session. Write it up as a
retrievable learning document, not a summary for me.

Classify it first: is this a defect (a thing that was broken) or guidance (a
convention, pattern, or decision)? Say which, and use the matching structure:

  Defect: Symptoms / What Didn't Work / Solution / Why This Works / Prevention
  Guidance: Context / Guidance / Why This Matters / When To Apply / Examples

Rules for the write-up:
- "What Didn't Work" is mandatory for a defect and must name the approaches we
  actually tried and why each failed. Do not compress this section.
- Every claim about code behaviour must quote the source line that proves it,
  with a file path. If you cannot find the line, mark the claim UNVERIFIED
  rather than asserting it.
- Add YAML frontmatter with: title, problem_type, component, root_cause, and
  3-6 tags a future search would plausibly use. Prefer vocabulary that already
  appears in existing docs in this repo over inventing new terms.

Before writing, search the repository for an existing document covering the
same problem. Compare on five dimensions: problem statement, root cause,
solution approach, files touched, prevention rule. If four or more match,
update that document instead of creating a new one and tell me which.

Finally: check whether this repo's agent instruction file would lead a future
session to find this document at all. If not, quote the smallest addition that
would fix it and ask before editing anything.

Czy zbieranie wniosków pogarsza pracę agentów?

Oto argument, na który compound engineering musi odpowiedzieć, a którego prawie żaden tekst o nim nie przywołuje.

Najbardziej bezpośrednie badanie plików kontekstowych w repozytorium — Gloaguen i in. z ETH Zurich — stwierdza w abstrakcie wersji v2, że pliki kontekstowe „nie poprawiają generalnie wskaźników sukcesu zadań, zwiększając przy tym koszt wnioskowania średnio o ponad 20%”. Wersja v1 podawała rozbicie, które v2 uśrednia: pliki wygenerowane przez model wypadały około 3% gorzej niż brak pliku w ogóle; napisane przez człowieka około 4% lepiej.

To strzał wprost w krok kumulacji w wersji opisanej przez przewodnik. Instrukcja przewodnika brzmi: „dodawaj nowe wzorce do CLAUDE.md, pliku, który agent czyta na starcie każdej sesji”. Rób tak po każdej funkcji przez rok, a dostaniesz maszynowo generowaną akrecję w jedynym pliku ładowanym zawsze — dokładnie tę konfigurację, którą badanie mierzy jako per saldo szkodliwą i na pewno droższą.

Zanim zrobi się lepiej, robi się gorzej. Dostawcy narzędzi odwrócili własne zalecenia w tej sprawie w lipcu 2026: Anthropic usunął ponad 80% promptu systemowego Claude Code dla generacji Claude 5 bez mierzalnej straty w ewaluacjach kodowych, a komunikat do użytkowników przeszedł z „dodaj linijkę za każdym razem, gdy model się pomyli” na „kasuj okresowo pliki kontekstowe i sprawdź, co model potrafi bez nich”. Nasz protokół ablacji do przycinania CLAUDE.md i AGENTS.md rozkłada to odwrócenie na czynniki pierwsze.

Dlaczego projekt wtyczki broni się przed tym zarzutem

Zarzut trafia w prozę przewodnika. Nie trafia w dostarczaną wtyczkę, a różnicę robi jedna właściwość: wyszukiwanie kontra ładowanie zawsze.

• docs/solutions/ to magazyn wyszukiwany. Wnioski leżą na dysku. ce-plan i ce-ideate wciągają te istotne jako grunt pod bieżące zadanie. Magazyn 400 wniosków nie kosztuje nic przy zadaniu, które pasuje do trzech z nich.
• CLAUDE.md to plik ładowany zawsze. Za każdą linijkę płacisz w każdym zadaniu, niezależnie od tego, czy jest istotna. To właśnie mierzy badanie i to bierze na cel lipcowe odwrócenie.

Wtyczka wkłada niemal wszystko do pierwszej kategorii, a drugiej dotyka tylko po to, by dodać wskaźnik do magazynu. Dostarcza też uzupełnienie, którego nikt nie buduje ręcznie: ce-compound-refresh utrzymuje magazyn w czasie, z pięcioma werdyktami — Keep, Update, Consolidate, Replace, Delete. To protokół ablacji dla bazy wiedzy i powód, dla którego magazyn nie staje się tym samym problemem w innym folderze.

Praktyczna reguła, niezależnie od tego, czy używasz wtyczki:

Uwaga

Wszystko, co musi być prawdą w każdym zadaniu, idzie do pliku ładowanego zawsze — i ten plik zostaje na tyle krótki, żeby obronić każdą linijkę z osobna. Wszystko, co jest prawdą w niektórych zadaniach, idzie do wyszukiwanego magazynu z tagami i indeksem, o którego przeszukiwaniu agent wie. Compound engineering zapisujący wnioski do pliku ładowanego zawsze to ta wersja, którą dane karzą.

Wskazówka

Gotowy prompt do audytu, czy magazyn wiedzy jest w ogóle czytany:

Audit whether this repository's accumulated knowledge is reachable by an agent
that has never seen it. Do not fix anything yet.

1. Find every location in this repo that stores durable engineering knowledge:
   solution docs, ADRs, runbooks, plan artifacts, wiki exports, long comments
   in the agent instruction file. List them with file counts and the date
   range of last modification.

2. For each location, answer: is it referenced from the file this project's
   agent loads at session start? Quote the referencing line, or write NOT
   REFERENCED.

3. Take the five most recently fixed bugs from `git log`. For each, search the
   knowledge locations for a document that would have prevented or shortened
   it. Report hit or miss, and for each hit say whether the document was
   findable by the words someone would actually search for, or only by knowing
   it existed.

4. Report the ratio of documents that are reachable AND findable to total
   documents. That number, not the document count, is the size of the
   knowledge base.

Finish with the single highest-leverage change: one line added to one file, or
one index created. Not a plan, one change.

Reguły, o których przewodnik milczy

CONCEPTS.md wtyczki to słownik utrzymywany przez zespół na użytek własnych agentów i zawiera reguły operacyjne rozstrzygające, czy cokolwiek z tego działa. Żadnej z nich nie ma w marketingu, a trzy uogólniają się daleko poza tę wtyczkę.

Dwóch recenzentów w jednym kontekście to nie dwóch świadków

Reguła w słowach samej wtyczki: niezależność jest właściwością kontekstu wykonania, w którym pracował recenzent, a nie soczewki, którą zastosował. Dwie persony rozumujące w jednym kontekście to dwie perspektywy, nie dwóch świadków.

To najlepiej przenaszalna myśl w całym repozytorium. Jeśli zlecisz jednemu agentowi „zrecenzuj to jako specjalista od bezpieczeństwa, potem jako od wydajności, potem jako architekt”, trzy zestawy ustaleń dzielą kontekst, dzielą to samo pierwsze odczytanie diffa i dzielą wszystko, co model pomylił za pierwszym razem. Zgodność między nimi nie jest potwierdzeniem. To ten sam świadek powtarzający się w trzech kostiumach.

Wtyczka egzekwuje konsekwencję: tylko osobno wysłane konteksty uprawniają do podniesienia pewności ustalenia albo nazwania go niezależnie potwierdzonym, a gdy wysyłka się nie powiedzie i praca idzie w linii, przebieg raportuje utraconą niezależność, zamiast na niej awansować.

Tożsamość modelu to pokwitowanie, nie żądanie

Gdy recenzja jest delegowana do innego dostawcy modeli po drugą opinię, wtyczka zapisuje raport samego backendu o tym, który model obsłużył przebieg, obok modelu, o który poproszono — tak, żeby oba mogły się widocznie nie zgodzić. Wyniki bez takiego pokwitowania są oznaczane jako „poproszone, ale niezweryfikowane”, a logika ważąca zgodność między modelami idzie za pokwitowaniem, nie za żądaniem.

Jeśli kiedykolwiek zbudowałeś wielomodelowy potok recenzji na założeniu, że wskazanie modelu oznacza, że go dostałeś, to jest ten tryb awarii, którego nie oprzyrządowałeś.

Treść skilla, którą host po cichu ucina

Każdy host agentowy ogranicza, ile treści skilla utrzyma w promptcie widocznym dla modelu, każdy dochodzi do tego limitu inną drogą i — to jest część istotna — każde znane ucięcie zachowuje początek treści i odrzuca resztę, a żadne nie zgłasza błędu.

Konsekwencja jest taka, że kolejność jest nośna. Reguła stopu albo granica bezpieczeństwa umieszczona pod długim blokiem routingu może zniknąć, podczas gdy wszystkie kontrole mechaniczne dalej świecą na zielono. Odpowiedzią wtyczki jest „phase-loaded kernel”: zawsze widoczna treść niesie tylko wynik, warunek zakończenia, uprawnienia, kolejność faz i klasy stopu, a mechanika każdej fazy siedzi w pliku referencyjnym ładowanym w chwili działania.

Jeśli piszesz własne skille albo długie pliki instrukcji, to najbardziej użyteczna rzecz w tym repozytorium: umieść to, co musi przetrwać, nad tym, co może zostać ucięte.

Ustalenia niosą kotwicę pewności, nie punktację

Ustalenia z recenzji są bramkowane dyskretną, samodzielnie przyznaną wartością pewności na małej, stałej skali, gdzie każdy poziom wiąże się z kryterium behawioralnym, które model potrafi uczciwie zastosować — celowo nie ciągłym wynikiem, bo ten zachęca do fałszywej precyzji. Potwierdzenie podnosi ustalenie o jeden poziom, ale wyłącznie między kontekstami spełniającymi opisany wyżej próg niezależności.

Wskazówka

Gotowy prompt do audytu niezależności dowolnej recenzji AI, którą już prowadzisz:

Audit the review process described below for independence, not for accuracy.

[paste your review prompt, command, or pipeline description]

Answer these, and refuse to guess:

1. How many separate model invocations does this actually make? Count contexts,
   not personas, roles, or bullet points in the prompt.
2. For each finding the process can produce, what would count as corroboration?
   If two findings can only arise from the same invocation, say so explicitly.
3. Where does the process treat agreement as evidence? Quote the line. Then say
   whether that agreement is between independent contexts or the same context
   talking to itself.
4. Which findings does the process rank or escalate, and is the ranking derived
   from anything other than the model's own confidence in its own output?
5. If a delegated model call silently fell back to a different model, what in
   this process would notice?

Output a table of claims the process makes versus what it can actually support,
and one concrete change that would buy real independence at the lowest cost.

Co się psuje, gdy prowadzisz pętlę kumulacji

Magazyn wniosków staje się drugą bazą kodu, której nikt nie utrzymuje. Zapisywanie jest tanie i satysfakcjonujące; utrzymanie nie jest ani jednym, ani drugim. Bez okresowego przeglądu dostajesz sprzeczne dokumenty o tym samym podsystemie i agenta, który pierwszy znajdzie ten nieaktualny. Rób przebieg Keep/Update/Consolidate/Replace/Delete według harmonogramu albo w ogóle nie zakładaj magazynu.

Instrukcje wygrywają z wnioskami w momencie działania. Słownik wtyczki mówi to wprost: agent ładuje instrukcje skilla, runbook albo główny plik instrukcji w chwili, gdy działa, więc wniosek sprzeczny z tą warstwą nie jest tylko nieaktualny — zostanie w praktyce nadpisany. Gdy wniosek i plik instrukcji się kłócą, plik instrukcji wygrywa, niezależnie od tego, który ma rację. Rozstrzygaj sprzeczność tam, gdzie agent czyta, nie tam, gdzie ty pisałeś.

Recenzja planu znika pierwsza pod presją terminu. Podział 80/20 odwraca się po cichu. Kiedy to nastąpi, jesteś na szczeblu 2 z narzędziami szczebla 4: agenci wypuszczają duże diffy z planów, których nikt nie przeczytał — dokładnie ta konfiguracja, która produkuje zator recenzencki opisany w fabrykach oprogramowania.

--dangerously-skip-permissions jest w przewodniku zalecany warunkowo. Warunki samego Every to gałąź odseparowana od głównej, testy zdolne złapać pomyłkę, ścieżka wycofania i brak realnych użytkowników dotykających kodu, zanim uznasz go za gotowy. Te warunki są całą argumentacją o bezpieczeństwie. Skopiuj flagę bez nich, a skopiowałeś ryzyko bez zabezpieczenia.

Kumulacja jest twierdzona, nie mierzona. „Godzina na agenta recenzującego oszczędza dziesięć godzin recenzji” to prawdopodobny kierunek bez opublikowanej liczby za sobą. Uczciwa wersja brzmi: zmierzysz to na własnym repo. Policz, ile razy na kwartał ktoś tłumaczy tę samą konwencję od nowa, i sprawdź, czy ta liczba spada po powstaniu magazynu. Jeśli nie spada, pętla się kręci, ale nie kumuluje.

Jak prowadzić pętlę bez instalowania czegokolwiek

Pętla jest procesem, nie produktem, i każdy jej krok działa ze zwykłym agentem, folderem docs/solutions/ i dyscypliną. Wtyczka kupuje ci egzekwowanie, odsyłacze i wysyłkę recenzentów — nie sam pomysł.

Zacznij tak, w tej kolejności: trzymaj krótki plik instrukcji ładowany zawsze, załóż wyszukiwany magazyn wniosków, po następnym prawdziwym błędzie zapisz jeden wniosek ręcznie, a miesiąc później sprawdź, czy cokolwiek go przeczytało. Jeśli nic — napraw wyszukiwalność, zanim napiszesz wniosek numer dwa. Ta kolejność jest różnicą między bazą wiedzy a folderem.

Wskazówka

Gotowy prompt na kwartalną ablację magazynu wniosków:

Review this repository's accumulated learning documents. For each one, return
exactly one verdict: KEEP, UPDATE, CONSOLIDATE, REPLACE, or DELETE.

Judge each document against the code as it exists now, not against the state
it described when it was written:

- DELETE if the code it describes no longer exists, the tool it depends on was
  removed, or the problem is now impossible by construction.
- REPLACE if the conclusion is now wrong. Say what is wrong and what the
  current answer is.
- CONSOLIDATE if another document covers the same root cause. Name the pair and
  which one should survive.
- UPDATE if the substance holds but a path, command, version, or API changed.
- KEEP only if you verified at least one specific claim against current code.
  Quote the line you checked.

Then run one extra check that matters more than staleness: for each document,
does it contradict anything in the instruction files this project's agents load
at the start of a session? A contradiction there outranks being out of date,
because the instruction file wins at the moment of acting. Report the file and
the conflicting lines. Do not edit the instruction file.

Output a table sorted by verdict, with DELETE and REPLACE first. Do not apply
anything yet.

Gdzie iść dalej z compound engineeringiem

Przycinanie CLAUDE.md i AGENTS.md Protokół ablacji, lipcowe odwrócenie 2026 i tabela decyzyjna, do którego z pięciu miejsc trafia dana linijka

Fabryki oprogramowania Co dzieje się niżej, gdy pętla działa w skali floty: zatory recenzenckie, rejestry autonomii i dawkowanie zaufania pętla po pętli

Wzorce pamięci Strona wyszukiwania: jak agenty przechowują i przywołują wiedzę między sesjami i co każde narzędzie zapisuje samo z siebie

Dokumentacja jako kontekst Jak sprawić, by dokumentacja czytana przez agenta różniła się strukturalnie od tej dla człowieka, i co badanie ETH mówi o obu

Superpowers Druga zdyscyplinowana wtyczka od projektu do PR, z worktree, wykonywalnymi planami i wymuszonym TDD — przydatna jako bezpośrednie porównanie

PRD, plan, todo Łańcuch artefaktów planistycznych pod pierwszym krokiem pętli, niezależny od jakiejkolwiek wtyczki