Nie wymyśliłem AppMakera. Złożyłem go z cudzych pomysłów.

W repozytorium AppMakera jest plik REFERENCES.md, o który dbam równie starannie jak o kod. Wymienia każdy projekt, który wpłynął na kształt całości: co z niego wziąłem, co rozważałem, co świadomie odrzuciłem. Prowadzę go, bo uczciwa odpowiedź na pytanie „jak to zaprojektowałeś?" brzmi: w większości wcale. Wybrałem najlepsze elementy i je złożyłem.

Dobre systemy rzadko powstają od zera. Oto mój, z pełną listą źródeł.

Co wziąłem i od kogo

Ze skilli Matta Pococka: forma i styl. Pliki markdown o jednym przeznaczeniu, bez frameworka, bez własnego środowiska uruchomieniowego. Jego zwięzły styl „caveman" stał się obowiązującym przewodnikiem stylu dla każdego skilla AppMakera. Najważniejsza lekcja to jedno zdanie z moich notatek: inspiracja jest lepsza niż zależność — skopiuj plik, zmień go, uczyń własnym. Kilka jego skilli (grill, TDD, to-prd) przetrwało w AppMakerze w rozpoznawalnej formie. Wszedł nawet jego wycofany skill ubiquitous-language: przejąłem format, który on porzucił, ale zmieniłem proces, który zapewne ten skill pogrążył — słownik utrzymuje się teraz sam, jako produkt uboczny innych skilli, zamiast wymagać osobnej pracy.

Z OpenSpec: katalog i filozofia. Osobne katalogi artefaktów dla każdej zmiany, z archiwizacją na końcu, oraz sformułowanie, do którego często wracam: konwencja bez przymusu. Brak sztywnych etapów nie oznacza braku struktury.

Ze Spec Kit: konstytucja. Zasady projektu jako pełnoprawny plik należący do użytkownika, a do tego wzorzec poleceń pogłębiających do wyboru zamiast obowiązkowej procedury.

Z GSD: ostrożność. Kontrola planu przed wykonaniem, sprawdzanie wiarygodności zależności (czy ten pakiet istnieje naprawdę, czy tylko podszywa się pod inny), pilnowanie budżetu kontekstu, wydobywanie niejasności na powierzchnię, zanim po cichu staną się założeniami.

Z gstack: dowody. Zmiany w interfejsie idą w parze ze zrzutami ekranu z przeglądarki, kontrola jakości zna zakres zmian, diagnoza zaczyna się od przyczyny. „U mnie wygląda dobrze" nie jest weryfikacją.

Z ECC: dwa elementy z 249 skilli. Rada decyzyjna czterech głosów (osobne, świeżo uruchamiane subagenty prowadzą spór w rolach Sceptyka, Pragmatyka i Krytyka, bez dostępu do rozmowy, więc nie ulegają temu, w co już wierzę) oraz bramka bezpieczeństwa. Pozostałych 247 świadomie nie przejąłem. Tak szeroka biblioteka możliwości to przeciwieństwo dyscypliny, którą buduję, a jej dołączenie oznaczałoby przeładowany kontekst i konflikty nazw.

Spoza świata repozytoriów: metoda „tracer bullets" z Pragmatycznego programisty (każda część przechodzi przez wszystkie warstwy i można ją osobno pokazać), wspólny język projektu z DDD Erica Evansa oraz pomysł Karpathy'ego, by traktować pamięć jak kompilację: surowe notatki na wejściu, uporządkowana wiki na wyjściu, z testami wykrywającymi zerwane odnośniki.

Porównanie z innymi

Sprawdziłem liczby w trakcie pisania (czerwiec 2026): każde ze źródeł żyje i jest ogromne. To zestawienie najlepiej pokazuje, czym AppMaker jest, a czym nie jest:

| Narzędzie | ★ | Co to jest | Co wziąłem | Czym AppMaker się różni | |---|---|---|---|---| | Skille Pococka | 119k | pojedyncze skille w markdownie | forma, styl caveman, wzorce grill/TDD/PRD | dodaje cykl życia obejmujący wiele skilli, nie tylko pojedyncze | | Spec Kit | 109k | pięcioetapowy proces GitHuba oparty na specyfikacjach | konstytucja, pogłębianie do wyboru | bez obowiązkowej procedury — bramki to skrypty, nie etapy | | gstack | 108k | 23 narzędzia o mocnych założeniach (zestaw Garry'ego Tana) | dowody z przeglądarki, kontrola jakości znająca zakres zmian | dowody trafiają do trwałych zapisów każdej części | | GSD | 64k | meta-prompty i inżynieria kontekstu | kontrola planu, wiarygodność pakietów, budżet kontekstu | kontrole stają się bramkami zaliczone/niezaliczone, powiązanymi z artefaktami | | Graphify | 60k | graf wiedzy o kodzie | opcjonalna warstwa kontekstu tylko do odczytu | używany, nigdy nie dołączany — małe, wersjonowane pakiety | | OpenSpec | 53k | katalogi zmian oparte na specyfikacjach | katalogi funkcji, archiwizacja | dokłada powiązania kryterium→test | | ECC | nowy | system operatora z 249 skillami | rada i bramka bezpieczeństwa, nic więcej | przeciwny zakład: kręgosłup, nie biblioteka | | AppMaker | 0 | warstwa specyfikacji i nadzoru | wszystko powyższe | sama synteza |

Tak, zero gwiazdek — publikuję ten tekst, zanim zacznę promować repozytorium. Każde narzędzie, z którego czerpałem, ma ich dziesiątki tysięcy. Ta różnica mnie nie krępuje; na niej opiera się cała teza tego wpisu. Poszczególne części sprawdziły się w dużej skali. Nowa jest synteza.

Czego nauczyły mnie porażki

REFERENCES.md ma sekcję, której większość takich list nie zawiera: odniesienia negatywne.

Pierwsze to mój projekt AppsMaker-2025. Implementował pomysłowy algorytm głosowania z pracy naukowej, w listopadzie 2025 osiągnął 75% ukończenia i od tamtej pory stoi w miejscu. Zbyt szeroko zakrojony, nigdy niezintegrowany, ambitny, ale pozbawiony minimalnej pierwszej wersji. Niczego nie dostarczył.

Drugie to pierwsza wersja samego AppMakera, przechowywana dziś w katalogu history/: 5 zapisów decyzji architektonicznych, 18 reguł konstytucyjnych, 3 schematy JSON, łańcuchy propagacji. Około 80% tych artefaktów służyło wewnętrznej spójności systemu, a nie żadnemu użytkownikowi. Nie zatrzymał tego żaden wskaźnik, tylko ludzka intuicja w środku sesji: musimy przerwać i ustalić, czemu to w ogóle służy.

Obie porażki nauczyły mnie tego samego, a ta lekcja stała się architekturą AppMakera: każda warstwa do wyboru, najpierw wersja minimalna, a decyzję o zatrzymaniu podejmuje człowiek, pytając: „czy to dziś komuś konkretnie pomaga?". Pięciowarstwowy układ w dużej mierze wyrósł z tych dwóch doświadczeń.

Dlaczego pokazuję źródła

Po części z uczciwości: ci ludzie wykonali trudną pracę koncepcyjną i ich repozytoria zasługują na uwagę. Ale przede wszystkim dlatego, że umiejętnością, którą tu pokazuję, jest właśnie wybór. Zgromadzić 249 możliwości potrafi każdy. Wybrać jeden wzorzec rady, który warto zachować; dostrzec, że porzucony skill miał format wart uratowania; potraktować własny wstrzymany projekt jako materiał projektowy — to jest właściwa praca.

Jeśli budujesz własny system oparty na agentach AI, przejmij najpierw ten proces, a dopiero potem którąkolwiek z części. Prowadź plik referencji, zapisuj, co odrzucasz i dlaczego, i dawaj porażkom miejsce równe sukcesom. Za pół roku, przy kolejnej decyzji projektowej, będziesz wdzięczny, że ten zapis istnieje.