Od zera do
vibe codera
Jak zarządzać projektem software, kiedy nigdy tego nie robiłeś — a Twój „zespół" to agenci AI.
Pisany pod realny projekt higi i Twój setup OpenClaw — nie pod podręcznik z 2010 roku.
Krótka odpowiedź: NIE ucz się Scruma — to przerost formy dla Ciebie. Bierzesz Kanban + dyscyplinę pisemną. Tablica, limit roboty w toku, małe kawałki, dziennik decyzji, przegląd raz w tygodniu.
Pełne uzasadnienie (czym różni się Agile od Scruma od Kanbana i czemu Scrum rozwiązuje problemy, których nie masz) → Moduł 2 ↓
Prawda, której nie powie Ci żaden kurs Agile
Większość książek o zarządzaniu IT zakłada, że masz zespół 5–9 programistów-ludzi, którzy się męczą, chorują, kłócą i potrzebują codziennych spotkań, żeby się zsynchronizować. Ty nie masz takiego zespołu.
Agenci nie potrzebują standupów. Nie mają złych dni. Nie obrażają się. Ale mają jedną słabość, która całkowicie zmienia Twoją robotę jako managera:
Człowiek-programista dopyta, domyśli się, „naprawi po drodze". Agent weźmie Twój niejasny opis i pewnym głosem zbuduje coś obok. Dlatego 80% Twojej pracy jako PM-a to nie zarządzanie ludźmi — to precyzja w opisie zadań i twarda kontrola na bramkach.
To dobra wiadomość. Tego można się nauczyć w miesiąc. Zaczynamy.
Jak w ogóle powstaje software
Mapa, której nikt Ci nie narysował. Wyobraź sobie kod jako tekst książki, który ciągle przepisujecie. Oto droga jednej zmiany od pomysłu do tego, co widzi klient na higi.com.pl:
Rozbijmy to na ludzki język:
| Pojęcie | Po ludzku |
|---|---|
| Repo | Folder z całym kodem + jego pełną historią. higi mieszka w numerika-ai/higi na GitHubie. Każda zmiana kiedykolwiek jest zapisana — nic nie ginie. |
| Branch | Osobny brudnopis. Agent kopiuje projekt na bok, grzebie tam, a główna wersja (main) jest nietknięta. Zepsuje brudnopis? Wyrzucasz brudnopis, nic się nie stało. |
| Commit | Jeden zapisany krok. Jak save w grze. „Dodałem przycisk" — save. „Zmieniłem kolor" — save. Każdy ma opis. |
| Pull Request | Moment, w którym agent mówi: „Skończyłem brudnopis, chcę to wcielić — zobacz i zatwierdź." To jest Twoja bramka. |
| Review | Ty (albo inny agent) oglądasz PR i mówisz „ok" albo „popraw to i to". |
| Merge | Wcielenie brudnopisu do main. Od tej chwili to oficjalna wersja kodu. |
| Deploy | Wysłanie kodu na serwer, żeby klient go zobaczył. UWAGA: merge ≠ deploy. Kod może być w main, a klient dalej widzi stare. O tym cały Moduł 6 — bo to Cię już ugryzło. |
| Prod | To, co widzi prawdziwy klient. Świętość. Tu się nie eksperymentuje. |
● Czemu „ciągłe zmiany, PR-y, update'y" to NIE bałagan — to zdrowie projektu
Boisz się, że jest tego dużo. Odwróć to. Dużo małych PR-ów = projekt, który oddycha. Każda mała zmiana jest łatwa do sprawdzenia, łatwa do cofnięcia, niska szansa, że coś wybuchnie. Jeden wielki PR raz na miesiąc to tykająca bomba — nikt nie ogarnia, co się w nim dzieje, a jak coś pęknie, nie wiadomo gdzie. Twoim celem jest robić zmiany MAŁE i CZĘSTE, nie rzadkie i wielkie.
Słownik vibe codera (bez ściemy)
Nie musisz umieć kodować. Musisz rozumieć te słowa — zobaczysz je codziennie w GitHubie i w rozmowie z agentami. Terminy zostawiam po angielsku, bo właśnie tak je zobaczysz na ekranie.
| Termin | Po ludzku | Czemu Cię to obchodzi jako PM |
|---|---|---|
repo | folder z kodem + historią | to jest „projekt" w sensie technicznym |
main | główna, oficjalna wersja kodu | nigdy nie pozwól pisać wprost do main |
branch | osobny brudnopis | jedno zadanie = jeden branch |
commit | zapisany krok ze swoim opisem | po opisach commitów czytasz, co się działo |
PR | prośba „wcielmy mój brudnopis" | Twoja bramka kontroli |
review | ocena PR-a przed wcieleniem | tu mówisz „ok" lub „popraw" |
merge | wcielenie brudnopisu do main | po tym zmiana jest oficjalna |
conflict | dwie zmiany dotknęły tej samej linijki | normalne, agent to rozwiązuje — Ty tylko wiesz, że to nie awaria |
deploy | wysyłka kodu na serwer do klienta | merge ≠ deploy, pamiętaj |
prod / dev | wersja dla klienta / wersja do testów | zmiany lecą NAJPIERW na dev |
rollback | cofnięcie deploya do poprzedniej wersji | Twoja poduszka bezpieczeństwa, gdy prod się wywali |
issue | zapisane zadanie / błąd do zrobienia | tu opisujesz CO ma się stać |
CI | robot, co automatycznie sprawdza kod przy PR | w higi CI jest martwe → sprawdzamy ręcznie |
scope | granice jednego zadania | Twoja najważniejsza broń — patrz Moduł 4 |
regression | „działało, a teraz przestało" | najgorszy typ błędu — dlatego testujemy przed deployem |
Tyle wystarczy na start. Resztę słownika złapiesz w boju.
Agile, Scrum, Kanban — co wybrać
Pytałeś wprost: uczyć się Agile czy czegoś innego. Szczera odpowiedź — i nie chcę, żebyś mi wierzył na słowo, więc wyjaśniam każde z trzech:
Agile
Nie metoda — filozofia. Z czterech zasad liczą się dla Ciebie dwie: dowoź małe kawałki często i reaguj na zmianę zamiast trzymać się sztywnego planu. To ma sens i to bierzesz.
Scrum
Ciężki rytuał Agile: sprinty 2-tygodniowe, codzienny standup, story pointy, planning, retro, Scrum Master. Cały Scrum istnieje, by zsynchronizować zespół ludzi i przewidzieć ile zrobią. Ty nie masz takiego zespołu. Scrum rozwiązuje problemy, których nie masz.
Kanban
Najprostsza rzecz na świecie: tablica Do zrobienia → W trakcie → Review → Zrobione, karteczki przesuwasz w prawo. Jedna żelazna zasada: limit roboty w toku (WIP limit) — nie rób 5 rzeczy naraz, skup się na 1–2 i dowoź do końca.
Twoja metoda = Kanban + dyscyplina pisemna. Nie Scrum.
Żadnych story pointów, żadnych standupów z samym sobą, żadnego Scrum Mastera. Jak ktoś każe Ci robić sprinty z agentami AI — nie słuchaj go, nie rozumie czym się zajmujesz.
● Pięć rzeczy, które kradniesz z Agile/Kanban i wdrażasz od jutra
- Tablica Kanban — masz ją: Plane PM (self-hosted na Loco39). Albo wprost GitHub Issues. Każde zadanie to karta, którą przesuwasz przez kolumny. Patrzysz na tablicę = wiesz, co się dzieje.
- WIP limit — maksymalnie 1–2 rzeczy „w trakcie" naraz. Reszta czeka w kolejce. To Cię uchroni przed chaosem „wszystko zaczęte, nic skończone".
- Małe kawałki — żadne zadanie nie powinno trwać dłużej niż „jeden PR, który ogarniesz w jednym przeglądzie". Duże dziel na mniejsze.
- Dziennik decyzji — Twój najważniejszy artefakt (Moduł 3).
- Cotygodniowy przegląd — 30 minut w piątek: co dowiozłem, co dalej, co wyrzucam z kolejki.
Twój system — jak to wygląda u Ciebie
Masz już realny system. Większość ludzi z Twoim pytaniem nie ma żadnego — Ty masz, tylko nie wiesz, że to „PM stack".
● Twoje narzędzia
- GitHub (
numerika-ai/higi) — tu mieszka kod, PR-y i issues. Serce projektu. - Plane PM (na Loco39) — Twoja tablica Kanban, planowanie, przypisania.
- OpenClaw — przez to gadasz z agentami i delegujesz zadania.
- Cloudflare Pages — tu mieszka żywy
higi.com.pl.
● Hierarchia źródeł prawdy (to jest GENIALNE i już to masz)
Gdy dokumenty się kłócą — a będą — musisz wiedzieć, który wygrywa. higi ma to zapisane wprost:
1. WORK-PLAN-*.md ← kolejność budowy, podział Claude/Codex (najwyższy) 2. DECISIONS.md ← dziennik decyzji (D-18, D-19, D-20, D-21) 3. SESSION-HANDOFF-*.md ← najnowszy stan sesji (nowszy bije starszy) 4. PROJECT-SPEC.md ← oryginalna specyfikacja (miejscami nieaktualna) 5. ARCHITECTURE.md, README ← reszta (najniższy)
● Dziennik decyzji — Twój najważniejszy artefakt
DECISIONS.md to nie formalność. To dokument, który ratuje Ci tyłek za 3 miesiące, kiedy zapomnisz, dlaczego coś jest tak a nie inaczej. Realne wpisy z Twojego projektu:
| D-18 | MVP bez Stripe (płatność = promo + ręczny dostęp) |
| D-19 | silnik v7 jest produktem, nie przepisujemy na React |
| D-21 | kanały dev/prod na jednej domenie |
● Granice własności (kto czego dotyka)
| Obszar | Właściciel |
|---|---|
Frontend (apps/web/**) | Claude |
Backend (apps/workers/**) | Codex |
Wspólny kontrakt (shared-types) | OBAJ — osobny PR, zatwierdza druga strona, mergujemy pierwszy |
| Sekrety, DNS, Clerk, „promuj na prod" | Bartosz (Ty) — poza repo |
Jasne granice = brak sytuacji „dwóch agentów dotknęło tej samej rzeczy i się pobili". Twoja robota PM-a: pilnować, żeby każdy orał swoją działkę.
Issues — jak opisać zadanie, żeby agent zrobił to dobrze za pierwszym razem
To rdzeń umiejętności vibe codera. Jeśli opanujesz tylko ten moduł — jesteś w top 10% ludzi sterujących agentami. Spec to Twoja kierownica. Niejasny spec = agent jedzie w krzaki pewnym głosem.
● Anatomia dobrego issue
Dobry opis ma pięć części:
## Kontekst Na /dev po zalogowaniu przez Clerk user czasem widzi biały ekran zamiast aplikacji. Dzieje się to po odświeżeniu strony (F5), nie przy pierwszym wejściu. ## Cel Po odświeżeniu zalogowany user ma widzieć aplikację, nie biały ekran. ## Zakres W zakresie: logika DevGate + przekierowanie po zalogowaniu (apps/web/src/features/auth/) POZA zakresem: nie ruszaj wyglądu, nie ruszaj prod (/), nie dotykaj backendu ## Kryteria akceptacji (jak poznam, że zrobione) - [ ] F5 na zalogowanej sesji → aplikacja, nie biały ekran - [ ] niezalogowany user dalej trafia na bramkę logowania - [ ] działa na /dev (prod / zostaje nietknięty) ## Ograniczenia - zmiana tylko na /dev (zasada: nowe FE idzie na /dev) - pokaż mi screenshot/nagranie że działa, zanim zmergujesz
| Pole | Pytanie, na które MUSI odpowiadać |
|---|---|
| Kontekst | co się dzieje teraz, gdzie, kiedy? |
| Cel | jaki stan końcowy chcesz? |
| Zakres | co JEST i co NIE JEST do ruszenia? (najważniejsze pole) |
| Kryteria akceptacji | jak konkretnie poznasz, że zrobione? (checklisty) |
| Ograniczenia | czego nie wolno, jakie zasady obowiązują? |
● Sekret nr 1: pole „POZA zakresem" jest ważniejsze niż „w zakresie"
Agenci (i programiści) mają naturalną tendencję do „przy okazji poprawię też to". To się nazywa scope creep i to zabójca projektów. Jedno zadanie puchnie, robi się nie do sprawdzenia, dotyka 8 rzeczy naraz. Pisząc wprost CZEGO agent NIE ma ruszać, zamykasz mu furtkę do rozlewania się. To jedna linijka, która oszczędza Ci godziny.
● Sekret nr 2: jak coś jest duże — podziel
Jeśli nie potrafisz opisać zadania w jednym ekranie, jest za duże. Podziel na 2–3 mniejsze issues, każde z własnym PR-em. Mniejsze + jaśniejsze zawsze wygrywa z większym + ogólnym. Zawsze.
Review PR-a — jak oceniać zmianę, gdy nie jesteś programistą
Tu się boisz najbardziej i niepotrzebnie. Nie musisz czytać kodu, żeby dobrze zrobić review. Musisz sprawdzić właściwe rzeczy i zadać właściwe pytania. To Twoja bramka — najważniejszy moment kontroli w całym procesie.
Agent otwiera PR. GitHub pokazuje: opis zmiany, listę plików, „diff" (zielone = dodane, czerwone = usunięte). Ty patrzysz i decydujesz: wcielamy czy poprawiamy.
● Checklista review dla nie-programisty (przejdź ją za każdym razem)
tsc -b && vite build green)● Pytania, które zadajesz agentowi przy review (działają zawsze)
- „Co dokładnie ten PR zmienia z punktu widzenia użytkownika?" — jeśli nie umie powiedzieć prosto, to znak ostrzegawczy.
- „Co może się przez to zepsuć? Co testowałeś?" — zmusza do myślenia o regresji.
- „Czy to wykracza poza zakres issue? Jeśli tak — czemu?"
- „Pokaż mi, że działa." — dowód, nie deklaracja.
W higi masz to zapisane wprost jako zasadę: żadna zmiana frontu nie idzie na prod (/) bez Twojego wyraźnego „promuj". Agent może zrobić wszystko inne — ale przejście na produkcję to Twoja decyzja i Twoje słowo. Trzymaj tę bramkę zębami.
Deploy i release — miejsce, gdzie projekty umierają
Najważniejszy moduł praktyczny — bo to dokładnie to, co Cię już raz boleśnie kopnęło.
● Trzy stany, które MUSISZ rozróżniać
● Twoje kanały (już je masz — D-21)
| URL | Co to | Zasada |
|---|---|---|
higi.com.pl/ | PROD — żywy klient | zamrożony, zmiany TYLKO na wyraźne „promuj" |
higi.com.pl/dev | DEV — testy za bramką | tu lecą wszystkie nowe zmiany frontu najpierw |
Żelazna zasada: wszystkie nowe zmiany frontu idą NAJPIERW na /dev. Na prod (/) tylko gdy Ty powiesz „promuj". Raz poszły zmiany prosto na prod (sprint #16/#17) — to był wyjątek, nie wzorzec.
● Rytuał deploya (każdy, za każdym razem)
- BACKUP — masz kopię poprzedniej wersji? (w higi:
/home/tank/higi-prod-backups/) - PREFLIGHT — sprawdzenie przed wysyłką (czy klucze są w buildzie, czy build zielony)
- DEPLOY — faktyczna wysyłka na serwer
- VERIFY — WEJDŹ NA STRONĘ i zobacz, że zmiana jest. Na własne oczy.
- MONITOR — popatrz chwilę, czy nic się nie sypie
● Rollback — Twoja poduszka bezpieczeństwa
Gdy prod się wywali po deployu, NIE panikujesz i NIE próbujesz „szybko naprawić na żywo". Robisz rollback — cofasz do poprzedniej działającej wersji jednym kliknięciem (w higi: CF Dashboard → Pages → higi → Deployments → wybierz poprzedni → „Rollback"). Klient wraca do działającej strony w sekundy, a Ty na spokojnie szukasz, co poszło nie tak. Rollback to nie wstyd, to profesjonalizm.
tsc -b && vite build ręcznie przed mergem). Twoja rola PM: pytaj „czy sprawdziłeś, skoro CI nie działa?" — bo nie ma automatu, który złapie błąd za Ciebie.Rytm pracy — jak wygląda Twój dzień i tydzień
Nie musisz siedzieć w tym 8h. Vibe coding PM to praca „sterowania", nie „produkcji".
Triage & sterowanie
- Triage — zerknij na tablicę: co się ruszyło, co czeka na Twoją decyzję/review
- Odblokuj — agenci stoją, póki nie odpowiesz. Ty jesteś najczęstszym wąskim gardłem (to normalne — bramka to Ty)
- Review — jeśli są PR-y, przejdź checklistę z Modułu 5
- Steruj — nowe zadanie? napisz porządne issue (Moduł 4) i wrzuć agentowi
Przegląd
- Co dowiozłem — co realnie wylądowało na prodzie (nie „co zaczęte" — co ZDEPLOYOWANE)
- Co dalej — wybierz 1–3 rzeczy na przyszły tydzień. Trzymaj WIP limit
- Przytnij kolejkę — wyrzuć z backlogu rzeczy nieważne. Backlog to lista priorytetów, nie śmietnik
- Zapisz decyzje — coś zdecydowałeś? → wpis do DECISIONS.md
To wszystko. Reszta czasu to życie.
Pułapki (prawdziwe — część już Cię dotknęła)
Lista rzeczy, które zabijają projekty software. Każda kiedyś kogoś (czasem Ciebie) ugryzła. Znając je, omijasz z daleka.
| Pułapka | Jak wygląda | Antidotum |
|---|---|---|
| Wielki PR | jeden ogromny PR na 40 plików, nikt nie ogarnia | tnij na małe, częste PR-y |
| Niejasny spec | „popraw logowanie" → agent zgaduje → robi nie to | Moduł 4, pięć pól, „poza zakresem" |
| Pominięte review | „agent mądry, na pewno ok" → bug na prodzie | checklista z Modułu 5, ZAWSZE |
| Prosto na prod | zmiana omija /dev, ląduje od razu u klienta | wszystko najpierw na /dev, prod tylko na „promuj" |
| „Build się zbudował" = „gotowe" | kod gotowy, ale deploy nie wykonany (Twój incydent 20.05) | „done" = zdeployowane I sprawdzone na oczy |
| Brak dziennika decyzji | za miesiąc debatujecie od zera rzecz raz ustaloną | DECISIONS.md, wpis za każdą decyzją „dlaczego" |
| Scope creep | „przy okazji poprawię też to" → zadanie puchnie | pole „POZA zakresem" w każdym issue |
| Sekret w czacie/repo | klucz API wklejony do rozmowy albo kodu | sekrety NIGDY do czatu/repo — osobny kanał (folder Drive / pliki) |
| Wszystko naraz | 6 zadań „w trakcie", nic skończone | WIP limit 1–2, dowoź do końca |
| Zmiana na prodzie bez planu | „szybko coś poprawię na żywo" → 273 restarty w pętli | backup → zmiana → test → monitor; nigdy na żywo na pałę |
Plan nauki — 30 dni od zera
Nie ucz się teorii. Ucz się na swoim żywym projekcie. Oto rampa:
Oswojenie
- Przeczytaj tę stronę jeszcze raz, na spokojnie
- GitHub
numerika-ai/higi→ Pull requests → otwórz 3 zamknięte PR-y, popatrz: opis, diff, dyskusja - Issues → przeczytaj 5, zobacz które dobre, które słabe
Pisanie zadań
- Napisz 3 issues wg szablonu z Modułu 4 (pięć pól, „poza zakresem"). Mogą być drobne
- Wrzuć agentom. Obserwuj: czy zrobili dokładnie to? Jeśli nie — wróć do swojego opisu
- To pętla nauki: niejasny wynik = niejasny był spec
Bramka
- Przejdź review 3 PR-ów SAM, z checklistą z Modułu 5 w ręku
- Raz świadomie powiedz „popraw to" i zobacz, jak agent poprawia
- Poczuj, że bramka jest Twoja
Pełny cykl
- Przeprowadź jedną zmianę od początku do końca sam jako PM:
- issue → branch+PR → review → „ok" → merge → deploy /dev → sprawdź na oczy → „promuj" → prod → sprawdź
- Jak zrobisz to raz świadomie — reszta to powtórka
Po 30 dniach jesteś sprawnym PM-em vibe codingu. Nie programistą — i nie musisz nim być. Architektem intencji i strażnikiem bramki.
Wszystko na jedną stronę
Wydrukuj (Ctrl+P), przypnij nad biurkiem albo trzymaj w zakładce. Cały kurs w jednym oddechu.
═══ VIBE CODER PM — ŚCIĄGA ═══
- JASNY SPEC — issue: kontekst, cel, ZAKRES, kryteria, ograniczenia
- TWARDA BRAMKA — review: zgodność z issue? dowód? dotyka prod?
- DYSCYPLINA DEPLOYA — „done" = zdeployowane I sprawdzone na oczy
- Mały zakres + jasny opis + twarda bramka = projekt dowozi
- Pole „POZA zakresem" ważniejsze niż „w zakresie"
- merge ≠ deploy ≠ „klient widzi"
- Wszystko najpierw na /dev. Prod TYLKO na Twoje „promuj"
- Kod mówi CO. Dziennik decyzji mówi DLACZEGO — zapisuj decyzje
- WIP limit 1–2. Dowoź do końca, nie zaczynaj 6 rzeczy
- Sekrety NIGDY do czatu/repo
- Na prodzie nic „na szybko": backup → zmiana → test → monitor
- Rollback to profesjonalizm, nie wstyd
- Kanban (tablica + WIP limit), NIE Scrum. Bez story pointów, bez standupów. Masz Plane PM + GitHub Issues.
- „Co to zmienia dla użytkownika?"
- „Co może się zepsuć? Co testowałeś?"
- „Czy to wykracza poza zakres issue?"
- „Pokaż mi że działa."
Słowo na koniec
Bałeś się, że „od strony projektowej będzie ciężko". Będzie — przez pierwsze dwa tygodnie, póki słownik jest obcy. Potem zaskoczy. Bo prawda jest taka, że już prowadzisz ten projekt — masz źródła prawdy, dziennik decyzji, podział własności, kanały dev/prod, bramkę „promuj". Większość ludzi pytających „jak zacząć" nie ma nic z tego. Ty masz cały system, tylko nie wiedziałeś, że to się nazywa „project management".
Nie musisz umieć pisać kodu. Musisz umieć jasno powiedzieć czego chcesz i twardo trzymać bramkę przed produkcją. Reszta to powtórka tych dziewięciu modułów, aż wejdzie w krew.
🔮 Jak coś będzie niejasne w boju — pytaj na bieżąco. Najlepiej uczysz się na żywym higi, nie z tej strony. To mapa. Teren przejdziesz sam.