TL;DR Muse nahrazuje zakázkové konzole pro orchestraci agentů čtyřmi nástroji, které má otevřené každý softwarový tým: Slack, Linear, GitHub a Claude Code. Žádný dashboard, žádná SPA, žádný člověkem napsaný kód. Každý PR musí projít sedmi bránami CI a recenzním panelem AI se třemi personami podle politiky sloučení s nulovými nálezy. Nasbíráno 40,000 hlasů, hodnocení základních modelů o 80% rychlejší.
Muse, zkratka pro Meshy Universal System for Evaluation, je naše interní platforma pro hodnocení modelů. Týmy v Meshy ji používají denně, aby zjistily, zda nové checkpointy modelů fungují lépe než ty staré.
Jednoho dne žhavý nový checkpoint modelu právě dozrál. Potřeboval arénový souboj, aby se určila další tréninková strategie. Tým zjistil, že k tomu potřebuje novou funkci v Muse.
"@Linear vytvoř issue v Muse k tomuhle"
řekl produktový manažer na Slacku.
O minutu později byl v Linearu vytvořen issue MES-12345.
Vlastník platformy Muse — tedy já — issue zahlédl. Bylo potřeba ho co nejrychleji nasadit, aby se odblokovala evaluační úloha. Pak byla zpráva odeslána Claude:
"Prošetři a oprav MES-12345"
Claude se na issue podíval a vynesl na povrch dvě návrhová rozhodnutí. Rozhodnutí padla a já odešel od terminálu pracovat na něčem jiném.
O hodinu a půl později byla nasazena nová verze Muse. Hotovo.
Autonomní softwarové inženýrství nemusí znamenat sofistikované konzole pro orchestraci agentů nebo dashboardy. A v tomto článku vysvětlím, jak jsme to umožnili.
Galerie, prohlížeč a tlačítko pro hlasování
Otázka, na kterou Muse odpovídá, je zdánlivě jednoduchá, ale ve skutečnosti obtížná: je nový checkpoint modelu opravdu lepší? Samozřejmě existují kvantitativní metriky, které se sledují u každého tréninkového běhu, ale zdaleka přesně nevystihují, jak vypadá „dobré" ve 3D generování. Muse proto dělá jednoduchou, ale účinnou věc: dvojitě slepé testování. Postaví výstupy dvou modelů vedle sebe, se stejným vstupním obrázkem, náhodně prohozené vlevo a vpravo, a nechá kolegy hlasovat naslepo.
Hodnocení je dávka takových dvojic. Někdo namíří Muse na dvě sady vygenerovaných sítí a složku referenčních obrázků, a aplikace si to od té chvíle obstará sama: spáruje modely, zaslepí přiřazení a servíruje vždy jedno srovnání. Hlasy se hromadí, kdykoli má někdo volnou minutku. Celé rozhraní je postavené tak, aby šlo použít na pár soust, a téměř celé se dá ovládat klávesovými zkratkami. Hlasující, který musí sáhnout po myši, hlasuje méně.
Hlasovací rozhraní Muse: dvě vygenerované sítě, stejný vstupní obrázek, náhodně prohozené vlevo a vpravo.
To je celý produkt. Galerie, prohlížeč a tlačítko pro hlasování. Na funkci Muse není nic složitého, a právě proto je z něj tak čistá případová studie. Neobvyklé je pouze to, jak se buduje.
Architektura, ve které se agenti dokážou orientovat
Projekt Muse odstartoval na konci roku 2025, kdy se „vibe coding" právě stával novým módním slovem. Kromě toho, že sloužil rostoucím potřebám hodnocení v tréninkových a release cyklech Meshy, měl Muse i ambiciózní cíl: postavit software pro celou firmu s nulou řádků kódu napsaného člověkem.
Dnes jsou výsledky famózní:
- Nasbíráno přes 40,000 hlasů od prvního nasazení Muse, s více než 30 hodnoticími projekty měsíčně
- Více než 4 týmy aktivně používají Muse pro svou každodenní práci
- První interní kódový základ, do kterého aktivně přispívá alespoň 1 netechnický člen týmu
- První interní kódový základ dosahující plně autonomního vývoje
Celkově odhadujeme, že Muse urychlil hodnocení našich základních modelů minimálně o 80 % a při každém vydání modelu ušetřil alespoň 10 člověkodnů práce. Bez Muse by bylo udržení současné rychlosti vývoje a vydávání kolekce generativních modelů Meshy, jako je geometrie, textura a smart topology, téměř nemožné.
Muse byl od prvního dne navržen tak, aby byl pro agenty co nejvíce čitelný. Už v roce 2025 jsme zjistili, že při implementaci stejného use case se agenti v některých ohledech trápili, zatímco v jiných uspěli napoprvé. Mnoho z těchto iterací nakonec vyústilo v dnešní záměrně nudný tech stack. Backend je v Pythonu: FastAPI, Postgres pro záznamy, S3 pro sítě a obrázky. Frontend je vykreslovaný na serveru: šablony Jinja2, HTMX pro dílčí aktualizace stránky, Tailwind pro styling, a jedna skutečná klientská komponenta — WebGL 3D prohlížeč, který vykresluje sítě. Neexistuje žádná SPA ani samostatný frontendový modul. Provázání obou stacků je to nejstarší, jaké web zná: backend vykreslí HTML, prohlížeč ho zobrazí. Když se má stránka změnit, HTMX si vyžádá fragment a server ho také vykreslí.
Zde je architektura jádrové hodnoticí aplikace v Muse:
Vrstvená architektura jádrové hodnoticí aplikace Muse. Závislosti směřují pouze dolů.
Pro agenty jsou na tomto tvaru důležité dvě vlastnosti. Zaprvé, stav frontendu žije na serveru. HTML, které uživatel vidí, je HTML vyprodukované backendem, takže test (nebo agent) nad ním může přímo provádět assertions, aniž by musel rozjíždět klientský framework a rekonstruovat to, co uživatel viděl. Zadruhé, každá závislost je vynucována strojově a směřuje pouze dolů. Složka funkce nesmí importovat svého souseda; pokud dvě funkce potřebují jedna druhou, kompoziční kořen (composition root) vloží jednu schopnost do druhé, takže závislost je vidět v přesně jednom souboru. Každá vrstva má jednu úlohu a tyto úlohy jsou zapsané přesně tam, kde na ně agent narazí:
| Vrstva | Role | Proč zde může agent bezpečně pracovat |
|---|---|---|
main/ | Pouze propojení (wiring). Registruje URL routy každého feature modulu. | Nová funkce znamená jednu složku plus jeden include řádek. Málo prostoru pro halucinace. |
apps/<feature>/ | Jedna složka na funkci: routy, stránky, service, store, testy. | Dosah úpravy je omezen na danou složku. Sourozenecké importy jsou chyba buildu, ne komentář v review. |
adapters/ | Vnější svět: vykreslování webu, databáze, object storage. | Veškeré I/O prochází jedním švem na systém. Pro každý šev existuje fake. |
libs/ | Sdílené instalovatelné knihovny. | Verzované jako kód třetích stran. Změna jedné je záměrně nápadná. |
Závislosti vždy směřují jen dolů podle tohoto seznamu a tento směr je vynucován kontrolou při buildu, ne pouhou konvencí.
Tři další vlastnosti dělají tento kódový základ záměrně čitelným pro agenty:
- Každý adresář nese vlastní dokumentaci (co daná služba dělá, jaká jsou pravidla vrstvení, přesné příkazy, které brání sloučení), takže se agent, který přistane bez kontextu, dokáže zorientovat, aniž by se musel ptát nebo si něco vymýšlet.
- Netriviální moduly nesou docstringy se zpětnými odkazy na návrhové dokumenty, takže proč přežívá vedle co.
- Žádný soubor nesmí přesáhnout 500 řádků — u několika výjimek platí jednosměrný mechanismus (ratchet): tyto soubory se mohou pouze zmenšovat, nikdy znovu narůst. Kontextová okna jsou konečná a architektura to respektuje.
Pokrok by neměl žít v malé místnosti
Dnes, kdy jsou LLM agenti mnohem výkonnější než v roce 2025, chceme, aby byl vývoj Muse plně autonomní. To znamená, že člověk agenta pouze nasměruje na úkol. Agent se sám zorientuje v kódovém základu a kontextu úkolu, propracuje se implementací, CI a code review, a nakonec sám dovede pull request až ke sloučení. Člověk pouze určuje prioritu issues a činí klíčová návrhová rozhodnutí.
První myšlenky o plně autonomním vývoji obvykle míří k zakázkovým platformám: konzole pro orchestraci, agent-nativní pracovní prostory, aplikace za aplikací slibující správu vaší flotily agentů. Podívali jsme se na ně a odmítli je. Ne proto, že by to nebyly skvělé produkty, ale znovu kvůli čitelnosti.
Chceme, aby práce agentů byla čitelná pro lidi, stejně jako by kódový základ měl být čitelný pro agenty. Jsme slušně velká firma. Když autonomní vývoj vložíte do vlastní konzole, jeho pokrok je viditelný jen pro hrstku lidí, kteří v té konzoli žijí.
Výsledkem je, že sada nástrojů pro spolupráci a vývoj je opět záměrně nudná. Vše v našem příběhu běželo na čtyřech nástrojích, které má otevřené každá softwarová firma: Slack, Linear, GitHub a Claude Code. Díky tomu je pokrok, který agent dělá, stejně pozorovatelný a dohledatelný jako pokrok kteréhokoli člena týmu. Produktový manažer otevírá issues v Linearu a kontroluje stav funkcí tak, jak to dělal vždycky. GitHub bug bot nebo security review čte vlákna v PR tak, jak to dělal vždycky. Kdokoli, kdo hlásí bug, vloží screenshot do stejného Slack kanálu jako vždycky, a oprava se objeví jako běžný pull request. Nikdo se nemusí nic učit, aby dohlížel na „stroj".
Zde je tvar jednoho autonomního issue, od začátku do konce:
Jedno autonomní issue, od začátku do konce. Člověk se do smyčky zapojí přesně na dvou místech.
Člověk se do této smyčky zapojuje přesně na dvou místech: nasměruje agenta na issue v Linearu a řeší hrstku rozhodnutí, která agent vynese na povrch ještě předtím, než napíše kód. Vše mezi tím — implementace, kontroly, diskuze v review, sloučení a nasazení — běží bez nikoho za volantem. Když nějaká kontrola selže nebo recenzent něco namítne, agent si přečte selhání, opraví ho a znovu pushne, a smyčka jednoduše oběhne další kolo. Skončí až ve chvíli, kdy je branch zelený, každý nález je vyřešen a fronta ho sloučila.
Co to umožňuje, není žádná zakázková integrace. Je to fakt, že tyto tři nástroje už samy vystavují příkazová rozhraní, která agent může přímo ovládat — ta stejná, která používá i člověk:
- GitHub, přes své CLI. Agent otevírá pull request, čte stav a logy jednotlivých CI jobů, odpovídá ve vláknech review a označuje je jako vyřešené a zařazuje branch do fronty ke sloučení — to vše pomocí běžných příkazů
gh. - Linear, přes svůj MCP server. Agent čte issue, na které byl nasměrován, sleduje odkazy na související issues kvůli kontextu, posouvá stav a zakládá navazující issues pro práci, kterou objeví cestou — to vše jako plnohodnotná volání nástrojů.
- Vlastní monitorovací smyčka Claude Code. CI trvá minuty a fronta ke sloučení ještě déle, a nikdo se přitom nedívá. Místo toho hlídá agent, a právě způsob, jakým hlídá, mění neobsluhovaný běh v něco praktického, místo aby šlo jen o hranici z propálených tokenů.
Když agent otevře pull request, nesedí u obrazovky a neobnovuje stránku dokola; zaregistruje si, na co čeká — běh CI, vlákna review, záznam ve frontě ke sloučení — a tím dokončí svůj tah. Funkce Monitor v Claude Code ho znovu vyvolá až ve chvíli, kdy se sledovaný stav změní: job zčervená, recenzní panel zveřejní nález, fronta sloučí branch. Protože agenta probouzejí zprávy od Monitoru o každé změně stavu, provede podle toho odpovídající další akci — třeba stáhne log ze selhaného jobu a pushne opravu, odpoví ve vlákně review a označí ho jako vyřešené, nebo zařadí branch do fronty, jakmile jsou všechny brány zelené.
Nic z toho není specifické pro Muse. Jakýkoli repozitář dostupný přes tyto tři nástroje lze řídit stejným způsobem, a přesně proto jsme si je vybrali.
Důvěra je artefakt buildu
Nedůvěřujeme samotnému LLM. Důvěřujeme LLM agentovi uvnitř harnessu, a tento harness lze navrhnout tak, aby fungoval jako strážce spolehlivosti. Konkrétně je harness naše CI/CD pipeline plus vrstva review nad ní. Tímhle musí projít úplně každý pull request, bez výjimky:
Každý pull request prochází stejným harnessem: nejprve automatizované kontroly, pak recenzní panel AI.
Jednotlivé joby s typickými časy naměřenými na nedávných reálných bězích PR:
| Job | Co vynucuje | Typický čas |
|---|---|---|
| Guardrails | Vrstvení (žádné sourozenecké importy), tvar složek, strop velikosti souboru, pojmenování | ~60 s |
| Lint | Formátovací a lintovací pravidla ruff | ~30 s |
| Kontrola typů | pyrefly, napříč celým projektem | ~20 s |
| Unit a integrační testy | pytest proti reálnému Postgresu postavenému ze schématu | ~90 s |
| Vizuální testy | Playwright screenshoty porovnávané se schválenými goldeny, ve vlastním rendereru CI | ~140 s |
| Security | statická analýza semgrep plus sken tajných klíčů | ~40 s |
| Test spuštění kontejneru | aplikace se musí spustit, což odmítne udělat, dokud každá routa nedeklaruje, kdo ji smí volat | ~215 s |
Guardrails jsou architektura, kterou jsme popsali, převedená do strojové podoby. Sourozenecký import tu není komentář v review; je to červený build. Vizuální goldeny se pořizují ve vlastním vykreslovacím prostředí CI, takže „u mě to funguje" nemůže být nikdy argumentem pro sloučení bugu do main.
Vrstva AI review je tam, kde to začíná být zajímavé. Každý PR čte náš vlastní panel tří recenzentů — kódujících agentů — kteří čtou stejný diff v kontextu psaných návrhových principů repozitáře, každý s jinak přiřazenou personou. Zde ukazujeme nástin promptů zadaných každému recenzentovi.
Hlavní inženýr:
Persona: Principal Engineer, návrhové review, velký rozsah
Recenzuješ na úrovni systému: zda tato změna sem patří, zapadá do architektury, znovu využívá to, co už existuje, a zůstává přídavná — ne zda je nějaký řádek upravený.
Vidíš diff + Guides, ne celý repozitář. Posuzuj znovupoužitelnost a konzistenci vzorů ...; netvrď, že jsi provedl vyhledávání napříč celým repozitářem, když to nejde.
Tvá optika: Posuzuj diff podle těchto částí poskytnutých Guides ...
Lakmusový test: „Kdybych byl hlavní inženýr tohoto kódového základu, poslal bych to zpátky za to, že to žije na špatném místě, duplikuje existující schopnost, nebo přidává druhý způsob, jak udělat něco, co už je vyřešené?" Pokud ne, vrať
[].
Senior inženýr:
Persona: Senior Engineer, logika / implementace / kvalita
Recenzuješ uvnitř změny: zda je logika správná, čistá, testovatelná a bezpečná. Toto je nejpečlivější review ze všech — sleduj cesty kódu, neproletávej to zběžně. Zaměř se na diff a soubory, kterých se dotýká (přečti je celé).
Tvá optika: Posuzuj diff podle těchto částí poskytnutých Guides ...
Lakmusový test: „Schválil bych tuto logiku, nebo bych při pečlivém čtení našel bug, netestovatelný šev, nebo bezpečnostní chybu?" Buď konkrétní ohledně selhávajícího vstupu nebo cesty kódu. Pokud je logika v pořádku, vrať
[].
QA inženýr:
Persona: QA Engineer, funguje to, je to otestované, nerozbije se to
Recenzuješ chování a riziko: udělá tato změna to, co tvrdí, je pokrytá testy, a mohla by rozbít něco živého nebo v produkci? Přečti si název a popis PR a pak zkontroluj, že diff to skutečně naplňuje.
Tvá optika: Shoda se záměrem ...; Pokrytí testy ...; Riziko regrese ...; Pasti v produkci ...
Lakmusový test: „Kdybych byl QA, který to schvaluje, zablokoval bych to za to, že to nedělá, co tvrdí, že to posílá netestované chování do produkce, nebo za změnu, která rozbije prod?" Pokud je to bezpečné a pokryté, vrať
[].
Kromě toho, že se na stejný diff kódu dívají z různých úhlů, sdílejí všichni 3 recenzenti i společnou sadu pravidel, která řídí vývoj celého kódového základu — totiž Guides:
- Věci, které se mění společně, žijí spolu; nesouvisející věci zůstávají oddělitelné. Změna nebo smazání jedné odpovědnosti se dotkne jednoho místa.
- Business logika nezávisí na detailech vnějšího světa. Funkce s business logikou běží v testu s předanými fake objekty, bez skutečného I/O. Výměna backendu se nedotkne žádné business logiky. Aplikace nikdy nevolá své vlastní HTTP endpointy.
- Znovupoužij, nevymýšlej znovu. Každá schopnost má jednu implementaci; nový konzument volá existující rozhraní místo toho, aby ho kopíroval.
- Funkce se přidávají přidáváním, ne úpravou. Přidání funkce znamená „nové soubory + jeden registrační řádek" a její smazání se nedotkne žádné jiné funkce.
- Jeden zavedený způsob, jak dělat každou věc. Nováček okopíruje existující vzor místo toho, aby si vybíral, a testy nepotřebují žádný server ani databázi.
- Smaž kód ve chvíli, kdy se přestane používat. Nic se neposílá do produkce, co nikdo nevolá; „nechme to pro jistotu" není důvod, protože git si pamatuje.
- Preferuj nejjednodušší řešení, které funguje; složitost přidávej jen pod tlakem nutnosti. Každá abstrakce si svou existenci zaslouží konkrétní aktuální potřebou. Změna je nejmenší možná, která problém vyřeší.
Panel zveřejňuje každý blokující nález jako inline komentář ukotvený k přesnému řádku, a tyto komentáře brání sloučení, dokud nejsou vyřešeny.
Review z nedávného PR s novou funkcí vypadá takto:
[medium] Riziko regrese. Tato funkce je sdílené hrdlo (chokepoint) pro vytváření a synchronizaci; nyní sloučí soubory se sufixem view do jednoho seskupeného řádku. Jakýkoli již existující dataset načtený podle starého schématu bude při další synchronizaci tiše přeskupen, čímž se smažou staré identity vzorků, na které se stále odkazují živá hodnocení. Žádný test nepokrývá opětovnou synchronizaci existujícího datasetu přes nové seskupování.
Ten nález byl správný. Kód prošel celou sadou testů i prvním kolem zelené CI. Testy byly pro kód tak, jak byl napsaný, v pořádku. Recenzent ale viděl, že kód tak, jak byl napsaný, je špatný pro data, která ve skutečnosti máme. Claude to opravil, přidal chybějící regresní test, odpověděl ve vlákně a nález vyřešil. Celá výměna je veřejná přímo v PR, úplně stejně, jako byste mentorovali juniorního inženýra při code review.
To byl jeden PR. Jak agenta provozujeme delší dobu, dokážeme odhalit i další typické vzorce:
- Oprava, která způsobí nový problém. Diagnostický nástroj, který jsme nasadili, měřil rychlost stahování. Review odhalilo, že výpočet používal MB (1,000,000 bajtů), ale server posílal MiB (1,048,576 bajtů), takže by každá rychlost vycházela o 5% nižší. O pár pushů později review upozornilo, že oprava nechala dvě konstanty synchronizované ručně. Vyžádalo si tedy místo toho počítat rychlost ze skutečného počtu přijatých bajtů. Recenzent odhalil bug, který vznikl při řešení jeho vlastního dřívějšího požadavku.
- Slepé uličky v use case. Tatáž stránka byla nasazena s odkazem viditelným pro každého přihlášeného uživatele, přestože samotná stránka vyžadovala konkrétní oprávnění. Kdokoli bez tohoto oprávnění by po kliknutí narazil na chybu 403. Žádný test neselhal, protože odkaz se zobrazoval a oprávnění fungovalo správně. Recenzent QA obě věci porovnal a zablokoval sloučení, dokud se odkaz nezobrazoval jen lidem, kteří tu stránku skutečně mohli otevřít.
- Napálení testů, aby prošly. Test jedné opravy si sám vyrobil přesně tu výjimku, kterou měl zachytávat, takže procházel, i kdyby bylo skutečné zpracování chyb rozbité — protože test dostal „správnou" chybovou zprávu výjimky. Panel to odhalil a přepsaný test teď pouští skutečné chyby skutečným kódem. Stejný PR měl i test, který procházel na stroji vývojáře, ale v CI selhával, protože se potichu spoléhal na soubor s přihlašovacími údaji, který existuje jen na našem dev stroji. Oba případy byly bugy přímo v testech, odhalené vrstvou nad nimi.
Naše politika sloučení je 0 nálezů z AI review. Každý nález je buď opraven, nebo vyvrácen důkazy, než si PR vezme fronta. Vyvrácení jsme udělali reálnou možností, protože recenzní panel nadhodnocuje nálezy v míře, která je snesitelná. Sepsání toho, proč je nález chybný, může naopak občas odhalit chybu v uvažování samotného recenzního panelu.
Za kontrolami fronta ke sloučení znovu ověří každý branch oproti pohybující se špičce main a sloučení automaticky nasadí do produkce, bez jakéhokoli člověka ve smyčce.
Za všemi branami fronta ke sloučení znovu ověří branch a sloučení nasadí do produkce.
Počet řádků kódu je jen malá část příběhu
V průběhu mnoha samořízených PR jsme odhalili nápadný, ale rozumný vzorec: čas strávený iterováním na kontrolách a review je mnohem delší než čas potřebný k napsání první implementace, a tento poměr se navíc výrazně liší podle typu úkolu. Zde porovnáváme dva typy vývojových úkolů ze stejného týdne.
Případ A: vyřazení mrtvé funkce. Malá legacy funkce šla offline; musel zmizet její odkaz, potvrzovací dialog, překlad, testy i screenshot baseline. Od založení issue v Linearu po sloučení PR do main uplynulo jen 16 minut, přičemž prvních 2 minuty šlo o psaní kódu. Review bylo jen poradní.
Případ B: zásadní vylepšení funkce síťové diagnostiky. Šlo o změnu podobné velikosti podle počtu řádků, přičemž první verze byla hotová za 5 minut, ale celkový čas do sloučení byl asi 3 hodiny. Během toho agent vyřešil 5 kol review a 7 nálezů blokujících sloučení.
Časové osy jsou také dost odlišné:
| Případ A: vyřazení mrtvé funkce | Případ B: vylepšení diagnostického nástroje | |
|---|---|---|
| Velikost změny | +10 / -125, 8 souborů | +439 / -19, 9 souborů |
| První funkční verze | 2 min | 5 min |
| Od založení issue po sloučení | 16 min | 3 hodiny |
| Kolikrát déle trvalo sloučení oproti první verzi | 8x | 36x |
| Blokující nálezy z review | žádné (jen poradní) | 7, napříč 5 koly |
| Nejhorší scénář, pokud je kód špatně | odkaz, na který nikdo neměl klikat | každý uživatel důvěřuje špatnému číslu |
Dva úkoly se srovnatelným počtem řádků, kterým bylo věnováno úsilí na ověřování úměrné riziku.
Druhý úkol trvá jedenáctkrát déle, ne proto, že by bylo těžší kód napsat, ale proto, že riziko bylo jiné, a úsilí na ověřování bylo vynaloženo úměrně tomu. Případ A bylo mazání: nejhorší výsledek byl rozbitý odkaz, na který se stejně nemělo chodit. Případ B byl měřicí nástroj: nejhorší výsledek byl, že každý uživatel důvěřuje špatnému číslu. Recenzní panel našel chyby a pak strávil ještě tři další kola odmítáním dílčích oprav, dokud nebylo zpracování chyb typované, úplné a důkladně otestované. Každé kolo udělalo implementaci přísně pevnější. Žádná z těchto vad neshodila žádný test, a všechny by se dostaly do produkce.
Tohle je přesně ta část, kterou generování kódu na jeden zátah (one-shot) svou podstatou dělá špatně. One-shot generování optimalizuje metriku, kterou je nejsnazší vidět: čas od promptu ke kódu, který se zkompiluje a spustí. Oba naše případy tuto metriku splnily během pár minut, a kdybychom se u ní zastavili, případ B by byl hotový pár minut po startu — a špatně po celé měsíce.
Stejná pipeline, která propustila smazání během 16 minut, držela měřicí nástroj 3 hodiny, aniž by nějaký člověk rozhodoval, jaké zacházení si který úkol zaslouží. Když se lidé ptají, jestli lze kódu napsanému AI v produkci důvěřovat, tohle je odpověď: kód je přesně tak důvěryhodný, jako ověřování, kterým je obalen, a hloubka ověřování je teď něco, co se kupuje za agentní hodiny místo za inženýrské dny. Špatné hlášení rychlosti stojí víc než tři hodiny hned napoprvé, kdy si podle něj někdo přebere síťovou stížnost.
Co jsme se naučili a co bude dál
Dnes je autonomie spíš vlastností harnessu než vlastností modelu. Každé vylepšení modelu udělalo naše agenty lepšími; samotná schopnost modelu ale nepřichází se zárukou, že agentovi můžete důvěřovat, že bude volně slučovat vlastní pull requesty. Místo investování další lidské pozornosti nebo slepého používání toho nejdražšího frontier modelu jsme se rozhodli postavit „ruce" a „oči", aby agenti měli vše potřebné k produkci správného produkčního kódu. A s tím, jak se schopnosti modelů vyvíjejí, nám to zároveň umožňuje jet na vlně, místo abychom přestavovali lešení, které kompenzuje omezení modelů.
Role člověka se koncentruje, nemizí. Co zbývá, je neredukovatelné jádro: rozhodovat, co stojí za to postavit, sepsat to dostatečně jasně a uplatňovat úsudek ve chvílích, které stroje označí jako nejednoznačné. Cit pro návrh a kvalita zadání jsou teď v tomto týmu inženýrská dovednost s nejvyšší pákou.
A nejzajímavější poznatek o týmech agentů je, že hodnota týmu nepramení ze spolupráce, ale z konfliktu. Rozdělit fullstack úkol mezi frontendového a backendového agenta může dávat smysl. Nechat frontendového a backendového agenta, aby si spolu jen tak povídali kvůli dokončení úkolu, smysl dává mnohem méně. Přínos týmu se projeví ve chvíli, kdy mají členové protichůdné cíle. Náš vývojový agent Muse chce kód dostat do produkce. Naši AI recenzní agenti chtějí najít, kde je kód špatně nebo špatně navržený. Je to právě jejich napětí, které dělá výsledek důvěryhodným a věrně odhaluje skutečné množství práce na daném vývojovém úkolu.
A co je důležitější, zjišťujeme, že nás naše zkoumání vede k novému, teprve se rodícímu způsobu vývoje softwaru: autonomní inženýrská organizace. Přestože jsme ukázali, že agenti dokážou pomocí existujících nástrojů autonomně dokončovat jednotlivé úkoly, zbývá pár chybějících dílků a otevřených otázek, které zvou k dalšímu bádání:
- Jak moc dokážeme takové systémy škálovat? Až autonomní organizace budou pracovat na čím dál větších úkolech a projektech s více paralelními agenty, jaké nové problémy vzniknou?
- Jak se mohou vlastní výstupy harnessu, jako je míra úspěšnosti CI napoprvé a nálezy z AI review, stát signály pro hodnocení? Jak měříme výkon agenta v organizaci a jak z toho uděláme systém, který se sám vyvíjí?
- Jak lze do takových systémů zapéct lidský cit pro design a produkt? Pokud lze inženýrství zautomatizovat s pouze řídkým lidským úsudkem, jak daleko to můžeme dotáhnout při řešení otázek, pro koho bychom měli software stavět a jak by měl vypadat?
Na závěr, děkujeme, že jste dočetli až do samého konce. Seznam úkolů pro hledání odpovědí na tyto otázky přiléhavě žije v Linearu, kde si ho možná vyzvedne náš další agent, nebo třeba vy.
