Jak realnie budujemy z asystentami AI

To opis naszej własnej metody pracy — R&D nad tym, jak budujemy, nie zlecenie klienta. Samo „pracujemy z AI” nie mówi nic o jakości. Znaczenie ma to, gdzie w potoku stoi asystent, kto sprawdza jego wynik i co się stanie, gdy sprawdzenie wypadnie źle.

Co to jest

Udokumentowany potok pięciu etapów, w którym każdy etap ma jedną twardą bramkę wejścia do następnego.

• Destylacja — materiały klienta zamieniamy w inwentarz decyzyjny: co zachować, co przepisać, co scalić, co usunąć.
• Brief — kierunek strategiczny i zakres. Bramką jest akceptacja klienta, zapisana z datą.
• Plan — architektura, model danych, kamienie milowe z estymatami i przypisaniem wykonawcy.
• Wdrożenie — kod, testy i niezależny przegląd, kamień milowy po kamieniu milowym.
• Weryfikacja — wydajność, dostępność, SEO techniczne, QA. Stąd jedna pętla zwrotna do wdrożenia.

Kolejność jest liniowa. Naprawy wracają do wdrożenia, ale nowy zakres wraca do planu, nie do briefu — brief zmieniamy tylko wtedy, gdy zmienia się cel biznesowy.

Jaki problem rozwiązuje

• „Wyszło szybko, ale nie wiadomo, co dokładnie”. Asystent generuje kod w tempie, którego nikt nie nadąża przejrzeć bez procedury. Bramki wymuszają przegląd, zamiast liczyć na dobrą wolę.
• Brak powtarzalności. Ta sama praca w dwóch sesjach potrafi dać dwa różne poziomy jakości. Lista warunków ukończenia utrzymuje wspólny poziom minimalny i ujawnia braki przed scaleniem.
• Kod bez decyzji. Po trzech miesiącach nikt nie pamięta, dlaczego wybrano to rozwiązanie. Dziennik decyzji jest częścią potoku, nie dodatkiem.
• Budowa przed zrozumieniem. Najdroższy błąd to poprawnie zbudowana rzecz, której nie trzeba było budować. Dlatego pierwsze dwa etapy nie zawierają ani linii kodu.

Jak to zbudowaliśmy

Podział ról jest jawny i asymetryczny. Jeden agent koordynuje pracę, dzieli ją na zakresy i pilnuje wspólnego kontraktu. Pozostali biorą rozłączne moduły albo dostają ten sam kontekst do postawienia niezależnej hipotezy, gdy diagnoza utyka. Role możemy przypisać Claude Code, Codex lub innym narzędziom zależnie od zadania; żaden wynik nie omija przeglądu osoby odpowiedzialnej za projekt.

Niezależny przegląd ważnych zmian: autor sprawdza własny wynik, ale nie jest jedyną bramką. Zmianę ocenia też inny agent albo osoba odpowiedzialna za projekt, a decyzja o scaleniu pozostaje po stronie człowieka.

Reguła granic plików: równoległe zadania domyślnie dostają rozłączne zbiory plików. Jeśli kilka obszarów schodzi się w jednym pliku integracyjnym, wyznaczamy jednego właściciela zmiany, a pozostali przekazują mu znaleziska do scalenia. Kontrakt między modułami — typy, sygnatury, kształt API — ustalamy przed rozjazdem prac. Bez tego konflikt scalania może kosztować więcej niż zysk z równoległości.

Bramka jakości jest maszynowa, nie deklaratywna. W CI uruchamiamy lint, sprawdzanie typów, walidację treści i build produkcyjny. Wydajność oraz dostępność mierzymy osobno na działającym środowisku według progów zapisanych w briefie; wyniku nie uśredniamy między szablonami, bo słaba strona nie znika od dobrego wyniku innej.

Stan projektu mieszka w trwałych artefaktach, nie w pamięci sesji: plan techniczny i dziennik decyzji w repozytorium, kod oraz treść bazowa w gicie, a treści redakcyjne tworzone w panelu — w bazie danych. Dzięki temu kolejna sesja startuje od zapisanego stanu, a zmiany w repozytorium mają historię i czytelny podgląd różnic.

Nazwany kompromis: ten potok przenosi wysiłek na początek. Discovery, brief i plan zajmują czas, zanim powstanie pierwszy ekran, a zmiany w treści bazowej wymagają przeglądu tak jak kod. Panel redakcyjny upraszcza publikację nowych wpisów, ale nie zastępuje wersjonowania decyzji i szablonów. Przy jednorazowej wizytówce taki rygor może się nie zwrócić; przy rozwijanym systemie ogranicza koszt późniejszych nieporozumień.

Czego to dowodzi

Że planowanie przed budową jest u nas procedurą, nie hasłem — z artefaktami, które można otworzyć i sprawdzić. To dowód dla usługi projektowanie i planowanie, czyli etapu, na którym rozstrzygamy, co i po co budujemy, zanim policzymy pełne wdrożenie.

Ten sam potok stoi za aplikacjami budowanymi od zera. Warstwę multiagentową opisujemy w workflow badawczych AI, a wersję dla klienta w procesie.