AppMaker

Agenci programujący są znakomici w pisaniu kodu i bardzo słabi w pamiętaniu, dlaczego piszą go tak, a nie inaczej. AppMaker to moja odpowiedź: otwarty plugin, który daje agentowi to, czego mu brakuje — proces inżynierski, w którym każda decyzja zostawia ślad.

Zobacz kod na GitHubie →

Problem

Programowanie z pomocą AI cierpi na dryf intencji. Reguły biznesowe ustalone na początku rozmowy później znikają z pola widzenia. Przypadki brzegowe, wspomniane raz, żyją tylko w zapisie czatu. Kryteria akceptacji nie istnieją, bo nikt ich nie spisał — więc model z pełnym przekonaniem improwizuje tam, gdzie zostały luki.

Efekt: kod, który działa podczas prezentacji, a zaskakuje na produkcji, i żadnego śladu, co zdecydowano, kto i dlaczego. Każdy, kto poważnie używa agentów AI, zna to zjawisko. Prawie nikt nie ma na nie narzędzi.

Co zbudowałem

AppMaker to warstwa specyfikacji i nadzoru nad środowiskiem Claude Code: 24 skille o jednym przeznaczeniu, prowadzące pełny cykl wytwarzania — od wnikliwego wywiadu o wymaganiach po zarchiwizowaną retrospektywę.

Założenie projektowe, dzięki któremu to działa: nie konkurować ze środowiskiem, tylko je nadzorować. Kiedy Claude Code dostaje lepszy mechanizm, AppMaker z niego korzysta, zamiast budować własny. Trwałą wartością jest wszystko to, czego środowisko samo nie robi:

• Artefakty zamiast historii czatu. Każda funkcja żyje w trwałym katalogu: wywiad, dokument wymagań, dekompozycja, zapisy realizacji każdej części, retrospektywa. Źródło prawdy jest na dysku i w gicie, a nie w zapisie rozmowy, który znika razem z sesją.
• Intencja identyfikowalna od początku do końca. Każde kryterium z dokumentu wymagań dostaje stały identyfikator, powiązany przez dekompozycję, kryteria akceptacji i testy aż z kodem produkcyjnym. Dryf przestaje być czymś, o czym ktoś zapomniał, a staje się zerwanym powiązaniem, które wykryje skrypt.
• Determinizm przed osądem. Kontrole przebiegają warstwami: najpierw skrypty, potem udokumentowane kryteria oceniane przez człowieka, na końcu ocena modelu. Bramka kontrolna zwraca wynik zaliczone/niezaliczone/uwaga z dowodami na poziomie plików — nigdy na wyczucie.
• Decyzje, które muszą pozostać ludzkie, pozostają ludzkie. Sprawy tożsamości, pieniędzy, marki i kroki nieodwracalne są oznaczone jako wymagające człowieka; system kieruje je do niego, zamiast zgadywać. Jest też rada decyzyjna czterech głosów: trzy świeżo uruchamiane subagenty spierają się w rolach Sceptyka, Pragmatyka i Krytyka, bez dostępu do rozmowy, więc nie ulegają temu, w co główny agent już wierzy.
• Pamięć, która się porządkuje. Retrospektywy zbierają wnioski do projektowej wiki, którą każdy kolejny proces czyta przed planowaniem — agent przy piątej funkcji wie o projekcie wymiernie więcej niż przy pierwszej.

Współpracuje z innymi narzędziami

AppMaker jest celowo cienką warstwą z konkretnymi integracjami, każda do wyboru:

• Środowisko Claude Code — skille, hooki, subagenty, system pluginów; AppMaker dodaje cykl życia, nie infrastrukturę
• Graphify (zewnętrzny graf wiedzy) — zamiast przeszukiwać kod na ślepo, agent odpytuje graf zależności modułów i dokumentacji; AppMaker korzysta z niego wyłącznie w trybie odczytu i zapisuje niewielkie, wersjonowane pakiety kontekstu
• Prawdziwa przeglądarka (środowisko gstack) — zmiany w interfejsie idą w parze ze zrzutami ekranu, kontrolą widoków na różnych szerokościach i testami trybów wyświetlania, a nie z zapewnieniem „u mnie wygląda dobrze"
• GitHub CLI — lista zadań może istnieć jako issues, a etapy badawcze mogą czerpać z prawdziwych repozytoriów
• Ref / dokumentacja przez MCP — decyzje architektoniczne wymagają zestawienia opcji opartego na aktualnej oficjalnej dokumentacji, a nie na danych treningowych modelu
• Skanery bezpieczeństwa — osobna bramka uruchamia dostępne narzędzia (npm audit, gitleaks, semgrep), zanim cokolwiek trafi na produkcję; najpierw deterministyczne fakty, potem ocena modelu
• Lokalny panel Studio — niewielki interfejs nad stanem projektu: postęp funkcji, dowody, etapy wykonywane równolegle

Dowody

• Prowadzi prawdziwy system produkcyjny. Cassie, platforma do prowadzenia spraw klinicznych, jest w całości rozwijana z AppMakerem: 6 funkcji przeszło pełny cykl (wywiad → dokument wymagań → części → testy → przegląd → archiwum), a 22 części trafiły na produkcję w pierwszych tygodniach. Pierwsza funkcja (ocena ryzyka biopsychospołecznego) przeszła od pomysłu do produkcji w jednej sesji trwającej około 5,5 godziny: 7 rozpisanych części, 21 testów jednostkowych w uczciwym cyklu „najpierw test, potem kod", 37 z 37 kryteriów akceptacji, 4 wdrożenia bibliotek — z użyciem każdego dostępnego wtedy polecenia pluginu.
• Skutki uboczne, które można skontrolować. Słownik projektu sam zapełnił się terminami z odnośnikami do plików i linii; komentarze w kodzie produkcyjnym wskazują artefakty wymagań, które realizują — odpowiedź na pytanie „dlaczego" przeżywa koniec sesji.
• Testowany jak produkt. 29 zestawów testów dymnych (około 2000 linii skryptów) obejmuje hooki, bramki, materializację, kontrole identyfikowalności i wykrywanie rozjazdów w dokumentacji.
• Poddany audytowi, z opublikowanymi wnioskami. Repozytorium zawiera raporty zewnętrznych audytów — analizę różnic między metodą a pluginem oraz przegląd wdrożenia — a wnioski są prowadzone jawnie jako numerowane decyzje projektowe, zamiast ginąć w historii zmian. Zapis sesji wymienia nawet to, co jeszcze niesprawdzone. Uważam to za bardziej przekonujące niż jakikolwiek benchmark.
• Sprawdzony na sobie trzykrotnie. AppMaker rozwija sam siebie: jego własne katalogi funkcji, listy zadań i retrospektywy są częścią repozytorium. Cassie działa na nim na produkcji. A ta strona została z jego pomocą zaplanowana, rozpisana w dokumencie wymagań, podzielona na części i napisana od testów; artefakty są częścią historii repozytorium strony.
• Otwarty kod, licencja MIT, całość samowystarczalna. Jedno polecenie init tworzy całe drzewo nadzoru — konstytucję, słownik, wiki pamięci, szablony, hooki — w dowolnym projekcie, nowym lub istniejącym.

github.com/paweldobrzynski/AppMaker →