Codex vs Claude Code: co se mění, když editor přestane být jen editor

Ještě nedávno znamenal „AI v editoru“ autocomplete, který doplnil tři řádky, a ten zbytek jste dopsali sami. Dnes znamená agenta, který si přečte issue, projde si repo, navrhne změnu, spustí testy a otevře PR. Mezi těmito dvěma věcmi není jen větší tlačítko — je to změna v tom, co je editor. Z nástroje pro psaní kódu se stal koordinační prostor pro něco, co pracuje rychleji než člověk a jinak než člověk. Codex a Claude Code jsou dva nejviditelnější zástupci téhle změny. Otázka pro praxi není „který je lepší“, ale „čím se liší, kdy jim svěřit práci a kde držet hranice“.

01Dva režimy práce s agentem

Codex a Claude Code se postupně k sobě přibližují — oba dnes mají lokální i cloudovou variantu, oba zvládají interaktivní práci i asynchronní úkoly. Pořád ale vyrostly z opačných konců a ten původ se v defaultech, ceně a integraci pořád projevuje: Codex přišel jako cloudový, asynchronní agent napojený na ekosystém OpenAI, Claude Code jako terminálový nástroj sedící developerovi u ruky. Pokud řešíte volbu, tohle je rozdíl, který stojí za otestování na vašem repu — ale není to to nejdůležitější rozhodnutí. Důležitější otázka zní: jaký režim práce s agentem si v týmu vědomě nastavíte? Dva režimy se ustálily a každý si vynucuje jinou disciplínu kolem sebe.

Cloud-first asynchronní agent. Zadáte úkol přes webové rozhraní nebo ticket, agent běží sám v sandboxovém prostředí, výsledkem je PR, který otevřete a zkontrolujete. Pracujete s agentem jako s juniorním kolegou: dáte zadání, on něco udělá, vy review. Hodí se na práci, která jde popsat textem a má jasné akceptační kritérium (test, lint, demo).

Developer-side interaktivní agent. Sedíte u terminálu nebo IDE, agent vidí váš kontext, edituje soubory, ptá se vás, spouští příkazy. Pracujete s ním jako s druhým párem rukou: rozhodujete vy, on dělá. Hodí se na práci, která je hluboká, vyžaduje úsudek a kde se zadání zpřesňuje v průběhu (refaktor, debugging, exploratory změny).

Oba režimy zvládá dnes každý z hlavních nástrojů. Proto je „pro jaký režim ho máte v týmu nasazený“ praktičtější otázka než „který produkt“ — podle režimu totiž vypadá celá disciplína kolem něj: review, gates, ownership, integrace.

02Co tyhle nástroje doopravdy mění

Pozor na pokušení vidět to jen jako rychlejší autocomplete. Změny jsou hlubší a dotýkají se věcí, na které není editor zvyklý:

Granularita úkolu. Místo „dopiš tuto funkci“ zadáváte „zavři tento issue“. Mezi těmi dvěma vstupy je dvojí přeskočení: musíte úkol formulovat tak, aby ho stroj pochopil bez vašeho dohledu, a musíte výsledek validovat na úrovni issue, ne na úrovni řádků.

Rychlost změn. Nudný PR, který by tým udělal za půl dne — přejmenování napříč soubory, mechanická migrace — agent udělá za deset minut. U práce, která vyžaduje úsudek, ta úspora rychle taje. Bottleneck se každopádně přesouvá z psaní kódu na review a integraci. Tým, který tenhle posun nezvládne organizačně, dostane úzké hrdlo právě na review, ne na tvorbě.

Review je jiná disciplína. A pozor — review strojem napsaného kódu není totéž co review kódu od kolegy. Nemůžete se opřít o autorský záměr („proč to udělal takhle“ se nemáte koho zeptat), failure modes jsou jiné (agent vyrobí věrohodně vypadající kód, který je subtilně mimo kontext, ne začátečnickou chybu, která bije do očí) a objem je vyšší. Tým, který přesune zátěž na review, ale nepřeškolí lidi na tenhle nový druh review, jen přesunul úzké hrdlo, ne ho odstranil.

Architektonická paměť. Agent přichází do repa s omezeným kontextem. Persistent context, project memory a skills ten studený start tlumí, ale nenahradí psanou paměť toho, co kód neříká — proč se to tady dělá takhle, čemu jsme se vyhnuli, jaký kompromis to byl. Bez explicitní paměti — viz ADR: architektonická paměť týmu — agent navrhuje konzistentně rozumné řešení, které je s vaší architekturou v rozporu.

Odpovědnost. Když agent něco rozbije, kdo to nese? Vývojář, který task zadal? Tým, který nastavil gates? Sám agent (a co to vůbec znamená)? Tématu se věnuje samostatný článek Agency a odpovědnost u AI agentů. Pro praxi: odpovědnost se nesvalí na nástroj; má ji vždycky člověk, který poslední dal souhlas.

03Jak je hodnotit (ne podle benchmarku)

Pokušení je porovnat oba nástroje na SWE-bench nebo podobném coding benchmarku a vybrat vyšší skóre. Pro produkční volbu je to slabý signál. Co rozhoduje v praxi:

Fit s vaším workflow. Pracujete většinou na malých, samostatných úkolech s jasným testem? Cloud-first asynchronní agent vám sedne. Děláte hodně refaktorů, debug napříč soubory, kde se zadání postupně zpřesňuje? Developer-side interaktivní bude doma.

Spolehlivost na vašem repo. Vezměte 5–10 reálných issue/úkolů z posledních týdnů a zkuste je oběma. Ne syntetické příklady — skutečnou práci. Sledujte úspěšnost (kolik z nich agent zvládl bez větší korekce), čas (kolik vás stálo dotáhnout neúplný výsledek) a počet rozbití (kolikrát PR neprošel review nebo testy). Pět realistických ticketů vám řekne víc než deset leaderboardů.

Integrace. Jak dobře nástroj rozumí vašemu build systému, testům, lintům, CI. Agent, který umí napsat kód, ale neumí ho rozumně otestovat ve vašem prostředí, vám produkční čas spíš sebere, než ušetří.

Náklady na omyl. Když agent navrhne špatnou změnu, jak rychle to poznáte a jak rychle to opravíte. Tohle je nedoceněná metrika — model s 80% úspěšností a snadnou kontrolou bije model s 90% úspěšností a obtížnou kontrolou.

Cena. Per úkol až poslední, při škálování dříve. U malých objemů jsou cenové rozdíly mezi modely zlomek předchozích bodů. Jakmile ale agent běží na velkém objemu úkolů napříč týmem, ekonomika nasazení se posouvá dopředu — a u některých režimů (cloud-first asynchronní agenti na každém ticketu) může rozhodnout o tom, jestli se nasazení vůbec vyplatí.

Benchmarky a leaderboardy mají místo (kandidátní seznam, dlouhodobý trend), ale rozhodnutí v týmu by se na ně nemělo opírat samy. Proč benchmarky neukazují produkční použitelnost rozebírá samostatný článek Proč benchmarky AI modelů nestačí.

04Kdy jim svěřit práci

Coding agent dnes není univerzální. Existuje docela jasný profil úkolu, který mu sedí, a profil, který mu nesedí.

• Sedí mu: velký objem nudné práce s jasným kritériem správnosti (přejmenování, migrace API, doplnění testů, převod stylu, malé bugfixy s reprodukcí). Práce, která je z pohledu člověka „kdo to bude dělat“ otravná, ale z pohledu stroje rutinní. Tady šetří agent reálné hodiny.
• Sedí mu podmíněně: středně velké fíčury s rozumnou specifikací. Tady agent funguje jako akcelerátor — udělá první draft, vy ho dotáhnete. Úspora je výrazná, ale závisí na kvalitě zadání. Špatně napsaný ticket vyrobí špatný PR.
• Nesedí mu: architektonická rozhodnutí, návrh API, řešení produkčního incidentu pod tlakem, práce, která vyžaduje rozhovor se stakeholdery. Tady je agent v nejlepším případě nástroj na pomocnou rešerši, ne autor řešení.

Tým, který tyhle tři zóny nerozlišuje a pustí agenta na všechno, dostává konzistentně rozumný kód v zónách, kde rozumný kód není to, co potřeboval. A naopak — tým, který agenta drží jen v zóně „autocomplete plus“, nevyužije ho tam, kde by reálně přinesl násobky.

05Kde držet hranice

Hranice mezi „agent může“ a „agent nesmí“ je rozhodnutí týmu, ne nástroje. Praktická pravidla:

Permissions a citlivá data jsou první otázka, ne poslední. Agent, který umí spouštět příkazy a fetchovat ze sítě, je v podstatě nový uživatel s nejasně definovanou rolí. Co může číst (kredencí, klíče, .env, produkční dumpy)? Kam se může připojit? Jaké příkazy smí spustit bez potvrzení? Odpověď patří do explicitní konfigurace ještě před prvním ostrým úkolem — allowlist příkazů, izolovaný sandbox, oddělené přístupy pro agentní účet, audit log. Spustit agenta s defaultními oprávněními a „doladit to později“ znamená, že „později“ obvykle přijde ve chvíli, kdy agent něco fetchne nebo přepíše, co neměl — a tehdy už se vysvětluje, ne nastavuje. Důvěra v model není bezpečnostní kontrola.

Nereverzibilní akce vyžadují člověka. Force push, drop database, smazat branch, deploy do produkce, poslat e-mail klientovi. Agent může připravit krok, ale stiskne ho vědomě člověk.

Merge do main vyžaduje review. Nezáleží na tom, jak moc důvěřujete agentovi — code review chrání nejen před chybami, ale taky před tichým posunem architektury, který se za pár měsíců těžko vrací.

Produkční incident bez agenta jako autora. Pod tlakem se snadno přijme rozumně vypadající návrh, který nezvládl kontext. Agent může pomoct rešerší (logy, dotazy, hypotézy), ale fix opravdu napsat má člověk, který nese odpovědnost za následky.

Architektonická rozhodnutí prochází lidskou debatou. Návrh agenta může vstoupit jako podklad, ale rozhodnutí — a hlavně jeho zaznamenání v ADR — patří týmu.

Hranice nejsou o tom, jestli agentu věříte. Jsou o tom, kdo nese náklady, když se to nepovede — a co všechno může jít špatně, když má agent přístup, který nikdo doma vědomě neschválil.

06Co s juniory?

Zóna, kterou agent obsadil nejdřív, je rutinní práce — přesně ta, na které se historicky junioři učili řemeslo. Migrace API, doplnění testů, drobné bugfixy, refaktory. Když tuhle vrstvu sebereme, otázka „kde se za pět let vezmou senioři“ není akademická a tým, který si ji nepoloží, ji za pár let dostane jako problém.

Jednoduchá odpověď neexistuje, ale tři pravidla pomáhají:

Junior nemá agenta jako prvního. Než se naučí, jak vypadá dobrý kód v daném repu, je užitečné, aby ho psal sám — i pomalu. Agent nasazený dřív vyprodukuje seniora, který umí jen review a v debug session pod tlakem neví, kde začít.

Review od juniora na PR od agenta. Junior na agentově PR se učí dvě věci najednou: kód v repu a kritický odstup od AI návrhu. Lepší trénink na příští roky se těžko vymýšlí — a pro tým je to způsob, jak udržet kontrolní vrstvu nad agentem.

Páření juniora se seniorem zůstává. Žádný agent zatím nenahrazuje rozhovor, ve kterém senior vysvětlí, proč se v repu před třemi lety zvolila tahle cesta a ne ta druhá. To je přesně ten kontext, který agent nemá a který se nepřenáší samovolně — předává se mluvením.

07Antipatterny, na které se snadno spadne

Tahle sekce schválně nepřevypráví hranice z minulé kapitoly v negativu — jde o vzorce chování, které vypadají neškodně a tím jsou zrádnější:

Agent jako merge bot. „Vždyť to projde testem.“ Test pokrývá funkčnost, ne kontext. Tichý posun architektury, neefektivní cesty, dluh — to test nezachytí.

Slepý PR review. Schválit PR od agenta po deseti vteřinách, protože „je to jen pár řádků“. Krátké PR od agenta umí být drobně mimo a chyba se pozná až v produkci. Tohle je přesně to místo, kde se nový druh review (viz výš) buď zavede, nebo tiše vynechá.

Agent jako jediný zdroj kontextu. Tým přestane psát ADR, dokumentaci a komentáře, „vždyť to agent přečte z kódu“. Agent přečte z kódu, ale ne to, co kód neříká — proč se zvolila tahle cesta. Architektonická paměť tím vyhladoví.

Auto-upgrade modelu. Přepnout coding agenta na nejnovější verzi modelu hned, jak vyjde. Pravidlo z článku o sledování AI modelů platí i tady — bez regression nad reálnými úkoly vám každý upgrade utajeně mění chování. (Mimochodem: než tenhle článek vyjde, modely v referencích dole už budou nejspíš o verzi dál. To je rys, ne chyba — a přesně proto píšu o režimech, ne o feature listu.) Disciplínu pro sledování nových modelů popisuje Jak sledovat nové AI modely bez hypu.

08Souvislosti

Tenhle text je jedním dílkem širší skládačky. Kdo nese důsledky rozhodnutí agenta řeší Agency a odpovědnost u AI agentů; kam do firmy agenta vůbec pustit AI architektura pro firmy; co si agent pamatuje napříč session Paměť AI agentů. Nutnou protiváhou je ADR: architektonická paměť týmu — bez psané paměti agent navrhuje v repu, který nezná.

09Závěr

Codex a Claude Code nejsou dva soutěžící produkty na stejnou roli. Jsou to dva režimy práce, mezi kterými si tým vybírá — a které se v produktech postupně kříží. Volba nástroje není to nejdůležitější rozhodnutí, které kolem agentů uděláte. Důležitější je, kde jim svěříte práci, jaká oprávnění jim dáte, kdo zkontroluje, že to, co dělají, neodvádí pomalu architekturu, a kde v týmu necháváte prostor pro lidi, kteří se to teprve učí.

Agent psaní kódu zrychluje. Architekturu, review, bezpečnost a růst lidí zrychlit nelze; ty zůstávají na vás.