Podstawowe metodologie programowania

Dwóch developerów dostaje tego samego asystenta AI i ten sam ticket: „dodaj zaproszenia do zespołu w panelu”. Jeden wkleja ticket, akceptuje diff na 400 linii i spędza popołudnie na debugowaniu, dlaczego zaproszenia po cichu zawodzą dla istniejących użytkowników. Drugi dowozi to w godzinę, z przechodzącymi testami i czystym diffem. Ten sam model, to samo zadanie. Różnicą jest metodologia, a nie prompting.

Proces, w którym te metodologie siedzą, to AI-native SDLC: sześć etapów w pętli, każdy commituje artefakt, który czyta następny etap. Ta sekcja to zestawy zagrań wewnątrz tych etapów — nie konkurencyjne ramy. I nie są teoretyczne: to wzorce wyodrębnione z zespołów dostarczających produkcyjny kod z Cursor, Claude Code i Codex, zarówno w startupach, jak i w korporacjach.

Dlaczego metodologia ma znaczenie w pracy z AI

Asystenci kodowania AI są probabilistyczni. Generują prawdopodobny kod, a nie dowodliwie poprawny. Bez ustrukturyzowanego podejścia kończysz w pętli: generujesz, zauważasz błąd, generujesz ponownie, wprowadzasz nowy błąd, generujesz jeszcze raz. Każdy cykl spala tokeny, czas i zaufanie.

Dobra metodologia daje ci trzy rzeczy:

• Przewidywalność. Wiesz, co AI zrobi dalej, bo sam mu powiedziałeś, co ma robić.
• Punkty kontrolne weryfikacji. Możesz wychwycić problemy na każdym etapie, zamiast debugować splątany chaos na końcu.
• Efektywność kontekstu. Ustrukturyzowane przepływy pracy utrzymują twoje prompty skupione, co oznacza, że AI działa lepiej w ramach swojego okna kontekstowego.

Kontekst to największa dźwignia jakości outputu

Zanim jakakolwiek metodologia pomoże, AI potrzebuje właściwych wejść. Dwa z nich wykonują większość roboty.

Precyzyjne wzmianki przez @. Odwołuj się do dokładnych plików i symboli, których dotyczy zadanie, zamiast pozwalać AI zgadywać. Dla powyższej funkcji zaproszeń: @src/db/schema.ts @app/api/teams/route.ts. Wskazanie schematu i trasy jest warte więcej niż dziesięć zdań opisu.

Trwały plik z zasadami. Zakoduj swój stack i konwencje raz, żeby nie powtarzać ich w każdym prompcie. Krótki CLAUDE.md (czytany również przez Codex) lub plik .cursor/rules/*.mdc w stylu:

- DB access goes through Drizzle in src/db; never write raw SQL in route handlers.
- API routes return typed JSON via the `apiResponse()` helper in lib/api.ts.
- All new tables need a migration in drizzle/ and a matching zod schema.

Uwaga

Więcej kontekstu nie zawsze znaczy lepiej. Zalewanie modelu dziesiątkami nieistotnych plików rozprasza uwagę i zaprasza pewne siebie, błędne odpowiedzi. Wyselekcjonuj zwięzły zestaw plików, które naprawdę mają znaczenie dla danego zadania.

Planuj, wykonuj, weryfikuj: pętla, na której stoi każda metodologia

Niezawodny wzorzec to trzy fazy z ludzkim punktem kontrolnym między każdą z nich. Oto on, zastosowany do dodawania zaproszeń do zespołu w aplikacji Next.js + Drizzle.

1. Najpierw planuj (tylko do odczytu). Pracuj w trybie tylko do odczytu, żeby AI proponowało, nie edytując. Każ mu stworzyć plan TODO, który wymienia pliki dotykane przez każdy krok.

   Prompt do skopiowania: plan wymieniający dotknięte pliki

   In read-only/plan mode, using `@src/db/schema.ts` and `@app/api/teams/route.ts`: propose a plan to add team invitations (invite by email, pending/accepted states, accept endpoint). Output a numbered TODO where each item names the exact files it changes and the Drizzle migration it needs. List your assumptions about existing-user vs. new-user invites as CONFIRMED or GUESS. Do not write code yet.

2. Wykonuj stopniowo. Przełącz się na tryb wykonania i rób jeden element TODO na raz, przeglądając każdy diff. Praca w małych krokach sprawia, że każda zmiana jest możliwa do przejrzenia.

   Prompt do skopiowania: wykonanie ograniczone do jednego elementu TODO

   Execute TODO item 1 only: add the `invitations` table to `src/db/schema.ts` with a matching zod schema and a Drizzle migration. Do not touch the API routes yet. Show me the migration and stop for review before item 2.

3. Weryfikuj ciągle (TDD). Używaj automatycznych pętli zwrotnych. Test-Driven Development jest tu szczególnie potężne: niech AI najpierw napisze testy, które nie przechodzą, potwierdź, że nie przechodzą, a następnie wdrażaj, aż będą zielone.

   Prompt do skopiowania: kontrola TDD odporna na oszukiwanie

   Write failing tests first for the invitation acceptance rules: an invite can be accepted once, expired invites are rejected, and an already-member user gets a 409. Show me the failing test output. Only then implement until the tests pass — do not modify the tests to make them pass, and tell me if a rule is ambiguous.

Jak każda faza mapuje się na Cursor, Claude Code i Codex

Kręgosłup Planuj-Wykonuj-Weryfikuj mapuje się na odmienną mechanikę w każdym narzędziu. Dyscyplina jest identyczna; różnią się elementy sterujące.

Cursor

Planuj w trybie Ask (rozwijane menu trybu, tylko do odczytu). Wykonuj, przełączając się na Agent i akceptując diffy fragment po fragmencie; Cursor zapisuje punkt kontrolny przed każdą edycją, więc możesz cofnąć zły krok. Weryfikuj, każąc Agentowi uruchomić twoje polecenie testowe i naprawić błędy, przeglądając każdą zmianę przed akceptacją.

Claude Code

Planuj w plan mode (claude --permission-mode plan lub Shift+Tab, by do niego przejść). Wykonuj w trybie default (zatwierdzaj polecenia) lub w trybie accept-edits dla automatycznie stosowanych edycji. Weryfikuj za pomocą hooka PostToolUse, który uruchamia twój zestaw testów po każdej edycji, żeby wadliwa zmiana nie nazbierała się niezauważona.

Codex

Planuj z codex --sandbox read-only -c approval_policy=on-request. Wykonuj z codex --sandbox workspace-write -c approval_policy=on-request; sandbox i polityka zatwierdzania są osobnymi kontrolkami. Użyj osobnego git worktree, gdy potrzebujesz izolacji checkoutu. Weryfikuj, pozwalając Codeksowi uruchomić testy, a następnie otwierając PR na GitHubie, żeby twoje zwykłe CI i recenzenci decydowali o scaleniu.

Notatka

Pomijając polecenia edytora i CLI, te trzy narzędzia mają ten sam szkielet: planowanie tylko do odczytu, małe kroki wykonania możliwe do przejrzenia oraz zautomatyzowaną pętlę weryfikacji. Wybierz narzędzie, którego bramka pasuje do twojego przepływu pracy.

Traktuj agenta jak implementera pierwszego podejścia

Agent jest bardzo szybkim implementerem, któremu nadal brakuje twojej oceny domeny. To nie to samo, co „recenzuj każdą linię jak PR juniora”.

• Dawaj jasne instrukcje: Bądź konkretny. Rozbijaj złożone zadania na kroki odpowiadające plan.md.
• Recenzuj na bramkach: Czytaj intent.md, spec.md, plan.md oraz podsumowanie PR i findingi agenta. Linia po linii tylko wtedy, gdy zmiana jest krytyczna albo agent ją oflagował.
• Iteruj i przekazuj uwagi: Jeśli pierwszy wynik nie jest właściwy, popraw plan albo plik z instrukcjami, żeby następna sesja nie powtórzyła błędu. Precyzyjne „przypadek 409 nie jest obsłużony; dodaj go i uruchom testy ponownie” jest szybsze niż przepisywanie promptu od zera.

Metodologie

Superpowers Połącz projekt, worktrees, wykonywalne plany, TDD, subagentów, review i weryfikację w jeden workflow agenta działający w wielu środowiskach.

Od PRD przez plan do listy zadań Fundamentalny przepływ pracy przy tworzeniu funkcjonalności. Przekształć wymagania w szczegółowy plan inżynieryjny, a następnie podziel plan na wykonywalne zadania, które AI może implementować jedno po drugim.

Programowanie sterowane testami Najpierw napisz testy, a potem pozwól AI napisać kod, który je przejdzie. TDD daje AI jednoznaczną definicję sukcesu i wbudowaną pętlę weryfikacji.

Programowanie sterowane błędami Użyj błędów jako głównego sygnału zwrotnego. Zamiast próbować zapobiec wszystkim błędom, potraktuj je jako najszybszą drogę do poprawnych implementacji.

Ciągła dostawa Dostarczaj małe, zweryfikowane zmiany w sposób ciągły. AI przyspiesza cykl od pomysłu do produkcji, gdy połączysz go z automatycznymi pipeline'ami i przyrostową dostawą.

Człowiek w pętli Wzorce, które pozwalają ci zachować kontrolę. Dowiedz się, kiedy interweniować, kiedy pozwolić AI działać, i jak przeglądać kod generowany przez AI bez stawania się wąskim gardłem.

Tryb agenta vs tryb zapytań Każde narzędzie oferuje tryby od autonomicznego wykonywania po analizę tylko do odczytu. Wiedza o tym, kiedy używać każdego trybu, to różnica między produktywnymi sesjami a zmarnowanym kontekstem.

Jak te metodologie się łączą

To nie są konkurencyjne podejścia. W praktyce łączysz je ze sobą. Typowe budowanie funkcjonalności może wyglądać tak:

1. Od PRD przez plan do listy zadań — produkujesz i commitujesz intent.md / spec.md / plan.md.
2. TDD — piszesz nieudane testy dla pierwszego zadania (pętla feedbacku sesji).
3. Tryb agenta — implementacja po akceptacji planu.
4. Człowiek w pętli — na bramkach: intent, plan, PR, produkcja — nie każda wygenerowana linia.
5. Programowanie sterowane błędami — gdy testy ujawnią przypadki brzegowe, których nie przewidziałeś.
6. Ciągła dostawa — zweryfikowana zmiana przez branch protection; agent nie przechodzi bramki produkcji.

Gdzie te praktyki zawodzą

• Przeciążenie kontekstem. Dwadzieścia plików wskazanych przez @ daje gorsze odpowiedzi niż trzy. Przytnij do tego, czego dotyczy zadanie.
• Dryf planu. Długie sesje odpływają od zatwierdzonego planu. Wklej ponownie ponumerowane TODO i zapytaj, na którym kroku jesteś, przed kontynuacją.
• Przeglądy z pieczątką. Po kilku poprawnych diffach przestajesz czytać; wtedy właśnie dowozi się buga. Trzymaj diffy małe i opieraj się na zautomatyzowanych bramkach (hooki, CI), które się nie męczą.
• Tautologiczne testy. Testy napisane przez AI mogą przechodzić mimo zepsutego kodu. Potwierdź, że test faktycznie nie przechodzi, gdy zepsujesz implementację.

Dokąd dalej w sekcji metody

Przeczytaj najpierw AI-native SDLC, aby poznać sześcioetapową pętlę, w której działają te metodologie, a potem Od PRD przez plan do listy zadań — rozmowę, która produkuje wczesne artefakty. Indeks zasad zawiera pełen zestaw. Poza tym:

Zarządzanie dużymi bazami kodu Utrzymaj AI na ziemi, gdy repozytorium jest za duże, by zmieścić je w kontekście.

Techniki promptowania Wzorce promptów, które dają output o jakości produkcyjnej.

Prywatność i bezpieczeństwo Trzymaj sekrety i wrażliwy kod z dala od niewłaściwych kontekstów.

Współpraca zespołowa Dziel się zasadami, promptami i przepływami pracy w całym zespole.