AppFactory: Budowanie MVP na autopilocie (i dlaczego pętla Ralpha to przyszłość)

#AI#Automatyzacja#MVP#AppFactory

Każdy z nas ma tę listę. Listę pomysłów na aplikacje, które „kiedyś zrobię”. Problem w tym, że między „mam pomysł” a „produkcja działa” rozciąga się dolina nudy: konfiguracja środowiska, stawianie bazy danych, boilerplate, walka z deploymentem.

A co, gdyby tę dolinę mógł przeskoczyć za nas ktoś inny? Nie człowiek, a system.

Tak narodził się projekt AppFactory.

Motywacja: MVP w godzinę, nie w tydzień

Moim celem od zawsze była maksymalna redukcja tarcia. Chciałem systemu, któremu wrzucam plik PRD.md (Product Requirements Document), a on — po serii cichych procesów w tle — oddaje mi gotowy link do działającej aplikacji na moim VPS.

Nie chodziło o kolejny generator kodu, który zostawia Cię z tysiącem linii, których nie rozumiesz. Chodziło o autonomicznego pracownika, który rozumie architekturę, potrafi pisać testy i samodzielnie naprawia błędy.

Inspiracja: Pętla Ralpha (Ralph Loop)

Budując fundamenty AppFactory, wzorowałem się na koncepcji, którą na polskim rynku spopularyzował Adam Gospodarczyk (overment) — tzw. Pętli Ralpha.

Nazwa brzmi niepozornie (ukłon w stronę Ralpha Wigguma z The Simpsons), ale kryje w sobie genialną prostotę. Kluczem do sukcesu agentów AI nie jest „największy możliwy kontekst”, ale czysty kontekst.

Pętla Ralpha polega na:

  1. Dzieleniu pracy na atomowe zadania.
  2. Uruchamianiu agenta (np. Claude'a czy Gemini) dla każdego zadania z osobnym, świeżym oknem rozmowy.
  3. Przechowywaniu wiedzy nie w „głowie” AI, ale w plikach (PRD, SPECS, Git).

Dzięki temu system jest niezwykle odporny. Jeśli agent zbłądzi w jednej iteracji, kolejna startuje od zera, bazując na twardych danych zapisanych w plikach. To nie jest sprint — to marsz upartego Ralpha, który krok po kroku, commit po commicie, dąży do celu.

Architektura Fabryki

W AppFactory tę koncepcję ubrałem w konkretną infrastrukturę:

  • Scheduler: Serce systemu. Co 5 minut sprawdza bazę factory.db w poszukiwaniu nowych zadań.
  • Agent Roles: Mamy architektów (projektują system), deweloperów (piszą kod) i audytorów (sprawdzają bezpieczeństwo).
  • Dashboard: Interfejs, gdzie widzę tablicę Kanban z moimi projektami. Widok TRIAGE → READY → IN_PROGRESS → DONE daje mi poczucie, że fabryka naprawdę pracuje, gdy ja piję kawę.

Proces wygląda tak:

PRD.md (Pomysł) → AI generuje SPECS.md (Technologia) → Scheduler tnie na TASKI → Agenci piszą kod → Auto-deploy

To dopiero początek

Dzisiaj AppFactory potrafi już postawić kompletną aplikację Next.js z bazą danych, i18n i pełnym CI/CD na moim VPS. Ale to nie jest produkt końcowy. To początek mojej drogi w stronę pełnej symbiozy z agentami AI.

Uczę się, jak być lepszym „operatorem” fabryki. Jak pisać lepsze instrukcje (prompt engineering na poziomie architektury), jak budować bezpieczniki (guardrails) i jak sprawić, by kod generowany przez AI był nie tylko działający, ale i czytelny dla człowieka.

AppFactory to mój manifest: programowanie w 2026 roku to już nie tylko pisanie linii kodu. To projektowanie procesów, które ten kod wytwarzają.

Fabryka ruszyła. Ciekawe, co zbudujemy jutro.