Najlepsze praktyki dla programowania z pomocą AI

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 przepływ pracy, a nie prompting.

Dobre korzystanie z asystenta AI mniej zależy od sprytnego doboru słów, a bardziej od powtarzalnej pętli: nakarm go właściwym kontekstem, zaplanuj przed wykonaniem i weryfikuj na bieżąco. Ten przewodnik omawia podstawowe praktyki, osadzone w prawdziwej funkcji, i kieruje cię do pogłębionych artykułów o każdej z nich.

Co z tego wyniesiesz

• Wejścia kontekstu, które faktycznie poprawiają jakość outputu (precyzyjne wzmianki przez @ i trwały plik z zasadami)
• Konkretna pętla Planuj-Wykonuj-Weryfikuj zastosowana do prawdziwej funkcji w Next.js + Drizzle
• Gotowe do wklejenia prompty na fazy planowania, wykonania i weryfikacji
• Jak każda faza mapuje się na mechanikę Cursora, Claude Code i Codeksu
• Scenariusze awarii, które po cichu nadgryzają pracę wspomaganą przez AI, i jak je wyłapać

1. Kontekst to podstawa

Największą dźwignią jakości outputu jest jakość kontekstu, który dostarczasz. Dwa wejścia 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 naszej 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.

2. Przyjmij uporządkowany przepływ pracy: planuj, wykonuj, weryfikuj

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

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.

   Wskazówka

   Prompt planistyczny, który wymienia 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.

   Wskazówka

   Prompt do stopniowego wykonania, ograniczony do jednego elementu:

   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.

   Wskazówka

   Prompt weryfikacyjny TDD, który opiera się oszukiwaniu:

   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.

Każda faza, w każdym narzędziu

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. Wykonuj z --full-auto (ustawia zatwierdzanie on-request i sandbox workspace-write), najlepiej w worktree, by odizolować zmiany. 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.

3. Traktuj AI jak młodszego programistę

AI jest szybkie, szeroko kompetentne i czasami naiwne. Kieruj nim jak utalentowanym juniorem: dawaj mu jedno dobrze ograniczone zadanie na raz (prompt wykonawczy powyżej), przeglądaj jego output linijka po linijce, zamiast ufać zielonym testom, i przekazuj korygujące uwagi, zamiast zaczynać od nowa. Pętla konwersacyjna to atut — precyzyjne „przypadek 409 nie jest obsłużony; dodaj go i uruchom testy ponownie” jest szybsze niż przepisywanie promptu od zera.

Kiedy to się psuje

• 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ę.

Co dalej

Zgłęb każdą praktykę:

Wybór właściwego trybu: agent vs zapytanie Eksploracja tylko do odczytu kontra wykonanie z odczytem i zapisem w każdym narzędziu.

Człowiek w pętli Kapelusze architekta, nadzorcy i recenzenta — oraz bramki przeglądu, które za nimi stoją.

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.