Sześć miesięcy z Claude Code — jak buduję SaaS bez zespołu (i co naprawdę poszło nie tak)

Pół roku z Claude Code — kontekst

Sześć miesięcy temu zarejestrowałem domenę pod nowy projekt SaaS. Nie miałem zespołu, nie miałem inwestora, nie miałem szczególnie dużo czasu. Miałem za to subskrypcję Claude i CLI o nazwie Claude Code, którą Anthropic kilka miesięcy wcześniej oddało developerom do testów. Postawiłem prosty eksperyment: zbuduję panel hostingowy SaaS — taki cPanel skrzyżowany z Wixem — sam, ale tak, jakbym miał zespół. Zespołem był Claude.

Ten artykuł nie jest reklamą Anthropic ani peanem na cześć AI. Jest szczerą relacją klienta. Opowiada, co realnie udało się zbudować, jak Claude Code zmienił sposób w jaki piszę kod, czego z jego możliwości używam, czego nie używam jeszcze (a powinienem), gdzie mi naprawdę pomógł, a gdzie tak samo realnie zawiódł. Jeśli zastanawiasz się czy warto wpiąć asystenta AI w swój dzienny workflow programistyczny — przeczytaj do końca. Jeśli już używasz i myślisz, że wyciskasz z niego maksimum — jest spora szansa, że nie.

Wszystko co opisuję wydarzyło się naprawdę, w jednym konkretnym projekcie. Nie zmieniam liczb, nie podkolorowuję efektów, nie ukrywam wpadek. Nie wymieniam nazwy projektu i pomijam szczegóły, które mogłyby go jednoznacznie zidentyfikować — bo to nie reklama produktu, tylko relacja z procesu.

Co właściwie zbudowaliśmy

Żeby reszta artykułu miała sens, muszę krótko opisać skalę. Projekt to wielomodułowy panel hostingowy SaaS na własnej infrastrukturze (jeden VPS, ok. 16 GB RAM, 8 vCPU). Stack: Next.js 15 z App Routerem na froncie, Fastify + Prisma + PostgreSQL na backendzie, Redis do cache i kolejek BullMQ, Docker do izolacji aplikacji marketplace, PM2 jako proces manager. Po pół roku stan jest taki:

Panel z rejestracją, logowaniem, 2FA, sesjami, billingiem (integracja z polską bramką płatności + automatyczne faktury)
Wbudowany kreator stron WWW (CMS) z 12 szablonami, generatorem wstępnych treści przez AI, biblioteką ponad 4000 zdjęć stockowych, animacjami Lottie
Pluginy w CMS: blog z edytorem WYSIWYG (Tiptap), sklep, system rezerwacji z iCal i pracownikami, generator wycen, generator dokumentów prawnych
Hosting e-mail z Postfixem, Dovecotem, webmailem i własną aplikacją mobilną (Android, APK, IMAP)
Zarządzanie domenami z DNS, DNSSEC, automatycznymi certyfikatami Let's Encrypt (włącznie z wildcardem)
Marketplace aplikacji (WordPress AI Wizard, kilka instalacji typu Nextcloud, izolowane przez Docker)
Dashboard administratora platformy z monitoringiem, healthchecki, panel banów IP, integracją fail2ban
Pełna lokalizacja na 6 języków (polski, angielski, niemiecki, szwedzki, litewski, bułgarski) z automatyzacją tłumaczeń
Sześć rund audytu bezpieczeństwa, ponad sto naprawionych issues, jeden zewnętrzny pentest black-box
Ok. 145 plików TypeScript, 52 strony Next, monorepo z trzema głównymi paczkami

Bez Claude Code zająłbym się jednym z tych obszarów na rok. Z Claude Code mam pełny stack po pół roku — niedoskonały, miejscami nadgryziony przez własne błędy, ale działający w produkcji i obsługujący realnych użytkowników.

Pamięć między sesjami — fundament

Pierwsza i najważniejsza rzecz, której zacząłem używać świadomie: system pamięci. Claude Code zapisuje pliki Markdown w katalogu ~/.claude/projects/..., a indeks MEMORY.md ładuje się do każdej kolejnej rozmowy. To wygląda banalnie — kilka plików tekstowych — ale efekt jest fundamentalny: nie zaczynamy każdej sesji od zera.

U mnie pamięć urosła do kilkudziesięciu plików w czterech kategoriach:

user — kim jestem, jak myślę, czego oczekuję od współpracy. Np. "myśli jak architekt, zadaje pytania systemowe nie o kod", "działa autonomicznie, nie ma czasu na zatwierdzanie".
feedback — wszystkie reguły, których go nauczyłem przez korekty. "Buduj nowe rzeczy, nie refaktoryzuj w kółko". "Nigdy nie używaj !important, zwiększ specyficzność selektora". "Po zmianie kodu zawsze pnpm build przed pm2 restart bo serwer czyta z dist/ nie z src/". Każda reguła ma swój powód — z jakiego incydentu wynikła.
project — stan projektu, decyzje architektoniczne, podsumowania ważniejszych sesji. Tu jest historia: co zrobiliśmy w którą sobotę, dlaczego, jakie pułapki napotkaliśmy.
reference — gdzie szukać czego (które logi, które dashboardy, które dokumenty).

To nie jest dokumentacja techniczna projektu — od tego mam DOKUMENTACJA.md w repo. To jest dokumentacja naszej współpracy. Reguła którą sobie wymyśliłem: jeśli musiałem dwa razy poprawić Claude'a w tej samej sprawie, trzeci raz nie poprawiam — zapisujemy to jako feedback memory. Po sześciu miesiącach mam ok. 50 takich plików. Efekt: nowa sesja od razu wie, że nie wolno robić git add -A, że buduje się z /srv/panel/ a nie z subkatalogów (bo tylko z roota działa cache Turborepo), że jest reguła "gate" — pięć obowiązkowych pytań przed dotknięciem kodu.

Bez tego mechanizmu uczyłbym Claude'a w nieskończoność tych samych rzeczy. Z nim — uczę raz, a kolejna sesja zaczyna od momentu, w którym poprzednia skończyła. To jest mniej więcej różnica między juniorem, którego musisz codziennie odprawiać, a senior developerem, który wraca po weekendzie i podejmuje wątek.

Subagenty: gdy jeden mózg to za mało

Druga zmiana, która przerobiła mój workflow: subagenty. Claude Code pozwala wywołać wyspecjalizowanego agenta jako narzędzie — z osobnym kontekstem, osobną listą uprawnień, czasem nawet osobnym modelem. U mnie najczęściej działają trzy:

Explore — szybko przeszukuje kodebase. Gdy mówię "znajdź wszystkie miejsca, gdzie używamy starego endpointu auth" — odpalam Explore zamiast samemu grepować. On zwraca syntezę, a nie surowy log z 200 trafień, które zaśmiecają mi główny kontekst.
Plan — projektuje implementację. Przy większej zmianie (np. dodaniu nowego pluginu do CMS) najpierw idzie Plan: rozpisuje pliki do utworzenia/zmiany, kolejność, ryzyka. Dopiero potem implementuję.
Review/Security-Review — sprawdza pull requesty i zmiany pod kątem bezpieczeństwa. Mam też custom Review Agent, który raz dziennie analizuje cały projekt i zgłasza issues.

Najważniejsza rzecz, którą zrozumiałem dopiero po jakimś czasie: subagenci pracują w izolacji od głównego kontekstu. To znaczy: jak Explore znajdzie dla mnie 50 plików, to do mnie wraca tylko podsumowanie ("oto 3 miejsca, które warto zmienić"), a nie 50 pełnych readów. Mój główny kontekst zostaje czysty, mogę pracować dłużej w jednej sesji bez utraty wcześniejszego stanu rozmowy.

Drugi trick: równoległość. Claude Code pozwala uruchomić kilka agentów w jednej wiadomości. Robię tak gdy potrzebuję zebrać niezależne informacje — np. równolegle: stan PM2, ostatnie commit messages, log z fail2ban. Trzy agenty, jedna sekunda zamiast trzech sekwencyjnych narad.

Skille i hooki — to ja decyduję jak ma pracować

Trzeci poziom: customizacja zachowania przez skille i hooki. To są konfiguracje w .claude/settings.json i katalogu skills, które pozwalają zmieniać sposób w jaki Claude Code reaguje na zdarzenia.

U mnie mam m.in.:

Slash command /init — generuje świeży CLAUDE.md z opisem kodebase
Slash command /review — pełen przegląd zmian w branchu
Slash command /security-review — audyt bezpieczeństwa pending changes
Skill simplify — analizuje moje ostatnie zmiany pod kątem nadmiarowości i automatycznie je upraszcza
Skill fewer-permission-prompts — skanuje moje transkrypty, wyciąga komendy, które najczęściej zatwierdzam, i dodaje je do allowlisty żebym nie musiał klikać tysiąc razy "approve"
Skill update-config — modyfikuje settings.json gdy chcę dodać nowe permission, hooki czy zmienne środowiskowe

Hooki to mocniejsza warstwa — pozwalają wpiąć skrypt powłoki w konkretne zdarzenie (przed wywołaniem narzędzia, po, gdy Claude kończy odpowiedź). Można nimi wymusić walidację linterów, automatyczne formatowanie, blokowanie niebezpiecznych operacji. Z hooków korzystam ostrożnie — łatwo nimi sobie zrobić bałagan — ale pre-commit hook na format i mały hook po-stop przypominający o aktualizacji pamięci to rzeczy, które stały się fundamentem.

Reguła, którą wyrobiłem przez błędy: jeżeli Claude zachowuje się "jakoś dziwnie", najpierw zaglądam w settings.json. Większość frustracji z asystentem AI bierze się z domyślnej konfiguracji, której nikt nie pomyślał dopasować do swojego projektu.

Agent który pracuje gdy ja śpię

Najbardziej niedoceniana funkcja Claude Code, której używam: scheduled agents. To po prostu agent uruchamiany cyklicznie przez cron, ze zdefiniowanym promptem. U mnie działa tak:

Codziennie o 02:00 uruchamia się Review Agent — autorski skrypt z dwunastoma podagentami, każdy odpowiedzialny za inną część projektu (autoryzacja, baza, cron, infrastruktura, frontend, security, performance, itp.). Każdy podagent dostaje swoją instrukcję, swoje pytania, swój zakres plików. Generują raport JSON z findings — od P0 (krytyczne) do P3 (kosmetyczne). Cross-validator sprawdza czy nie ma fałszywych alarmów. Wynik trafia do /srv/panel/reports/ jako Markdown i PDF.

Rano czyta to dla mnie kolejny agent i streszcza w trzech zdaniach. Jak są P0 — pingują mnie. Jak nie ma — kawa i kod.

Dodatkowo używam /loop i ScheduleWakeup. Loop to powtarzanie tego samego promptu co X minut (np. "co pięć minut sprawdź czy build CI przeszedł"). ScheduleWakeup to inteligentna pauza — Claude sam decyduje za ile minut do siebie wrócić sprawdzić stan długiego procesu, bez polowania na wynik. Razem z agentami w tle to robi z asystenta coś więcej niż chatbota: pracownika który ma własne zegarki i czeka na właściwy moment.

MCP — Claude wchodzi do przeglądarki i klika

Najnowsza warstwa, którą wpiąłem: MCP (Model Context Protocol). Pozwala dodać do Claude'a serwery które dają mu dostęp do zewnętrznych narzędzi. U mnie działa głównie Claude in Chrome — Claude może otworzyć kartę w mojej przeglądarce, wykonać action (kliknij, wpisz, screenshot), przeczytać DOM, sprawdzić console.

Konkretne zastosowania w moim projekcie:

Test E2E rejestracji — Claude wchodzi na landing, wypełnia formularz, sprawdza czy przyszedł e-mail weryfikacyjny, klika link, dochodzi do dashboardu. Cały scenariusz w jednej rozmowie, bez Cypressa, bez Playwright.
Diagnoza błędów wizualnych — "wejdź na stronę X, zrób screenshot, opisz co widzisz źle". Często wykrywa rzeczy, których nie zauważyłem przy code review (np. niewidoczny tekst na ciemnym tle, źle ustawione paddingi).
Sprawdzenie cudzej dokumentacji — "wejdź na tiptap.dev, znajdź jak włączyć extension X" — i Claude przegląda docs zamiast halucynować z pamięci.

Gmail, Calendar, Drive — też mam wpięte, ale używam mniej. Najmocniejsze są te, które dają Claude'owi dostęp do tego, co i tak robię w przeglądarce: Chrome, dokumentacje techniczne, panele wewnętrzne.

Czego jeszcze nie używam (a powinienem)

Po sześciu miesiącach widzę dokładnie czego nie wykorzystuję — a powinienem. Lista jest długa i to świadczy zarówno o szerokości narzędzia, jak i o moich własnych ograniczeniach.

Claude Agent SDK — to oficjalny SDK Anthropic do budowania własnych agentów programistycznie, nie z linii poleceń. Mógłbym mieć w panelu wbudowanego mini-Claude, który pomaga moim użytkownikom konfigurować strony WWW. Albo agenta zarządzającego e-mailem klienta. Nie napisałem ani jednej linii. Ciągle mam to "na potem".

Claude API z prompt caching — używam głównie CLI, ale są w projekcie miejsca, gdzie wprost wołam API z code'a (auto-translate bloga, generator opisów branż, czyszczenie treści Tiptap). Cache'owanie promptów potrafi obciąć koszt o 90% przy powtarzalnych systemowych instrukcjach. Mam to w jednym miejscu, w sześciu innych nie. To jest do nadrobienia w jeden weekend.

Worktrees — Claude Code potrafi otworzyć agenta w izolowanym worktree git, żeby pracował na kopii repozytorium bez ruszania mojego working directory. Nigdy tego nie odpaliłem. A to znaczy, że wciąż czasem agent wchodzi mi w paradę z plikami.

IDE extensions — Claude Code działa też jako wtyczka do VS Code i JetBrains. Ja siedzę w terminalu i edytorze tekstowym. Powodem nie jest dogmat — po prostu nie zmieniłem nawyku. Wtyczka dawałaby lepszą integrację z linterami, debuggerem i diff view.

Zaawansowane skille — wbudowanych mam kilka, własnych nie napisałem żadnego. A mógłbym mieć skill "deploy", który robi build + restart + smoke test + commit jednym promptem. Każdy ma godzinę na napisanie. Wciąż mam wpisane "TODO" w pamięci.

Background command monitoring — Claude Code potrafi puścić długą komendę w tle i powiadomić mnie gdy się skończy. Używam tego rzadko — instynkt każe mi czekać na wynik w foregroundzie. Tracę przez to czas, zamiast w międzyczasie pracować nad czymś innym.

Wniosek: największa pojemność narzędzia nie tkwi w tym co już daje out-of-the-box, ale w tym co możesz na nim zbudować. Ja jestem dopiero w połowie tej drogi.

Co realnie zyskałem

Przejdźmy do twardych zysków, bez marketingowych ogólników.

Tempo. Refactoring który zająłby mi dwa wieczory robię w godzinę z dyktanda — opisuję cel i ograniczenia, Claude proponuje kroki, ja akceptuję i nadzoruję. Pierwsza wersja całego CMS-a (12 szablonów, wizard z 6 krokami, generator wstępnych treści, biblioteka stocków) — trzy dni roboty. Solo z dokumentacją Next.js i Prismy zająłbym się tym przez miesiąc.

Zasięg. Sam zrobiłbym dobrze frontend albo backend. Z Claude Code ogarniam jedno i drugie, plus Docker, plus Postfix/Dovecot, plus DNS z DNSSEC, plus aplikację Android, plus monitoring, plus 6 języków lokalizacji. Każda z tych rzeczy z osobna nie jest nieosiągalna. Wszystkie naraz, w pojedynkę, bez asystenta — niemożliwe w realnym czasie.

Jakość bezpieczeństwa. Sześć rund audytu wewnętrznego, jeden zewnętrzny pentest black-box. Wykryto i naprawiono ponad sto issues — od trywialnych (X-Powered-By header) po krytyczne (instalator WordPress dostępny publicznie na subdomenie tenanta). Bez Claude'a robiłbym security audit raz, na pamięć, tracąc 80% rzeczy. Z Claude'em mam systematyczne, powtarzalne sprawdzanie.

Dokumentacja. Każda istotna sesja kończy się zaktualizowanym DOKUMENTACJA.md i wpisem w pamięci. Ja sam nie pisałbym dokumentacji — programiści tego nie robią. Claude robi to z automatu, bo go o to poprosiłem raz w feedback memory.

Self-monitoring projektu. Cron Review Agent znajduje rzeczy o których zapomniałem — orphaned procesy, wycieki w skryptach, źle skonfigurowane jaile fail2ban. Bez tego psułoby się to w tle, aż ktoś by zauważył.

Gdzie zawiódł — szczerze i konkretnie

Teraz część, której większość artykułów o AI nie pisze. Bo to nie jest cudowna technologia, tylko narzędzie z konkretnymi słabościami. Wymieniam te, które kosztowały mnie najwięcej.

Powtarzające się błędy. Mam w pamięci osobny plik feedback_dont-repeat-bugs.md z listą błędów, które Claude zrobił dwa lub więcej razy. Klasyk: konfiguracja sudo dla fail2ban — pierwsze podejście "hardcode'owało" hasło, drugie nie miało odpowiedniej reguły w sudoers, trzecie wreszcie zadziałało. Każde podejście to półtora godziny i restart usługi w produkcji. To był mój błąd, że nie wymusiłem zapisania reguły wcześniej, ale to też był jego błąd, że nie szukał wzorca po pierwszym fiasku.

Symptom-fixing zamiast root cause. Dwa konkretne incydenty. W jednym bug w skrypcie tłumaczeń pokazywał "190 missing, 0 translated" mimo że agent faktycznie tłumaczył. Pierwsza diagnoza Claude'a: "claude CLI nie zwraca poprawnego JSON-a". Po sprawdzeniu kodu okazało się, że bug był w jednej linii — odrzucał wszystko co nie było stringiem (a tłumaczenia kroków były tablicami). Druga sytuacja: użytkownik zgłosił że strona "nie działa". Claude wpadł od razu w testowanie API, sprawdzanie PM2, konfiguracji nginx. Faktyczna przyczyna: po build z roota, fail2ban zbanował IP użytkownika za 12 błędów 404 na chunkach Next.js, których nie ma w cache przeglądarki. Trzy minuty robót zamiast pół godziny — gdyby od razu sprawdził fail2ban dla tego konkretnego IP.

Nadmierna pewność przy zerowej weryfikacji. Klasyk z dziś: spytałem o stan bloga. Claude odpowiedział "blog jest pusty, API zwraca 404" i poszliśmy w tę stronę. Po dwóch minutach okazało się, że testował /api/blog/posts, a właściwy endpoint to /api/cms-public/blog/posts — bo blog jest pluginem CMS, nie głównego API. Blog miał w bazie 91 postów. Cała diagnoza opierała się na fałszywym założeniu, którego Claude nie zweryfikował.

Refaktor który psuje rzeczy. Trzy razy przy próbie "uporządkowania" kodu Claude wprowadził regresję. Raz w autoryzacji (po przeniesieniu logiki do AuthService), raz w nginx (po deduplikacji konfiguracji), raz w workerze (po migracji na BullMQ). Za każdym razem testy łapały to przed deployem, ale dwie godziny rozwiązywania regresji to nie jest "zysk czasu z AI".

Eskalacja drobnej zmiany w wielką operację. Klasyczny pattern: proszę o "drobny fix CSS" a kończy się propozycją refactor całego komponentu, dodaniem dwóch zależności i napisaniem nowego hooka. To moja wina że nie ograniczałem od razu — ale też jego, że ma tendencję do "ulepszania" zamiast minimalnej zmiany. Naprawiłem to przez memory: "buduj nowe rzeczy, nie refaktoryzuj/skanuj/debuguj w kółko".

Ślepe punkty w infrastrukturze. Dwa konkretne. Pierwszy: instalator WordPressa został publicznie dostępny pod subdomeną tenanta i nikt tego nie zauważył przez tygodnie, aż zewnętrzny pentest black-box wykrył to jako CRITICAL. Drugi: po jednej z deployów ownership .next/ zmienił się na root:root, co oznaczało że proces panel-web (uruchamiany jako www-data) nie mógł zapisywać do .next/cache — przez wiele godzin każdy SSR robił świeży fetch do API zamiast korzystać z cache. Claude zobaczył błąd EACCES w logach dopiero gdy go spytałem dlaczego build trwa długo.

Halucynacje na bazie pamięci. Memory daje świetny kontekst, ale ma datę. Czasem Claude rekomenduje plik, który już dawno został przeniesiony, albo flaga która została usunięta. Lekcja: pamięć to obserwacja w czasie, nie aktualny stan. Trzeba weryfikować przed użyciem.

Słaba intuicja co do priorytetów biznesowych. Claude świetnie wykonuje konkretne polecenia. Ale kiedy mówię "zrób żeby strona miała więcej ruchu" — bardzo trudno mu samemu podzielić to na sub-zadania według wagi (technical SEO < indexowanie < content marketing < backlinki). Zawsze idzie najpierw w to, co technicznie najprościej naprawić. Ja muszę go ukierunkowywać.

Jak ustawiłem proces żeby ograniczyć szkody

Po sześciu miesiącach mam dość ścisły proces, który redukuje powyższe ryzyka. Dzielę się nim bo zajęło mi wymyślenie go drogą bólu.

Brama pięciu pytań przed kodem. Mam w pamięci plik z pięcioma pytaniami, które Claude musi zadać sobie zanim napisze pierwszą linię kodu: jaki jest cel? jakie ograniczenia? jakie istniejące rozwiązania? jak to przetestować? jaki rollback plan? Bez tego wpada od razu w pisanie. To mój pierwszy mechanizm bezpieczeństwa.

Mapa zależności. Wymuszam żeby przed zmianą w środku systemu zmapował co od czego zależy. Wcześniej kilka razy poprawiał coś w jednym miejscu i wywalał trzy inne. Dziś robi diagnozę, dopiero potem leczy.

Build before restart. Reguła w pamięci: zawsze pnpm build przed pm2 restart. Brzmi banalnie, ale w monorepo z TypeScript serwer czyta z dist/, nie z src/. Pierwsze kilka razy restart bez builda kończyło się produkcją z poprzedniego dnia.

Niezależna weryfikacja efektów. Po większej zmianie nie wystarczy "pnpm build przeszedł". Trzeba zrobić smoke test (cURL na endpoint, screenshot strony), sprawdzić logi, monitorować przez kilka minut. Jak nie ma niezależnej weryfikacji — uznajemy że zadanie jest niedokończone.

Sesja state. Przy paczce poprawek (np. 14 fixów po raporcie security) zapisuję stan po każdym kroku do session-state.json. Gdyby coś poszło nie tak — wracam do checkpointa zamiast zaczynać od początku.

Daily review agent. O nim już pisałem — codzienna inspekcja całego projektu. Bez tego dryfowałby w bałagan.

Update memory after every task. Hook po-stop przypomina o aktualizacji pamięci. Bez tego pamięć przestaje być aktualna i staje się źródłem halucynacji.

Dla kogo to ma sens, dla kogo nie

Claude Code jest narzędziem dla konkretnego profilu osoby — i to nie jest "każdy programista". Po pół roku widzę to wyraźnie.

Działa świetnie dla:

Solo founderów i małych zespołów budujących produkty od zera. Skala "zrobić wszystko samemu" nagle staje się skala "zrobić wszystko z asystentem". Gigantyczna różnica.
Senior developerów którzy potrafią kierować, weryfikować i poprawiać. Claude to nie jest senior — to jest junior z encyklopedyczną wiedzą i nieskończoną cierpliwością. Bez seniora, który go nadzoruje, robi rzeczy które wyglądają poprawnie, a są błędne.
Osób, które nie mają oporów wobec procesu. Ten styl pracy wymaga ścisłej dyscypliny: pamięć, feedback, plany, weryfikacja. Bez tego bałagan rośnie szybciej niż produkt.
Projektów wielomodułowych, gdzie zysk z asystenta skaluje się z liczbą warstw stack-u.

Działa źle dla:

Junior developerów, którzy nie potrafią zweryfikować odpowiedzi. Claude napisze im coś co skompiluje się i odpali — ale nie zauważą że to robi rzecz inną niż chcieli.
Projektów greenfield bez żadnej refleksji architektonicznej. Bez kierunku Claude buduje na ślepo. Z kierunkiem — w dobry sposób.
Osób oczekujących "magii". Claude nie zastąpi myślenia, tylko je przyspieszy. Jeśli ktoś szuka narzędzia "napisz mi cały SaaS jednym promptem" — to nie tu.

Wnioski

Po sześciu miesiącach mam projekt SaaS, który normalnie wymagałby trzy- lub czteroosobowego zespołu na rok. Mam też wyraźne pojęcie o tym, gdzie Claude Code działa świetnie, a gdzie zawodzi. Najważniejsze rzeczy, których się nauczyłem:

Pamięć jest fundamentem. Bez niej każda sesja jest restartem. Z nią — masz "zespół" który pamięta co ustaliliście w czerwcu.
Subagenty to nie luksus, to ergonomia. Bez nich główny kontekst zaśmieca się w kilka godzin.
Custom skille i hooki to gdzie naprawdę kryje się produktywność. Standardowy Claude jest dobry. Skonfigurowany pod twój projekt — kilka razy lepszy.
Scheduled agents zmieniają wszystko. Praca w tle, gdy ja śpię, to inny tryb pracy niż "asystent w czacie".
Należy mu nie ufać. Nie z powodu złych intencji, ale dlatego że jego pewność nie koreluje z prawdą. Każda odpowiedź "jest gotowe" wymaga niezależnej weryfikacji.
Process > promptowanie. 80% wartości jaką wyciągam z Claude Code wynika z procesu który zbudowałem wokół niego (memory, hooki, daily review, brama pięciu pytań), nie z tego że "umiem dobrze pisać prompty".
Największa luka to nie technologia. Anthropic dał już więcej narzędzi, niż jestem w stanie wykorzystać. Wąskim gardłem jest moja wyobraźnia i czas na konfigurację, nie ich SDK.

Czy budowałbym jeszcze raz projekt SaaS bez Claude Code? Nie. Czy zalecam każdemu tę drogę? Tylko jeśli masz dyscyplinę, żeby zbudować proces wokół narzędzia. Bez procesu — Claude Code to ekspres do bałaganu produkcyjnego. Z procesem — najbardziej multiplikatywne narzędzie dla pojedynczego programisty, jakie do tej pory miałem w rękach.

Druga połowa tej drogi zaczyna się dla mnie teraz. Plan na kolejne pół roku: skończyć z odkładaniem Agent SDK, napisać własne skille deploy/release, wpiąć prompt caching wszędzie gdzie wołam API, zbudować dashboardową integrację Claude'a dla moich użytkowników. Jak się uda — opiszę. Jak nie — też.