Od połowy kwietnia do połowy czerwca prawie nie ruszałem funkcji swojego produktu.
Budowałem OwlMeans, czyli pipeline wytwarzania, który z user stories robi oprogramowanie. Praca wokół niego była tymczasem rozproszona: strategia, notatki o marce, research i teksty na stronę leżały w różnych miejscach.
Za każdym razem, gdy prosiłem agenta o pomoc, od nowa opowiadałem mu o firmie.
Przez dwa miesiące to zmieniałem. Zbudowałem przestrzeń roboczą, w której dziś trzymam wiedzę o firmie i wykonuję powtarzalną pracę.
Problem wychodził przy zwykłych zadaniach.
Do artykułu potrzebne było aktualne pozycjonowanie, do poprawki na stronie wiedza o tym, co produkt faktycznie potrafi, a do researchu pytanie klienta, na które próbowaliśmy odpowiedzieć.
Za każdym razem liczyły się te same fakty, a ja wciąż podawałem je ręcznie. Zdarzało mi się zapomnieć o jakimś zastrzeżeniu. Kiedy indziej w szkicu pojawiał się przekaz, który należał do wcześniejszej wersji firmy.
Zdolny agent radził sobie z materiałem, który mu dawałem. Tyle że nie dałem mu miejsca, w którym zawsze mógłby ten materiał znaleźć.
Ta różnica była istotna. Mogłem dopracowywać prompt pod każde zadanie albo sprawić, żeby wiedzę, z której firma korzysta na co dzień, łatwiej było odnaleźć i aktualizować. Wybrałem to drugie.
Wspólna baza wiedzy
Wiki firmy założyłem w Markdownie.
Są w niej strategia, wiedza o klientach, zasady marki i dokumentacja produktu. Indeksy folderów podpowiadają agentowi, gdzie szukać. Każda strona ma konkretny temat, a nowe ustalenie trafia obok wiedzy, którą zmienia.
Brzmi to jak segregowanie papierów. I w dużej mierze nim jest.
Z tej samej bazy mogą korzystać research i realizacja zadań. Gdy artykuł potrzebuje faktu o produkcie, agent ma gdzie go sprawdzić. Gdy przy poprawce na stronie wyjdzie na jaw nieaktualny fakt, w wiki jest miejsce na korektę.
Baza wiedzy nie zwalnia z myślenia. Niesprawdzone przekonanie o rynku nie staje się prawdą tylko dlatego, że agent odłożył je do porządnie zorganizowanego folderu. Otwarte hipotezy trzymamy osobno od ustalonej wiedzy.
Następną warstwą były umiejętności (skills).
Spisałem procedury, które powtarzałem: research, przygotowanie artykułów, synchronizację strony i utrzymanie dokumentacji produktu. Każda umiejętność opisuje zadanie i lokalne zasady, które łatwo przeoczyć.
Dzięki temu poprawka może ulepszyć następny przebieg. Trzeba ją jednak przenieść do właściwych wytycznych, bo model nie zapamięta wiedzy o firmie na stałe tylko dlatego, że poprawiłem go na czacie.
Umiejętność może się zestarzeć tak samo jak dokument. Ktoś musi sprawdzać, czy opisana w niej procedura wciąż pasuje do narzędzi i do pracy.
Wspólny format folderu i metadanych zapewnia specyfikacja Agent Skills. Instrukcje w naszych umiejętnościach wciąż jednak piszemy i utrzymujemy sami.
Kod obok firmy
Do przestrzeni roboczej podpiąłem też nasze repozytoria.
Przy pisaniu dało to konkretną korzyść. Artykuł o nowym wydaniu mógł wychodzić od implementacji, a nie od wspomnienia tego, co zamierzaliśmy wypuścić. Dokumentacja techniczna mogła odróżniać kod, który już trafił do repozytorium, od pomysłu z roadmapy.
Połączenie nie zaciera różnicy między tymi źródłami. Dokument projektowy opisuje zamiar, a commit pokazuje implementację. Żaden z nich nie dowodzi, że konkretny proces klienta przećwiczono w praktyce i że zadziałał.
W firmie, która sprzedaje pipeline wytwarzania oprogramowania oparty na AI, trzeba pilnować, żeby te różnice było widać. To część pracy.
Struktura od razu przydała się w procedurze pisania artykułów.
Mogłem podyktować temat i kazać agentowi sprawdzić naszą wiki i źródła zewnętrzne, przygotować szkic i przepuścić go przez przegląd redakcyjny. Grafiki i wersje do mediów społecznościowych to były osobne kroki. Do publikacji dochodziło tylko na wyraźną prośbę.
Fakty nie musiały już wędrować z mojej pamięci do każdego promptu.
Ten sam układ pomógł przy pracy nad stroną. Publiczną podstronę i wewnętrzne wyjaśnienie dało się ze sobą uzgodnić, póki miałem pod ręką jedno i drugie.
Firma nie zaczęła przez to działać beze mnie. Nadal to ja wybierałem, co opublikować, sprawdzałem twierdzenia i decydowałem, która praca zasługuje na uwagę.
Z tego doświadczenia korzystamy też w Usługach. Obok samego pisania oprogramowania liczy się zdefiniowanie procesu i przygotowanie przekazania. Jedno i drugie wymaga konkretnego zakresu w projekcie klienta, a nie obietnicy, że firmę poprowadzi agent.
Pliki pamięci
Czerwcowa wersja tego tekstu opisywała pliki kontekstu, których wtedy używałem. Od tamtej pory konfiguracja się zmieniła.
W październiku nasze wspólne wytyczne mieściły się już w AGENTS.md i w jednym katalogu umiejętności, a tam, gdzie było trzeba, uzupełniał je mały pomost w CLAUDE.md. Osobne kopie instrukcji dla poszczególnych agentów przestały być wzorem, którego należy się trzymać.
Aktualna dokumentacja pamięci w Claude Code odróżnia instrukcje projektu od pamięci automatycznej. Dawne kategoryczne twierdzenie, że to narzędzie nie ma trwałej pamięci, jest więc nie na miejscu.
Nasza firmowa baza wiedzy służy czemuś innemu. Mówi, jakie decyzje zapadły w OwlMeans, jakie dowody stoją za twierdzeniem o produkcie i która procedura pasuje do zadania. Potrzebuję, żeby dało się ją przejrzeć niezależnie od narzędzia.
Późniejszą strukturę repozytoriów dokładniej opisuje tekst o przebudowie wytycznych dla agentów.
Ile to kosztowało
Dla założyciela, który działa w pojedynkę, dwa miesiące to spore zboczenie z kursu.
Dzięki przestrzeni roboczej łatwiej mi wracać do powtarzalnej pracy, ale budując ją, opóźniłem funkcje produktu. Przybył mi też stały obowiązek: instrukcje i wiedza muszą pozostawać aktualne.
Zainwestowałbym tak samo jeszcze raz, bo z tej struktury korzystam w pracy. Gdybym robił to od nowa, zacząłbym skromniej. Rzetelna baza wiedzy dla kilku powtarzalnych zadań przydaje się, zanim jeszcze stanie się systemem dla całej firmy.
Poprawiono 15 października 2026 r. Historia zboczenia z kursu od kwietnia do czerwca pozostała bez zmian; powyższe opisy układu repozytoriów i pamięci odróżniają pierwotną konfigurację od obecnej.