Migrace je ten nejhorší typ práce pro AI agenta v chatu. Snadno se začne — přepsat první modul zvládne každý — ale po třicátém souboru ztratíš přehled: co je hotové, co čeká na review a co agent vlastně rozbil. Cursor Projects, které Cursor spustil 10. září 2026 jako betu, řeší přesně tuhle situaci: místo jednoho chatu dostaneš koordinátora, který migraci rozseká na desítky paralelních agentů a drží kontext přes týdny práce. Ukážu ti, jak takovou migraci nastavit — koordinátora, sdílený kontext a hlavně ledger, jediný zdroj pravdy o stavu migrace.
Proč se dlouhé migrace v chatu zaseknou
Znáš to. Otevřeš nový chat, vysvětlíš projekt od nuly, agent přepíše tři soubory a skončí. Za hodinu otevřeš další okno — a zase vysvětluješ. Mezitím nevíš, jestli je modul auth už hotový, nebo jestli na něm dělá jiný agent z vedlejšího okna. Review se ti hromadí, CI řve a po týdnu migraci rezignuješ.
Cursor sám používá Projects na migrace, které „se snadno začínají a těžko dokončují" — například přechod na nový styling systém napříč stovkami pull requestů. Podle oznámení z 10. září 2026 mergují uživatelé, kteří primárně používají Projects, šestkrát víc PR než běžní uživatelé (noví uživatelé průměrně o 30 % víc). Rozdíl není v modelu, ale v tom, jak je práce zorganizovaná.
Jak Cursor Projects fungují
Projekt založíš v levém panelu Agents Window → sekce Projects → New Project. Vybereš ikonu a název, pod Workspace repozitář (projekty běží na cloudových agentech, takže nabídka ukazuje repozitáře dostupné tvým cloud agentům — případně se nabídne Connect GitHub) a pod Model model, který bude koordinátor používat. Pak popíšeš, co chceš postavit, a koordinátor přebírá řízení.
Tři mechanismy z toho dělají jiný způsob práce než chat:
- Koordinátor nekóduje. Plánuje, zakládá a řídí agenty, kteří kód píšou, a přináší ti hotovou práci ke kontrole. Protože práci jen deleguje, nikdy není zablokovaný — odpovídá ti hned, i když pod ním běží desítky agentů paralelně.
- Cloud jako výchozí stav. Projekt běží na vlastním počítači v cloudu, takže zavření notebooku ho nezastaví. Když je potřeba otestovat něco na tvém stroji, koordinátor spustí lokálního agenta.
- Sdílený kontext. Každý projekt drží sadu souborů synchronizovaných na všechny stroje, kde jeho agenti běží. Agenti do nich zapisují, co zjistili — jak se spouštějí testy, kde je nastavená služba, jak chceš skládat PR. Další agent si to přečte, než začne. Kontext roste s projektem a koordinátor je časem efektivnější.
K tomu subscriptions: koordinátor umí sledovat Slack kanál, běžet podle rozvrhu nebo hlídat všechny tvé PR — opravuje CI a reaguje při otevření či mergi. Jakmile má aspoň jednu subscription, nad vstupem chatu se objeví pilulka Listening, kde vidíš všechny události, na které projekt poslouchá.
Dostupnost Projects jsou na každém tarifu, který zahrnuje Cloud Agents — Premium a vyšší, Teams, Enterprise (od verze 3.21.9) a starší placené tarify. Na Free, Plus a legacy Hobby nejsou a nefungují ani v Privacy Mode (Legacy), protože cloud agenti při běhu ukládají kód do cloudu. Přehled tarifů máme v článku Cursor cena 2026.
Příprava: sdílený kontext a ledger
Zkušenost z praxe i z toho, jak Projects používá sám Cursor: migrace se nerozbíjí koordinátorovi, ale špatnou přípravou podkladů. Než napíšeš první pokyn, připrav si dva soubory.
Spec migrace do sdíleného kontextu
První soubor je specifikace migrace — dejme tomu migration-spec.md. Popisuje:
- co za co se přepisuje (např. „styly ze styled-components na Tailwind, mapování utilit v tabulce níže"),
- jak se pozná hotový modul (kritéria: žádný import starého systému, testy prochází, vizuální diff v pořádku),
- jak se testuje (přesný příkaz, který agent spustí po každé změně — když jeden agent zjistí, jak testovat službu, každý další už to má),
- jak má vypadat PR (rozsah, pojmenování větve, popisek, co do review).
Tenhle soubor je důvod, proč Projects fungují: nezačínáš s každým agentem od nuly. Napiš ho jednou pořádně a koordinátor ho použije pro stovky delegací.
Ledger: jediný zdroj pravdy o stavu
Druhý soubor je ledger — stavová tabulka migrace, například migration-ledger.md. Jako jediný ví, co je hotové, co je v práci a co čeká:
# Ledger migrace na Tailwind
| Modul | Stav | PR | Poznámky |
|------------------|-----------|------|------------------------------|
| components/button | hotovo | #412 | merged 12. 10. |
| components/modal | v review | #438 | čeká na vizuální diff |
| pages/checkout | v práci | — | agent spuštěn 16. 10. |
| pages/settings | čeká | — | závisí na components/modal |
Pravidlo pro koordinátora i agenty: před zahájením úkolu si přečti ledger, po mergi ho aktualizuj. Tím odpadne dvojí práce, opakování hotového i migrace, která „byla skoro hotová" — buď je, nebo není, a ledger rozhodne.
Tip Ledger drž v jednoduchém markdownu. Koordinátor ho umí číst i psát, a čím prostší formát, tím méně chyb při aktualizaci.
Jak rozdělit migraci mezi agenty krok za krokem
Krok 1: Založ projekt pro migraci
New Project → workspace na repozitář → model → Create. Jeden projekt = jedna migrace. Nemíchej do něj feature práci ani bugfixy, jinak ledger a kontext ztratí význam.
Krok 2: Naplň sdílený kontext
Nech koordinátora, ať jako první úkol přečte repo a zapíše do sdíleného kontextu, co se dozvěděl: struktura, jak se builduje, jak se testuje. Pak doplň svůj migration-spec.md a migration-ledger.md. Překontroluj je — chyba ve specu se zkopíruje do každého dalšího PR.
Krok 3: Zadávej šarže, ne celou migraci
Koordinátorovi nepiš „přepiš celý frontend". Rozděl migraci na šarže po pěti až deseti modulech a požádej o malé, samostatně reviewovatelné PR:
„Podle ledgeru vezmi dalších 5 modulů se stavem ‚čeká', dodrž migration-spec.md, pro každý modul založ samostatný PR podle pravidel ve specu a po otevření PR aktualizuj ledger."
Malé PR se rychle reviewují, snadno revertují a koordinátor mezi nimi pěkně aktualizuje ledger.
Krok 4: Napoj subscriptions na PR a CI
Řekni koordinátorovi, ať sleduje PR migrace: opravuje padající CI, reaguje na komentáře v review a po mergi zaktualizuje ledger a spustí další šarži. Tím se projekt chová jako kolega, který nikdy nespí — i když máš zavřený notebook. Zkušenosti s cloud agenty obecně shrnuje článek Cursor Background Agents.
Krok 5: Postupně uber nohu z review
Ze začátku kontroluj každý PR pečlivě a korekce piš zpátky do specu — projekt se učí tvoje preference. Jak se PR začnou opakovaně držet specu, stáhni review na vzorky. Přesně takhle to popisuje Cursor: na začátku reviewuješ každý PR, jakmile se opravy drží, reviewuješ méně a koordinátor migruje dál sám. Jejich design-system projekt tak dorostl na 20–100 PR denně, přičemž inženýr už jen dohlíží na místa, kde je pozornost potřeba.
Kdy Projects na migraci nepoužívat
- Jednorázová práce na pár souborech — zbytečný overhead, stačí obyčejný agent v chatu.
- Free nebo Plus tarif — Projects vyžadují Cloud Agents, tedy Premium a výš.
- Privacy Mode (Legacy) — cloud agenti ukládají kód do cloudu, s legacy privacy režimem nejsou dostupné.
- Migrace, kde každý krok vyžaduje individuální design rozhodnutí — Projects září u práce s jasnými pravidly a měřitelným stavem, ne u kreativního redesignu.
Pokud nechceš přesedlávat na Cursor, podobný vzorec — koordinace paralelních agentů se sdíleným stavem — jde postavit i v Claude Code, jak popisujeme v článku Claude Code projekty: deleguj práci na paralelní thready. Rozdíl je v tom, že Cursor má koordinátora, cloud a sdílený kontext zabudované přímo v editoru; detaily najdeš v oficiální dokumentaci Projects a na stránce nástroje Cursor.
Časté otázky
Běží Cursor Projects i když zavřu notebook?
Ano. Projekt běží na vlastním počítači v cloudu, takže zavření notebooku ho nezastaví. Když je potřeba něco otestovat lokálně na tvém stroji, koordinátor k tomu spustí lokálního agenta.
Jsou Cursor Projects dostupné ve Free tarifu?
Ne. Projects jsou součástí tarifů, které zahrnují Cloud Agents: Premium a vyšší, Teams, Enterprise (od verze 3.21.9) a starší placené tarify. Na Free, Plus a legacy Hobby tarifu funkce není.
Jak poznám, že dva agenti nedělají na stejném modulu?
Přes ledger. Pokud má každý agent za pravidlo přečíst stavovou tabulku před zahájením práce a koordinátor přiděluje moduly podle sloupce „Stav", nemůže se stát, že dva agenti řeší totéž. Proto je důležité ledger zavést dřív, než pustíš první šarži.
Kolik pull requestů denně projekt zvládne?
Záleží na velikosti PR a rychlosti review. Cursor uvádí, že jejich interní design-system projekt je na dráze 20–100 PR denně — ale jen proto, že review se postupně zredukovalo na vzorky a koordinátor práci organizuje sám.
Můžu s koordinátorem mluvit česky?
Ano, koordinátorovi můžeš psát česky. Spec a ledger ale drž anglicky — sdílený kontext čtou všichni agenti a případní kolegové v týmu, a angličtina je u kódu bezpečnější výchozí volba.
Závěr
Dlouhá migrace neselhává na kvalitě modelu, ale na organizaci práce. Cursor Projects ji řeší třemi vrstvami: koordinátor, který deleguje a nikdy není zablokovaný, sdílený kontext, díky kterému žádný agent nezačíná od nuly, a ledger jako jediný zdroj pravdy o stavu. Založ projekt, napiš spec a ledger, zadávej šarže malých PR, napoj subscriptions na CI a review postupně uvolni. Migrace, která by se v chatu rozpadla po týdnu, doběhne sama do konce — a ty se vrátíš k práci, která vyžaduje člověka.
