Zanim w ogóle otworzysz agenta AI
Największy błąd na starcie to wejście do narzędzia typu Claude Code z pustymi rękoma i liczenie, że sam prompt załatwi sprawę. Zanim napiszesz cokolwiek do agenta, warto otworzyć zwykły plik tekstowy i wypisać w punktach: do kogo strona jest skierowana, jakie sekcje mają się na niej znaleźć, co ma się dziać po wejściu na stronę. Nie chodzi o gotowy brief marketingowy, tylko o zrzut myśli własnymi słowami. Dopiero z takim plikiem w ręku warto zaczynać rozmowę z agentem, bo inaczej model ma tendencję do spłaszczania pomysłów do ogólników, których sam się domyślił.
Ten sam efekt daje ręczny szkic na kartce papieru, sfotografowany i dołączony do rozmowy. Modele językowe potrafią dziś analizować obraz i wyciągać z niego wnioski o układzie strony, więc odręczny rysunek jednej sekcji bywa skuteczniejszy niż akapit opisu.
Jeśli pracujesz w Claude Code, przydaje się też dodatkowy krok przed pisaniem kodu: włączenie trybu planowania, w którym agent najpierw układa sobie checklistę zadań, zamiast od razu zabierać się do pisania. Wtedy widzisz, co dokładnie zamierza zrobić, zanim to zrobi, a on sam popełnia mniej błędów po drodze. Do tego samego celu służy wtyczka Superpowers, oficjalny plugin dostępny w marketplace Claude Code, która zawiera między innymi tryb brainstormingu: zamiast od razu pisać kod, agent najpierw dopytuje o wymagania i proponuje warianty rozwiązania.
Jak precyzyjnie opisać, czego chcesz
Nazywanie rzeczy po imieniu to najważniejsza pojedyncza rzecz w tej całej liście. Polecenie w stylu „zrób nowoczesną, ładną stronę” bez podanej liczby i nazw sekcji, bez informacji o odbiorcy i celu strony, prowadzi do tego, że agent błądzi, a Ty musisz go co chwilę poprawiać. To kosztuje więcej czasu niż minuta czy dwie poświęcone na precyzyjny opis na starcie.
Skąd wziąć konkretny wzorzec, jeśli sami nie macie jeszcze wyrobionego gustu na strony internetowe? Warto zacząć od stron zbierających inspiracje: katalogów szablonów typu Webflow Templates, gdzie strony da się od razu podejrzeć w przeglądarce, albo bibliotek inspiracji, w których projekty są podzielone tematycznie. Strony nagradzane za design bywają efektowne, ale często mało funkcjonalne, więc lepiej traktować je jako źródło pomysłów niż wzorzec do odtworzenia.
Kiedy już znajdziesz stronę, która Wam się podoba, sam zrzut ekranu to za mało. Skuteczniejsza kombinacja to zrzut całej strony (rozszerzenie do przeglądarki robiące zrzut pełnej długości strony, nie tylko widocznego fragmentu) razem ze skopiowanymi stylami CSS z inspektora przeglądarki (klik prawym na elemencie body, opcja kopiowania stylów). Oba pliki trafiają do agenta razem z jasnym poleceniem: odtwórz układ i styl, ale nie kopiuj tekstu z oryginału. To ważne zastrzeżenie, bo bez niego agent czasem przepisuje też treść ze strony wzorcowej.
Jak sprawdzić, czy agent faktycznie widzi to, co tworzy
Domyślnie agent piszący kod strony działa na ślepo. Nie widzi, że jakiś przycisk jest przysłonięty przez inny element, że coś się nie klika, że layout się rozjeżdża na mniejszym ekranie. Rozwiązaniem jest połączenie agenta z żywą przeglądarką przez Chrome DevTools MCP, oficjalny serwer MCP wydany przez zespół Chrome. Dzięki niemu agent może otworzyć własną instancję przeglądarki, przejść po stronie, zrobić sobie zrzut ekranu i porównać go z tym, co miał osiągnąć.
Sama instalacja nie wystarczy. Warto wprost polecić agentowi, żeby sam robił sobie zrzuty ekranu i oceniał, czy efekt pasuje do wzorca, zamiast zakładać, że skoro kod się kompiluje, to strona wygląda dobrze. To jedna z najbardziej praktycznych różnic między stroną „napisaną na ślepo” a taką, która faktycznie została sprawdzona wizualnie przed oddaniem.
Skąd brać gotowe komponenty, a nie budować wszystkiego od zera
Do rozbudowy strony o konkretne elementy (przyciski, cenniki, sekcje ze zdjęciami, formularze) przydają się biblioteki gotowych komponentów, takie jak 21st.dev, gdzie można podejrzeć kod i demo danego elementu, a potem po prostu powiedzieć agentowi „to mi się podoba, zrób coś takiego”. Tego typu bibliotek jest bardzo dużo, więc łatwo się w nich zgubić. Sensowniejsze jest wybranie dwóch, trzech sekcji na jedną stronę i skupienie się na tym, żeby strona faktycznie działała, niż zbieranie efektownych elementów ze wszystkich zakątków internetu. Więcej ozdobników zwykle oznacza gorszą czytelność dla użytkownika, nie lepszą.
Jedno źródło prawdy: plik ze stylem
Kiedy strona ma już pierwszą sensowną wersję, warto poprosić agenta o osobny plik, na przykład style-guide.html, w którym zbierze wszystkie zasady projektowe: kolory, czcionki, odstępy, promienie zaokrągleń, cienie. Taki plik pełni funkcję jedynego źródła prawdy o wyglądzie strony. Przy każdej kolejnej sekcji czy podstronie agent odwołuje się do niego zamiast zgadywać styl na nowo, a Wy nie musicie za każdym razem opisywać tego samego od zera.
Eksperymentowanie bez bałaganu w głównym projekcie
Testowanie kilku wariantów tej samej sekcji bezpośrednio w głównym projekcie szybko robi bałagan w plikach. Lepiej przenieść tę fazę do osobnego narzędzia do projektowania wizualnego (np. Claude Design), załączając wcześniej przygotowany plik ze stylem jako punkt odniesienia. Można wtedy poprosić o kilka całkowicie różnych wariacji tej samej sekcji, zachowujących spójność ze stylem strony, porównać je i dopiero zwycięski wariant przenieść z powrotem do głównego projektu.
Hosting: od repozytorium do własnej domeny
Warto założyć konto na GitHubie i połączyć je z narzędziem, w którym pracujecie nad stroną, żeby całość trafiała do jednego repozytorium. Dzięki temu stronę można potem hostować bezpośrednio z tego repozytorium, bez ręcznego wgrywania plików za każdym razem. Wiele hostingów oferuje dziś integrację z Git: łączysz repozytorium z panelem hostingu, wskazujesz gałąź (zwykle main), a każda zmiana wypchnięta na GitHub trafia po chwili na żywą stronę pod Waszą domeną. To wygodne również wtedy, gdy nie korzystacie z żadnego konkretnego hostingu, bo repozytorium samo w sobie ułatwia dzielenie się projektem i pracę z innego komputera.
Formularze i analityka bez pisania backendu
Do zbierania zgłoszeń z formularza kontaktowego nie trzeba stawiać własnego serwera. Web3Forms to darmowa usługa wysyłająca zgłoszenia z formularza HTML prosto na maila, bez kodu po stronie serwera. Plan darmowy obejmuje 250 zgłoszeń miesięcznie, co w większości przypadków startowych wystarcza, a konfiguracja sprowadza się do wklejenia jednego klucza w formularzu. Do bardziej rozbudowanych automatyzacji mailowych (np. zapis do newslettera) przydaje się połączenie agenta z MCP konkretnego dostawcy automatyzacji mailowej, takiego jak MailerLite. Sama treść maila i tak trzeba napisać samodzielnie, ale konfigurację automatyzacji można oddelegować.
Do podstawowej analityki ruchu dobrze sprawdza się Umami: prosta, przejrzysta i skupiona na najważniejszych wskaźnikach, bez nadmiaru danych, których nikt i tak nie przegląda. Warto przy okazji poprosić agenta, żeby przed wdrożeniem wypisał w tabeli, co dokładnie chce śledzić, i dopiero po Waszej akceptacji dodawał odpowiednie znaczniki na stronie. To prostszy sposób na uniknięcie sytuacji, w której na stronie ląduje śledzenie dziesiątek zdarzeń, z których nikt potem nie korzysta.
Jak pracować z agentem, żeby nie spalić budżetu
Agent zapamiętuje kontekst tylko w ramach jednej rozmowy, więc wnioski wyciągnięte podczas pracy nad projektem warto regularnie zapisywać w pliku, który wczytuje się przy każdej kolejnej wiadomości (w Claude Code to plik CLAUDE.md). Dobra praktyka to poproszenie agenta, żeby na koniec dłuższej sesji podsumował, czego się nauczył i jak dotrzeć do podobnego efektu szybciej następnym razem, a potem dodał to w skróconej formie do tego pliku. Plik warto trzymać krótki, orientacyjnie do 200 linijek, żeby faktycznie był czytany, a nie tylko rósł. Jeśli coś ma formę powtarzalnego procesu czy checklisty (na przykład testowanie strony krok po kroku), lepiej ubrać to w osobny skill niż dokładać do CLAUDE.md, bo skille lepiej radzą sobie z procesami do odhaczania.
Osobna sprawa to praca w pętli, na przykład polecenie terminalowe /goal w Claude Code, które pozwala zapętlić agenta wokół jednego celu. Tu kluczowe jest podanie celu mierzalnego, a nie ocennego. „Popraw tę stronę, dopóki nie będzie ładna” zmusza agenta, żeby sam zdecydował, co to znaczy „ładna”, co zwykle kończy się niepotrzebnym zużyciem tokenów i efektem, który niekoniecznie odpowiada Waszym oczekiwaniom. „Iteruj stronę, dopóki wynik testu szybkości Lighthouse nie osiągnie konkretnej wartości” to cel, który agent może faktycznie zweryfikować sam, bez zgadywania.
Agent, którego zadaniem jest złamać Waszą stronę
Ostatni element, który rzadko pojawia się w podstawowych poradnikach: osobny subagent, którego jedynym zadaniem jest regularne testowanie strony pod kątem tego, co może pójść nie tak. Wypełnianie formularza w nietypowy sposób, zmniejszanie okna przeglądarki, klikanie w nieoczywistej kolejności. W Claude Code taki subagent trafia do folderu .claude/agents i można go wywoływać ręcznie po każdej większej zmianie, a docelowo nawet zautomatyzować jego uruchamianie co kilka commitów. Warto też ustawić go na tańszym modelu, żeby regularne stres-testy nie generowały niepotrzebnych kosztów.
Narzędzia z tego procesu w skrócie
| Narzędzie | Do czego służy | Koszt |
|---|---|---|
| Plik tekstowy / notatnik | Spisanie założeń przed rozpoczęciem pracy z agentem | Bezpłatnie |
| Superpowers (plugin Claude Code) | Brainstorming i tryb planowania przed pisaniem kodu | Bezpłatnie |
| Webflow Templates, biblioteki inspiracji | Wzorce wizualne do pokazania agentowi | Bezpłatnie / płatne szablony |
| Chrome DevTools MCP | Agent widzi i testuje stronę w prawdziwej przeglądarce | Bezpłatnie, open source |
| 21st.dev i podobne biblioteki | Gotowe komponenty do rozbudowy strony | Zależnie od komponentu |
| Claude Design | Testowanie wariantów bez bałaganu w głównym projekcie | W ramach planu Claude |
| GitHub + hosting z integracją Git | Wdrażanie zmian na żywą stronę bez ręcznego wgrywania plików | Zależnie od hostingu |
| Web3Forms | Formularz kontaktowy bez backendu | Bezpłatnie do 250 zgłoszeń/mies. |
| Umami | Prosta, przejrzysta analityka ruchu | Zależnie od wdrożenia |
| CLAUDE.md / skille | Zapamiętywanie wniosków między sesjami z agentem | Bezpłatnie |
| Subagent testujący | Regularne stres-testy strony | Koszt zapytań do modelu |
Materiał powstał na podstawie filmu Mikołaja Abramczuka „19 Nieoczywistych Sposobów Na Świetne Strony z AI” oraz weryfikacji opisanych w nim narzędzi.
FAQ
Czy do zbudowania strony z AI trzeba umieć programować?
Nie w takim stopniu jak przy klasycznym pisaniu strony od zera, ale warto rozumieć, o co prosisz agenta i umieć ocenić efekt. Największa różnica między dobrą a słabą stroną zbudowaną z AI nie leży w umiejętności pisania kodu, tylko w jakości opisu, referencji wizualnych i tego, czy ktoś w ogóle sprawdza efekt zanim trafi on na żywo.
Ile realnie kosztuje utrzymanie takiej strony?
Sam hosting, formularz kontaktowy i podstawowa analityka da się dziś złożyć praktycznie za darmo lub za symboliczne kwoty, przynajmniej dopóki ruch na stronie jest niewielki. Kosztem, który realnie rośnie, są zapytania do modelu przy dłuższej pracy nad projektem i przy regularnym uruchamianiu agenta testującego.
Czy strona zbudowana samodzielnie z AI różni się jakością od tej zrobionej przez agencję?
Zależy głównie od tego, czy ktoś stosuje ten proces, a nie od samego narzędzia. Strona zrobiona jednym poleceniem „zrób mi ładną stronę” i strona przygotowana z założeniami, referencjami wizualnymi, style guide’em i testami to dwa różne poziomy, niezależnie od tego, kto siedzi po drugiej stronie klawiatury.
Co jeśli agent źle zrozumie, jak ma wyglądać strona?
Zwykle wynika to z braku konkretów w poleceniu, nie z ograniczeń samego narzędzia. Najczęstszy błąd to opisywanie efektu ogólnikami zamiast wskazania konkretnych sekcji, odbiorców i wzorców wizualnych.
Czy warto zlecić to komuś, kto już ma taki proces poukładany?
To zależy od tego, ile czasu chcecie w to zainwestować i jak bardzo strona ma być dopracowana. Jeśli wolicie mieć ten proces poprowadzony przez kogoś, kto robi to regularnie, napiszcie do nas, chętnie pokażemy, jak wygląda to w praktyce przy konkretnej stronie.