Když dnes někdo řekne „AI programátor“, většinou tím myslí chytřejší autocomplete. To už je zastaralý pohled. Claude Opus 4.7 a GPT-5.5 v Codexu ukazují jiný směr: agent, kterému dáte pracovní úkol, repo, testy a hranice — a on se snaží dojít k hotovému pull requestu.

Pro firmu to neznamená, že zítra vyhodí vývojáře. Znamená to něco praktičtějšího: část práce, která dřív čekala na seniora nebo externí agenturu, může běžet jako kontrolovaný proces. Refaktor menší služby. Oprava bugů. Doplnění testů. Migrace API. Dokumentace. Interní nástroj. A hlavně: všechno přes Git, build, testy a lidské schválení.

Nejde o „který model je nejlepší“. Jde o typ práce

Claude Opus 4.7 i GPT-5.5 v Codexu míří na podobnou oblast: dlouhé, nástrojové, více-krokové úkoly. Přesto se vyplatí přemýšlet jinak než přes jeden žebříček benchmarků.

Claude Opus 4.7 je podle Anthropic postavený na složité reasoning a agentic coding úkoly. Zajímavé jsou hlavně tři věci: lepší práce na dlouhých úlohách, přesnější dodržování instrukcí a vyšší rozlišení pro práci s obrázky nebo screenshoty. V API má model ID claude-opus-4-7, podporu velkého kontextu a nové mechanismy jako effort nebo task budgets pro agentní běhy.

GPT-5.5 v Codexu je zase silný hlavně jako pracovní prostředí. OpenAI ho popisuje jako model pro „messy, multi-part tasks“ — tedy ne krásně izolované otázky, ale práci, kde je potřeba plánovat, používat nástroje, kontrolovat výsledek a pokračovat. Codex changelog ukazuje, že samotný produkt kolem modelu dozrává: CLI, IDE, cloud, code review, goals, permissions, pluginy a integrace.

Překlad do firemní řeči: Claude je často silný jako hluboký řešitel úkolu. Codex je silný jako pracovní systém okolo repozitáře. V praxi ale stejně rozhodne konkrétní úloha, repo, testy a schvalovací proces.

Co se reálně mění pro firmy

Největší změna není rychlost psaní kódu. Největší změna je, že AI agenti začínají zvládat delší smyčku:

  1. pochopit zadání,
  2. projít existující codebase,
  3. navrhnout změny,
  4. upravit více souborů,
  5. spustit testy nebo build,
  6. opravit chyby,
  7. připravit diff k review.

To je přesně typ práce, který ve firmách často stojí. Ne proto, že by byl nemožný, ale protože nikdo nemá kapacitu. Typické příklady:

  • staré interní skripty bez testů,
  • rozbitá integrace mezi CRM a fakturací,
  • ruční reporting z pěti systémů,
  • administrační dashboard, který všichni chtějí, ale nikdo na něj nemá sprint,
  • technický dluh v e-shopu nebo B2B portálu,
  • migrace z jednoho API na druhé.

Dřív se z toho stal backlog. Teď z toho může být fronta agentních úkolů. Každý úkol má jasné zadání, branch, test, PR a člověka, který rozhodne, jestli výsledek projde.

Kde bych použil Claude Opus 4.7

Claude Opus 4.7 dává smysl tam, kde potřebujete hlubší promyšlení a méně přímočarou práci.

Typické situace:

  • rozmotání složitého bug reportu,
  • návrh refaktoru před samotnou implementací,
  • práce s větším množstvím kontextu,
  • analýza architektury a závislostí,
  • přepis business logiky, kde je důležitý význam, ne jen syntaxe,
  • review většího návrhu nebo PR,
  • práce se screenshoty, diagramy, dokumenty a UI návrhy.

Zajímavý detail u Opus 4.7 je přesnější dodržování instrukcí. To je dobrá zpráva, ale i riziko. Pokud máte starý prompt typu „nějak to oprav a buď stručný“, nový model ho může vzít až příliš doslova nebo odhalit, že instrukce byly špatně napsané. U agentů se proto vyplatí mít jasný systém:

  • co smí měnit,
  • co nesmí měnit,
  • kdy má spustit testy,
  • kdy se má zastavit,
  • jak má reportovat nejistotu,
  • jaké soubory jsou citlivé.

Silnější model nezachrání špatný proces. Jen ho provede rychleji.

Kde bych použil GPT-5.5 v Codexu

GPT-5.5 v Codexu bych nasazoval tam, kde je důležitý tok práce přímo nad repozitářem.

Typické situace:

  • opravy GitHub issues,
  • menší až střední feature branche,
  • generování testů,
  • údržba dokumentace v repu,
  • hromadné mechanické změny s validací,
  • práce v CLI nebo IDE,
  • code review workflow.

Codex je zajímavý právě tím, že není jen „model“. Je to prostředí pro práci s kódem: sandbox, oprávnění, cíle, integrace, možnost běžet v CLI, IDE i cloudu. Pro firmu je to důležité, protože governance se nedělá jen promptem. Governance je také otázka toho, kde agent běží, jaká má práva, co může spustit, jaké soubory vidí a kdo schvaluje výsledek.

Bez procesu je to jen dražší chaos

U obou směrů platí stejná věc: agentní coding bez hranic je riziko.

Nejčastější chyba, kterou vidím: firma dá agentovi příliš široké zadání. „Projdi náš systém a vylepši ho.“ To není úkol. To je pozvánka k náhodnému diffu.

Lepší zadání vypadá takto:

Cíl: přidat export objednávek do CSV pro účetní.
Rozsah: backend endpoint + tlačítko v adminu.
Neměnit: fakturační logiku, platební modul, autentizaci.
Validace: npm test, npm run build, ruční kontrola CSV na 3 vzorcích.
Výstup: PR s popisem změn a rizik.

Takhle z AI neděláte kouzelníka. Děláte z ní pracovní sílu v definovaném procesu.

Praktický model nasazení

Pro menší firmu bych nezačínal otázkou „Claude nebo Codex?“. Začal bych tímto:

  1. Vyberte jeden bezpečný backlog typ. Například dokumentace, testy, interní report, jednoduché admin funkce.
  2. Dejte agentovi jen repo a branch. Ne produkční databázi, ne plný cloud účet.
  3. Vynucujte build a testy. Bez validace není PR hotové.
  4. Schvalujte přes PR. Agent nesmí mergeovat sám.
  5. Měřte reálný přínos. Kolik úkolů prošlo review, kolik se muselo zahodit, kolik času se ušetřilo.

Teprve potom má smysl řešit sofistikovanější orchestrace: více agentů, paralelní research, automatické issue triage nebo napojení na interní systémy.

Co bych sledoval v dalších měsících

Claude Opus 4.7 i GPT-5.5 ukazují, že coding agenti se posouvají od „napíš mi funkci“ k „dokonči pracovní balík“. To je velký rozdíl.

Pro firmy budou rozhodovat čtyři otázky:

  • Spolehlivost: dokončí agent úkol konzistentně, nebo jen občas zazáří?
  • Cena: vyplatí se silný model na tento typ práce, nebo stačí levnější model s lepším procesem?
  • Kontrola: umíte omezit práva, data a rozsah změn?
  • Integrace: zapadne agent do GitHubu, Slacku, Telegramu, CI a existujícího workflow?

Můj názor: vítěz nebude model s nejhezčím demem. Vítěz bude firma, která vezme agentní vývoj jako procesní změnu. Malé, bezpečné úkoly. Jasné hranice. Automatická validace. Lidské schválení.

Pokud chcete zjistit, kde by agentní vývoj dával smysl ve vaší firmě, začněte AI auditem. Projdeme backlog, interní procesy a technická rizika a vybereme první automatizaci, která má reálnou návratnost. Pokud už víte, co chcete zkusit, napište přes kontakt.