W 2026 agent w edytorze nie jest nowością. Nowością jest to, że da się na nim oprzeć sprint — albo w tydzień zepsuć repo, sekrety i zaufanie do własnego kodu. Poniżej nie ma recenzji Cursora. Jest workflow, którego używam przy utrzymaniu aplikacji (w tym Next.js), żeby AI skracało robotę, a nie zastępowało myślenie.

Autocomplete, chat, agent — to nie to samo

Autocomplete kończy linię. Dobry do boilerplate, zły do architektury. Chat (Cmd-L / inline) tłumaczy plik, proponuje patch w zasięgu wzroku. Agent dostaje cel, sam chodzi po repo, odpala testy, otwiera PR. Im szerszy zasięg, tym ciaśniejszy kontrakt: instrukcje, kontekst, zakazy.

Błąd, który widzę najczęściej: wrzucenie „zrób feature X” do agenta na całym monorepo. Dostajesz diff, którego nikt nie rozumie. Zaczynaj od najwęższego trybu, który załatwia sprawę.

Plan przed implementacją

Zanim agent ruszy pliki: 5–10 zdań, co ma powstać, czego nie ruszać, jak zmierzyć sukces (test, URL, zachowanie). W Cursorze to plan / tryb Ask, potem Agent. W Next 16.3 agent może czytać wersjonowane docs z AGENTS.md — nie musisz wklejać dokumentacji frameworka do promptu. Szczegóły: Next.js 16.3 w praktyce.

Plan, który działa, nazywa pliki, a nie „warstwę serwisową”. Plan, który nie działa, brzmi jak oferta software house’u.

Context engineering

Agent nie „zna projektu”. Widzi to, co mu podasz: otwarte taby, @-pliki, instrukcje, MCP, wynik wyszukiwania. Zasada: ograniczony, aktualny, celowy kontekst.

Daj 2–4 pliki kontraktu (typ, routing, analogiczny komponent), nie 40.
Nie wklejaj całego data.ts, jeśli zmieniasz jeden wpis — wskaż wzorzec.
Powiedz, czego nie czytać: node_modules, lockfile, zrzuty, .env.
Jeśli zadanie jest UI, daj viewport i ścieżkę użytkownika, nie zrzut Figma na 12 ekranów.

Za dużo kontekstu = halucynacje ze starych komentarzy. Za mało = wymyślony API.

AGENTS.md i instrukcje projektu

Trzymaj w repo to, czego nie chcesz powtarzać: stack, komendy, konwencje, zakazy (sekrety, nie commituj .env, nie odpalaj exploita). W Next 16.3 framework dopisuje zarządzany blok z docs — Twoje zasady siedzą obok, nie wewnątrz.

Dobry AGENTS.md ma 1–2 ekrany. Zły to powieść o kulturze firmy. Skills (np. next-dev-loop) bierz na powtarzalne procedury: inspect → edit → verify na działającym next dev, nie na „napisz całą aplikację”.

# AGENTS.md (skrót)
- Stack: Next.js App Router, SCSS modules, Vitest.
- Komendy: npm run lint, typecheck, test, build (katalog frontend/).
- Nie commituj .env*, kluczy, dumpów.
- UI: nie wymyślaj tokenów — patrz .cursor/rules.
- Po zmianie typów: SQL/migration + mapper + UI razem.

Plan → implementacja → test → review

Plan w 8 punktach, zaakceptowany przez Ciebie.
Agent implementuje na osobnej gałęzi.
Testy, które już są w repo: lint, typecheck, test, krytyczny flow w przeglądarce.
Review diffa jak juniora, którego nie znasz: po co ten plik, czy nie obchodzi auth, czy nie zostawił console.log z tokenem.
Dopiero wtedy commit / PR.

Jeśli nie umiesz wyjaśnić diffa, nie mergujesz. „Wygląda OK” to nie review.

Gdzie AI realnie skraca czas

Refactor — zmiana nazwy typu w 15 plikach, gdy kontrakt jest jasny.
Testy — szkielety Vitest/Playwright do istniejącej funkcji, nie „pokryj 90%” na ślepo.
Debug — wklejasz stack + 2 pliki. Agent zgaduje mniej, gdy widzi log, nie cały dump Sentry.
Review — poproś o listę ryzyk (auth, XSS, N+1), potem sam to weryfikujesz.
Docs — changelog PR z diffa. Nie „dokumentacja produktu” z pustego promptu.
Research — MCP / docs w node_modules zamiast blogów z 2023. WordPress + AI w CMS to inny temat: co działa, a co hype.

Bezpieczeństwo pracy z agentem

Agent z dostępem do terminala to użytkownik z Twoimi uprawnieniami.

Sekrety — .env* w .gitignore i w ignore agenta. Nie wklejaj kluczy do czatu „żeby odtworzyć błąd”. Czerwony klucz w transcriptcie żyje dłużej niż myślisz.
NEXT_PUBLIC_* — to nie sekret. Agent chętnie wrzuci klucz Stripe na front. Ty masz to wyłapać.
Auto-run komend — wyłącz dla rm, git push --force, migracji, curl | sh. Potwierdzaj świadomie.
Supply chain — nie akceptuj „dorzuć tę paczkę” bez sprawdzenia rejestru. Tygrysie dependency to klasyka.
Dane klientów — nie wklejaj dumpów z produkcji do modelu w chmurze. Zanonimizuj albo użyj lokalnego logu.

Wdrożenie bez wycieku sekretów w obrazie: Next.js na VPS.

Dlaczego nadal musisz rozumieć kod

Model optymalizuje pod „wygląda na skończone”. Nie płaci za incydent. Nie pamięta, że RLS w Postgresie jest jedyną barierą. Jeśli nie umiesz powiedzieć, czemu ten fetch jest na serwerze, a nie w kliencie, to nie review — to nadzieja.

AI jest dźwignią na kod, który potrafisz utrzymać. Na kod, którego nie rozumiesz, jest generatorem długu. To samo dotyczy treści i pluginów w WP — AI w WordPress: co działa, a co hype.

Mój przykładowy workflow z coding agentem

Task z maila: „dodaj 5 wpisów na bloga, PL/EN, SEO jak reszta strony”.

Odczyt — sam otwieram lib/blog/types.ts, data.ts, sanitizeBlogHtml, sitemap.ts, jeden istniejący wpis. Agent dostaje te ścieżki, nie całe src/.
Plan — lista plików do zmiany, decyzja: bez schedulera, daty publikacji X, kategoria Y. Zatwierdzam plan.
Research — agent czyta oficjalne docs (WP, Next), ja sprawdzam daty i CVE. Halucynowana wersja frameworka nie wchodzi do tekstu.
Implementacja — treść + hreflang w istniejącym buildBlogPostMetadata. Żadnego nowego CMS.
Weryfikacja — npm run lint, typecheck, build, 10 URL-i, sitemap, JSON-LD. Agent może odpalić komendy; ja czytam output.
PR — diff review pod kątem sekretów, śmieciowego CSS, broken linków. Merge dopiero gdy umiem obronić każdy nowy slug.

Ten sam szablon działa przy feature w apce typu Księgowy AI: najpierw kontrakt danych, potem agent, potem test ścieżki użytkownika.

FAQ

Czy pisać kod tylko agentem?

Nie. Autocomplete i 20 linii ręcznie nadal wygrywają przy jednym haku. Agent od progu złożoności, nie od ego.

Czy AGENTS.md wycieka IP?

To konwencje repo, nie sekrety. Klucze API tam nie trafiają. Trafiają do menedżera sekretów i do .env, którego agent nie czyta.

Co z MCP?

MCP do dev serwera (logi, compile_route) jest cenniejszy niż „wyszukaj w internecie cokolwiek”. Im węższe narzędzie, tym mniej halucynacji.

Podsumowanie

Skuteczny workflow w 2026 to ciasny kontekst, pisany plan, testy z repo i review jak obcego juniora. Cursor jest edytorem z agentem, nie zastępcą lead developera. Jeśli nie rozumiesz wygenerowanego kodu, nie masz feature’a — masz ticket na później, z odsetkami.