← KNIHOVNA
AI agenti5 min6. srpna 2026

Model pro vývojáře už nestačí zkoušet jedním zadáním

Modely pro vývojáře se začínají hodnotit podle dlouhých agentských běhů přes nástroje, repozitář a kontrolu změn. Muse Spark 1.2 ukazuje, proč vedle výkonu řešit i cenu a pravidla pro data.

Monumentální římská bazilika vede prázdné mramorové desky dlouhou cestou od archivu přes několik kontrolních prostorů až k tribunálu, zatímco scénu sledují pouze kamenné sochy a reliéfy.

TL;DR:

  • Nové modely pro psaní kódu se začínají lámat na tom, jak dlouho udrží práci přes nástroje, repozitář a postupné opravy.
  • Krátký test odpovědi nestačí, pokud má agent pro vývoj softwaru zvládnout změnu od zadání po použitelný rozdíl v kódu.
  • Muse Spark 1.2 ukazuje směr: více tréninku na kódování, lepší porozumění repozitáři a těsnější napojení na Muse Code.
  • Při výběru modelu musíš vedle kvality sledovat i cenu dlouhých běhů a pravidla pro použití pracovních dat.
  • Praktický první krok je otestovat agenta na jedné reálné změně v repozitáři a měřit výsledek podle kontroly, ne podle dojmu z odpovědi.

Představ si běžný úkol v malém týmu: upravit část aplikace, najít související místa v repozitáři, opravit testy, vysvětlit rozdíl a připravit změnu tak, aby ji člověk mohl bezpečně sloučit. To není jedna otázka a jedna odpověď. Je to řetězec rozhodnutí, hledání, volání nástrojů, práce se soubory a návratů po slepých odbočkách.

Právě tady se mění měřítko kvality modelů pro vývojáře. Dřív dávalo smysl ptát se, který model napíše lepší funkci na první pokus. Teď je praktičtější ptát se, který model udrží dlouhý agentský běh bez toho, aby ztratil kontext, začal opravovat nesouvisející věci nebo skryl nejistotu za plynulý text.

Rozhoduje celý pracovní běh

Agent pro vývoj softwaru není jen chytřejší doplňování kódu. Když má fungovat v každodenní práci, musí rozumět zadání, najít relevantní soubory, rozlišit důležité změny od šumu, spustit nebo navrhnout kontrolu a vrátit člověku srozumitelný rozdíl. Každý krok zvyšuje šanci na chybu.

Proto je dlouhé agentské volání nástrojů důležitý signál. Znamená schopnost modelu opakovaně používat externí nástroje, držet směr práce a reagovat na mezivýsledky. U vývoje softwaru to může být čtení souborů, hledání v repozitáři, úprava kódu, práce s testy nebo rozdělení úkolu mezi dílčí pomocné agenty.

Simon Willison u vydání Muse Code a Muse Spark 1.2 upozorňuje právě na tento posun: klíčovou vlastností modelů už není jen jednorázové generování, ale dlouhé agentské používání nástrojů. Pro čtenáře Agentivpraxi je z toho praktický závěr: model nehodnoť podle ukázkové odpovědi, ale podle toho, jestli dovede projít skutečnou pracovní cestu.

Co naznačuje Muse Spark 1.2

Muse Spark 1.2 je popsaný jako verze zaměřená na kódování. Má přinést zlepšení v generování kódu, složitějším ladění, porozumění existujícímu repozitáři a vývojářském pracovním postupu od zadání po změnu v kódu.

Důležité je i to, jak má být model připravený. Podle zdroje Meta navýšila výpočetní kapacitu tréninku na úlohách spojených s kódováním a rozšířila pestrost tréninkových prostředí. Model byl zároveň trénovaný společně s Muse Code, aby lépe fungoval s konkrétním agentským nástrojem a jeho sadou nástrojů.

To neber jako nezávislé potvrzení výkonu. Je to rámec vydání produktu a komentář ke směru trhu. Přesto je užitečný, protože ukazuje, kam se přesouvá důraz: od samostatného modelu k modelu, který je připravený pracovat uvnitř delšího nástroji řízeného procesu.

Jak takový model zkoušet v praxi

Pokud vybíráš model pro tým, nezačínej sadou krátkých úloh typu „napiš funkci“. Přidej scénář, který připomíná skutečnou práci. Například vezmi menší chybu v aplikaci, ke které je potřeba projít několik souborů, upravit test a vysvětlit dopad změny.

Sleduj tři věci. První je orientace v repozitáři: najde agent správná místa, nebo se chytá prvního podobného názvu? Druhá je kvalita rozdílu v kódu: řeší příčinu, nebo jen přidává lokální záplatu? Třetí je schopnost zastavit se u nejistoty: umí říct, co neověřil, místo aby předstíral hotovou práci?

Pro freelancera nebo malý vývojový tým může být dobrý test ještě jednodušší. Vyber jednu změnu, kterou bys normálně udělal za hodinu. Dej agentovi jasné zadání, nech ho pracovat v omezeném rozsahu a potom si změř, kolik času zabralo čtení výsledku, opravy a finální kontrola. Pokud kontrola trvá déle než ruční práce, agent zatím nepřinesl pracovní úsporu.

Cena tokenů není celá cena práce

U dlouhých agentských běhů roste význam ceny. Model, který vypadá levně v krátkém dotazu, může být drahý, když při jedné změně opakovaně čte soubory, navrhuje úpravy a zpracovává dlouhý kontext. Proto má smysl počítat cenu na dokončený pracovní výsledek, ne jen cenu za milion vstupních a výstupních tokenů.

U Muse Spark 1.2 je zajímavá dvojí cenová varianta. Standardní model muse-spark-1.2 má podle zdroje cenu 1,25 dolaru za milion vstupních tokenů a 4,25 dolaru za milion výstupních tokenů. Varianta muse-spark-1.2-contributor je výrazně levnější, 0,10 dolaru za milion vstupních tokenů a 0,20 dolaru za milion výstupních tokenů, pokud souhlasíš s použitím dat ke zlepšování produktů dodavatele.

To není jen účetní detail. Je to rozhodnutí o datech. Pokud agent pracuje s interním repozitářem, zákaznickými úpravami nebo neveřejnou logikou produktu, levnější běh může mít vyšší organizační cenu. Firma by měla předem určit, které repozitáře a typy úloh se do takového režimu vůbec smějí dostat.

Člověk musí vlastnit konečné rozhodnutí

Dlouhý agentský běh svádí k tomu, aby člověk kontroloval jen konečný výsledek. To je slabé místo. Čím delší je pracovní řetězec, tím víc potřebuješ průběžné hranice: co agent měnit smí, co má pouze navrhnout a kdy musí zastavit.

U změn v kódu si nastav minimální kontrolní body. Agent může připravit rozdíl, ale člověk kontroluje architekturu, bezpečnost, testy a finální sloučení. Agent může shrnout, co změnil, ale důvěru si zaslouží až rozdíl v kódu a ověřené chování. Agent může navrhnout větší přestavbu, ale neměl by ji provést v jednom běhu bez samostatného lidského rozhodnutí.

Praktický další krok: vyber jednu opakovanou vývojářskou úlohu a napiš pro ni hodnoticí list. Zahrň kvalitu orientace v repozitáři, počet nutných lidských oprav, cenu běhu, práci s nejistotou a pravidla pro data. Teprve potom porovnávej modely. Ne podle toho, který zní nejsebevědoměji, ale podle toho, který spolehlivěji předá člověku kontrolovatelnou změnu.

Zdroj

Simon Willison: Introducing Muse Code and Muse Spark 1.2 https://simonwillison.net/2026/Aug/5/muse-code-and-muse-spark-12/#atom-everything

Související z knihovny

Praktická AI jednou týdně.

Jeden plný workflow, důležité novinky a postupy, které se dají použít v práci.

Workflow týdněDůležité novinkyPraktické tipy