Dlaczego agent AI zapomina o Twoim projekcie (i jak to naprawić)

Znamy to wszyscy. Pracujesz z asystentem AI nad projektem, który ciągnie się kilka dni. Pierwszy dzień idzie gładko – kod powstaje, testy działają, dokumentacja jest na bieżąco. Następnego dnia otwierasz nową sesję i… agent nie ma pojęcia, co się działo wcześniej. Znowu tłumaczysz strukturę projektu od zera.

Problem nie leży w limicie kontekstu. Leży w tym, gdzie trzymamy wiedzę o projekcie.

Czat jako pamięć projektu – zły wybór

Rozmowy z AI świetnie sprawdzają się do szybkiej współpracy. Gorzej, gdy mają służyć jako repozytorium decyzji i kontekstu.

Dlatego właśnie pojawiają się problemy:

• Trudno wrócić do wcześniejszych ustaleń – trzeba przekopywać tysiące tokenów.
• Nie ma jednego źródła prawdy – wersje specyfikacji mieszają się między sesjami.
• Nowy agent zaczyna od zera, niezależnie od tego, ile już zrobiono.
• Sprzeczności narastają – jeden agent wybiera strategię testów, drugi ją zmienia, trzeci oznacza coś jako „gotowe”, choć nie jest.

Nie chodzi o to, czy model potrafi napisać kod. Potrafi. Problem w tym, czy rozumie, co i dlaczego budujemy.

Proste rozwiązanie: Markdown w repozytorium

Zamiast trzymać wiedzę w czacie, zapiszmy ją tak samo jak kod – w plikach Markdown w repozytorium.

Nie chodzi o wiki czy zewnętrzne narzędzie. Wystarczy kilka lekkich plików z metadanymi.

Przykład:

# Project Architecture Decision

Lifecycle: active
Role: spec
Project: payment-service
Updated: 2024-01-15

Related:
- implements: charter-payment-api
- pairs-with: implementation-log-payment-core

Struktura jest prosta: tytuł, cykl życia (active/completed/archived), rola dokumentu (spec, log, decision), powiązania z innymi rekordami i treść.

Nic więcej nie potrzeba.

CLI zamiast kopania w czacie

Największa zmiana przychodzi, gdy agent nie musi „czytać czatu”, tylko może odpytąć system.

Zamiast analizować historię rozmowy, agent uruchamia polecenie:

docs list --project=payment-service --role=spec

Dostaje aktualny obraz: co jest w toku, co zablokowane, co wymaga decyzji. Może też tworzyć nowe rekordy, archiwizować stare czy aktualizować timestampy – wszystko przez komendy, nie przez ręczną edycję plików.

Dzięki temu relacje i metadane pozostają spójne, nawet jeśli agent nie jest idealny.

Świeży agent, znany stan

Dzięki temu schematowi nowa sesja nie oznacza utraty kontekstu. Agent po prostu:

1. Uruchamia docs list, żeby zobaczyć co jest aktywne.
2. Czyta log implementacji z poprzedniego dnia.
3. Sprawdza aktualną specyfikację.

Stara rozmowa? Można ją zamknąć. Stan projektu żyje w repozytorium.

Dla kogo to ma sens

Ten sposób przydaje się, gdy:

• Budujesz z AI w sesjach rozłożonych na wiele dni.
• Korzystasz z agentów, które muszą wracać do pracy bez pełnego kontekstu.
• Chcesz, żeby pipeline CI sprawdzał spójność projektu.
• Pracujesz w zespole i potrzebujecie wspólnego obrazu decyzji.
• Szybko iterujesz i łatwo zgubić aktualny stan specyfikacji.

To nie zastępuje Gita ani testów. To warstwa, która sprawia, że praca z AI staje się spójna w czasie.

Najlepsze w tym jest to, jak nudne jest to rozwiązanie

Nie budujemy nowego systemu bazodanowego. Korzystamy z tego, co już znamy – Markdowna, Gita i prostego CLI. I właśnie dlatego to działa.

Gdy agent popełni błąd, walidacja go złapie. Gdy coś przeoczy – lista pokaże. Gdy pojawią się sprzeczności – indeks je wykryje.

To nie jest spektakularne. Ale to właśnie odróżnia sytuację „agent trochę pomógł” od „agent zrozumiał projekt i dostarczył”.