Code review wspierane przez AI w Cursorze

Cursor sprawdza kod w trzech miejscach: Agent Review analizuje lokalny diff przed wypchnięciem commita, BugBot recenzuje każdy pull request według reguł dopasowanych do standardów zespołu, a Cursor CLI uruchamia własne przepływy review wewnątrz GitHub Actions. Przebieg AI zbiera usterki mechaniczne, żeby ludzie poświęcali uwagę architekturze i logice biznesowej.

Piątkowe popołudnie, w kolejce sześć pull requestów. Dwa od juniora, który regularnie zapomina o obsłudze błędów. Jeden to refaktor w 47 plikach, którego samo ogarnięcie zajmie godzinę. Kolejny dotyka przepływu płatności. Senior, który recenzuje większość PR-ów, siedział na spotkaniach do trzeciej, więc wszystko leżało godzinami — a gdy kolejka wreszcie schodzi, schodzi na tyle szybko, że umyka sprawdzenie na null postawione w złej kolejności.

Wąskim gardłem nie jest zasada review, tylko przepływ pracy. Review wspierane przez AI nie zastępuje ludzi, tylko ich wzmacnia. AI wyłapuje rzeczy mechaniczne — brakującą obsługę błędów, niespójne wzorce, możliwe odwołania do nulla — żeby człowiek mógł ocenić to, czego AI ocenić nie potrafi: czy architektura ma sens, czy logika biznesowa jest poprawna i czy to w ogóle było właściwe podejście.

Co daje review wspierane przez AI

• Przepływ autoreview, który wyłapuje większość uwag, zanim wystawisz PR-a
• Konfigurację BugBota łapiącą realne problemy bez generowania szumu
• Własny przepływ review na CLI pod standardy konkretnego zespołu
• Prompty copy-paste do złożonych PR-ów, kodu wrażliwego na bezpieczeństwo, dużych refaktorów i kodu wygenerowanego przez AI
• Reguły projektu zapisujące zespołową listę kontrolną review, żeby każda powierzchnia egzekwowała tę samą
• Pipeline, w którym ludzie oceniają decyzje, a nie odhaczają listy

Trzy miejsca, w których Cursor sprawdza kod

Każdy mechanizm pokrywa inny etap potoku, a razem dają pokrycie, którego nie osiągnie żaden z osobna.

Agent Review: kontrola przedstartowa własnego diffa

Zanim wypchniesz commit, Agent Review przepuszcza analizę Cursora przez twój lokalny diff. Po wygenerowaniu zmian przez Agenta — albo kiedy tylko masz niezacommitowane zmiany — kliknij Review w widoku diffa, a potem Find Issues. Agent analizuje zmiany linia po linii i wskazuje możliwe błędy, pomyłki w logice i pominięte przypadki brzegowe.

Możesz też z zakładki Source Control przejrzeć wszystkie zmiany względem gałęzi głównej — to wersja warta uruchomienia tuż przed otwarciem PR-a. W polu czatu to samo zrobią /review i /review-bugbot, bez odrywania rąk od klawiatury.

W ustawieniach Cursora możesz włączyć:

• Auto-run on commit: automatyczne skanowanie w poszukiwaniu błędów po każdym commicie
• Include submodules: sprawdzanie zmian w submodułach gita
• Include untracked files: wyłapywanie problemów w plikach jeszcze nieprzygotowanych do commita

Włącz auto-run, jeśli chcesz stałej informacji zwrotnej; zostaw wyłączone i uruchamiaj review ręcznie, jeśli wolisz panować nad zużyciem.

BugBot: każdy pull request, automatycznie

BugBot to zarządzana usługa Cursora do automatycznych review pull requestów. Włącz ją w panelu Cursora (Settings > BugBot) albo przez aplikację GitHub, podepnij repozytorium, a będzie recenzować każdy PR i wystawiać ustalenia pogrupowane po wadze (Bugs, Security, Compliance). Ręczne uruchomienie to komentarz bugbot run albo cursor review pod pull requestem.

BugBot działa inaczej niż ręczny prompt review. Korzysta z analizy dostrojonej do wyłapywania błędów w diffach — nie tylko kwestii stylu, ale realnych pomyłek w logice, pominiętych przypadków brzegowych i możliwych regresji. Gdy coś zgłosi na PR-ze, Autofix with Cloud Agent odpala izolowaną maszynę, która nanosi poprawkę, weryfikuje zestaw testów i dokłada commit na gałęzi.

Uwaga

BugBot i automatyczni agenci review dochodzą do bramki merge i się zatrzymują — scalić nie mogą. Ochrona gałęzi nadal musi wymagać co najmniej jednej akceptacji człowieka będącego code ownerem, zanim cokolwiek trafi na main. Automatyczne review, które samo akceptuje i scala, przestaje być review.

Cursor CLI: logika review, którą piszesz sam

Do logiki wykraczającej poza BugBota — kontroli zgodności, egzekwowania wzorców architektonicznych, integracji z zewnętrznymi narzędziami — Cursor CLI uruchamia w pełni własne przepływy review w GitHub Actions.

Wskazówka

Prompt copy-paste do stworzenia własnej akcji review na GitHubie:

Create a GitHub Actions workflow at .github/workflows/code-review.yml that:

1. Triggers on pull_request events (opened, synchronize, reopened)
2. Installs Cursor CLI via curl https://cursor.com/install
3. Runs an agent that reviews the PR diff using gh pr diff
4. Flags only high-severity issues (security, logic errors, data loss risks)
5. Posts inline comments on specific changed lines
6. Adds a summary comment at the end
7. Does NOT approve or request changes -- only comments
8. Limits to 10 inline comments maximum per review

Use .cursor/cli.json to deny Write and git push permissions.
Use the CURSOR_API_KEY secret for authentication.

To konfiguracja uprawnień sprawia, że agent review może czytać kod i pisać komentarze, ale nie może ruszyć repozytorium:

.cursor/cli.json

{
  "permissions": {
    "deny": [
      "Shell(git push)",
      "Shell(gh pr create)",
      "Shell(gh pr merge)",
      "Write(**)"
    ]
  }
}

Autoreview, zanim otworzysz PR-a

Największą dźwignią jest przejrzenie własnego kodu, zanim zobaczy go ktokolwiek inny. Wyłapuje to większość uwag, które i tak byś dostał, dzięki czemu recenzenci zajmują się architekturą, a nie wytykaniem przypadku pustej tablicy.

Wskazówka

Prompt copy-paste do autoreview:

Review all changes on the current branch compared to main.

Check for:
1. Security: SQL injection, XSS, missing authentication, hardcoded secrets
2. Error handling: uncaught promises, missing try/catch, swallowed errors
3. Performance: N+1 queries, unnecessary data fetching, blocking operations
4. Consistency: does the new code follow the patterns in @src/services/user-service.ts?
5. Edge cases: null/undefined inputs, empty arrays, concurrent access
6. Missing tests: are all new code paths covered?

For each issue found, provide the file, line, the problem, and a specific fix.
Do not make any changes yet -- just report the findings.

Uruchom to w trybie Ask, popraw, co znajdzie, i wystaw PR-a. Gdy zmiana dotyka czegoś wrażliwego dla bezpieczeństwa, zrób drugie, węższe przejście zamiast poszerzać pierwsze — prompt poniżej schodzi głębiej w jednej osi i celowo ignoruje kod, którego nie ruszałeś:

Wskazówka

Prompt copy-paste do review twoich zmian pod kątem bezpieczeństwa:

Review my current git diff for security vulnerabilities:

1. Check for SQL injection, XSS, and CSRF vulnerabilities
2. Verify that user input is validated and sanitized
3. Ensure secrets are not hardcoded or logged
4. Check that authentication and authorization are properly enforced
5. Look for unsafe deserialization or eval usage
6. Verify error messages don't leak internal details

Only flag issues in the changed lines, not pre-existing code.

Zapisanie standardów zespołu jako reguły

Reguły projektu w Cursorze to jedno miejsce na spisanie listy kontrolnej review, a czytają je wszystkie powierzchnie: Agent Review, /review i BugBot. Reguły z zakresem “Always Apply” trafiają do każdego review BugBota, a wzorce glob zawężają te ostrzejsze do miejsc, gdzie mają sens, na przykład src/api/**/*.ts.

---
description: Standards for AI-assisted code review
alwaysApply: false
---

## Always check
- Every new API endpoint must have input validation using Zod
- Database queries must use parameterized inputs, never string concatenation
- Error handling must not swallow errors silently (no empty catch blocks)
- New React components must have TypeScript prop interfaces, not inline types
- Async functions must have try/catch or .catch() error handling
- Error responses must follow the format in @src/lib/errors.ts

## Performance
- No N+1 queries: if a loop contains a database call, flag it
- No synchronous file system operations in request handlers
- Images must use lazy loading in frontend code

## Testing
- New utility functions must have corresponding test files
- Test files must include at least one edge case test
- Mock external services, never hit real APIs in tests

## Do not flag
- Style preferences (formatting is handled by Prettier)
- Import ordering (handled by ESLint)
- Variable naming unless it is genuinely confusing

Zapisz to jako .cursor/rules/review-standards.mdc. Sekcja “Do not flag” to ta część, którą większość zespołów pomija, i to właśnie ona rozwiązuje problem fałszywych alarmów: bez niej każde review kłóci się z Prettierem.

Zapisanie powtarzalnego review jako komendy

Przy review, które powtarzasz, zapisana komenda bije wklejanie promptu od nowa:

---
description: Run a security-focused review on the current changes
---

Review all changes on the current branch compared to main for security issues.

Check for:
- User input that reaches database queries without parameterization
- Missing authentication or authorization checks
- Secrets or credentials in code or configuration
- User input rendered in HTML without sanitization
- File paths constructed from user input
- Deserialization of untrusted data

For each finding, rate it as Critical, High, Medium, or Low severity.
Provide the file, line, the vulnerability, and a specific fix.

Zapisz jako .cursor/commands/security-review.md i wywołuj przez /security-review przed otwarciem pull requesta.

Recenzowanie cudzego pull requesta

Najpierw model myślowy zmiany

Piętnaście zmienionych plików i 400 linii diffa to jeszcze nie problem review, tylko problem zrozumienia:

Wskazówka

Prompt copy-paste do zrozumienia PR-a:

I am reviewing a PR that modifies these files:

[PASTE THE FILE LIST OR DIFF SUMMARY]

Help me understand:
1. What is the overall goal of this change?
2. What is the sequence of changes -- which file is the entry point?
3. Which changes are structural (moves, renames) vs. behavioral (new logic)?
4. What are the riskiest parts that need careful review?

Do not evaluate the code yet. Just help me build a mental model of the change.

To oszczędza dziesięć minut przewijania diffa w próbie odgadnięcia, po co ten PR w ogóle powstał.

Jedno skupione przejście na jedno zagadnienie

Trzy skupione przejścia wyłapują więcej niż jedno rozmyte “przejrzyj ten kod”:

Wskazówka

Prompt copy-paste do skupionego review:

Review @src/services/payment-service.ts for error handling completeness.

For every external call (database queries, API calls, file operations):
1. Is there a try/catch or .catch()?
2. Is the error logged with enough context to debug?
3. Is the error propagated or handled appropriately?
4. Are there timeout or retry mechanisms for external services?
5. What happens if the service is completely down?

List any gaps you find with specific line references.

Duże refaktory w trzech przejściach

To przy dużych PR-ach review AI daje najwięcej. Uwaga człowieka siada po pierwszych 200 liniach diffa, a AI trzyma ten sam poziom skrupulatności przez 2000. Rozpisz przejścia wprost, żeby nie mieszało zagadnień:

@src/services

This PR refactors the service layer from class-based services to functional modules.
Review the changes in three passes:

Pass 1 - Correctness: Do the new functional implementations preserve the same
behavior as the class-based versions? Check return types, error handling, and
edge cases.

Pass 2 - API Surface: Are the exported function signatures backward-compatible?
Will consumers of these services need to update their imports or call patterns?

Pass 3 - Testing: Do the existing tests still make sense with the new
implementation? Are there new code paths that lack test coverage?

Summarize findings for each pass separately.

Reguły architektury zamiast dobrych praktyk

Czasem review ma egzekwować twoją konkretną architekturę, a nie ogólną jakość:

Wskazówka

Prompt copy-paste do review pod kątem architektury:

Review this PR against our architecture rules:

1. API routes must not contain business logic -- they delegate to service functions
2. Service functions must not import from route files (no circular dependencies)
3. Database access goes through the repository layer, never called directly from services
4. Cross-service communication goes through the event bus, not direct function calls
5. React components must not call API endpoints directly -- use custom hooks

For each violation, show the file, line number, and a suggested fix.

Opis PR-a, z którym recenzent ma co zrobić

Dobry opis odpowiada na trzy pierwsze pytania recenzenta, zanim otworzy diff: co się zmieniło, po co i gdzie patrzeć.

Wskazówka

Prompt copy-paste do opisu PR-a:

Generate a PR description based on the diff between this branch and main.

Structure:
## What
One sentence explaining what this PR does.

## Why
The problem this solves or the feature requirement it fulfills.

## How
A brief explanation of the approach taken, including any notable design decisions.

## What to review
The 2-3 areas where reviewer attention is most valuable.

## Testing
What tests were added or modified, and how to verify the changes manually.

Keep it concise. Do not list every file changed -- focus on what a reviewer needs to know.

Kod wygenerowany przez AI pod szczególnym nadzorem

Kod wygenerowany przez AI ma charakterystyczny wzorzec awarii: wygląda na poprawniejszy, niż jest. Funkcja bywa opakowana w try/catch, który łapie błędy i nic z nimi nie robi. Walidacja sprawdza trzy z czterech wymaganych pól. Struktura wygląda dobrze, choć zachowanie jest złe, i właśnie dlatego tak łatwo przepuścić to dalej.

Wskazówka

Prompt copy-paste do review kodu wygenerowanego przez AI:

I used Agent mode to generate the code in @src/services/notification-service.ts.

Review it with extra scrutiny for:
1. Plausible-looking code that actually does nothing (e.g., error handlers that swallow errors)
2. Hardcoded values that should be configurable
3. Mock-like patterns that accidentally made it into production code
4. Functions that look complete but miss edge cases
5. Dependencies that are imported but do not exist in package.json

This code was AI-generated, so do not assume any of it is correct. Verify everything.

Odpowiadanie na uwagi z review

Uwaga, której nie rozumiesz, kosztuje najwięcej czasu. Cursor wyjaśni tok rozumowania recenzenta, zanim zdecydujesz, czy ją przyjąć:

Wskazówka

Prompt copy-paste do adresowania uwag z review:

I received this review comment on my PR:

"[PASTE REVIEW COMMENT]"

The relevant code is in @src/[file-path].

Help me:
1. Understand what the reviewer is asking for
2. Determine if the suggestion is correct or if there is a reason the code is written this way
3. If the suggestion is valid, make the change
4. If I disagree, draft a response explaining my reasoning

Do not make changes unless I confirm the suggestion is valid.

Pipeline, który robi z tego kulturę pracy

Najskuteczniejsze zespoły traktują review AI jako pierwsze przejście, nigdy jako zamiennik:

1. Autor uruchamia Agent Review lokalnie przed wypchnięciem i naprawia oczywiste rzeczy, zanim PR w ogóle powstanie.
2. BugBot recenzuje PR-a automatycznie po otwarciu, łapiąc błędy, brakujące testy i problemy bezpieczeństwa zgodnie z regułami projektu.
3. Człowiek skupia się na architekturze, decyzjach projektowych i logice biznesowej — na ocenie, do której AI nadaje się najgorzej.
4. Autor adresuje uwagi z obu źródeł, oddając mechaniczne poprawki trybowi Agent.

AI odhacza listę kontrolną. Ty podejmujesz decyzje.

Gdzie review AI zawodzi

BugBot produkuje zbyt wiele fałszywych alarmów. Zwykle reguły projektu są zbyt szerokie albo wzajemnie sprzeczne. Zawęź je: zamiast “wszystkie funkcje muszą mieć obsługę błędów” napisz “funkcje async w src/api/ muszą opakować ciało w try/catch”. I spisz listę “Do not flag” — AI nie zgadnie, że formatowanie należy już do Prettiera.

Agent Review przepuszcza oczywiste błędy. Review jest tyle warte, ile model i kontekst, który dostał. Przy złożonej logice pytaj wprost: “Is there a case where this function returns undefined instead of throwing?” Celne pytania biją otwarte “przejrzyj ten kod”.

Review AI nie widzi błędów w logice biznesowej. Łapie rzeczy strukturalne. Funkcja licząca podatek na opak przejdzie każde review AI, o ile kod jest czysty. Poprawność logiki biznesowej zostaje na stałe odpowiedzialnością człowieka.

Review zamienia się w pieczątkę. Jeśli przyjmujesz wyniki AI bez czytania, tracisz problemy zależne od kontekstu, czyli dokładnie to, o co chodziło. Traktuj ustalenia jako punkt wyjścia własnego review, nie jako jego koniec.

Przepływ review na CLI dubluje komentarze. Workflow wyzwalany na synchronize recenzuje cały diff przy każdym pushu. Każ agentowi najpierw sprawdzić: “Before posting a comment, check if similar feedback already exists on nearby lines using gh pr view —json comments.”

Review trwa zbyt długo i blokuje PR-a. Ustaw limit czasu zadania w GitHub Actions — dziesięć minut zwykle wystarcza. Jeśli dalej się nie mieści, zawęź zakres do zmienionych plików zamiast całej bazy kodu.

Opisy PR-ów wychodzą ogólnikowe. “Zaktualizowano serwis” znaczy tyle, że AI nie miało dostępu do “po co”. Kontekst biznesowy dopisz w prompcie — to jedyna sekcja, której z diffa wywnioskować się nie da.

Dokąd dalej po ustawieniu review z AI

Polowanie na błędy Badaj problemy wskazane w review aż do przyczyny źródłowej.

Wzorce testowania Podnoś jakość kodu, zanim trafi do recenzenta.

Pipeline'y CI/CD Wepnij przepływ review w kompletny pipeline CI/CD.

Współpraca zespołowa Skaluj praktyki review i wspólne reguły na cały zespół.