Szybkie efekty w pierwszych 24 godzinach

Szybkie efekty z Claude Code, Codeksem i Cursorem to dziesięć technik na pierwszy dzień, które zwracają się w kilka minut. Pięć nie wymaga konfiguracji (wyjaśnianie kodu, testy charakteryzujące, poprawki zaczynające się od testu, refaktoryzacja za bramką testów i przegląd przed pushem), a pięć wymaga 10–30 minut przygotowania. Każda łączy gotowy prompt z kontrolą potwierdzającą wynik bez czytania każdej linii.

Ta strona jest dla dewelopera, który wczoraj zainstalował agenta i jeszcze nie powierzył mu prawdziwej pracy. Za godzinę masz standup, w repozytorium leży moduł bez żadnego testu, a w logach czeka stack trace z wczorajszego wdrożenia. Poniższe prompty działają na tym kodzie już dziś, a każdy kończy się dowodem, który sprawdzisz w niecałą minutę: testem, który najpierw był czerwony, a potem zielony, wskazanym numerem linii albo raportem z przeglądu.

Nie masz jeszcze agenta? Zacznij od szybkiego startu Claude Code, Codeksa albo Cursora.

Co wyniesiesz z pierwszego dnia

• Pięć promptów, które działają na twoim prawdziwym repozytorium bez żadnej konfiguracji poza instalacją
• Pięć jednorazowych przygotowań — plik instrukcji, aktualna dokumentacja bibliotek, praca od planu, skill wielokrotnego użytku i równoległe worktree — które poprawiają każde kolejne zadanie
• Nawyk weryfikacji dla każdej techniki, dzięki któremu oceniasz agenta po dowodach, a nie po ponownym czytaniu jego diffu
• Punkt odniesienia, z którym jutro porównasz wyniki, zamiast polegać na wrażeniu

Skonfiguruj agenta w pięć minut

Zacznij od czystego drzewa roboczego Gita (git status nie pokazuje nic do zatwierdzenia). Czyste drzewo to twój przycisk „cofnij”: cokolwiek zrobi agent, git diff to pokaże, a git restore . usunie.

Pierwszego dnia zostań przy domyślnym modelu narzędzia. Zasada tego serwisu: zacznij od domyślnego modelu, najpierw podnieś poziom wysiłku (effort), a model zmieniaj dopiero wtedy, gdy wskażą to twoje własne wyniki. Aktualne domyślne modele i ceny znajdziesz w przeglądzie modeli.

Claude Code

1. W terminalu, w katalogu głównym repozytorium, uruchom claude.
2. Uruchom /init. Claude Code zapisze CLAUDE.md z opisem projektu, jego poleceń i konwencji. Przeczytaj go od razu; Efekt 6 go ulepszy.
3. Sprawdź tryb uprawnień w stopce; Shift+Tab przełącza między trybami, m.in. Manual, Accept edits, Plan i Auto. Manual pyta, zanim Claude edytuje plik lub uruchomi polecenie.
4. Zapytaj What is this project, and which commands build, test and lint it? Poprawna odpowiedź oznacza, że agent umie uruchomić twoje kontrole, a od tego zależy każda technika poniżej.

W jakim trybie startujesz

Od wersji 2.1.283 (kanał latest) sesje interaktywne na każdym planie i u każdego dostawcy startują w trybie auto, w którym klasyfikator ocenia każdą akcję przed jej wykonaniem. Na kanale stable (26.09.2026 to wersja 2.1.274, z niego korzysta też cask Homebrew claude-code) w trybie auto startują sesje w planach Pro, Max i Team, tak jak od 14.08.2026; pozostałe plany mogą startować w trybie Manual. Na obu kanałach sesja startuje w trybie Manual, gdy plik ustawień zawiera disableAutoMode albo gdy jej model nie obsługuje trybu auto (Haiku, Sonnet 4.5 i Opus 4.5 wszędzie; w Bedrock, Google Cloud i Foundry każdy model poza Sonnet 5, Opus 4.7+ i Fable — dlatego domyślna sesja w Foundry startuje w trybie Manual). Wszystkie tryby opisuje przewodnik po uprawnieniach i sandboksie.

Codex

1. W terminalu, w katalogu głównym repozytorium, uruchom codex.
2. Uruchom /init. Codex zapisze AGENTS.md z opisem projektu, poleceniami i konwencjami.
3. Pierwszego dnia zostaw domyślną politykę zatwierdzania, on-request: Codex pyta, zanim wyjdzie poza sandbox.
4. Zapytaj What is this project, and which commands build, test and lint it? i popraw w AGENTS.md wszystko, co agent pomylił.

Cursor

1. Otwórz repozytorium w Cursorze i otwórz panel Agent.
2. Na razie zostaw domyślny wybór modelu; Cursor często zmienia domyślne modele, więc porównaj selektor z przeglądem modeli.
3. Zanim dasz agentowi prawdziwą pracę, otwórz ustawienia Cursora, znajdź Run modes (decydują, które polecenia terminala agent uruchamia bez pytania) i wybierz tryb, który czeka na twoją zgodę. Dlaczego, wyjaśnia przewodnik po bezpieczeństwie Cursora.
4. Zapytaj What is this project, and which commands build, test and lint it? Efekt 6 zamieni odpowiedź w regułę projektu.

Pierwsze 30 minut: pięć efektów bez konfiguracji

Te pięć promptów jest takich samych we wszystkich trzech narzędziach. Wklej je do sesji Claude Code lub Codeksa albo do panelu Agent w Cursorze. Zamień ścieżki plików na prawdziwy plik z twojego repozytorium.

Efekt 1: zrozum obcy kod z cytowanymi numerami linii

Funkcja na 200 linii z niejasnymi nazwami to problem czytania, nie pisania, więc agent ma tu tylko czytać. Weryfikacja jest wbudowana w prompt: każde twierdzenie musi wskazywać linię, a ty sprawdzasz dwie z nich.

Prompt do skopiowania: wyjaśnienie modułu bez zmian w kodzie

Read src/services/paymentProcessor.ts and explain it. Do not edit any file.
1) What the module does, in three sentences.
2) The happy path and each error path, with the line numbers that implement them.
3) Inputs that are not handled (null, empty, duplicate, timeout), each with the line where it would fail.
4) Which tests cover this file today, by test name. Say "none" if none do.
Cite a line number for every claim. If you are unsure, say so instead of guessing.

Sprawdź: otwórz dwie wskazane linie. Jeśli którakolwiek nie mówi tego, co twierdzi agent, odrzuć wyjaśnienie i zapytaj ponownie o mniejszy fragment.

Efekt 2: utrwal obecne zachowanie testami charakteryzującymi

Testy dla nieprzetestowanego kodu to dobre pierwsze zadanie, bo każda późniejsza zmiana staje się sprawdzalna. Poproś o testy, które zapisują to, co kod robi teraz, łącznie z błędami, a nie to, co powinien robić.

Prompt do skopiowania: testy charakteryzujące dla modułu bez testów

Write characterization tests for src/utils/validation.ts using the test framework this project already uses.
Record what each exported function does today, including behaviour that looks wrong; mark those tests with a comment "CURRENT BEHAVIOUR - review".
Cover empty strings, null, undefined, boundary values and every thrown error.
Do not change validation.ts.
Run the new tests and show me the output.
Then prove the tests can fail: change one comparison operator in validation.ts, run the tests, show me which test fails, and revert the change.

Sprawdź: ostatni krok to jednolinijkowy test mutacyjny. Jeśli po zmianie kodu żaden test nie zaświeci się na czerwono, zestaw jest ozdobą. Pełną technikę opisuje przewodnik po testach charakteryzujących.

Efekt 3: napraw błąd ze stack trace’u, zaczynając od testu

Wklejenie stack trace’u z prośbą o poprawkę działa, ale poprawka jest udowodniona dopiero wtedy, gdy wcześniej test odtworzył błąd. Kolejność ma znaczenie: czerwony, poprawka, zielony.

Prompt do skopiowania: najpierw odtwórz, potem napraw

Here is an error from production:

PASTE_STACK_TRACE_HERE

1) Find the root cause. Trace the data flow to the failing line and explain it in two sentences.
2) Write a test that reproduces this error. Run it and show me that it fails for the reason above.
3) Make the smallest fix that makes that test pass.
4) Run the full test suite and show me the result.
Do not change any existing test to make it pass.

Zamień PASTE_STACK_TRACE_HERE na pełny stack trace, razem z liniami z twojego własnego kodu. Przed wklejeniem usuń ze stack trace’u tokeny, adresy e-mail i identyfikatory klientów.

Sprawdź: potrzebujesz dwóch wyników: nowego testu, który nie przechodzi przed poprawką, i całego zestawu, który przechodzi po niej. Poprawka bez wcześniejszego czerwonego testu mogła naprawić inny problem.

Efekt 4: zrefaktoryzuj długą funkcję za bramką testów

Refaktoryzacja jest bezpieczna, gdy zachowanie zostało utrwalone, zanim zmieni się struktura. Prompt każe agentowi najpierw zbudować to zabezpieczenie, jeśli go brakuje.

Prompt do skopiowania: refaktoryzacja bez zmiany zachowania

Refactor processOrder in src/controllers/orderController.ts into smaller functions with one responsibility each.
Before changing anything, run the tests that cover processOrder. If fewer than three tests exercise it, write characterization tests first and show me they pass.
Keep the exported API and all observable behaviour identical.
After the refactor, run the same tests plus the type checker and the linter, and show me all three results.

Sprawdź: te same testy przechodzą przed zmianą i po niej, a sprawdzenie typów i linter są czyste. Oceniasz kształt nowych funkcji, a nie każdą przeniesioną linię.

Efekt 5: zrób przegląd, zanim wypchniesz zmiany

Zanim zmianę zobaczy człowiek, niech przejrzy ją agent. Wbudowane polecenia przeglądu czytają diff i zgłaszają uwagi z odwołaniem do pliku i linii.

Claude Code

Uruchom w sesji /code-review, żeby przejrzeć bieżące zmiany. /security-review robi przegląd skupiony na bezpieczeństwie.

Codex

Uruchom w sesji /review albo w powłoce codex review --uncommitted, żeby przejrzeć zmiany w indeksie, niezaindeksowane i nieśledzone pliki bez otwierania sesji.

Cursor

Wklej poniższy prompt do panelu Agent. Przy pull requestach recenzentem Cursora jest Bugbot, który szuka błędów, problemów z bezpieczeństwem i jakością kodu; zanim go włączysz, sprawdź swój plan.

Prompt do skopiowania: przegląd własnego diffu przed pushem

Review the uncommitted changes in this repository as a strict senior reviewer.
Report only real problems: bugs, missing error handling, security issues, and behaviour changes that no test covers.
For each finding give file, line, severity (high, medium or low), and a one-line fix.
Do not edit files. If you find nothing above low severity, say so in one line.

Sprawdź: popraw każdą uwagę o wysokiej wadze albo zapisz, dlaczego jest błędna. Przegląd, który na dużym diffie nie znajduje niczego, to sygnał, żeby zapytać ponownie o węższy zakres.

Reszta dnia: pięć efektów, które wymagają 10–30 minut przygotowania

Te techniki wymagają jednorazowej inwestycji i poprawiają każde kolejne zadanie. Wykonaj je w tej kolejności: plik instrukcji najpierw, bo czyta go każda późniejsza technika.

Efekt 6: dopracuj plik instrukcji, który agent czyta w każdej sesji

Plik z /init to szkic. Staje się użyteczny, gdy zawiera zasady, których agent nie wywnioskuje z kodu: które polecenia dowodzą poprawności zmiany, których katalogów nie ruszać i co znaczy „gotowe”.

Claude Code

Claude Code czyta CLAUDE.md na początku każdej sesji. Od wersji 2.1.277 (kanał latest) czyta też AGENTS.md, gdy projekt nie ma CLAUDE.md, więc repozytorium dzielone z użytkownikami Codeksa może mieć jeden plik.

Codex

Codex czyta AGENTS.md. W projektach, którym nie zaufałeś, Codex pomija AGENTS.md (od wersji 0.150.0), więc zaufaj projektowi, gdy Codex o to zapyta.

Cursor

Cursor czyta Rules. Poproś agenta, żeby utworzył regułę projektu i podał plik, który zapisał, wklej do tego pliku wynik poniższego promptu i zatwierdź go w repozytorium. Przewodnik po regułach projektu w Cursorze pokazuje, jak zawęzić reguły do ścieżek.

Prompt do skopiowania: zamień szkic w działające instrukcje

Improve the project instructions file for this repository. Keep it under 80 lines.
Include only what you cannot infer from the code:
- the exact commands for build, test, lint and type check, and which of them must pass before a task is done
- directories and files never to edit (generated code, vendored code, migrations already applied)
- conventions that differ from the framework's defaults, each with one real file as an example
Verify every command by running it. Delete any line you could not verify.
Show me the diff of the file.

Sprawdź: każde polecenie w pliku zadziałało w trakcie tego promptu. Krótszy, zweryfikowany plik jest lepszy od długiego i zgadywanego; zobacz przycinanie plików kontekstu.

Efekt 7: daj agentowi aktualną dokumentację bibliotek przez Context7

Modele znają API bibliotek ze stanu z danych treningowych. Serwer MCP Context7 od Upstash pobiera na żądanie dokumentację dla konkretnej wersji. Serwer działa bez klucza API; darmowy klucz podnosi limity.

Claude Code

claude mcp add --scope user --transport http context7 https://mcp.context7.com/mcp

Codex

codex mcp add context7 -- npx -y @upstash/context7-mcp

Cursor

Dodaj serwer do .cursor/mcp.json w repozytorium:

{
  "mcpServers": {
    "context7": { "url": "https://mcp.context7.com/mcp" }
  }
}

Żeby dodać klucz, najpierw usuń wpis bez klucza (claude mcp remove context7 albo codex mcp remove context7) i odczytaj klucz ze zmiennej środowiskowej, którą wypełnia twój magazyn sekretów. Nigdy nie wpisuj samego klucza w polecenie:

# Claude Code: powłoka rozwija zmienną, a zakres user zapisuje wartość w twojej konfiguracji użytkownika, nie w repozytorium
claude mcp add --scope user --header "Authorization: Bearer $CONTEXT7_API_KEY" --transport http context7 https://mcp.context7.com/mcp
# Codex: zapisuje tylko nazwę zmiennej i odczytuje klucz przy połączeniu
codex mcp add context7 --url https://mcp.context7.com/mcp --bearer-token-env-var CONTEXT7_API_KEY

W Cursorze wpis z kluczem umieść w swoim pliku użytkownika ~/.cursor/mcp.json, a nie w pliku projektu. Nigdy nie commituj klucza do .cursor/mcp.json ani .mcp.json: oba leżą w repozytorium, więc klucz trafiłby do historii Gita.

Potem nazwij w prompcie bibliotekę i wersję: Use Context7 to check the current Next.js routing API for the version in package.json before you change this file.

Każdy serwer MCP dokłada narzędzia, spośród których agent musi wybierać, a w niektórych klientach także ich definicje w kontekście, więc dodawaj serwery pojedynczo, gdy zadanie ich wymaga. Przewodnik po Context7 opisuje przypinanie identyfikatora biblioteki i tryb CLI bez MCP.

Efekt 8: zaplanuj funkcję i uzgodnij kryteria akceptacji przed kodem

Przy wszystkim większym niż poprawka błędu każ agentowi najpierw zaplanować pracę i spisać kryteria akceptacji, które da się sprawdzić. Zatwierdzasz trzy strony planu zamiast przeglądać trzysta linii błędnego kodu.

Claude Code

Włącz tryb Plan poleceniem /plan albo klawiszami Shift+Tab i wklej prompt. Agent czyta i planuje, ale niczego nie edytuje.

Codex

Uruchom /plan, żeby przełączyć się w tryb Plan, i wklej prompt.

Cursor

Przełącz agenta w Plan Mode, który tworzy plan implementacji przed napisaniem kodu, i wklej prompt.

Prompt do skopiowania: plan ze sprawdzalnymi kryteriami akceptacji

I need email notifications when an order ships. Do not write code yet.
Read the order and email code first, then give me:
1) Acceptance criteria as Given/When/Then statements, each one checkable by an automated test.
2) The files you will change or add, and why.
3) The edge cases: duplicate events, email provider timeout, user without an email address.
4) An implementation order in which each step ends with a test run.
Wait for my approval before implementing anything.

Sprawdź: każde kryterium akceptacji ma w końcowej zmianie co najmniej jeden test, a testy przeszły. To powiązanie zatwierdzasz. Przewodnik po kryteriach akceptacji pokazuje, jak pisać kryteria, których agent nie zrozumie źle.

Efekt 9: zapisz powtarzany prompt jako skill

Do popołudnia wkleisz prompt przeglądu z Efektu 5 trzy razy. Skill zamienia go w nazwany, wersjonowany plik, który agent wczytuje, gdy go potrzebuje. Skille korzystają z otwartego formatu Agent Skills (katalog z plikiem SKILL.md), który obsługują wszystkie trzy narzędzia.

Claude Code

Utwórz .claude/skills/pre-push-review/SKILL.md:

---
name: pre-push-review
description: Review uncommitted changes for bugs, missing error handling, security issues and untested behaviour changes before a push.
---
Review the uncommitted changes as a strict senior reviewer.
Report only real problems, each with file, line, severity (high, medium, low) and a one-line fix.
Do not edit files. If nothing is above low severity, say so in one line.

Wywołaj go przez /pre-push-review albo pozwól Claude Code wczytać go, gdy prośba pasuje do opisu. Zatwierdź katalog w repozytorium, żeby dostał go cały zespół.

Codex

Poproś Codeksa, żeby wbudowanym skillem skill-creator zamienił prompt z Efektu 5 w skill projektu o nazwie pre-push-review, a potem uruchom /skills i sprawdź, czy jest na liście. Codex czyta skille repozytorium z .agents/skills/ (sprawdzone w binarce 0.157.1), więc zatwierdź ten katalog w repozytorium.

Cursor

Cursor obsługuje Agent Skills. Poproś agenta, żeby z promptu z Efektu 5 utworzył skill projektu o nazwie pre-push-review i podał, gdzie go zapisał, a potem sprawdź, czy pojawił się na liście skilli agenta, i zatwierdź ten katalog w repozytorium.

Sprawdź: uruchom skill na diffie ze znanym błędem, na przykład z usuniętym sprawdzeniem null. Jeśli raport go nie wychwyci, zaostrz treść skilla, zanim zaczniesz na nim polegać. Skille społeczności instaluje się poleceniem npx skills add OWNER/REPO; przeczytaj SKILL.md przed instalacją, bo skill to instrukcje, które twój agent wykona.

Efekt 10: uruchamiaj niezależne zadania równolegle w worktree

Trzy niezwiązane zadania — funkcja, poprawka błędu i aktualizacja dokumentacji — nie muszą na siebie czekać. Każdy agent dostaje własne worktree Gita, więc ich zmiany się nie zderzają, a każda trafia na osobną gałąź.

Claude Code

# Terminal 1
claude --worktree order-emails
# Terminal 2
claude --worktree token-refresh-fix
# Terminal 3
claude --worktree api-docs

Każda sesja działa we własnej kopii roboczej, na własnej gałęzi.

Codex

# Uruchom raz na zadanie, każde we własnym terminalu
codex --worktree

Każda sesja działa w nowym, zarządzanym worktree Gita.

Cursor

Użyj Worktrees, żeby lokalni agenci pracowali w odizolowanych kopiach Gita, albo przekaż zadanie Cloud Agentowi, który działa w odizolowanej maszynie wirtualnej w chmurze z pełnym środowiskiem deweloperskim, podczas gdy ty pracujesz lokalnie.

Sprawdź: praca równoległa mnoży ilość przeglądów, więc każde zadanie przechodzi przez bramkę, zanim na nie spojrzysz: testy, sprawdzenie typów i linter muszą przejść na gałęzi. Scal gałąź z zielonymi kontrolami; pozostałe odeślij z wynikiem, który nie przeszedł. Zacznij od dwóch zadań, nie od pięciu. Narzędzia na dalsze dni opisuje strona agenci równolegli.

Skąd wiesz, że wynik całego dnia jest poprawny?

Za każdą techniką stoi ten sam nawyk: poproś o dowód, a potem sprawdzaj dowód zamiast kodu. Ta tabela to cały proces przeglądu na pierwszy dzień.

Efekt	Dowód, który sprawdzasz	Czas sprawdzenia
1. Wyjaśnienie kodu	Dwa wskazane numery linii zgadzają się z twierdzeniami	1 minuta
2. Testy charakteryzujące	Testy przechodzą, a jedna celowa mutacja sprawia, że test przestaje przechodzić	1 minuta
3. Poprawka błędu	Nowy test nie przechodzi przed poprawką, cały zestaw przechodzi po niej	1 minuta
4. Refaktoryzacja	Te same testy zielone przed i po; typy i linter czyste	1 minuta
5. Przegląd	Każda uwaga o wysokiej wadze poprawiona albo odrzucona z uzasadnieniem	5 minut
6. Plik instrukcji	Każde wymienione polecenie zadziałało w trakcie promptu	2 minuty
7. Dokumentacja bibliotek	Wygenerowany kod kompiluje się z zainstalowaną wersją biblioteki (sprawdzanie typów przechodzi)	1 minuta
8. Zaplanowana funkcja	Każde kryterium akceptacji ma przechodzący test	5 minut
9. Skill	Raport skilla wykrywa podłożony błąd (usunięte sprawdzenie null)	2 minuty
10. Praca równoległa	Kontrole zielone na każdej gałęzi, zanim otworzysz diff	1 minuta na gałąź

Za to, co scalasz, nadal odpowiadasz ty. Dowody mówią ci, gdzie poświęcić czas na czytanie: na uwagę zgłoszoną przez recenzenta, test, który trudno było napisać, i plik, który zmienił kształt. Strona dowody zamiast diffów zamienia ten nawyk w metodę pracy.

Zmierz pierwszy dzień względem punktu odniesienia

Wrażenie szybkości to nie pomiar. Badania kontrolowane nie są zgodne: kontynuacja badania METR z końca 2025 roku z deweloperami open source dała szacunki punktowe o około 18% krótszego czasu pracy z AI u powracających deweloperów i 4% u nowo zrekrutowanych, ale oba przedziały ufności obejmują zero, a METR zaznacza, że wyniki trudno interpretować (METR, opublikowane 24.02.2026). Jedyne liczby, które dotyczą twojej bazy kodu, to twoje własne.

Co zapisać	Jak	Co ci to mówi
Zamknięte zadania	Policz zadania scalone dziś i w zwykły dzień w zeszłym tygodniu	Przepustowość
Czas na zadanie	Godzina rozpoczęcia i zakończenia dla trzech do pięciu zadań	Gdzie agent pomaga, a gdzie nie
Poprawki	Zmiany wycofane lub ponownie otwarte w ciągu tygodnia	Czy szybkość kosztowała jakość
Pokrycie	Zmierz pokrycie testami przed Efektem 2 i na koniec dnia	Czy sprawdzalna powierzchnia urosła

Kiedy szybkie efekty zawodzą i jak z tego wyjść

• Agent edytuje pliki, o które nie prosiłeś. Uruchom git diff --stat, żeby zobaczyć zasięg zmian, i git restore <path>, żeby odrzucić niechciane pliki. W Claude Code Esc Esc (albo /rewind) cofa sesję do wcześniejszego checkpointu. Potem dopisz zakazane ścieżki do pliku instrukcji (Efekt 6).
• Testy przechodzą, ale zachowanie jest złe. Agent napisał testy dopasowane do własnej implementacji. Powtórz krok z mutacją z Efektu 2; jeśli żaden test nie przestanie przechodzić, spisz kryteria akceptacji samodzielnie (Efekt 8) i poproś o testy na ich podstawie, bez pokazywania implementacji.
• Agent zmienił istniejący test, żeby przeszedł. Odrzuć zmianę i przywróć plik testu. Dopisz do pliku instrukcji Never edit an existing test to make it pass; report the conflict instead. Przewodnik chroń wyrocznię pokazuje, jak wymusić to hookami i w CI.
• Kod używa API, które już nie istnieje. Zainstaluj Context7 (Efekt 7) i podaj w prompcie wersję biblioteki. Jeśli błąd się powtarza, wklej do promptu odpowiedni fragment changeloga biblioteki.
• Agent powtarza ten sam błąd. Kontekst sesji jest zaśmiecony nieudanymi próbami. Zacznij od nowa (/clear w Claude Code, /new w Codeksie, nowy czat w Cursorze) i powtórz zadanie z ograniczeniem, które agent ciągle łamał.
• Równoległe gałęzie konfliktują przy scalaniu. Zadania nie były niezależne. Najpierw scal gałąź z najmniejszym diffem, a potem poproś drugiego agenta o rebase na nią i ponowne uruchomienie kontroli.

Dokąd iść po pierwszym dniu

Ścieżka dewelopera Uporządkowana ścieżka od szybkiego startu narzędzia do specyfikacji, pętli zwrotnych i przeglądu opartego na dowodach

Szybki start z Claude Code Instalacja, konfiguracja i pierwszy projekt z agentem w terminalu

Szybki start z Codeksem CLI, aplikacja, AGENTS.md i pierwsze zadanie z przeglądem

Szybki start z Cursorem Od instalacji do pierwszej funkcji zbudowanej przez agenta w IDE

Triki dla zaawansowanych Skróty i ustawienia, które mają znaczenie, gdy podstawy wejdą w nawyk

Przepływy pracy dla trzech narzędzi Planowanie, testy, przegląd i wdrażanie pokazane w Claude Code, Codeksie i Cursorze