Vibecoding · · 6 min czytania
Pierwszy projekt vibecoding: checklist 12 kroków zanim odpalisz Cursor
Zanim wpiszesz pierwszy prompt: repo, kontekst, testy i plan. Dwanaście kroków.
Twój pierwszy projekt w stylu vibecoding zacznie się od najgorszej możliwej decyzji: odpalisz Cursora i napiszesz „zbuduj mi aplikację SaaS do zarządzania zadaniami”. Po 4 godzinach będziesz miał chaos, w którym żaden plik nie chce się skompilować. Niżej checklist 12 kroków, który zrobi z tej samej idei wdrożalny projekt w 2 dni.
1. Zdefiniuj jeden user story
Nie funkcjonalność, nie produkt. Jeden user story w formacie „jako X chcę Y, żeby Z”. Przykład: „jako project manager chcę widzieć wszystkie taski mojego zespołu na jednej tablicy, żeby ocenić, czy zdążymy z deadline”. Tyle. Jeśli masz więcej niż jedno user story, jesteś za wcześnie.
2. Wybierz stack „nudny”
Pierwszy projekt nie jest miejscem na egzotyczne biblioteki. Stack rekomendowany dla vibecodera-debiutanta: Next.js 15 + App Router, TypeScript, Tailwind, shadcn/ui, Drizzle + Postgres (Neon), tRPC, Vercel. Tę kombinację rozumieją wszystkie modele i znajdziesz tysiące przykładów.
3. Załóż repo i zacznij od commita pustego projektu
npx create-next-app@latest, init git, push do GitHub. Pusty projekt = zerowy punkt odniesienia. Każda przyszła zmiana będzie pokazana jako diff od tego pustego stanu.
4. Napisz SPEC.md przed pierwszym promptem
Format minimum: jednym akapitem co, dla kogo, jakie krytyczne ekrany, jakie modele danych. Maksymalnie 400 słów. Zbyt szczegółowy spec też jest błędem – nie da agentowi swobody podpowiedzi. Spec napisz w oczekiwanym jakości stylu – tak będzie wyglądał twój styl „w średnio”.
5. Wybierz IDE i model
Dla początkującego: Cursor (najprostszy UI). Composer w Cursorze, model Sonnet 4.6. Jeśli preferujesz terminal, Claude Code. Trzymaj się jednego narzędzia przez pierwsze 30 dni, potem porównuj.
6. Zlecaj zadania „wielkości kawy”
Każdy prompt powinien być na tyle krótki, żeby implementacja zmieściła się w 15-20 minut, a review w 10 minut. Jeśli Cursor pisze 40 minut bez przerwy, twoje zadanie było za duże – podziel.
7. Commituj co krok
Nawet jeśli to brzydkie commity. Po każdej zielonej zmianie: git add, krótki conventional commit, kontynuuj. Po godzinie pracy będziesz miał historię, do której możesz bezpiecznie wrócić. Brak commitów to gwarancja, że za 4 godziny nie wiesz, gdzie się popsuło.
8. Trzymaj listę „rzeczy do zrobienia później” osobno
Pierwsze 2 dni nie poprawiaj stylów, nie wdrażaj a11y, nie pisz testów do każdego komponentu. Trzymaj plik TODO.md z listą długu i pchaj user story do działania. Optymalizacja przed działaniem to recepta na pierwsze zniechęcenie.
9. Najpierw wdroż na stage, potem na prod
Vercel preview deploy za każdym PR – otwierasz w przeglądarce i sprawdzasz, czy działa naprawdę. Lokalnie zawsze działa. Na stage czasem nie. Na prodzie to już problem twojego użytkownika.
10. Wprowadź jedną metrykę sukcesu
Coś, co możesz zmierzyć po wdrożeniu. „3 osoby z mojego zespołu używają tablicy 5 razy w tygodniu” to dobra metryka. „Aplikacja wygląda ładnie” to nie.
11. Otwórz issue na każdą rzecz, której nie chcesz robić teraz
Issue tracker (GitHub Issues wystarczy) zamiast inboxu w głowie. Każdy pomysł, każdy bug, każdy „ej, fajnie by było” ląduje jako issue z labelem. Wieczorem 5 minut grupowania – widzisz, co naprawdę powinieneś zrobić jutro.
12. Zaplanuj retro po 7 dniach
Po tygodniu siadasz, czytasz git log, sprawdzasz metrykę sukcesu, czytaszTODO.md. Trzy pytania: co działa? co spowalnia? co odpuścić? To 30 minut, które ratuje projekt z „to jest tylko prototyp” do „to jest produkt”.
Bonus: nie buduj klona Twittera
„Klon Twittera” jako pierwszy projekt wygląda jak dobry pomysł, bo Twitter „ma proste fichi”. Nie ma. Ma autoryzację, infinite scroll, real-time, search, ranking. Jako pierwszy projekt zbuduj coś, czego sam użyjesz w przyszłym tygodniu. „Trackery moich nawyków”, „notatnik z tagami”, „dashboard moich finansów”. Małe, twoje, używane.
TL;DR
Pierwszy projekt vibecoding udaje się, kiedy zaczynasz od specu, jednego user story i nudnego stacka. Commituj co krok, optymalizuj na końcu, mierz sukces po użytkownikach. Klona Twittera zostaw na piąty projekt.