Fabryka kodu w homelabie: Jak spiąłem Paperclipa, OmniRouter, flotę modeli i GitLaba w jeden potok

Większość dyskusji o „programowaniu z AI” kończy się na zachwytach nad promptem wklejanym w przeglądarkę albo nad kolejnym edytorem, który po cichu wysyła Twoją bazę kodu do chmury i blokuje się po przekroczeniu limitu zapytań. Przy jednym pliku to działa. Przy ekosystemie kilkunastu mikroserwisów, aplikacji webowych i infrastrukturze homelaba — leżysz i kwiczysz.

Zamiast bawić się w półśrodki, zbudowałem w serwerowni w pełni zautomatyzowaną fabrykę kodu sterowaną agentami.

Żaden model nie ma bezpośredniego dostępu do gałęzi main. Żadne zapytanie nie leci bezpośrednio do drogich API bez kontroli kosztów. Całość spina autorski potok: mój prompt → Paperclip → autorouter OmniRouter (chmura + lokalne LM Studio) → rygorystyczna analiza i testy w worktree → Merge Request do prywatnego GitLaba z CI/CD.

Oto jak ta machina wygląda pod maską.

1. Wielki obraz: Pełna topologia potoku

Cały proces od wpisania zadania do gotowego kodu z testami odbywa się wewnątrz prywatnej sieci i na dedykowanych węzłach wirtualizacji:

2. Serce orkiestracji: Paperclip

Wewnątrz domowej infrastruktury działa Paperclip — centralny orkiestrator i dyspozytor zadań dla modeli językowych.

Gdy mam do zrobienia feature lub refaktor, nie wklejam kodu do okienka. Wrzucam prompt i zadanie do Paperclipa:

Zadania w kwarantannie: Paperclip tworzy izolowaną przestrzeń roboczą dla danego ticketu.
Pamięć trwała (Compounding Wiki): Zamiast naiwnego RAG-a, który co zapytanie od nowa przeszukuje losowe fragmenty tekstu, Paperclip utrzymuje ustrukturyzowaną bazę wiedzy o projektach. Jeśli agent podczas rozwiązywania problemu poznał specyfikę bazy CMS-a, biblioteki animacji czy konfiguracji reverse-proxy, zapisuje to w schemacie wiedzy.
Zarządzanie stanem: Agent wie, co zostało zrobione w poprzednim kroku, jakie pliki zostały zmodyfikowane i dlaczego dany test wywalił asercję.

3. Giełda modeli: OmniRouter i lokalne LM Studio

Paperclip nie rozmawia z zewnętrznymi API bezpośrednio. Wszystkie żądania wykonawcze trafiają na ujednolicony endpoint OmniRoutera.

W OmniRouterze działa silnik autoroutera, który analizuje złożoność prompta, bieżące obciążenie, limity dostawców i stan portfela. Zależnie od warunków, ruch przekierowywany jest dynamicznie:

Top-Tier / Architektura (gdy potrzebne jest potężne rozumowanie):
- Claude Code
- Antigravity
- Codex / Mistral Large
Gatewaye i agregatory (gdy liczy się elastyczność i load balancing):
- OpenRouter & KiloGateway — routing do wyspecjalizowanych modeli bez konieczności utrzymywania kilkunastu osobnych subskrypcji.
- Trae & Gemini CLI — do szybkich, równoległych weryfikacji i zadań wymagających gigantycznego okna kontekstowego.
Self-Hosted Local: LM Studio:
- Nasz lokalny wół roboczy postawiony bezpośrednio w klastrze homelaba.
- Przetwarza zadania, które nie powinny opuszczać sieci LAN (analiza wewnętrznych logów, konfiguracje środowiskowe, masowe sprawdzanie składni, lintering).
- Koszt: 0 zł. Narzut na zewnętrzne łącze: 0 ms.

Automatyczny Failover: Koniec z błędami 429 i 529

Jeśli zewnętrzny dostawca rzuci przeciążeniem serwera (529 Overloaded) albo wyczerpie się sekundowy limit zapytań (RPM/TPM), autorouter OmniRoutera w ułamku sekundy przepina strumień na model zapasowy o zbliżonej charakterystyce (np. z jednego gatewaya na Mistrala lub Gemini). Agent w Paperclipie nie przerywa zadania po 40 minutach pracy — po prostu kontynuuje pisanie kodu.

4. Wykonanie i audyt: Żelazne reguły w worktree

Gdy model zwróci plan zmian i instrukcje, zaczyna się właściwa inżynieria w izolowanym Git Worktree:

Rygor AGENTS.md: Agent ma obowiązek przeczytać plik kontraktu projektu. Wie, jakich reguł typowania przestrzegamy, że nie commitujemy bezpośrednio do gałęzi głównej, a krytyczne pętle animacji nie mogą powodować niekontrolowanego zrzucania pamięci przez Garbage Collector.
Kompilacja i testy: Zanim kod gdziekolwiek wyjdzie, odpala się lokalny potok weryfikacyjny:
bash
npm run lint && npm run typecheck && npm test
Jeśli cokolwiek zgłasza błąd — model ma obowiązek poprawić swój kod w kolejnym przebiegu.
Czyszczenie historii commitów: Narzędzia AI uwielbiają dopisywać do commitów niepotrzebne stopki i trailery. Nasz proces bezlitośnie czyści te metadane z gałęzi, zostawiając schludną, profesjonalną historię Gita.

5. Finał: Merge Request do własnego GitLaba z CI/CD

To jest najważniejszy punkt całej filozofii: żaden agent nie ma uprawnień do samodzielnego wdrożenia kodu na produkcję.

Po pomyślnym przejściu wszystkich testów w worktree, wygenerowany branch jest pushowany na własny GitLab z CI/CD.

Tam automatycznie otwierany jest Merge Request (MR) zawierający:

Zwięzły opis wprowadzonych zmian i motywację architektoniczną.
Listę zmodyfikowanych modułów wraz z wynikami testów.
Identyfikator powiązanego zadania z Paperclipa.

W tym momencie odpala się GitLab CI — buduje kontener produkcyjny, testuje migracje bazy danych i weryfikuje integralność całej aplikacji.

Ja dostaję powiadomienie, otwieram GitLaba, robię szybki code review czystego diffa i jednym kliknięciem zatwierdzam merge. Webhook systemu wdrożeniowego odbiera sygnał i w kilkadziesiąt sekund nowa wersja żyje na serwerze.

Dlaczego właśnie tak?

Większość ludzi traktuje AI w programowaniu jak gadającego bota. Dla mnie to zoptymalizowany podwykonawca wpięty w szyny infrastruktury:

Paperclip trzyma kontekst i pilnuje porządku w zadaniach.
OmniRouter tnie koszty, eliminuje przestoje API i pozwala płynnie miksować chmurę z lokalnym LM Studio.
Własny GitLab z CI/CD gwarantuje, że nic nie wybuchnie na produkcji bez mojego ostatecznego zatwierdzenia.

To nie jest „vibecoding”. To przewidywalna, odporna na awarie inżynieria.