O czym jest ten film
- Agenci kodujący budują dokładnie to, o co poprosisz — jeśli nie określisz stosu technologicznego, wybiorą go za ciebie, co mści się przy wdrożeniu, skalowaniu i bezpieczeństwie.
- Autor spakował swoje ~20 lat doświadczenia full stack w trzy skille: Start an App, Review an App, Deploy an App.
- Demo: kompletny klon Trello zbudowany z jednego promptu — z landing page, bannerem cookies, dokumentacją publiczną, stronami prawnymi, logowaniem i organizacjami.
- Każda aplikacja dostaje zdalny serwer MCP, dzięki czemu Claude, ChatGPT czy inny asystent może działać w aplikacji w imieniu użytkownika — bezpiecznie i z jego uprawnieniami.
- Ustawienia konta z „danger zone”: zmiana e-maila i hasła, pobranie własnych danych, usunięcie konta — rzeczy wymagane prawnie, których agent sam z siebie nie doda.
- Skille są zestawem plików Markdown z referencjami (AI, auth, baza, e-maile, zadania w tle, płatności, SEO) — każdą warstwę można podmienić, edytując jeden plik.
- Review an App sprawdza dryf projektu, podatności według OWASP Top 10 oraz SEO — łącznie z
robots.txt,sitemapillms.txt. - Deploy an App stawia produkcję na Vercelu: repozytorium GitHub, zmienne środowiskowe, baza Neon, blob storage, Inngest do zadań w tle, migracja SQLite → Postgres.
- Przed wdrożeniem agent pokazuje „deployment sheet” z podsumowaniem decyzji i kosztami — w demie wszystko mieści się w darmowym planie Vercela.
- Ograniczenie: tymczasowa domena Vercela nie działa z połączeniem MCP — potrzebna jest prawdziwa domena.
Redakcyjne tłumaczenie
Problem: agent robi dokładnie to, o co prosisz
Agenci kodujący, tacy jak Claude Code czy Codex, potrafią dziś zbudować praktycznie wszystko. Jest jednak haczyk: zbudują dokładnie to, o co poprosisz. Jeśli nie określisz stosu technologicznego, agent zdecyduje za ciebie. To potrafi zemścić się później — przy próbie wdrożenia aplikacji, przy skalowaniu, a nawet w postaci podatności bezpieczeństwa, które mogą narobić poważnych kłopotów.
Agenci skupiają się głównie na głównej funkcjonalności, co oznacza, że wszystkie drobne rzeczy zostają pominięte. Aplikacja może więc wyglądać poprawnie na pierwszy rzut oka, a w rzeczywistości brakuje jej wielu elementów, które czynią z niej prawdziwą aplikację produkcyjną.
Buduję oprogramowanie od prawie dwudziestu lat, więc wziąłem swoje doświadczenie jako full stack developer i zapakowałem je w trzy podstawowe skille. Z tymi trzema skillami zbudujesz dowolną aplikację webową — od prostej strony aż po dużą aplikację SaaS.
(Informacja dodatkowa: „skill” w Claude Code to pakiet instrukcji i plików referencyjnych, który agent wczytuje na żądanie i traktuje jak zestaw reguł dla danego typu zadania.)
Demo: klon Trello z jednego promptu
Zanim przejdę do konfiguracji, pokażę szybko, jakiego rodzaju efekty daje ten zestaw. Cała ta aplikacja powstała z jednego promptu. Brzmiał mniej więcej tak: „Użyj skilla start an app. Chcę, żebyś stworzył kompletny funkcjonalnie klon Trello. Będę go używał głównie do śledzenia postępów wszystkich naszych działań na YouTubie, ale w gruncie rzeczy to nic więcej niż klon Trello”. I tyle. Agent zadał kilka pytań doprecyzowujących i zbudował całą tę aplikację.
Landing page. Ile razy prosiłeś agenta o zbudowanie jakiejś aplikacji i dostawałeś wyłącznie dashboard i stronę logowania? Tutaj dostajemy pełny interfejs, ale — co bardzo ważne — także banner cookies. Skoro aplikacja korzysta z ciasteczek, w niektórych krajach jest to wręcz wymagane. Banner faktycznie śledzi zgody: możesz wybrać, co chcesz włączyć, a co wyłączyć, i zapisać preferencje. Zostaną zachowane w przeglądarce, dokładnie tak, jak byś tego oczekiwał w prawdziwej aplikacji.
Aplikacja działa na prawdziwej domenie, a wdrożenie także zostało skonfigurowane przez skill — nie musisz robić nic samodzielnie.
Dokumentacja publiczna. Gdy zjedziemy do stopki, znajdziemy strony pomocy. To naprawdę ważne: zależnie od typu budowanej aplikacji agent przygotuje publiczną dokumentację. Jeśli sam korzystałeś kiedyś z aplikacji SaaS, wiesz, że to praktycznie wymóg. Przy tak prostej aplikacji nie ma wiele do opisania — poza jedną rzeczą. Mamy dokumentację pokazującą, jak podłączyć aplikację do asystentów i agentów AI, takich jak Claude Code czy ChatGPT.
Serwer MCP jako standardowe wyposażenie
Ten skill tworzy i konfiguruje także zdalny serwer MCP dla twojej aplikacji. Oznacza to, że asystenci AI mogą wchodzić z nią w interakcję w bezpieczny sposób. Nie muszę logować się do aplikacji, żeby z niej korzystać — podpinam ją do Claude’a przez konektor albo do ChatGPT przez plugin i po prostu proszę, żeby wykonały działania w moim imieniu.
(Informacja dodatkowa: MCP — Model Context Protocol — to otwarty standard opisujący, jak aplikacja udostępnia asystentom AI zestaw narzędzi i danych.)
Jestem głęboko przekonany, że udostępnianie możliwości aplikacji asystentom AI jest dziś koniecznością. Coraz więcej osób używa agentów do obsługi aplikacji w swoim imieniu i twoja aplikacja musi umieć bezpiecznie przyjmować takie połączenia.
Strony prawne. Niżej w stopce znajdziemy komplet stron prawnych. Znów: nie dotyczy to każdej budowanej aplikacji. Przy prostej stronie jednoekranowej nic z tego nie jest potrzebne. Ale skill inteligentnie instruuje agenta, żeby dodał te strony, jeśli są konieczne dla danego typu aplikacji. Jeśli faktycznie budujesz i sprzedajesz oprogramowanie, to nie jest opcjonalne — polityka cookies, regulamin i polityka prywatności są wymagane.
Konta użytkowników i „danger zone”
Ponieważ budujemy tu aplikację SaaS, mamy możliwość zakładania kont i logowania. Obsługiwane jest logowanie społecznościowe, można też po prostu założyć konto e-mailem i hasłem. Po zalogowaniu tworzę i zarządzam tablicami. To demo nie jest jednak o samej aplikacji — chodzi o to, co skille dają ci od ręki.
W profilu użytkownika mamy dostęp do publicznej dokumentacji, ale naprawdę chcę pokazać ustawienia. Wszystko to pochodzi z tego jednego, bardzo prostego promptu i niczego więcej. Agent instynktownie wie, że budując aplikacje SaaS z uwierzytelnianiem użytkowników, musimy dać im dostęp do profilu i innych informacji, których udostępnienie bywa wymogiem prawnym.
Po zalogowaniu mogę zmienić zdjęcie profilowe. W zakładce konta zmienię e-mail i hasło. Ale spójrz na to: mamy też „danger zone”. Możemy pobrać własne dane i zażądać usunięcia konta z aplikacji — czyli usunięcia wszystkich danych, które aplikacja ma na nasz temat. To nie jest opcjonalne, jeśli budujemy prawdziwe oprogramowanie. A agenci nie dodadzą tych rzeczy, dopóki wprost o to nie poprosisz.
(Informacja dodatkowa: w Unii Europejskiej prawo do przenoszenia danych i prawo do usunięcia danych wynikają z RODO.)
W zakładce „connected apps” zobaczymy, jak podłączyć asystentów AI do aplikacji przez serwer MCP, oraz listę wszystkich podłączonych klientów — Hermes Agent, Codex, Claude Code, ChatGPT, cokolwiek mamy powiązane z kontem. Możemy im odebrać dostęp. Mamy też pełną przejrzystość co do tego, jaka była aktywność agenta.
Na tablicy Kanban „YouTube pipeline” widać wszystkie karty. Za aplikacją stoi prawdziwa baza danych i porządne uwierzytelnianie. Mamy nawet organizacje i przestrzenie robocze, więc mogę zapraszać członków i przypisywać im różne role i uprawnienia. To wszystko jest po prostu wbudowane w skill — nie musisz o tym myśleć. Zakres tych możliwości zależy oczywiście od tego, jaką aplikację budujesz.
Co daje serwer MCP w praktyce
Z poziomu Claude Code dodaję swoją aplikację przez serwer MCP — wklejam adres URL. To daje agentowi natychmiastowy dostęp do sporego zestawu funkcji: odczytu kart i tablic, tworzenia kart, aktualizowania statusów, przypisywania użytkowników. Wszystko tam jest.
Mogę więc powiedzieć: „wypisz wszystkie karty przypisane do mnie”. I to jest bardzo ważne: Claude poprosi o zgodę przed wywołaniem któregokolwiek z tych narzędzi. Mamy pełną kontrolę nad tym, jak wyglądają kroki zatwierdzania dla poszczególnych narzędzi. Dla każdego udostępnionego narzędzia możemy powiedzieć agentowi, że ma pytać o zgodę, możemy je całkowicie zablokować albo zawsze zezwalać na dostęp.
Warto też wspomnieć o przycisku rozłączenia. Żeby korzystać z tego MCP, musimy uwierzytelnić się w naszej aplikacji. Oznacza to, że Claude działa w niej w naszym imieniu i ma dokładnie taki dostęp, jaki mu w niej nadamy. To wszystko jest bezpieczne.
Karty zostały pobrane — w „YouTube pipeline” mamy cztery karty i po powrocie na tablicę widzimy dokładnie te same cztery. Proszę: „zmień status filmu o trzech skillach na in recording”. Claude kończy zadanie, odświeżam aplikację i karta jest zaktualizowana. Ale to nadal jest aplikacja webowa — mogę korzystać z niej bezpośrednio albo podpiąć ją do Hermes Agent czy dowolnego innego asystenta.
Jest jeszcze mnóstwo rzeczy, które mógłbym wskazać — choćby skróty klawiszowe dla zaawansowanych użytkowników. Po prostu bardzo dużo rzeczy jest domkniętych od razu.
Instalacja skilli
Konfiguracja jest naprawdę prosta. Skille linkuję w opisie filmu. Wchodzisz do repozytorium GitHub, kopiujesz URL, przechodzisz do swojego agenta — użyję Claude Code — wklejasz adres i piszesz: „zainstaluj proszę te skille”. I tyle. Claude to zrobi. Instalacja powinna przebiec na poziomie globalnym, co oznacza, że skille będą dostępne we wszystkich twoich projektach.
Alternatywnie możesz wejść na skills.sh, skopiować gotowe komendy i przekazać je agentowi albo uruchomić w terminalu.
Bonusowy skill: Create Brand Kit. Możesz go użyć do stworzenia logo firmy i całego brand kitu. Użyłem go do wygenerowania logo dla mojej strony „cognitive” — stworzył też paletę kolorów i kolory marki. Widać, że logo i reszta treści do siebie pasują; efekt jest po prostu dużo bardziej profesjonalny. Dostajesz różne wersje logo: małe logo w kółku, warianty na tryb jasny i ciemny, a także pliki SVG, czyli wektory, które można skalować do rozmiarów billboardu albo drukować na koszulkach. Skill generuje też dokument HTML wyjaśniający uzasadnienie projektu — widać finalne logo, ideę, ścieżkę projektową i zestaw reguł oraz rozmiarów. To może być bardzo przydatne, gdy startujesz projekt zupełnie od zera i chcesz mieć logo od razu.
Trzy skille i ich budowa
Ale wracamy do sedna: trzy skille to Start an App, Review an App i Deploy an App. Każdy z nich jest w wysokim stopniu konfigurowalny. Zbudowałem je w oparciu o stos technologiczny, którego używam od wielu lat i z którego korzysta też wiele dużych firm i przedsiębiorstw. Ale jest on w pełni wymienny — jeśli chcesz podmienić któryś komponent na coś, co wolisz, jest to bardzo elastyczne.
W skillu Start an App mamy podstawowy plik skilla, który wyjaśnia agentowi, jak skill działa i jak stosować poszczególne reguły. Agent będzie zadawał pytania doprecyzowujące i próbował zrozumieć, czego potrzebujesz. Zauważysz, że pytania są w zwykłym języku — bardzo proste, nietechniczne. Wystarczy zwykła rozmowa z agentem, a on sam ustali, jak powinien wyglądać stos technologiczny pod spodem.
Wszystko to napędzają pliki referencyjne. Jeśli budujesz aplikację wymagającą funkcji AI — czy to chatbota, czy wbudowanego agenta z dostępem do narzędzi — opisuje to plik AI.md. System uwierzytelniania jest opisany w pliku auth, dalej mamy bazy danych, sposób pisania publicznej dokumentacji, wysyłkę e-maili. To kolejna rzecz: aplikacja potrafi wysyłać e-maile transakcyjne — kody jednorazowe, resety hasła, weryfikację kont. Obsłużone są też zadania w tle, więc jeśli twoja aplikacja wymaga przetwarzania w tle, które może się nie udać i wymaga wznowienia, to również jest pokryte. Jest obsługa płatności. Jest SEO. Wszystko tam jest.
A jeśli chcesz coś podmienić, wystarczy otworzyć odpowiedni plik .md. W AI.md korzystam z dwóch rzeczy: AI SDK od Vercela albo OpenRoutera, ewentualnie z kombinacji obu. Domyślnie aplikacja użyje AI SDK z OpenRouterem. Ale załóżmy, że wolisz Claude Agent SDK albo Pydantic AI. To bardzo proste — poproś swojego agenta kodującego, żeby zmodyfikował ten plik pod wybrane SDK. Tak samo z płatnościami: domyślnie wspierane są Polar i Stripe, ale jeśli chcesz czegoś innego, modyfikujesz ten plik.
Start an App w praktyce
Użycie jest naprawdę proste. Po zainstalowaniu skilli wystarczy w projekcie rozpocząć nową sesję i uruchomić komendę start an app. Zróbmy coś banalnego: „zbuduj prostą aplikację do zadań”. Wiem, że aplikacje to-do wszystkim się już przejadły, ale chodzi o pokazanie działania skilla.
Najpierw agent zada kilka pytań doprecyzowujących. Odpowiadam, że ma być maksymalnie prosto i że każdy powinien móc się zalogować i korzystać z aplikacji. To skłania agenta do użycia bazy danych na informacje o użytkownikach i na zadania. Mówi mu też, że aplikacja potrzebuje uwierzytelniania, więc skonfiguruje system logowania.
I to jest bardzo ważne: agent pyta, czy chcemy bazę Postgres, czy SQLite. Te opcje pochodzą z pliku DB w skillu Start an App. SQLite jest przeznaczony głównie do aplikacji zabawkowych — jeśli nigdy nie planujesz wdrożenia, możesz go użyć. Jeśli planujesz wdrożyć, wybierz Postgres.
Kolejne pytanie: czy aplikacja ma wysyłać e-maile, na przykład do weryfikacji adresu? Jeśli powiesz „tak”, agent skonfiguruje Resend albo inną usługę pocztową. Na razie to pomijam.
Jedna rzecz, którą lubię robić w narzędziu do agentowego kodowania: zmieniam nazwę konwersacji na „start an app”. Przy klonie Trello, który wam pokazywałem, sesja nazywała się „YouTube manager”. Widać tam trzy sesje: start an app do zbudowania aplikacji, potem review an app, który omówimy zaraz, a na końcu deploy an app. Ten ostatni załatwił wszystko — utworzenie bazy w produkcji, a nawet blob storage na pliki. Po prostu wykonał całą pracę za mnie.
System projektowy
Jeśli chodzi o system projektowy, wchodzę na stronę styles.refero.design. Poszukajmy czegoś w stylu „clean SaaS”, a żeby było ciekawiej — weźmy Slacka. Wybieram wersję rozszerzoną, kopiuję i mówię: „użyj proszę tego systemu projektowego”. W przeciwnym razie agent wymyśli własny, nudny design.
Jeśli chcesz nauczyć się budować systemy projektowe, mam poświęconą temu sekcję w moim kursie agentowego kodowania — kilka filmów, od podstaw systemów projektowych, przez ucieczkę od „AI slopu”, po narzędzia takie jak Claude Design i Google Stitch. Link w opisie.
Efekt: aplikacja to-do
Claude skończył. Przetestował aplikację także we wbudowanej przeglądarce. I choć demo było banalne, agent naprawdę dał z siebie wszystko. Mamy landing page. Mamy banner cookies — po kliknięciu „więcej o cookies” trafiamy do dokumentacji. Mamy sekcję hero zgodną z systemem projektowym, który wcześniej ustawiliśmy. Jest strona pomocy z całą publiczną dokumentacją, jak korzystać z aplikacji. Powstał też zdalny serwer MCP, więc mamy dokumentację podłączania aplikacji do agentów AI. Jest komplet dokumentów prawnych — wystarczy podać agentowi nazwę firmy, a on podmieni symbol zastępczy.
Sprawdźmy, czy da się założyć konto. Rejestracja zadziałała i była błyskawiczna. Teraz mogę dodawać zadania — nic nadzwyczajnego. Naprawdę chcę jednak sprawdzić, co dzieje się po kliknięciu w profil użytkownika. Zwykle, gdy agenci budują aplikacje, ta część jest bardzo uboga, o ile w ogóle istnieje. A tu mamy ustawienia i podłączone aplikacje. Wchodzę w ustawienia — i proszę: profil, informacje o koncie, możliwość pobrania i usunięcia danych. To wszystko z bardzo prostego promptu.
Możemy zobaczyć podłączone aplikacje i instrukcje konfiguracji serwerów MCP. Dostajemy też stronę statusu systemów, co jest bardzo fajne. Można ją ukryć, ale pokazuje, czy system działa: czy uwierzytelnianie jest poprawnie skonfigurowane, czy baza danych działa. To naprawdę użyteczne.
Możesz oczywiście poprosić agenta o dodanie czegokolwiek innego albo o poprawki, ale przejdźmy do drugiego skilla.
Review an App: dryf, bezpieczeństwo, SEO
Review an App sprawdza dryf — czy design nie zaczyna się rozjeżdżać albo czy agent nie dodał czegoś, co do aplikacji nie pasuje. Zbiera dowody i podobne rzeczy. Ale dwie rzeczy chcę podkreślić.
Po pierwsze, skill sprawdza podatności bezpieczeństwa według OWASP Top 10. Jeśli nie wiesz, co to jest — to bardzo powszechny zestaw kontroli pozwalający wyszukać krytyczne podatności w aplikacji, takie jak nieprawidłowa kontrola dostępu, błędy kryptograficzne, SQL injection i kilka innych.
(Informacja dodatkowa: OWASP Top 10 to publikowana przez fundację OWASP lista dziesięciu najpoważniejszych kategorii ryzyk w aplikacjach webowych.)
Po drugie, sprawdzamy SEO. Tego akurat nie widziałem, żeby ktokolwiek poruszał w kontekście agentowego kodowania. Budując aplikacje webowe, chcesz, żeby były odkrywalne przez wyszukiwarki. A w obecnych czasach chcemy też, żeby duże modele językowe potrafiły znaleźć i zrozumieć nasze aplikacje. Ten skill jest dość rozbudowany, ale spróbuje zoptymalizować aplikację pod SEO. Doda też pliki robots.txt, llms.txt oraz mapę witryny.
To już moje własne pojęcia z zakresu SEO, ale w skrócie: robots.txt blokuje lub zezwala robotom na dostęp do konkretnych stron czy katalogów — jeśli są strony, które nie powinny trafić do wyszukiwarek, robots.txt zablokuje scraperom dostęp do tych ścieżek. Mapa witryny określa wszystkie adresy w serwisie, które powinny zostać zaindeksowane. llms.txt to rzecz nowa — tworzy podsumowanie tego, czym jest twoja aplikacja lub strona, wraz z ważnymi ścieżkami czy produktami, ale napisane w formie łatwo przyswajalnej dla dużych modeli językowych.
Uruchomienie tego jest bardzo proste: w tym samym projekcie tworzysz nową sesję i wywołujesz skill Review an App. To wszystko. Sesję również zmieniam na „Review an App”.
Fajne jest to, że i ten skill jest w pełni konfigurowalny. Jeśli chcesz dodać dodatkowe kontrole do procesu przeglądu, śmiało dodawaj kolejne pliki. Jeśli chcesz sprawdzać rzeczy, których nie sprawdzam w sekcji SEO, zmień te reguły. A jeśli chcesz szukać podatności wykraczających poza OWASP Top 10 — po prostu zmodyfikuj ten plik. To ma być punkt wyjścia, który weźmiesz i uczynisz swoim.
Deploy an App: produkcja bez ręcznej roboty
Ostatni skill to Deploy an App. Znów uruchamiamy komendę Deploy an App i tyle.
W samym skillu można otworzyć katalog referencji, gdzie jest sporo plików do przejrzenia i zmiany. Skill jest nastawiony na wdrażanie projektów na Vercel. Ale jeśli chcesz wdrażać na Cloudflare Workers, Hostinger albo własny VPS, możesz odpowiednio zmienić te pliki — wrzuć je do Claude Code czy innego agenta i poproś o dostosowanie pod wybranego dostawcę.
Cały proces jest naprawdę prosty. Skilli nie instalujesz za każdym razem — robisz to raz. Potem, gdy chcesz zacząć nowy projekt, uruchamiasz Start an App. Kiedy projekt jest zbudowany i sam go przetestujesz, uruchamiasz Review an App, który poprawi SEO i ewentualne podatności. Następnie uruchamiasz Deploy an App, który skonfiguruje wszystko w produkcji: wdroży pliki projektu, ale też postawi bazę danych i blob storage. Jeśli używasz przetwarzania w tle, skonfiguruje Inngest. Naprawdę ustawi wszystko, czego aplikacja potrzebuje, żeby działać na produkcji.
I jeszcze jedno: jeśli budowałeś projekt na SQLite — a wspominałem, że SQLite nadaje się głównie do lokalnych, jednorazowych projektów — a potem zdecydujesz, że jednak chcesz wdrożyć aplikację, skill to wykryje i przekonwertuje bazę. Napisze skrypt migracji z SQLite do Postgresa i wdroży całość na bazie Postgres w produkcji.
Jeśli nie wiesz, czym jest Vercel: to firma hostingowa, usługa pozwalająca wdrażać strony i projekty na ich infrastrukturze. Darmowy plan jest wyjątkowo hojny. Nie jestem przez nich sponsorowany — po prostu sam z nich korzystam. Za bazę danych, blob storage i sam hosting nie zapłacisz ani grosza.
Pytania przy wdrożeniu
Claude Code zadaje kilka istotnych pytań. Pierwsze: pod jakim adresem ma działać aplikacja? Możesz kupić domenę, na przykład .com, przez Vercela, albo pozwolić im wygenerować tymczasowy adres URL — to jest darmowe. Więc dopóki budujesz i zastanawiasz się nad domeną, wdrażaj pod darmowym adresem. Kiedy już zdecydujesz, zarejestrujesz domenę u Vercela albo u innego dostawcy i podepniesz ją do konta Vercel. Agent może ci w tym pomóc. W tym demie wybieram darmowy URL.
Drugie pytanie: ten folder nie jest repozytorium Git, jak mają działać wdrożenia? Możesz wdrażać projekt prosto na Vercel i dla części osób to będzie w zupełności wystarczające. Ja jednak lubię tworzyć repozytorium na GitHubie, żeby kod był gdzieś zbackupowany, a wypchnięcie zmian na GitHuba wyzwalało aktualizację na Vercelu. Wybieram tę opcję: git init, repozytorium prywatne, a push na GitHuba ma uruchamiać aktualizację na Vercelu.
I to jest naprawdę fajne — dostajemy „deployment sheet”. Zawsze go dostaniesz, korzystając z tego skilla. To podsumowanie tego, co ustaliliśmy: że potrzebna jest baza danych, że jest kilka rzeczy do zrobienia. Ale najważniejsza część to koszty. Skill mówi nam, że nie zapłacimy nic — wszystko, co skonfigurowaliśmy w tym projekcie, mieści się w darmowym planie hobby Vercela. Nawet baza danych będzie darmowa. Mówię więc: „brzmi dobrze”.
Efekt wdrożenia
Claude zakończył wdrożenie i testuje mapę witryny oraz samą aplikację na domenie produkcyjnej. Zobaczmy, co zrobił. Utworzył repozytorium na GitHubie — nasz kod jest zbackupowany. Po zalogowaniu do Vercela wchodzimy w projekt i wszystko tam jest: aplikacja wdrożona, tymczasowa domena przypisana. Przypominam, że możesz poprosić agenta o zakup domeny albo zrobić to samodzielnie w zakładce domen projektu — kupić nową lub przenieść istniejącą.
Skonfigurowane zostały też wszystkie zmienne środowiskowe. Jeśli kiedykolwiek robiłeś takie wdrożenia, wiesz, o czym mowa — agent ustawił je wszystkie za nas. W zakładce storage widać utworzoną bazę Neon. Gdyby aplikacja potrzebowała przechowywania plików, byłby tu również blob store. Wszystko skonfigurowane w twoim imieniu.
To jest nasza aplikacja działająca na produkcji. Każdy, kto ma ten adres, może z niej korzystać. Cookies działają. Zakładam konto — działa. Dodaję zadanie, odświeżam stronę i wszystko jest zapisane.
Zastrzeżenie: MCP a domena tymczasowa
Jedna uwaga: jeśli chcesz podłączyć tę aplikację do czegoś takiego jak Claude Code, potrzebujesz prawdziwej domeny. Nie sądzę, żeby tymczasowa domena zadziałała — miałem z tym wcześniej problemy. Ale gdy tylko przypiszesz właściwą domenę, wszystko działa.
Dla porządku spróbujmy jednak. Kopiuję adres, w Claude wchodzę w konektory, zarządzanie konektorami, dodaję własny konektor, nazywam go „Tick”, wklejam URL serwera MCP i klikam „dodaj”. Teraz trzeba się uwierzytelnić. I proszę — dostajemy komunikat, że nie udało się połączyć. To wyłącznie kwestia domeny. Zmarnowałem sporo czasu na debugowanie tego, a wniosek jest taki, że z domenami tymczasowymi to nie zadziała. Gdy tylko zarejestrujesz prawdziwą domenę, serwer MCP zacznie działać.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Domyślne decyzje agenta to twój dług techniczny
Na czym polega: Jeśli nie określisz stosu technologicznego, agent wybierze go za ciebie. Konsekwencje ujawniają się dopiero przy wdrożeniu, skalowaniu albo w postaci podatności.
Jak stosować: Zanim poprosisz o kod, ustal na piśmie bazę danych, system uwierzytelniania, dostawcę hostingu i sposób obsługi płatności. Skille autora robią to za ciebie, ale sama zasada działa nawet bez nich — wystarczy plik z regułami projektu.
Na co uważać: Zbyt wczesne zamrożenie stosu bywa równie kosztowne. Trzymaj decyzje w osobnych plikach referencyjnych, żeby podmiana jednego komponentu nie oznaczała przepisywania promptów.
2.Skill to plik reguł, nie magia
Na czym polega: Każdy z trzech skilli to plik główny plus katalog referencji (AI.md, auth, DB, e-maile, płatności, SEO, zadania w tle). Agent czyta te pliki i stosuje reguły.
Jak stosować: Zainstaluj skille globalnie — raz, na poziomie konta, żeby były dostępne we wszystkich projektach. Potem edytuj pojedynczy plik .md, żeby zmienić warstwę: na przykład zamień AI SDK z OpenRouterem na Claude Agent SDK.
Na co uważać: Nie edytuj plików ręcznie na oślep — poproś agenta o modyfikację i sprawdź, czy reguły nadal są ze sobą spójne. Sprzeczne pliki referencyjne dają nieprzewidywalne wyniki.
3.Rozdziel budowę, przegląd i wdrożenie na osobne sesje
Na czym polega: Autor prowadzi trzy oddzielne sesje agenta: Start an App, Review an App, Deploy an App — i każdą nazywa odpowiednio.
Jak stosować: Zamknij sesję budowania, zanim uruchomisz przegląd. Nazwij sesje, żeby po tygodniach móc wrócić do konkretnego etapu i zobaczyć, jakie decyzje zapadły.
Na co uważać: Między start a review przetestuj aplikację samodzielnie. Skill przeglądowy szuka dryfu i podatności, a nie tego, czy produkt robi to, czego chcesz.
4.Strony prawne i „danger zone” to wymóg, nie ozdobnik
Na czym polega: Polityka cookies, regulamin, polityka prywatności, pobranie własnych danych i usunięcie konta — agent nie doda tego z siebie, a przy sprzedawanym oprogramowaniu bywa to obowiązkowe.
Jak stosować: Wpisz te elementy do stałych wymagań projektu, tak jak logowanie czy bazę danych. Podaj agentowi nazwę firmy, żeby podmienił symbole zastępcze w dokumentach.
Na co uważać: Wygenerowane dokumenty prawne to szablony, nie porada prawna. Przy realnym produkcie sprawdź je z prawnikiem — zwłaszcza pod kątem RODO, jeśli działasz w UE.
5.Wystaw aplikację asystentom AI przez serwer MCP
Na czym polega: Skill tworzy zdalny serwer MCP, dzięki czemu Claude, ChatGPT czy inny asystent może czytać i modyfikować dane w aplikacji w imieniu zalogowanego użytkownika.
Jak stosować: Traktuj MCP jako część produktu, nie dodatek — udokumentuj podłączenie na publicznej stronie pomocy i daj użytkownikowi ekran „connected apps” z możliwością odebrania dostępu.
Na co uważać: Serwer MCP nie zadziała na tymczasowej domenie Vercela — potrzebna jest prawdziwa domena. Autor stracił na debugowaniu tego sporo czasu.
6.Bezpieczeństwo MCP opiera się na uwierzytelnieniu i zgodach
Na czym polega: Agent musi się uwierzytelnić w aplikacji i dostaje dokładnie te uprawnienia, które ma dany użytkownik. Klient pyta o zgodę przed każdym wywołaniem narzędzia.
Jak stosować: Dla każdego udostępnionego narzędzia ustaw tryb: pytaj o zgodę, zawsze zezwalaj albo blokuj. Zapisuj i pokazuj historię aktywności agenta.
Na co uważać: „Zawsze zezwalaj” dla narzędzi zapisujących lub usuwających dane to proszenie się o kłopoty. Zostaw je w trybie z potwierdzeniem.
7.SQLite tylko do zabawy, Postgres do produkcji
Na czym polega: Skill pyta o wybór bazy. SQLite nadaje się do lokalnych, jednorazowych projektów; przy wdrożeniu potrzebujesz Postgresa.
Jak stosować: Jeśli jest choćby cień szansy na wdrożenie, wybierz od razu Postgres. Jeśli już masz SQLite, Deploy an App wykryje to i wygeneruje skrypt migracji.
Na co uważać: Automatyczna migracja to skrypt wygenerowany przez agenta — przejrzyj go i zrób kopię danych, zanim uruchomisz na czymkolwiek, na czym ci zależy.
8.Przegląd: OWASP Top 10 plus SEO i llms.txt
Na czym polega: Review an App szuka dryfu projektu, podatności z listy OWASP Top 10 (nieprawidłowa kontrola dostępu, błędy kryptograficzne, SQL injection) oraz optymalizuje SEO, generując robots.txt, mapę witryny i llms.txt.
Jak stosować: Uruchom przegląd przed każdym wdrożeniem. llms.txt traktuj jako streszczenie aplikacji przeznaczone dla modeli językowych — z najważniejszymi ścieżkami i produktami.
Na co uważać: Automatyczny skan nie zastępuje audytu bezpieczeństwa. Przy aplikacji przetwarzającej płatności lub dane osobowe rozszerz reguły w pliku skilla o własne kontrole.
9.Wymuś system projektowy, zanim agent wymyśli własny
Na czym polega: Bez wskazania systemu projektowego agent wygeneruje własny, nijaki design. Autor kopiuje gotowy system ze styles.refero.design i wkleja go do promptu.
Jak stosować: Wybierz i wklej system projektowy w tej samej sesji, w której startujesz budowę — zanim powstaną pierwsze komponenty.
Na co uważać: System projektowy narzuca też zachowania, nie tylko kolory. Sprawdź, czy skopiowany zestaw pasuje do typu twojej aplikacji, zanim agent rozjedzie na nim cały interfejs.
10.Sprawdź „deployment sheet” i koszty przed kliknięciem OK
Na czym polega: Przed wdrożeniem skill pokazuje podsumowanie decyzji i szacowane koszty. W demie wszystko mieściło się w darmowym planie hobby Vercela — łącznie z bazą Neon i hostingiem.
Jak stosować: Czytaj tę stronę uważnie, zamiast odruchowo zatwierdzać. To ostatni moment, żeby wyłapać usługę, której nie planowałeś, albo pomyłkę w konfiguracji.
Na co uważać: Darmowy plan ma limity, a demo było proste. Przy realnym ruchu, blob storage i zadaniach w tle koszty rosną — nie traktuj „zero złotych” z dema jako obietnicy dla twojego projektu.