Claude Code vs Cursor vs Copilot: zpráva z praxe týmu, který používá všechny tři

Koncem května 2026 GitHub spustil Claude Opus 4.8 uvnitř Copilota. Stejný model teď pohání nativní CLI od Anthropicu i IDE runtime od Microsoftu. O týden dřív GitHub publikoval framework čtyř fází AI adopce. Byznysová otázka se otevřeně posouvá z „který AI nástroj“ na „v jaké fázi je tým“.

Pro nás to není teoretická změna. DX Heroes nasazuje produkční kód se všemi třemi nástroji, napříč velmi rozdílnými stacky a klienty. Vidíme, jak se stejný model chová jako jiný produkt podle toho, v jakém wrapperu běží. Vidíme střední firmy, které spálily šestimístné částky na Github Copilota, který neodpovídal jejich inner loopu a nikdo ho nepoužil. Vidíme seniorní inženýry, kteří si poskládali workflow z Claude Designu, Cursoru a reálného typového systému, a vyšlo to rychleji než jakékoli demo od jednoho dodavatele.

Tohle jsme se z toho naučili. Ne feature matice, ta zestárne za pár týdnů. Mapa failure modů: kde každý nástroj vyhrává, kde padá, kterému týmu dnes skutečně sedí.

Claude Code je terminálový a agent-first. Jen modely od Anthropicu. Navržený na dlouho běžící úlohy, velké refaktoringy, custom skilly a multi-step agentní flows, do kterých lidé zasahují na hranicích. Tvůj shell, repo a filesystem bere jako prvotřídní kontext.

Cursor je IDE-nativní a multi-modelový. Stojí na rychlosti inner loopu: editor řídí kontext, diff je jednotka práce, model si vybíráš ten, který se ti dneska hodí. Nejlepší na cyklus prototype-to-production a na cestu z designu do kódu, kde má editor strukturovaný kontext už v sobě.

GitHub Copilot je IDE-nativní, multi-modelový (nově včetně Claude Opus 4.8) a pevně přilepený k GitHub estate: issues, pull requesty, Actions, Copilot Memory. Vyhrává hloubkou integrace v platformě, na které už enterprise stejně sedí.

Realita na stroji jednoho inženýra je často všechny tři najednou. Jak to suše shrnul Prokop z našeho týmu: „Dneska používám hodně Claude Code a Codex CLI a pouštím to typicky v Cursoru. Cursor jako takový už moc nepoužívám — pro mě je to editorová plocha.“ Wrappery si nekonkurují o stejnou minutu práce. Každý obsazuje jinou roli ve workflow.

Failure mode Claude Code je zřídka subtilní. S autonomními tool cally, agent módem a dlouhým kontextovým oknem klidně utratí hodiny nad špatně ohraničeným promptem a nevrátí rozumný výsledek.

Nejčistší příklad, který teď máme, je od Jakuba, na Claude Code 1.9659.3 s Opus 4.8:

Kubův přístup ukazuje, jak přistupovat k chybám AI nástrojů: konkrétní verze, konkrétní failure mode, známý baseline. To už je popis, se kterým se dá pracovat. „Claude Code je špatný” není správný závěr. Bez disciplíny se i větší a dražší model s objemnějším tool surfacem mění ve spoustu drahých tokenů spálených bez výsledku.

Lék je tvar úlohy. Menší plány, explicitní hranice, lidský checkpoint na každé smysluplné změně stavu. Několik lidí z týmu, kteří Claude Code používají jen na úzce vymezenou práci, problém s cyklením vůbec nevidí. Miloš to řekl natvrdo: drží se menších úkolů, kde se cyklení nemá kam chytit. Failure mode je reálný, ale je to scope úlohy, ne nástroj.

Stojí za zmínku ještě sekundární tření: přenositelné skilly. Prokop znovu, k mezeře mezi CLAUDE.md a cross-tool konvencí AGENTS.md, na kterou se ostatní nástroje sbližují:

Drobnost, dokud nechcete použít stejnou agent definici v Claude Code, Cursoru a Copilotu zároveň. Pak je to daň.

Cursor funguje, protože kontext řídí IDE. Diff je jednotka práce, editor zná tvoje otevřené soubory, LSP cpe typy do promptů a model si nemusí domýšlet, co znamená „codebase“. Přesně tam ale Cursor padá: ve chvíli, kdy práce opouští IDE.

Terminál-heavy infra práce, CLI-driven agenti, CI pipelines, dlouhá multi-file orchestrace. Cursor v té místnosti není. Správný krok je přepnout wrapper, ne tlačit Cursor do role, na kterou není stavěný. Většina našich seniorů to dělá přesně takhle: Cursor na inner loop, Claude Code na agent loop.

Cursor v naší zkušenosti nejvíc vyhrává na cestě z designu do kódu. Matyáš nám provedl svým workflow:

To je obrázek Cursoru v jeho nejlepším světle: strukturovaný upstream kontext (designovaný UI), reálná codebase, kterou editor rozumí, a model, který mezi tím překládá. Matyáš tak dokáže dostat wireframe do klikatelného prototypu a do první funkční verze rychleji než s jakýmkoli monolitickým generátorem, který jsme zkoušeli.

Tahle lekce platí obecněji. Cursor není kouzelné IDE; je to kontext-engineering plocha. Čím víc strukturovaný vstup, tím lepší výstup. Workflow je nacpat tech stack a designový záměr do editoru, ne čekat, že si je model vymyslí.

Po stránce funkcí Copilot za posledních dvanáct měsíců zavřel obrovskou mezeru. Agent mode, Memory, repository-scoped persistence, MCP tooling, AI-adoption cohorts v API. Wrapper je dnes skutečný produkt.

Poctivý enterprise failure mode je ale na komerční, ne na technické straně. Slevová křivka, která dělala Copilota atraktivní od 50 sedaček nahoru, se u prémiových modelů zhoršuje. K 1. červnu 2026 GitHub upravil, jak modely třídy Opus konzumují usage units uvnitř Copilota: výrazný skok multiplikátorů u nejnáročnějších modelů, který nejvíc dopadá na týmy, které tyto modely brzy adoptovaly. Prokop to zarámoval:

Přesné multiplikátory v textu nehoníme, protože GitHub iteruje pricing rychle. Důležitý je vzor: per-seat headline cena už není celý příběh. Memory, agentní funkce a modely třídy Opus tlačí spotřebu do jiných units a nákupní matiku je třeba přepočítat vždycky, když se cokoli z toho hne.

Kde Copilot skutečně vyhrává, je governance trust uvnitř GitHub estate. Prokop, který v těch místnostech seděl:

To není technické srovnání, je to nákupní realita. Pro dvousetčlennou vývojářskou organizaci, která už stojí na GitHub Enterprise, je „další AI dodavatel“ jiná diskuse než „rozšiřme Copilot“.

S Claude Opus 4.8 uvnitř Claude Code i Copilota se dá přímo porovnat, jak wrapper tvaruje stejný backbone. Dvě pozorování z našeho týmu se těžko odvidí.

Za prvé, paměť je vlastnost wrapperu, ne modelu. Jakub:

Stejný model, na druhé straně jiného wrapperu, žádnou srovnatelnou smyčku nemá. To není vlastnost modelu; je to vlastnost produktu.

Za druhé, plocha kontextu rozhoduje o tom, jaká práce je vůbec proveditelná. Claude Code ti dává plnou skill a agent surface; můžeš mu předat svůj shell, filesystem, custom MCP a opakovaně použitelné skilly. Copilot tě pevně váže k repository scope, GitHub Memory a pohledu IDE na svět. Pro refaktoring přes pět repozitářů je Claude Code ten wrapper, který sedí na práci. Pro cílenou změnu uvnitř jednoho repa, kde je GitHub konverzační historie součástí kontextu, je Copilot.

Vyber wrapper, který sedí na to, jak tým reálně pracuje, ne model, který nejlíp zní v press releasu.

Framework čtyř fází od GitHubu z konce května sedí na to, co vidíme v klientských projektech:

Namapovat tým na fázi je užitečnější než namapovat ho na nástroj. Tým v Fázi 1 z Claude Code nedostane hodnotu Fáze 3, ať jsou ty seaty jakkoli seniorní. Tým, který už neformálně jede Fázi 3 v Cursoru, zaplatí daň za přesun na Copilota bez jasného governance důvodu.

I přes vše, co jsme o wrapperech řekli, se obraz rozostří ve chvíli, kdy padne otázka, kterou CIO jednou stejně položí: používají to lidé bezpečně?

Jakub strávil poslední měsíce snahou ji zodpovědět z prostředí Copilota i Claude Code, ale jeho závěr nám ukazuje na ještě hlubší problém:

Prokop, který se na stejný problém dívá z pohledu produktového designu, došel nezávisle ke stejné diagnóze:

Dva seniorní inženýři, dva různé úhly pohledu, stejný závěr: vrstva wrapperu není místem, kde se governance řeší. Řeší se na úrovni protokolu. Memory, persistence, audit, inventář nástrojů a identita žijí pod IDE, a jakýkoli vážně myšlený multi-tool tým jednou potřebuje odpověď na téhle vrstvě. Víc jsme o tom napsali ve Stavíme MCP gateway pro enterprise a v přehledu řízení MCP; krátká verze je, že volba mezi Claude Code, Cursorem a Copilotem není governance rozhodnutí. Je to rozhodnutí o workflow. Governance rozhodnutí sedí pod všemi třemi.

Pokud máte 5–10 lidí v produktovém týmu a chcete tento kvartál zrychlit vaši práci: Cursor na inner loop, Claude Code na refaktoringy a agentickou práci, Copilot vynechte. Integrační režie se v téhle velikosti nevyplatí.

Pokud jste organizace nad 50 vývojářů uvnitř GitHub ekosystému: Copilot Business jako základ plus cílené Claude Code licence pro nejseniornějších 10 % na refaktoringy a agentní práci. Jak to řekl Jakub: „Pro skutečně velké enterprise týmy je nejdál GitHub Copilot, hlavně díky existující GitHub infrastruktuře.“ Opačné nasazení (Cursor první, Copilot druhý) je téměř vždycky pomalejší a dražší.

Pokud jste regulovaná nebo governance-first organizace: udělejte MCP governance práci dřív, než nasazujete nástroje. Standardizujte se na Copilotu jako wrapperu, Claude Code odsuňte do doby, než budete mít vnitřně dořešené nastavení skillů a identity agentů, a mezi každým wrapperem a vašimi reálnými systémy mějte MCP Gateway (nebo ekvivalent). Cena neřízeného rozrůstání nástrojů v regulovaném prostředí převyšuje jakýkoli rozdíl v produktivitě mezi wrappery.

A ať si vyberete cokoli, berte volbu nástroje jako rozhodnutí o workflow, nejde jen model. Prokop znovu:

Zní to jednoduše a je to jednoduché.

Dodáváme produkční kód v Claude Code, Cursoru i Copilotu. Vedeme školení přizpůsobená fázi adopce, ve které tým aktuálně je. Stavíme MCP governance pro enterprise, která je kompatibilní se všemi zmíněnými wrappery, aniž byste přišli o audit trail.

Pokud je váš tým uprostřed nasazování a failure mody popsané v tomto článku vám znějí povědomě, ozvěte se nám. Stejné otázky jsme prošli s engineering lídry od 10člennných produktových týmů po 500vývojářské enterprise organizace, a odpověď skoro vždycky začíná u workflow, ne u wrapperu.