Sytuacja
Prawie cały dzień pracuję z agentami do programowania, na kodzie produkcyjnym dla prawdziwych klientów. Agenci są dobrzy i mylą się w przewidywalny sposób. Gubią wątek przy skracaniu rozmowy. Zbaczają z kursu w pracy trwającej kilka dni. Uruchamiają komendy, których nie powinni. Ogłaszają koniec pracy, której nikt nie sprawdził. code-os to system, który zbudowałem do pracy z nimi w Claude Code. Pamięć projektu żyje w repo. Działania agenta przechodzą automatyczne kontrole. Jest ścieżka od spec do weryfikacji. System jest publiczny od czerwca 2026, na licencji MIT. cowork-os to jego odpowiednik do pracy biznesowej, przygotowany dla Claude Cowork. Głównym maintainerem jest Raffaele.
Co zrobiłem
Po sześciu tygodniach codziennego używania przepisałem system do drugiej wersji, wydanej w sierpniu. Większość pracy polegała na usuwaniu: powtórzonych instrukcji, sprzecznych reguł, obowiązkowych kroków, które przy nowszych modelach tylko spowalniały. Zostawiłem to, co naprawdę chroniło pracę.
Zmieniłem też to, kto decyduje. Dziś Claude Code koordynuje, a inni agenci, także od innych dostawców, badają, implementują lub robią review. Inny model często znajduje rzeczy, których autor nie widzi. Ostatnie słowo o tym, co trafia do kodu, zostaje u osoby, która koordynuje, czyli u mnie.
Co się zmieniło
Przy małych zadaniach mam mniej formalności, a przy ważnych więcej kontroli. Nowa sesja zaczyna tam, gdzie skończyła się poprzednia, bez ponownego czytania czatu. Praca jest skończona dopiero wtedy, gdy sam ją sprawdzę. Tak zbudowałem swój second brain. To on utrzymuje tę stronę na bieżąco.
Czego się nauczyłem
Pierwsza wersja code-os miała kilka nakładających się dokumentów z regułami. Dwa z nich ustalały różne limity dla tej samej rzeczy. Nikt tego nie zauważył, bo każda nowa reguła wyglądała jak ulepszenie. Instrukcje dla agentów rosną jak kod, ale nikt nie traktuje ich jak kodu: dodaje się je i nigdy nie usuwa. W drugiej wersji usunąłem dokumenty, które mówiły agentowi, gdzie patrzeć, i ręcznie napisałem krótki plik instrukcji. Dziś każda reguła ma jedno źródło. Jeśli nie potrafię na głos wyjaśnić, jak pracuje agent, wiem, że plik jest za długi.
Pierwsza wersja wymagała spec, planu i wykonania dla każdego nietrywialnego zadania. Z modelami z początku 2026 miało to sens. Po sześciu tygodniach codziennego używania, z lepszymi modelami, ten cykl stał się stałym kosztem nawet przy małych zadaniach. Wydawał się częścią, która chroni pracę. Pamięć i zabezpieczenia były czymś osobnym. Nigdy nie były kosztowną częścią, więc zostawiłem wszystkie włączone. Dziś małe zadania po prostu się robi. Średnie omawia się bezpośrednio z modelem. Pełny cykl zostaje dla pracy dłuższej niż jedna sesja. Ten próg sprawdzam ponownie, gdy zmieniają się modele.
Godziny stracone na delegowaniu pracy innym agentom z wiersza poleceń nie wynikały z tego, że agenci robili coś źle. Wynikały z procesów, które czekały, nie mówiąc o tym, i wyników znikających bez błędu. Agent zwracający pustą wiadomość na pierwszy rzut oka wygląda jak agent, który skończył. Od tamtej pory każde delegowane zadanie ma ustalone miejsce na wynik jeszcze przed startem. Pusty wynik oznacza niepowodzenie. Zanim zaakceptuję jakąkolwiek pracę, sam czytam zmiany i ponownie uruchamiam testy. Relacja agenta mówi mi tylko, gdzie patrzeć.
W lipcowej wersji cowork-os daliśmy każdej decyzji stan, źródło, osobę odpowiedzialną i datę review. To, co system znajduje w mailach i na czacie, trafia jako kandydat do zatwierdzenia. Pamięć firmy może idealnie zapamiętać zdanie i błędnie uznać je za obowiązujące. Hipoteza rzucona na rozmowie, przeczytana miesiąc później, wygląda jak podjęta decyzja. Dziś w moim second brain obowiązuje ta sama zasada: to, co wynika z rozmowy, pozostaje kandydatem, dopóki ktoś tego nie zatwierdzi. Historia tego, co zastąpiło co, zostaje.
// każdy prompt injection mile widziany.