Týmy AI agentů v testu zdražily práci. Lepší výsledek nebyl samozřejmostí

TL;DR

• V testu programátorských úloh od Vals AI stály týmy agentů 1,8krát až 5,1krát tolik co samostatní agenti. Významné zlepšení výsledku zaznamenala jen jedna testovaná konfigurace.
• Záleželo i na způsobu spolupráce: GPT-6 Sol rozděloval práci souběžně podle částí aplikace, Opus 5.5 postupoval v navazujících vlnách.
• Než zapojíš další agenty, porovnej na stejné úloze kvalitu, celkovou cenu a čas do použitelného výsledku.

Pověříš jednoho agenta úpravou aplikace, nebo práci rozdělíš mezi několik dalších? Souběžná práce může vypadat jako snadná cesta ke zrychlení. Každý další agent ale spotřebovává prostředky a jeho výstup musí někdo spojit s ostatními. Rozhodující proto je, zda tým dokončí úlohu lépe nebo rychleji za cenu, která ti dává smysl.

Přehled AINews na Latent Space z 10. října 2026 shrnuje test Vals AI, který porovnal GPT-6 Sol a Opus 5.5 při samostatné práci a v týmech na Vibe Code Bench. Výsledek dává konkrétní důvod měřit přínos spolupráce: vyšší náklady provázely týmové konfigurace, významný posun v kvalitě ale jen jednu z nich.

Co přinesli další agenti v programátorském testu

Podle shrnutí výsledků Vals AI byly týmy 1,8krát až 5,1krát dražší než samostatní agenti. Významně se zlepšil pouze GPT-6 Sol při střední úrovni uvažování, a to o 7,3 bodu.

Rozdíl byl také v organizaci práce. Sol delegoval úlohy souběžně podle architektury aplikace. Opus pracoval v postupných vlnách. Při nejvyšší úrovni uvažování připadalo u Opusu na aplikaci v průměru přibližně 6,8 dílčího agenta a zhruba 1 140 jejich volání nástrojů, aniž test zaznamenal významné zlepšení výsledku.

To neznamená, že týmy agentů obecně nefungují. Jde o konkrétní porovnání dvou modelů v programátorském testu. Ukazuje ale, že počet zapojených agentů ani množství provedených akcí samy o sobě nedokládají lepší výsledek.

Souběžná práce potřebuje oddělitelné části

Představ si ilustrační úlohu: do malé aplikace chceš přidat export objednávek. Jeden agent může připravovat změnu rozhraní, druhý část pro zpracování dat a třetí testy. Takové rozdělení má šanci pomoci, pokud mají všichni předem jasno v tom, jak má export fungovat a jak si jednotlivé části předají data.

Když se toto zadání teprve hledá, mohou agenti vycházet z různých předpokladů. Čas získaný souběžnou prací pak může padnout na sjednocování změn. To je praktická úvaha pro návrh práce, nikoli další výsledek uvedeného testu.

Pro malý tým z toho plyne jednoduché doporučení: deleguj části s jasným vstupem, výstupem a způsobem ověření. Urči také, kdo změny spojí a zkontroluje celek. U drobné úpravy, kde jednotlivé kroky těsně závisejí jeden na druhém, začni jedním agentem.

Porovnej cenu dokončené úlohy

Při vlastním zkoušení dej samostatnému agentovi i týmu stejné zadání a stejná kritéria přijetí. Sleduj tři věci:

• Kvalitu: splnil výsledek zadání a prošel stejnými testy?
• Celkovou cenu: kolik stáli všichni agenti včetně opakovaných pokusů a oprav?
• Čas do přijetí: jak dlouho trvala práce včetně spojení změn a tvé kontroly?

Předem si také stanov hranici nákladů, při které pokus zastavíš. Levně vypadající dílčí úkol nemusí znamenat levné dokončení celé změny.

Pokud tým stojí víc, ale výrazně zkrátí čekání na důležitou opravu, může se vyplatit. Pokud pouze provede více akcí a přidá ti kontrolu navíc, přínos chybí. Uvedené porovnání samo neříká, která varianta bude nejlepší pro tvou aplikaci.

Vyber proto jednu ohraničenou změnu, u které poznáš správný výsledek. Nejdřív si změř práci jednoho agenta a teprve potom zkus rozdělení úlohy. Získáš základ pro rozhodnutí, zda další agenti pomáhají právě tobě.

Zdroj

Latent Space: AINews z 10. října 2026, část o orchestraci více agentů a shrnutí testu Vals AI