Przejście na Cursor, Claude Code lub Codex: przewodnik migracji

Migracja zespołu na Cursor, Claude Code lub Codex to projekt w pięciu krokach: wybór narzędzia według tego, gdzie pracuje zespół, przeniesienie instrukcji i konfiguracji MCP wbudowanymi importerami, sprawdzenie narzędzia na własnym repozytorium zespołu jego zestawem testów, etapowe wdrożenie z kryteriami wyjścia i utrzymanie starego narzędzia, dopóki pomiary nie uzasadnią jego wyłączenia.

Twój zespół ma budżet na nowego agenta kodującego. Połowa programistów chce Claude Code w terminalu, druga połowa żyje w Cursorze, licencje Copilota odnawiają się w przyszłym miesiącu, a nikt nie zapisał, po czym poznacie, że zmiana się opłaciła. Ten przewodnik jest dla programisty lub tech leada, który odpowiada za tę zmianę, i dla CTO, który ją zatwierdza.

Co wyniesiesz z tego przewodnika migracji

• Tabelę decyzyjną, która przekłada sposób pracy zespołu na Cursor, Claude Code lub Codex.
• Polecenia importu, które przenoszą instrukcje, serwery MCP i skille, oraz prompt, który sprawdza, czego import nie przeniósł.
• Prompty do skopiowania, które testują nowe narzędzie na twoim kodzie, razem z bramkami rozstrzygającymi o wyniku.
• Etapowe wdrożenie z kryteriami wyjścia zamiast tygodni w kalendarzu, zestaw metryk z punktem odniesienia i plan wycofania.
• Listę kontrolną do wklejenia w zgłoszenie migracji.

Na które narzędzie przejść?

Odpowiedz na pięć pytań. Większości zespołów pasują dwie kolumny, a praca na dwóch narzędziach ze wspólnym AGENTS.md to normalny wynik, a nie brak decyzji.

Pytanie	Wskazuje na Cursor	Wskazuje na Claude Code	Wskazuje na Codex
Gdzie mija większość czasu pracy nad kodem?	W edytorze, z wizualnym diffem	W terminalu, skryptach i CI	Na kilku powierzchniach: aplikacja desktopowa, CLI, rozszerzenie IDE, zadania w chmurze
Co najbardziej chcesz oddać agentowi?	Interaktywne zmiany w wielu plikach, które obserwujesz	Długie autonomiczne sesje, hooki, uruchomienia headless	Równoległe zadania i code review pull requestów
Które integracje muszą dalej działać?	Rozszerzenia VS Code, Bugbot na pull requestach	GitHub Actions (anthropics/claude-code-action@v1), hooki, pluginy	@codex review na GitHubie, @ChatGPT w Slacku i @Codex w Linearze (według dokumentacji OpenAI, sprawdzone 2026-10-12)
Jak dobrze zespół czuje się w terminalu?	Woli GUI	Pracuje w terminalu na co dzień	Różnie
Jakie ograniczenia dotyczą dostawcy lub danych?	Privacy Mode jest domyślnie włączony dla zespołów, a maszyny self-hosted trzymają wykonywanie narzędzi w twojej sieci (dokumentacja Cursora, sprawdzone 2026-10-12); warunki dostawców modeli potwierdź z Cursorem przed pilotażem	Działa na API Anthropic, Amazon Bedrock, Agent Platform w Google Cloud, Microsoft Foundry i Claude Platform on AWS	Plany ChatGPT lub klucz API, który obejmuje tylko CLI, SDK i rozszerzenie IDE (strona cennika Codeksa OpenAI, sprawdzone 2026-10-12); dostawca Amazon Bedrock

Zacznij od domyślnego modelu każdego narzędzia i zmieniaj go dopiero wtedy, gdy każą ci to twoje własne ewaluacje. Nazwy i ceny modeli są w przeglądzie modeli, ceny planów w analizie cen, a porównanie funkcja po funkcji w macierzy funkcji. Jeśli bierzesz pod uwagę także agentów spoza wielkiej trójki, przegląd rynku agentów kodujących zawiera protokół porównania (bake-off) używany w całym serwisie.

Co spisać przed zmianą narzędzia?

Wpisz odpowiedzi w zgłoszenie migracji, zanim ktokolwiek cokolwiek zainstaluje. Z tą inwentaryzacją porównasz potem wynik importu i promptu audytowego.

• Z czego odchodzisz: narzędzia, liczba licencji i data odnowienia każdej subskrypcji.
• Na co przechodzisz: jedno narzędzie albo dwa ze wspólnym plikiem instrukcji.
• Istniejąca konfiguracja: pliki instrukcji (.cursor/rules/, CLAUDE.md, AGENTS.md), serwery MCP i miejsce, w którym trzymają poświadczenia, skille, pluginy, hooki i zadania CI, które wywołują agenta.
• Wymogi zgodności: SOC 2, RODO, HIPAA, retencja danych i dostawcy modeli dozwoleni w waszych umowach.
• Ludzie: dwie lub trzy osoby do pilotażu o różnym stażu i jeden właściciel wspólnej konfiguracji.
• Punkt odniesienia i reguła decyzji: metryki z sekcji skąd wiesz, że zmiana się udała, zmierzone przed pilotażem, oraz warunki wycofania.

Przenieś konfigurację

Każde narzędzie trzyma te same trzy warstwy w innych miejscach: instrukcje projektu, serwery MCP i skille. Pluginy się nie przenoszą: każde narzędzie ma własne marketplace’y, więc zainstaluj odpowiednik od nowa. Format Agent Skills jest wspólny, więc folder ze SKILL.md działa we wszystkich trzech narzędziach, gdy trafi do właściwego katalogu.

Claude Code

Claude Code (v2.1.296) importuje z Codexa, Gemini CLI i Cursora. Uruchom import w repozytorium, najpierw na sucho:

claude import cursor --dry-run   # or: codex, gemini
claude import cursor             # opens a picker; choose what to bring over
claude mcp list                  # confirm each imported server connects

Według dokumentacji poleceń Anthropic (sprawdzonej 2026-10-12) import przenosi pliki instrukcji, serwery MCP, polecenia, subagentów i skille. Wymaga v2.1.213 lub nowszej, a dla Cursora v2.1.265 lub nowszej. Nie działa na Amazon Bedrock, Agent Platform w Google Cloud, Microsoft Foundry, Claude Platform on AWS ani przez Claude apps gateway.

Żeby utrzymać jedno źródło instrukcji, zrób z CLAUDE.md jednoliniowy plik z @AGENTS.md. Ten import działa na każdym kanale wydań, a wbudowany mechanizm Claude Code (czytanie AGENTS.md, gdy nie ma CLAUDE.md) wymaga v2.1.277 lub nowszej (oba kanały wydań, stan na 2026-10-12).

Codex

Codex CLI ma /import (0.162.1, sprawdzone 2026-10-12). Uruchom codex w repozytorium i wpisz je, a zaproponuje „import setup, this project, and recent chats from Claude Code”. Według notatek do wydań 0.145.0 i 0.147.0 import obejmuje konfiguracje z Claude Code i Cursora: ustawienia, serwery MCP, pluginy, sesje, polecenia i skille zarządzane przez Cursora. Potem sprawdź serwery z terminala:

codex mcp list

Codex czyta AGENTS.md natywnie; /init utworzy ten plik, jeśli import nie przeniósł twoich reguł. Skille projektu trafiają do .agents/skills/.

Cursor

Cursor czyta większość wspólnej konfiguracji tam, gdzie już leży (dokumentacja i pomoc Cursora, sprawdzone 2026-10-12). Obsługuje AGENTS.md w katalogu głównym projektu i w podkatalogach, a CLAUDE.md czyta tak samo i zawsze stosuje, więc nie potrzebujesz wygenerowanej reguły projektu. Ładuje skille z .agents/skills/ i .cursor/skills/, a dla zgodności także z .claude/skills/ i .codex/skills/; npx skills add <owner/repo> nadal instaluje skill z repozytorium. Reguły dotyczące tylko niektórych plików wpisz w .cursor/rules/*.mdc (zwykły plik .md w tym katalogu jest ignorowany, a .cursorrules to rozwiązanie przestarzałe, legacy); format opisuje strona reguły projektu. Napisz .cursor/mcp.json ręcznie. Na dzień 2026-09-26 nie potwierdziliśmy wbudowanego importera w Cursorze, więc potraktuj przeprowadzkę jako ręczną. Cursor nie potrzebuje wygenerowanej kopii AGENTS.md; o utrzymywaniu jednego wspólnego pliku reguł w zgodzie między narzędziami mówi artykuł jedno źródło reguł dla każdego agenta.

Wersja krok po kroku dla przejścia między tymi trzema narzędziami, z konfiguracją MCP dla każdego z nich i testem w CI, który nie pozwala plikom instrukcji się rozjechać, jest w artykule migracja między Codexem, Cursorem i Claude Code.

Prompt do skopiowania: audyt tego, czego import nie przeniósł

We are migrating this repository from Cursor to Claude Code. Compare the old
configuration with the new one and report every gap. Read everything under
.cursor/rules/, .cursor/mcp.json, AGENTS.md, CLAUDE.md, .mcp.json, and .claude/
(skills, agents, settings.json).

Produce a table with one row per rule, command, MCP server, and skill: where it
lived before, where it lives now, and one of MIGRATED, MISSING, DUPLICATED, or
CHANGED. Flag any instruction that now exists in two files, any MCP server whose
credential is written inline instead of read from an environment variable, and
any skill that did not come from this repository or a vendor marketplace.

Do not edit any file. End with the three gaps most likely to change how the
agent behaves on this codebase.

Przy przejściu na Codex zamień docelowe ścieżki na ~/.codex/config.toml i .agents/skills/.

Sprawdź nowe narzędzie na własnym kodzie

Demo dostawcy nic nie mówi o twoim repozytorium. Wybierz trzy zgłoszenia zamknięte w ostatnim sprincie: proste, średnie i trudne, z poprawkami, którym ufasz. Dla każdego utwórz gałąź z commita sprzed poprawki, daj nowemu narzędziu treść zgłoszenia i oceń wynik tymi samymi bramkami, które uruchamia twoje CI, a nie czytaniem każdej linii.

Wynik przechodzi, gdy przechodzą istniejące testy i testy ze scalonej poprawki, type checker i linter są czyste, a diff nie dodaje zależności, o którą nikt nie prosił. Dla każdego zadania zapisz, czy przeszło za pierwszym podejściem, ile razy ktoś musiał interweniować i ile limitu zużyło (/usage zarówno w Claude Code, jak i w Codexie). Jeśli wybierasz między dwoma narzędziami, uruchom te same trzy zadania w obu. Decyzję o pilotażu opiera się na tym zapisie, a nie na wrażeniu z lektury diffa. Pakiet dowodów definiuje, co pull request agenta powinien dać recenzentowi.

Prompt do skopiowania: walidacja pierwszego dnia z bramkami

Read AGENTS.md (or CLAUDE.md) and the src/services/ directory. For each service
file, check that every async function handles errors, that multi-step database
writes run inside a transaction, and that a matching test file exists under
tests/. Report the gaps as a table before changing anything.

Then fix the three gaps with the highest production risk, one commit each.
After each fix, run the test suite, the type checker, and the linter, and paste
the exact commands and their final output lines. If a gate fails, fix the cause
or revert that commit. Do not weaken, skip, or delete a test. Finish with every
file you changed and one line on why.

Programiści, którzy nigdy nie oddali zadania agentowi, powinni zacząć od pracy, która nie może zepsuć produkcji. Testy charakteryzacyjne to najbezpieczniejsze pierwsze zadanie, bo dodają tylko pliki, a przebieg testów pokazuje, czy agent zrozumiał kod.

Prompt do skopiowania: bezpieczne pierwsze zadanie dla nowego użytkownika agenta

Look at src/services/UserService.ts and its existing tests. List the public
methods and edge cases that no test covers. Write tests that pin down the
current behaviour, including error paths. Do not modify any file outside
tests/. Run the new tests and show the output.

If a test fails against the current code, do not change the code. Leave the
test in place with a comment that describes the behaviour you found, and list
it for me as a possible bug.

Co się zmienia w zależności od narzędzia, z którego odchodzisz?

Konfigurację przeniesiesz w jedno popołudnie. Nawyki zmieniają się dłużej i zależą od punktu startu.

Odchodzisz od	Co się przenosi	Nawyk do zmiany	Szczegółowy przewodnik
GitHub Copilot	Agent Skills i serwery MCP, które Copilot też obsługuje. Copilot ma dziś agenta w chmurze (cloud agent), CLI i aplikację desktopową, więc wiele zespołów dodaje drugie narzędzie zamiast go wymieniać	Akceptowanie podpowiedzi linia po linii → przekazanie całego zadania z kryteriami akceptacji	Claude Code lub Codex obok Copilota
ChatGPT w przeglądarce	Tylko twoje prompty	Wklejanie kodu i błędów → pozwolenie agentowi czytać repozytorium i uruchamiać polecenia	Od zwykłego czatu do zintegrowanego developmentu
Devin Desktop (dawniej Windsurf)	Reguły, serwery MCP; workflowy stają się skillami	Ufanie wyzwalaczom reguł, których nikt nie przetestował → sprawdzenie, że reguły działają	Migracja z Devin Desktop
Inne narzędzie z wielkiej trójki	Prawie wszystko: przez importery opisane wyżej i dlatego, że Cursor czyta AGENTS.md, CLAUDE.md oraz foldery skilli Claude i Codexa tam, gdzie leżą	Oczekiwanie tych samych domyślnych uprawnień i pracy równoległej	Migracja między Codexem, Cursorem i Claude Code
IDE bez AI	Ustawienia edytora i skróty klawiszowe	Pisanie każdej linii → specyfikowanie zachowania i weryfikacja bramkami	Migracja z tradycyjnych IDE

Claude Code i Codex to przede wszystkim agenci. Jeśli zespół polega na podpowiedziach w trakcie pisania, zostaw obok agenta edytor, który je daje, na przykład Cursor z Tab.

Wdrażaj w zespole etapami

Przechodź do kolejnego etapu, gdy spełnione jest jego kryterium wyjścia, a nie gdy każe kalendarz. Kryteria sprawiają, że wdrożenie samo się sprawdza: etap, który nie spełnia kryterium, mówi ci, co naprawić, zanim więcej osób zacznie od niego zależeć.

1. Pilotaż z dwiema lub trzema osobami. Wybierz różny staż i różne części kodu. Uczestnicy przechodzą zadania walidacyjne opisane wyżej, potem prawdziwe zgłoszenia, i commitują wspólną konfigurację. Wyjście, gdy zadania porównawcze przechodzą bramki, a pilotaż spisał, co się zepsuło. Kohorty i reguły decyzji opisuje projekt pilotażu, który czegoś dowodzi.

2. Pierwsi użytkownicy, około jednej czwartej zespołu. Opublikuj krótki wewnętrzny przewodnik konfiguracji zbudowany z notatek z pilotażu, otwórz jeden kanał na pytania i wyznacz właściciela AGENTS.md. Wyjście, gdy nowa osoba konfiguruje wszystko z samego przewodnika w jednym podejściu, a kolejka code review nie rośnie.

3. Wszyscy. Szkol na własnym repozytorium, a nie na ogólnych demo, i prowadź dyżury przez pierwszy miesiąc. Każdy pull request agenta przechodzi te same bramki CI co pull request człowieka. Wyjście, gdy metryki z sekcji niżej są w punkcie kontrolnym na poziomie punktu odniesienia lub lepsze.

4. Wyłącz stare narzędzie. Anuluj stare licencje po ostatnim punkcie kontrolnym, usuń stare pliki instrukcji, gdy nowe są jedynym źródłem, i przenieś pozostałą automatyzację (boty do code review, zadania CI).

Uwaga

Nie pomijaj pilotażu. Wdrożenie dla wszystkich naraz nie ma wewnętrznego eksperta, który odpowie na pytania, wspólnej konfiguracji ani punktu odniesienia, więc pierwszy zły tydzień staje się wyrokiem dla narzędzia. O ludzkiej stronie wdrożenia piszą artykuły adopcja w zespole i jak pomóc zespołowi przestać czytać każdy diff.

Skąd wiesz, że zmiana się udała?

Zanim ruszy pilotaż, zmierz punkt odniesienia z ostatnich jednego do trzech miesięcy historii gita i CI, a potem porównuj go w każdym punkcie kontrolnym. Cele ustal względem tego punktu i zapisz regułę decyzji przed pierwszym tygodniem. Deklarowane przyspieszenie nie jest dowodem. Kontynuacja badania METR z 2026 roku, dotycząca narzędzi AI w pracy nad open source, dała przedziały ufności przechodzące przez zero, a sam METR pisze, że nowe wyniki są „hard to interpret” (METR, repozytorium badania, odczyt 2026-09-26). Raport DORA z 2025 roku ujmuje ryzyko wprost: „AI doesn’t fix a team; it amplifies what’s already there” (blog Google Cloud DORA, 2025-09-23).

Metryka	Jak ją mierzyć	Co mówi
Czas od zgłoszenia do scalonego pull requesta	Znaczniki czasu z trackera i gita, mediana	Czy praca faktycznie płynie szybciej
Odsetek zielonych pierwszych przebiegów CI	Udział pull requestów, których pierwszy przebieg CI jest zielony	Czy agent spełnia bramki bez poprawek
Odsetek revertów lub nieudanych zmian	Reverty i hotfixy na scalony pull request	Czy szybkość kosztuje stabilność
Czas code review na pull request	Czas od prośby o review do akceptacji	Czy code review stało się wąskim gardłem
Koszt zaakceptowanej zmiany	Licencje, zużycie, CI i poprawki podzielone przez scalone, niecofnięte zmiany	Czy zmiana się opłaca; metoda jest w artykule ekonomia oprogramowania budowanego przez agentów
Satysfakcja i faktyczne użycie	Krótka anonimowa ankieta (1–5) i dzienni aktywni użytkownicy	Czy ludzie zostaną przy narzędziu

Definicje, które przetrwają kod pisany przez agentów, są w artykule DORA, SPACE, DX Core 4 i pomiar AI.

Prompt do skopiowania: punkt odniesienia z historii gita

Using git and the gh CLI in this repository, build a baseline for the last 90
days. List merged pull requests with
`gh pr list --state merged --limit 500 --json number,createdAt,mergedAt,title`,
then compute: the median hours from creation to merge, the number of merged
pull requests per week, and how many commits on the default branch are reverts
(`git log --oneline --grep '^Revert'`). Show every command you ran and its
output, put the results in a table, and save it as docs/migration-baseline.md.
Do not change any other file.

Zaplanuj wycofanie, zanim będzie potrzebne

Plan wycofania pisany po pierwszym złym tygodniu to negocjacje. Wpisz go w zgłoszenie migracji od razu:

1. Zachowaj stare licencje do ostatniego punktu kontrolnego. Nie odnawiaj rocznego planu starego narzędzia, ale nie anuluj go, zanim nowe nie przejdzie swoich punktów kontrolnych.
2. Trzymaj starą konfigurację w gicie. Stare pliki reguł zostają w repozytorium, dopóki nowe narzędzie nie przejdzie tych samych zadań walidacyjnych, więc powrót to checkout, a nie przepisywanie.
3. Zdefiniuj mierzalne warunki. Na przykład: odsetek revertów jest powyżej punktu odniesienia w dwóch kolejnych punktach kontrolnych, spada odsetek zielonych pierwszych przebiegów CI albo przegląd zgodności blokuje dostawcę.
4. Ustal punkty kontrolne po 30, 60 i 90 dniach. Decyduj na podstawie metryk, a nie najgłośniejszej opinii na retro.
5. Dopuść wyjątek z datą. Osoba, która utknęła, może zostać przy starym narzędziu do wskazanego dnia, co kosztuje mniej niż wymuszona zmiana, która zatrzymuje jej pracę.

Co się psuje, gdy zespół zmienia narzędzie AI do kodowania?

Agent ignoruje polecenia budowania, których stare narzędzie zawsze przestrzegało. Dwa pliki instrukcji mówią co innego albo ktoś ma wersję Claude Code starszą niż v2.1.277 i nie dostaje obsługi AGENTS.md. Naprawa: jeden AGENTS.md, CLAUDE.md z linią @AGENTS.md i test w CI, który zawodzi, gdy ta linia zniknie (synchronizacja reguł).

Importer jest niedostępny. /import w Claude Code nie działa na Bedrock, Agent Platform w Google Cloud, Microsoft Foundry, Claude Platform on AWS, przez Claude apps gateway ani z wyłączonym pobieraniem flag funkcji. Naprawa: uruchom podgląd importu na maszynie z bezpośrednim dostępem do API albo przenieś konfigurację ręcznie, traktując prompt audytowy jako listę kontrolną.

Serwer MCP działa w jednym narzędziu, a w drugim nie. Claude Code negocjuje specyfikację MCP 2026-07-28 z bezpośrednimi serwerami HTTP (a od v2.1.292 także z lokalnymi serwerami stdio; 2026-10-17 oba kanały wydań), a Codex 0.157.1–0.162.1 nadal używa starszego protokołu (mcp_2026_07_28 jest w budowie i wyłączone w codex features list, sprawdzone 2026-10-12). Naprawa: sprawdź każdy serwer przez claude mcp get <name> i codex mcp get <name>, przypnij wersję serwera i sprawdź w jego changelogu obsługę specyfikacji.

Zaimportowane skille, których nikt nie przejrzał. Importery kopiują skille w całości. OWASP Agentic Skills Top 10 (wersja przed publikacją, ostatnia aktualizacja w marcu 2026) wymienia ponowne użycie między platformami i dryf aktualizacji jako nazwane ryzyka. Naprawa: przeczytaj każdy SKILL.md przed pilotażem, zostaw tylko skille z własnego repozytorium lub marketplace’u dostawcy i przypnij wersje.

Programiści albo akceptują całe diffy, albo przepisują wszystko. Oba zachowania to problem kalibracji zaufania. Naprawa: niech decydują bramki, zaczynaj od zadań wyłącznie testowych i przenieś code review z diffa na dowody, jak opisuje czytanie dowodów zamiast kodu.

Spadek wydajności jest niewidoczny, bo nikt nie zmierzył punktu odniesienia. Bez niego pierwszy wolny tydzień wygląda jak dowód porażki narzędzia. Naprawa: uruchom prompt z punktem odniesienia teraz; historia gita pozwala go odtworzyć wstecz.

Limity kończą się w połowie pilotażu. Subskrypcje Claude Code i Codexa liczą zużycie w oknach pięciogodzinnych i tygodniowych (plany Pro w Codeksie obecnie nie mają limitu pięciogodzinnego, według strony cennika OpenAI, odczyt 2026-10-12). Naprawa: obserwuj /usage w trakcie porównania i dobierz plany według analizy cen przed pełnym wdrożeniem.

Lista kontrolna migracji do zgłoszenia

Wklej ją w zgłoszenie migracji i odhaczaj po kolei.

• Inwentaryzacja spisana: narzędzia, licencje, daty odnowień, konfiguracja, wymogi zgodności
• Narzędzie docelowe wybrane z tabeli decyzyjnej, a wszystko krytyczne sprawdzone w macierzy funkcji
• Punkt odniesienia zmierzony z historii gita i CI; reguła decyzji i warunki wycofania spisane
• Podgląd importu przejrzany; prompt audytowy uruchomiony; jeden AGENTS.md w repozytorium
• Serwery MCP dodane i sprawdzone w każdym narzędziu; poświadczenia czytane ze zmiennych środowiskowych
• Skille przejrzane i przypięte; pluginy zainstalowane z marketplace’u nowego narzędzia
• Trzy zamknięte zgłoszenia powtórzone w nowym narzędziu i ocenione bramkami
• Uczestnicy pilotażu wyznaczeni; wewnętrzny przewodnik i kanał na pytania gotowe
• Punkty kontrolne po 30, 60 i 90 dniach w kalendarzu
• Anulowanie starych licencji zaplanowane po ostatnim punkcie kontrolnym

Dokąd dalej z migracją

Migracja między Codexem, Cursorem i Claude Code Jeden AGENTS.md, polecenia importu, MCP w każdym narzędziu i test zgodności.

Projekt pilotażu, który czegoś dowodzi Kohorty, punkt odniesienia i reguła decyzji podpisana przed pierwszym tygodniem.

Analiza cen Ceny planów trzech narzędzi w jednym miejscu.

Claude Code: szybki start Od instalacji do pierwszego zadania w terminalu.

Codex: szybki start Konfiguracja CLI, aplikacji i AGENTS.md.

Cursor: szybki start Reguły projektu, MCP i pierwsza funkcja w edytorze.