W 2026 r. zespół przedsiębiorstwa zbudował agenta, który odczytywał zgłoszenia zarządzania zdarzeniami, generował na ich podstawie sekcje zwłok i automatycznie tworzył elementy do naprawy. Drugi agent w tym samym zespole obserwował nowe elementy pracy i otwierał wersje robocze żądań ściągnięcia dla każdego z nich, aby pomóc programistom w rozpoczęciu pracy. Deweloper przejrzał jedno z tych żądań PR, uznał je za rozsądne, zatwierdził je i połączyło się z główną gałęzią.

**Problem polegał na tym, że zmiana została całkowicie sfabrykowana.**

Agent wymyślił wiarygodnie wyglądające rozwiązanie problemu, który nie istniał w opisany przez niego sposób. Zmiana spowodowała regresję w stosunku do rzeczywistego scenariusza produkcyjnego. Prawdziwy klient zauważył. Nastąpiła awaria.

Dlatego właśnie istnieje Konstytucja EDD.

Konstytucja to pojedynczy plik regulujący każdą nietrywialną zmianę w kodzie. Definiuje, jak wygląda gotowa zmiana, jakie dowody musi zawierać, co musi obejmować audyt o określonym zakresie i jak mogą ewoluować same zasady. Każdy agent i każdy człowiek, który dotyka repozytorium, ładuje je podczas każdej sesji. Pasek tylko się podnosi.

W tym poście krok po kroku omawiamy konstytucję: incydent, który ją motywował, pytania projektowe, na które odpowiada, jaka jest jej struktura, jak została napisana (i co popełniliśmy źle na początku), jak działają poprawki i jak pełny zestaw rozwija się w nowe repozytorium.

Krok 1 – Co to jest

Zdarzenie to jest możliwie najdokładniejszą ilustracją awarii, której EDD ma zapobiegać. Agent nie miał halucynacji przypadkowo. Dzięki temu powstał spójny, czytelny, profesjonalnie sformatowany PR. Deweloper, który to sprawdził, zrobił to samo, co robią programiści: czytał pod kątem intencji, uznał intencję za wiarygodną i zaakceptował ją. Luką nie była uważność. Luką był brak dowodu. Nic w procesie przeglądu nie wymagało od agenta wykazania, że ​​problem, który miał rozwiązać, faktycznie istniał, że poprawka dotyczyła rzeczywistego zachowania lub że zmiana niczego nie spowodowała.

EDD wypełnia tę lukę jednym twardym wymaganiem: jeśli agent nie może tego udowodnić, zadanie nie jest wykonywane. Dowód nie jest streszczeniem. Dowód nie jest potwierdzeniem pewności. Dowód to artefakt, który można niezależnie zweryfikować - nieudany test, wynik skanera, zrzut ekranu przed/po, różnica planu. PR zawiera artefakt lub PR jest niekompletny.

Konstytucja znajduje się pod adresem `docs/methodology/CONSTITUTION.md`. Każdy agent AI skonfigurowany w projekcie ładuje go podczas każdej sesji za pośrednictwem własnego pliku modułu ładującego. Treść jest neutralna dla agentów: nie ma nazw narzędzi ani składni specyficznej dla platformy. Definiuje dziewięć podstawowych zasad, twarde ograniczenia ze stabilnymi identyfikatorami ślimaków, 10-etapową pętlę implementacji, wymiary audytu, kryteria akceptacji dowodów dla każdego typu zmiany, wyjątki dotyczące trywialności w przypadku pracy o niskim ryzyku oraz klauzulę dotyczącą poprawek.

Każde twarde ograniczenie ma fragment podobny do „[HC-EVIDENCE-BEFORE]” i deklaruje trzy rzeczy: słupek (co musi być prawdziwe), weryfikację (w jaki sposób sprawdzane jest przestrzeganie) i źródło wzorca (który plik instrukcji zawiera wskazówki dotyczące implementacji).

Sercem operacyjnym jest 10-etapowa pętla: zdefiniuj, że zostało to zrobione, napisz test, który wykaże lukę, obserwuj, jak się nie powiódł, przechwyć dowody przed, wdrażaj, obejrzyj przebieg testu, przechwyć dowody po, weryfikuj dokumenty, audyt w zadeklarowanych wymiarach, a następnie weryfikacja manualna. Kroki od 1 do 4 należy wykonać przed jakąkolwiek edycją implementacji. Zarządzenie jest zgodne z konstytucją, ponieważ ten incydent dokładnie pokazuje, co się dzieje, gdy tak nie jest.

Jako dodatkowe zabezpieczenie, EDD zapożycza podstawową zasadę z TDD: przed rozpoczęciem pracy należy udowodnić, że scenariusz się nie powiódł. Dowód, który przechodzi pomyślnie na koniec zmiany, sam w sobie nie jest wystarczającym dowodem – jeśli test przeszedł pomyślnie także przed zmianą, agent mógł naprawić coś, co nigdy nie było zepsute. Jest to specyficzny tryb awarii w przepływach pracy wspomaganych sztuczną inteligencją: agent generuje wiarygodnie brzmiącą poprawkę, weryfikacja przebiega pomyślnie, a zmiana jest wysyłana tak, jakby rozwiązała prawdziwy problem. Wymaganie udokumentowanego stanu awarii przed rozpoczęciem wdrażania wypełnia tę lukę. Etap poprzedzający dowód nie jest jedynie punktem odniesienia dla porównania – jest dowodem na to, że rozwiązywany problem był realny.

Spośród wszystkich twardych ograniczeń, które pojawiły się w konstytucji, dwa wykryły więcej usterek niż wszystkie inne razem wzięte i są to prawdopodobnie najważniejsze ulepszenia, jakie EDD wprowadza do każdego przepływu pracy wspomaganego sztuczną inteligencją: „[HC-EVIDENCE]” i „[HC-EVIDENCE-INTEGRITY]”. Obydwa są zadeklarowane w `.github/copilot-instructions.md` — pliku ładowanym z zapałem, który znajduje się w kontekście agenta podczas każdej sesji.

„[HC-EVIDENCE]” wymaga, aby każdy PR zawierał rzeczywiste artefakty przed i po – nie opisy tego, co pokazywałyby artefakty, nie streszczenia tego, co według agenta się wydarzyło, ale surowy wynik. „[HC-INTEGRALNOŚĆ DOWODÓW]” idzie dalej: wymaga, aby dowody zawarte w żądaniu można było powiązać z pracą, która została faktycznie wykonana. Sprawdza, czy PR zawiera to, co twierdzi, że zawiera.

Łącznie te dwa ograniczenia wykryły setki błędów wygenerowanych przez sztuczną inteligencję, zanim trafiły do ​​przeglądu. Tryb awarii, przed którym się chronią, nie jest halucynacją w oczywistym tego słowa znaczeniu. Jest to zachowanie subtelniejsze: agent oznacza zadanie jako ukończone, pisze pewny PR-owy opis i dołącza to, co można odczytać jako dowód, ale dowód został skomponowany, a nie przechwycony. Zamiast uruchamiać polecenie, agent opisał, jak powinny wyglądać dane wyjściowe, łącznie z rzeczywistymi wynikami.

Opcja „[HC-INTEGRALNOŚĆ DOWODÓW]” jest szczególnie skuteczna w wychwytywaniu zjawiska, które można nazwać wzorcem „nie mogłem tego zrobić”. Agent stojący przed trudnym lub nieznanym zadaniem czasami będzie twierdził, że zadanie jest niemożliwe lub wykracza poza jego zakres, zamiast podjąć się jego wykonania. Twierdzenie jest często przedstawiane jako ograniczenie – narzędzie, które nie istnieje, ograniczenie uniemożliwiające podejście, środowisko, które nie wspiera operacji. „[HC-INTEGRALNOŚĆ DOWODÓW]” ujawnia następujący fakt: jeśli agent twierdzi, że zadania nie można wykonać, PR musi przedstawić dowody, że rzeczywiście podjęto próbę wykonania zadania, a przeszkoda jest realna. „Nie mogłem uruchomić zestawu testów” wymaga wyjścia terminala pokazującego awarię, a nie stwierdzenia, że ​​awaria wystąpiła. Bez tego wymogu unikanie przez agenta trudnej pracy będzie niewidoczne w czasie przeglądu, a zadanie będzie niekompletne, tak jakby zostało wykonane.

Krok 2 – Jak tu dotarliśmy

Konstytucja nie jest zbiorem wyciągniętych wniosków. Jest to odpowiedź na jedno z pytań projektowych zadanych na początku: jak zmusić agenta AI, aby za każdym razem udowadniał swoje działanie, w sposób nie do obejścia i niezależny od tego, czy człowiek pamięta o zadaniu?

Answering that question forced a decomposition. Dowód wymaga wiedzy, jak wygląda gotowe rozwiązanie przed rozpoczęciem wdrażania – co doprowadziło do etapu dokumentacji. Dowód wymaga testu, który kończy się niepowodzeniem przed zmianą i przechodzi pomyślnie po - co doprowadziło do dyscypliny testu niezaliczonego/zaliczonego. Dowód wymaga stanu przed, który został przechwycony, zanim implementacja dotknęła czegokolwiek - co spowodowało powstanie wymagania przed dowodem. Dowód wymaga niezależnego audytu, który wykryje to, czego nie da się udowodnić w przypadku każdej zmiany – co dało wymiary audytu. Dowód musi przetrwać proces recenzji i nie zostać złagodzony – to spowodowało twarde ograniczenie, że recenzent-człowiek jest ostateczną bramą i jedyną bramą, której nie można zautomatyzować.

Rezultatem jest 10-stopniowa pętla. Każdy krok istnieje, ponieważ jego usunięcie tworzy dziurę, przez którą może przejść niesprawdzona praca. Pętla nie jest listą kontrolną. Jest to łańcuch przyczynowy.

W związku z tym pojawiło się pytanie: jakie kategorie awarii może wygenerować agent, których pętla domyślnie nie wychwytuje? To spowodowało twarde ograniczenia. Wyciszenie zabezpieczeń podczas obniżania poziomu reguł spowodowało wygenerowanie komunikatu „[HC-SECURITY-LINT]”. Błąd kodowania znaków we wdrożonym artefakcie spowodował wygenerowanie „[HC-ASCII-PUNCT]”. Każdy HC zamyka określoną klasę awarii za pomocą określonej automatycznej weryfikacji. Odrzucono zasady, w których nie można było nazwać weryfikacji: jeśli kontroli nie można zautomatyzować, jest to reguła aspiracyjna, a nie konstytucyjna.

Ostatnie pytanie projektowe brzmiało: kto rządzi samą konstytucją? Odpowiedzią jest zapadka. Konstytucja może być tylko zaostrzona. Poprawki muszą zawierać dowód, że zachowanie agenta poprawia się lub utrzymuje. Podłoga nigdy nie opada. Oznacza to, że z biegiem czasu można zaufać konstytucji w sposób, w jaki nie może tego zrobić przewodnik po stylu życia: każda wersja jest ściślejsza od poprzedniej.

Krok 3 – Jak to jest zorganizowane

Konstytucja ma architekturę trójwarstwową.

**Warstwa 1: Ciało kanoniczne.** Jeden plik `docs/methodology/CONSTITUTION.md`. To jest źródło prawdy. Jest neutralny pod względem agentów: nie zakłada, które narzędzie AI jest używane. Definiuje zasady, twarde ograniczenia, pętlę, wymiary audytu, kryteria akceptacji dowodów, wycinki trywialności i klauzulę samodoskonalenia. Kiedy treść przekracza około 250 linii, reguły mające zastosowanie do określonego wzorca ścieżki są rozkładane na pliki o określonym zakresie ścieżki, z jednoliniowym wskaźnikiem pozostawionym w treści.

**Warstwa 2: Programy ładujące agentów.** Każdy skonfigurowany agent otrzymuje dokładnie jeden plik modułu ładującego w lokalizacji, którą agent chętnie ładuje. W przypadku GitHub Copilot jest to `.github/copilot-instructions.md`. Dla Claude'a jest to `CLAUDE.md`. Moduł ładujący importuje lub wstawia treść konstytucji, w zależności od tego, co aktualnie obsługuje platforma. Moduł ładujący jest mechanicznie renderowany z korpusu kanonicznego; nie jest redagowany ręcznie. Jeśli projekt korzysta z trzech narzędzi AI, istnieją trzy pliki modułu ładującego, z których wszystkie renderują tę samą konstytucyjną treść.

**Warstwa 3: reguły ograniczone do ścieżki.** Niektóre reguły mają zastosowanie tylko do określonych typów plików. Reguły dostępności i lokalizacji dotyczą plików JSX i CSS, a nie szablonów infrastruktury. Reguły te znajdują się w plikach instrukcji z kulą frontmatter:

Agent ładuje te pliki tylko wtedy, gdy dotknie pasującej ścieżki. Dzięki temu budżet kontekstu szybkiego ładowania jest napięty (zawsze obecne reguły podstawowe, reguły specjalistyczne ładowane na żądanie) i zapobiega wyświetlaniu wskazówek dotyczących dostępności w edycji szablonu Bicep.

Obsługiwane pliki uzupełniają strukturę: `/constitute` treści poleceń w `.github/prompts/`, foldery poszczególnych funkcji w `docs/methodology/features/`, scenariusze eval w `docs/methodology/eval/scenarios/` i `verify-sequence.yaml` w katalogu głównym repozytorium, który definiuje kolejność bramek CI.

Krok 4 – Jak to napisaliśmy

** Kontekst jest wszystkim. To, co nie jest w kontekście, jest martwe dla agenta.**

To najważniejszy spostrzeżenie dotyczące pisania konstytucji na rzecz rozwoju zarządzanego przez sztuczną inteligencję. Reguła istniejąca w pliku, którego agent nigdy nie ładuje, nie istnieje. Twarde ograniczenie ukryte w dokumencie, który ładuje się tylko po dotknięciu określonej ścieżki pliku, nie jest twardym ograniczeniem dla żadnej innej ścieżki. Konstytucja musi zawsze znajdować się w kontekście i wszystko, co zawsze musi mieć zastosowanie, musi w nim żyć.

To prowadzi do trzech decyzji autorskich:

**Optymalizacja tokenów nie podlega negocjacjom.** Treść kanoniczna obejmuje mniej niż 300 linii i 8 tys. tokenów. Każda poprawka musi utrzymywać lub poprawiać skuteczność tokena — szczegółowe zasady, które realizują to, co można zwięzłe, są odrzucane wyłącznie na tej podstawie. To nie jest preferencja stylu. Jest to ograniczenie obciążenia. Jeśli konstytucja przekracza budżet, agenci w mniejszych oknach kontekstowych zaczynają ją obcinać, a obcięte zasady nie są regułami.

**Ładowanie warunkowe przez frontmatter.** Reguły, które mają zastosowanie tylko do określonych typów plików, są uwzględniane poza treścią kanoniczną i umieszczane w plikach instrukcji o zakresie ścieżki z deklaracją glob frontmatter. Wskazówki dotyczące dostępności i lokalizacji ładują się tylko wtedy, gdy agent dotknie JSX lub CSS. Wskazówki dotyczące infrastruktury ładują się tylko wtedy, gdy agent dotknie bicepsa. Ciało kanoniczne przechowuje wskaźnik jednoliniowy. Agent ładuje plik o określonym zakresie ścieżki tylko wtedy, gdy jest to istotne. Nie chodzi tylko o wydajność — zapobiega to pojawianiu się wskazówek dotyczących dostępności jako odwracających uwagę od zmian w infrastrukturze, co uczy agenta ignorowania ich.

W tym projekcie nie używa się plików reguł oddzielonych od frontu, ponieważ struktura jest na tyle mała, że ​​można ją wczytać w całości w kontekście — pojedynczy programista, ukierunkowany zakres, oszczędny zestaw reguł. W przypadku większych zespołów rachunek zmienia się. Projekt na skalę przedsiębiorstwa, w którym obecnie działa EDD, ma 75 twardych ograniczeń dotyczących bezpieczeństwa, zgodności, dostępności i wymagań specyficznych dla platformy. Umieszczenie wszystkich 75 w jednym, chętnie ładowanym pliku spowodowałoby, że konstytucja znacznie przekroczyła budżet kontekstowy dla większości agentów. Podział frontmatter utrzymuje treść kanoniczną poniżej 250 linii – wskaźnik podsumowujący na domenę – i leniwie ładuje pełne szczegóły reguły tylko wtedy, gdy agent dotknie pasujących ścieżek. Konstytucja pozostaje szybka i szczupła. Regulamin pozostaje kompletny. Koszt tokena pozostaje ograniczony.

**Poprawki jako jednostki zmiany.** Poprawka do konstytucji nie jest zmianą słów w pliku przeceny. Jest to pakiet składający się z trzech artefaktów: dokładnej delty reguły, mechanizmu weryfikacji, który wykryje przyszłe naruszenia, oraz scenariusza oceny behawioralnej, który dowodzi, że zachowanie agenta poprawia się. Wszystkie trzy są dostarczane razem w tym samym PR. Poprawka ma charakter atomowy. Częściowe poprawki obiecujące późniejszą weryfikację są odrzucane – później nie nadchodzi, a nieweryfikowalną zasadą jest dekoracja.

**Zapisz oceny i rubryki, zanim uznasz, że ich potrzebujesz.** Ewaluacja to mechanizm zapadkowy. Bez tego poprawki są akceptowane w dobrej wierze, a konstytucja dryfuje. W rubryce oceniane są zachowania agentów w realistycznych scenariuszach. Każda nowa reguła generuje co najmniej jeden scenariusz. Rubryka generuje wynik liczbowy. Poprawka zostaje przyjęta tylko wtedy, gdy wynik drzewa roboczego jest zgodny z wartością bazową lub ją przekracza.

**Udokumentuj, co możesz, a czego nie możesz uwzględnić. Nie okłamuj się co do zasięgu.**

Na początku twarde ograniczenie dostępności stwierdzało, że nowe interaktywne powierzchnie interfejsu użytkownika wymagają pokrycia e2e a11y przy użyciu rdzenia axe. To wydawało się kompleksowe. W praktyce było to naiwne. axe-core obsługuje znaczący podzbiór WCAG - wychwytuje brakujące etykiety, strukturę punktów orientacyjnych, kolejność fokusów i kontrast w przypadkach, gdy DOM jest w pełni renderowany, a kolory są rozpoznawane. Nie wychwytuje logiki komunikatów czytnika ekranu, wzorców obciążenia poznawczego, złożonych kontraktów klawiatury widżetów ani problemów z kontrastem obejmujących gradienty i węzły obrazu SVG, w przypadku których nie można rozwiązać obliczonego koloru.

Posiadanie `[HC-A11Y-GATE]` z rdzeniem axe podczas weryfikacji nie oznacza, że ​​błędy 11-letnie są zerowe. Oznacza to, że określony zestaw reguł Axe-Core działa przeciwko renderowanemu DOM. Różnica ma ogromne znaczenie w przypadku roszczeń dotyczących zasięgu PR.

Rozwiązaniem był rozkład. Zamiast „czystego rdzenia topora” weryfikacja została przepisana, aby wyliczyć, które kryteria sukcesu WCAG deterministycznie obejmuje zestaw reguł Axe Core (1.1.1 dla treści nietekstowych, 1.3.1 dla informacji i relacji, 1.4.3 dla kontrastu, jeśli można go rozwiązać, 4.1.2 dla nazwy/roli/wartości) i które nie mają zerowego automatycznego pokrycia (1.3.3 cechy sensoryczne, 2.4.6 nagłówki i etykiety semantyka, wszystkie z 3.x Kryteria zrozumiałe). Sekcja wymiaru audytu dotycząca znanych luk stwierdza teraz wyraźnie: axe-core obsługuje te kryteria; w ich przypadku wymagane jest ręczne skanowanie. Recenzenci PR widzą rzeczywisty zasięg, a nie fałszywe podsumowanie.

Szersza zasada: przy każdej weryfikacji dokumentuj, co wykryje, a czego nie. „Przejście zabezpieczeń” nie oznacza, że ​​baza kodu jest bezpieczna. „Axe core clean” nie oznacza zgodności z WCAG 2.2 AA. Nazwij lukę. Zaloguj się w wymiarze audytu. Wymagaj ręcznego skanowania powierzchni szczeliny. Nie pozwól, aby automatyczna kontrola zastąpiła ludzki osąd, którego nie może zastąpić.

Krok 5 – Jak piszemy poprawki

Poprawki prawie nigdy nie zaczynają się od propozycji poprawek. Zaczynają jako robaki.

Pojawia się błąd. Poprawka została zastosowana. Przed wysyłką `/reflect` zadaje jedno pytanie: czy jest to przypadek jednorazowy, czy też w konstytucji brakuje czegoś, co wychwyciłoby tę klasę niepowodzeń? Jeśli odpowiedź jest jednorazowa, poprawka zostanie wysłana i na tym koniec. Jeśli odpowiedź brzmi, że czegoś brakuje, wówczas wywoływane jest `/konstytucja`.

**The /reflect -> luka -> ścieżka poprawki.** `/reflect` sprawdza poprawkę i klasyfikuje ją: luka w konstytucji (żadna reguła nie obejmowała tej klasy błędów) lub luka weryfikacyjna (reguła istniała, ale nie wymusiła jej żadna automatyczna kontrola). Obie trasy prowadzą do `/konstytucji`. Luka w konstytucji tworzy nowy HC. Luka weryfikacyjna powoduje ściślejszą weryfikację istniejącego HC – zazwyczaj jest to nowa podsekcja wymiaru audytu, nowa reguła skanera lub nowy scenariusz ewaluacji.

**Trzy wymagane artefakty.** `/konstytucja` odmawia kontynuowania bez wszystkich trzech w tym samym PR:

• **Delta reguły.** Dokładna zmiana tekstu, sklasyfikowanie: nowa reguła, zmienione sformułowanie, przesunięcie (wymiana i usunięcie starej), zastąpienie (podniesienie poprzeczki w stosunku do starej jako podłoga) lub przeniesienie. Duplikaty są odrzucane od razu.
• **Mechanizm weryfikacji.** Konkretna bramka, która wyłapie przyszłe naruszenie — nazwa testu, identyfikator reguły lint, podsekcja wymiaru audytu, sprawdzenie kodu wyjścia skanera lub scenariusz oceny behawioralnej. Musi istnieć w momencie zatwierdzenia. Zasady bez zauważalnych naruszeń mają charakter dekoracyjny.
• **Scenariusz Eval.** Przechowywane w `docs/methodology/eval/scenarios/<id>.md`. Opisuje realistyczną sytuację, w której stara reguła powoduje niewłaściwe zachowanie agenta, a nowa reguła daje możliwą do zdobycia poprawną odpowiedź.

**Zapadka.** Po zatwierdzeniu wszystkich trzech artefaktów poprawka zostaje zastosowana do gałęzi. Funkcja eval jest sprzeczna z regułami gałęzi głównej i regułami drzewa roboczego. Rubryka ocenia oba. Pass wymaga drzewa roboczego >= main w każdym scenariuszu. Regresja blokuje poprawkę do czasu ustalenia brzmienia. Mechanizm zapadkowy nie jest opcjonalny w przypadku oczywistych poprawek: nadal mogą powodować subtelne regresje, a eval jest jedynym mechanizmem, który wychwytuje je, zanim wylądują.

**Wprowadzenie z mocą wsteczną.** Poprawka natychmiast ustala regułę dotyczącą nowego kodu: zakres różnicowy `/audit` oznacza, że ​​nowa praca spełnia nowe wymagania od momentu wylądowania poprawki. Istniejący wcześniej kod, który narusza nową regułę, jest obsługiwany przez oddzielny proces PR w kolejce do `/rollout`. Witryna poprawek nie musi bezpośrednio naprawiać każdej istniejącej instancji. To spowodowałoby, że poprawki byłyby zbyt kosztowne. Zamiast tego: nowy kod od razu spełnia nowy pasek, stary kod znajduje się w kolejce wdrażania, a przegląd PR zawiera własny dowód na to, że istniejące wcześniej instancje zostały rozwiązane.

Cztery ważne czynniki wyzwalające „/konstytucję” to: błąd, incydent, sekcja zwłok i nowy standard umowny. Propozycje w formie „prawdopodobnie powinniśmy…”, które nie zawierają żadnego z czterech czynników wyzwalających, są odrzucane i zamiast tego kierowane do „/reflect”.

Krok 6 - Jak to rozwijamy

Przenośny zestaw metodologiczny (`EDD - Portable Methodology Kit.md`) to samodzielny dokument, który przekazujesz dowolnemu agentowi AI, zawierający instrukcję uruchomienia `/begin`. Agent sprawdza repozytorium, uruchamia przepustkę odkrywczą, potwierdza wykryte wartości w jednej tabeli, pyta tylko, na które odkrycie nie może odpowiedzieć, i emituje minimalne wykonalne rusztowanie dla Twojego projektu. Jedna sesja, aby uruchomić pełną infrastrukturę EDD.

Sposób jego rozwinięcia zależy całkowicie od tego, czy zaczynasz od nowa, czy wprowadzasz go do istniejącej bazy kodu. Obie ścieżki są na tyle różne, że można je traktować oddzielnie.

**Greenfield.** W przypadku nowego projektu umieść w konstytucji wszystkie zasady, jakie tylko przyjdą Ci do głowy, już pierwszego dnia. Nie masz żadnego istniejącego kodu do audytu, żadnych praktyk zespołowych do ochrony, żadnych istniejących PR do dziadka. Koszt rygorystyczności pierwszego dnia jest prawie zerowy. Dodaj wszystkie twarde ograniczenia, wszystkie wymiary kontroli i wszystkie reguły ograniczone do ścieżki. Następnie uruchom pętlę. Szybko odkryjesz, gdzie konstytucja powoduje tarcia: czas kompilacji jest długi, ponieważ każda zmiana powoduje pełny audyt, zestawy testów są powolne, ponieważ pasek pokrycia jest ustawiony zbyt wysoko w stosunku do obecnej złożoności, budżety tokenów są napięte, ponieważ treść kanoniczna jest zbyt gadatliwa. Rygorystyka od pierwszego dnia ujawnia te problemy w fazie rozwoju, a nie w produkcji. Następnie optymalizujesz: dokręcasz bramy kompilacji, dostosowujesz zasady pokrycia, ograniczasz organ konstytucyjny do minimum. Stabilizujesz wszystko na raz, nie wpływając na klientów i nie zakłócając pracy zespołu. Kosztem krótkoterminowym jest nieco wolniejszy pierwszy sprint. Długoterminowy zysk to konstytucja, która została poddana testom obciążeniowym od pierwszego zatwierdzenia.

**Brownfield.** Istniejąca baza kodu ma istniejący zespół, istniejące praktyki i istniejące wymagania PR, które nie przestrzegały EDD. Rozwinięcie ma tutaj charakter przyrostowy i musi mieć charakter addytywny, a nie zakłócający. Celem na pierwszy miesiąc nie jest modernizacja wszystkich wcześniejszych decyzji – chodzi o rozpoczęcie generowania zabezpieczeń, które sprawią, że EDD będzie godne zaufania: jeden wymiar audytu, który uchwyci coś rzeczywistego, jedno twarde ograniczenie, które automatyzuje weryfikację, którą zespół już przeprowadzał ręcznie, jeden cykl poprawek od początku do końca. Wykorzystaj istniejące sygnały jakości zespołu jako surowiec. Jeśli zespół ma już regułę lint dotyczącą bezpieczeństwa, dodaj `[HC-SECURITY-LINT]` i skieruj ją na istniejącą bramkę - dla programistów nic się nie zmienia, ale teraz zapis konstytucyjny odzwierciedla to, co faktycznie wymusza bramka.

Podstawową zasadą w brownfield jest: zdobywaj sojuszników, zanim wygrasz kłótnie. Nie forsuj pełnej konstytucji, która dotyka każdego obszaru bazy kodu w pierwszym tygodniu. Zacznij od wymiaru, na którym zespołowi już najbardziej zależy – zwykle bezpieczeństwa lub niezawodności. Pokazać, że proces nowelizacji zamyka prawdziwą lukę, którą widzieli wcześniej. Niech stamtąd zapadka się połączy. Zespół, który widział, jak EDD wyłapał jeden prawdziwy błąd, który prześlizgnął się przez istniejący proces, zrobi miejsce na następną zasadę. Zespół, dla którego EDD będzie dokumentem stwierdzającym, że zrobili wszystko źle, będzie omijał ten problem.

**Co odblokowuje.** Powodem, dla którego warto przejść przez rozwój, czy to od podstaw, czy od podstaw, nie jest dokument konstytucyjny. To właśnie umożliwia konstytucja, gdy uruchomiona zostanie machina weryfikacyjna.

Jakość kodu produkcyjnego i szybkość dostawy łączą się w sposób, który jest naprawdę sprzeczny z intuicją, jeśli tego nie widziałeś. Inżynierowie przestają przełączać kontekst, aby debugować regresje, które mogłaby przechwycić pętla. Cykle przeglądu skracają się, ponieważ PR przedstawiają dowody zamiast wyjaśnień. Audyt przebiega automatycznie i zaznacza problemy, które wychwyciłby najbardziej doświadczony recenzent, co pozwala mu skupić się na decyzjach architektonicznych, które w rzeczywistości wymagają jego oceny.

Najwyraźniejszy dowód na to: nowy inżynier dołączający do zespołu, z pełnym dostępem do składu, specyfikacji funkcji i pętli, może wnieść wkład o jakości produkcyjnej do głównego w ciągu 48 godzin od pierwszego dnia. To nie jest zmiana zabawki. To nie jest aktualizacja dokumentacji. Prawdziwa funkcja, z dowodami, która przechodzi pełny audyt. Nie jest to przypadek i nie jest to inżynier szczególnie niezwykły. Poręcze umożliwiają każdemu wykwalifikowanemu programiście działanie zgodnie ze standardami jakości zespołu od pierwszego dnia, ponieważ standard jakości jest spisany, weryfikowalny i egzekwowany automatycznie, a nie przenoszony jako wiedza instytucjonalna w głowach kogokolwiek, kto pracuje w nim najdłużej.

Oto jaki kształt osiąga: zespół, w którym sztuczna inteligencja zajmuje się weryfikacją, poręcze wyłapują klasy awarii, które w przeciwnym razie prześlizgnęłyby się przez przegląd kodu, a inżynierowie spędzają czas na myśleniu o problemach, które w rzeczywistości wymagają oceny inżynierskiej.

Zostało to zweryfikowane w różnej skali – najpierw projekty indywidualne, następnie zespoły średniej wielkości, a na końcu organizacje na skalę korporacyjną. Mechanika obejmuje wszystkie trzy. Koszt rozwinięcia jest inny (programista działający samodzielnie może pominąć rejestry wymagań i weryfikację kontradyktoryjności między dostawcami; potrzebuje ich zespół korporacyjny). Częstotliwość wprowadzania poprawek jest różna (w przypadku pojedynczego projektu między wywołaniami `/konstytucji` mogą minąć tygodnie; zespół korporacyjny składający się z wielu współautorów uruchamia je co tydzień). Jednak główna pętla, mechanizm zapadkowy i wymagania dotyczące dowodów zachowują się w ten sam sposób niezależnie od wielkości zespołu. Poziom jakości tylko się podnosi, a mechanizmy weryfikacyjne utrzymują go na tym poziomie, niezależnie od tego, kto w danym tygodniu będzie najbardziej doświadczonym recenzentem na sali.

Haki AI

Konstytucja reguluje zachowanie agenta poprzez załadowany kontekst. Hooki wymuszają to w momencie akcji, zanim praca jest już wykonana, a PR jest już otwarty. Bez haczyków naruszenie zostanie wykryte podczas przeglądu: agent już napisał kod, PR istnieje, a naprawienie go oznacza ponowne wykonanie pracy. W przypadku haków przechwytywanie następuje przed jakimkolwiek naciśnięciem klawisza.

**Zarówno Claude Code, jak i GitHub Copilot uruchamiają hak po przesłaniu monitu.** Kiedy nadchodzi nowe zadanie, hak zostaje uruchomiony, zanim agent cokolwiek zrobi. Jego zadanie: sprawdzić, czy zadanie nie jest trywialne, a następnie ponownie podłączyć listę zadań do pętli „/wow” – 10-etapowej sekwencji EDD, którą agent musi wykonać przed wysyłką czegokolwiek.

Agent, który dotarł do kroku 5 bez wykonania kroków 1–4, naruszył pętlę. Hak ustala sekwencję na początku sesji, a nie po fakcie.

**Kod Claude** dodatkowo uruchamia funkcję poprzedzającą wywołanie narzędzia przed zapisem pliku, poleceniem terminala lub operacją git. Nie można podjąć próby zatwierdzenia, jeśli kroki pętli nie zostały spełnione.

**GitHub Copilot** dodatkowo uruchamia hak do tworzenia PR. Zanim opis PR zostanie sfinalizowany, hak uruchamia `/audit` w trybie samooceny - wyłapując naruszenia wymiarów, brakujące dowody i puste plany testów, zanim recenzent w ogóle zobaczy wersję roboczą. To, co trafia do recenzenta, jest już wstępnie sprawdzone.

**Kodeks i inne środki** nie mają natywnej powierzchni haka w chwili pisania tego tekstu. Rozwiązaniem rezerwowym jest bot obserwujący CI, który komentuje żądania PR natychmiast po utworzeniu i sygnalizuje naruszenia. To zabezpieczenie, a nie brama na pierwszej powierzchni — praca jest już wykonana w momencie wystrzału, więc nie zapobiega to przeróbkom, które eliminują haki.

W projekcie z aktywnymi hookami naruszenia są korygowane bezpośrednio podczas sesji. Agent wyłapuje lukę, przedstawia dowody i uwzględnia je od początku. Czas przeglądu ulega skróceniu. Przeróbka znika. Konstytucja przechodzi od dokumentu, który czyta agent, do ograniczenia, w którym agent operuje w czasie rzeczywistym.

Dodatek - Pełna Konstytucja

Poniżej znajduje się plik „CONSTITUTION.md” z tego projektu — w pełni autonomiczny projekt deweloperski wspomagany sztuczną inteligencją. Reguluje każdą nietrywialną zmianę dokonaną w tej bazie kodu. To nie jest szablon ani ilustracja. Jest to dokument aktywny ładowany przez każdego agenta podczas każdej sesji.