Jak měříme skutečný dopad AI na vývojáře (a proč nestačí počítat tokeny)

Náš vývojářský tým prohnal za posledních třicet dní AI nástroji šest miliard tokenů. Ve stejném okně napsala AI zhruba 135 000 řádků kódu, které šly do produkce.

Jsou to reálná čísla z našeho vlastního dashboardu. A sama o sobě taky skoro nic neznamenají.

Šest miliard je velké číslo. Šest set milionů taky. A šedesát miliard ještě víc. Ani jedno z nich vám neřekne, jestli byť jediný vývojář udělal svou práci rychleji, jestli byl ten kód k něčemu, nebo jestli by někomu v týmu vadilo, kdybyste mu nástroje zítra sebrali. Objemové číslo měří aktivitu, ne dopad. A ve chvíli, kdy ho začnete reportovat někomu nad sebou, začnou ho lidi tiše optimalizovat. A to je přesně špatná motivace.

Téhle pasti jsme se chtěli vyhnout, když jsme začali měřit používání AI napříč týmem. Tohle jsme postavili, tohle jsme se rozhodli měřit místo objemu a takhle upřímně se díváme na to, kde má takové měření meze.

Celé to odstartovala interní debata. Jeden z našich vývojářů, Damian, zpochybnil už samo pojetí „používání AI“ jako metriky. Jeho námitka byla přímá: vědět, jestli někdo spálil 100 000, nebo 100 milionů tokenů, vám o doručené hodnotě neřekne nic. Může to znamenat, že dělá těžší práci. Může to znamenat, že se zacyklil a pořád dokola promptuje model, který ho nechápe. Číslo vypadá v obou případech stejně a znamená pravý opak.

Ve skutečnosti chtěl deterministicky změřit, komu AI pomáhá víc. Ne agregovanou útratu, ale po jednotlivcích a po workflow zjistit, jestli si nástroje na sebe vydělávají. Právě tenhle posun úhlu pohledu je jádrem celého článku. V momentě, kdy přijmete, že spotřeba není hodnota, musíte jít a hodnotu definovat. A to je těžší.

Je to stejný problém, který před deseti lety vyřešily DORA metriky pro výkonnost dodávek softwaru. Frekvence nasazení sama o sobě je číslo na efekt; frekvence nasazení vedle change failure rate a doby obnovy se stává reálným signálem, protože se ty metriky navzájem hlídají. Měření AI potřebuje stejnou disciplínu: žádné číslo nestojí samo.

Provozujeme Grafana dashboard, který tahá data z naší MCP Gateway, z logovací vrstvy (Loki) a z editorů a agentů, které lidi denně používají, tedy z Cursoru a našeho interního Coworku. Je rozdělený do pěti oblastí a to rozdělení je důležitější než jakýkoliv jednotlivý graf:

Ta struktura v sobě nese přesvědčení: využití a dopad jsou ta snadná, svůdná čísla, a samy o sobě jsou nebezpečné. Spodní tři oblasti existují proto, aby ty horní dvě zůstaly poctivé.

„135 000 řádků AI napsaného kódu nasazeno“ je přesně ten typ statistiky, co skončí na slidu. Jsme vůči ní obezřetní z jednoduchého důvodu: počet řádků kódu je jedna z nejstarších zdiskreditovaných metrik produktivity v softwaru. AI to nespravila, jen zlevnila generování objemu, který vypadá jako pokrok.

Číslo Dopadu tak něco znamená jedině vedle svých pojistek. Když počet AI napsaných řádků roste a zároveň s ním roste change failure rate nebo množství přepisování v reviews, není to dopad, ale problém s kvalitou převlečený za dopad. Vrstva pojistek je to, co vám umožní rozlišit mezi „AI dodává funkční kód“ a „AI dodává kód, který zaplatíme za tři sprinty“. Pokud z tohohle postavíte jen jednu půlku, postavte pojistky. Graf objemu se o sebe postará sám.

Část, na kterou máme nejvyhraněnější názor, je sentiment, protože je to vrstva, kterou většina týmů přeskočí, a zároveň ta, která se nejhůř falšuje.

Postavili jsme malou Slack appku, která se týmu periodicky ptá, jak jim nástroje fungují. Lidi odpovídají kombinací emoji a volného textu, nízká bariéra a žádné formuláře. Odpovědi pak automaticky parsuje jazykový model (používáme na to Gemini 3.1 Flash) do témat a čtení sentimentu, takže kvalitativní zpětná vazba v malém měřítku neumře v tabulce, kterou nikdo neotevře.

Aktuální čísla: NPS 100 a 80% míra vyplnění dotazníku.

A tady musíme být poctiví, protože NPS 100 by v každém přemýšlivém člověku mělo vzbudit podezření. Náš tým je malý, zhruba jedenáct aktivních uživatelů AI, pět z nich intenzivně a každý den. Při téhle velikosti jediný frustrovaný člověk skóre dramaticky srazí a „100“ hlavně říká, že lidi, kteří si tyhle nástroje vybrali, jsou se svou volbou spokojení. Je to reálný signál, ale signál early adopterů, ne důkaz, že AI funguje všem. Reportujeme ho s touhle výhradou pokaždé. Perfektní skóre, které neokomentujete, je marketingové číslo, ne měření.

V čem je vrstva sentimentu opravdu dobrá, je směr. Když se v naparsovaných odpovědích opakovaně objeví nějaké téma — nástroj, který pořád rozbíjí jedno workflow, model skvělý pro jeden jazyk a k ničemu pro druhý — tomu pak věnujeme další kolo pozornosti. Skóre je titulek; ta témata jsou skutečný produkt.

Každá metrika v tomhle článku přestane být k něčemu ve chvíli, kdy se z ní stane cíl. To je Goodhartův zákon a AI nástroje jsou mu vystavené neobvykle silně, protože ty metriky se dají uměle pohnout extrémně snadno.

Řekněte lidem, že se jejich využití AI sleduje a hlídá, a využití vyletí nahoru. Ne proto, že se zlepšila práce, ale protože nikdo nechce vypadat jako ten pozadu. Udělejte z počtu AI napsaných řádků cíl a dostanete víc AI napsaných řádků a horší kód. Ošidit se dá i sentiment, jakmile si lidi spojí, že nízké skóre spustí poradu.

Čisté řešení na tohle nemáme a nevěříme nikomu, kdo tvrdí, že ho má. Co děláme v praxi: držíme dashboard jako týmový nástroj, ne nástroj hodnocení lidí. Čísla říkají, kam investovat do nástrojů a školení; neřadí jednotlivce do žebříčku. Ve chvíli, kdy začnou figurovat v něčím hodnocení, přestane celé to měření říkat pravdu a strávili jste čtvrtletí stavbou propracovaného způsobu, jak lhát sami sobě.

Náš přesný stack nepotřebujete. Ten postup se dá zopakovat s jakýmkoliv observability nástrojem, který už provozujete. Kdybychom to stavěli znovu od nuly, pořadí by bylo tohle:

Přístup „gateway na hranici“ je stejný kontrolní bod, který popisujeme v textu o MCP governance pro enterprise: vrstva, která už tak vidí každé volání AI, je přirozené místo, kde ho měřit, řídit a držet auditovatelné. Pokud provozujete AI nástroje v jakémkoliv měřítku, tu řídicí vrstvu nejspíš stejně potřebujete. Měření je jedna z věcí, které se vám na ní vyplatí. Je to postup, který balíme jako MCP Gateway Enterprise, i když ta myšlenka měření stojí sama o sobě bez ohledu na to, na čem ji postavíte.

Šest miliard tokenů, 135 000 řádků, NPS 100 — to všechno náš dashboard ukazuje. Když se nás ale někdo zeptá, jestli AI našemu týmu funguje, žádným z těch čísel nezačínáme. Samo o sobě tu otázku nezodpoví ani jedno.

Co sledujeme doopravdy, je vztah mezi nimi: produkuje ten objem kód, který přežije review, a říkají lidi, co tu práci dělají, že jim to pomáhá? Když se ty dvě věci hýbou spolu, to je dopad. Když se hýbe objem a zbytek ne, to je varování. Skutečná práce dashboardu není vyrobit působivé číslo, ale zviditelnit ten rozdíl dřív, než vás začne něco stát.

Jestli stavíte něco podobného a chcete porovnat poznámky o tom, co měřit (nebo se vám nechce drátovat gateway a observability vrstvu sami), ozvěte se. Přineseme dashboard, čísla, která nedáváme na slidy, a upřímné zhodnocení toho, kde měření pořád nestačí.