Než se Rostislav Babáček na interním Lightning Talku dostal k hodnocení cílů AI adopce, musel nejdřív vyřešit nefunkční sdílení obrazovky. A jakmile se prezentace konečně rozjela, ukázalo se, že jí něco chybí – část slidů si napsal v Claude Code těsně před vystoupením, a nástroj mu mezitím kousek smazal.
📋 TL;DR
- Adoption level měří hloubku AI zapojení na projektu, proficiency level schopnosti jednotlivého vývojáře – dvě různé škály, které se neplní automaticky společně.
- V dubnu 2026 byl cíl unifikovat celý tým na jediný nástroj, Claude Code (dřív někdo Codex, někdo Cursor), a dostat projekty na adoption level 1, lidi na proficiency level 3–4.
- Do konce května 2026 měly projekty dosáhnout adoption level 2, lidé proficiency level 5–6. Z 21 sledovaných projektů to splnilo 18, tedy 86 %.
- U proficiency levelů vznikl rozdíl mezi tím, co lidé nahlásí sami (83 % splnění), a tím, co potvrdí reálná aktivita v Notionu (73 %) – desetibodová mezera, která se stala tématem samotného talku.
- Na léto 2026, do konce srpna, přichází levely 7 až 9, kde už nejde o „umím použít agenta“, ale o celá workflows kombinující agentické nástroje se staršími principy softwarového inženýrství.
- Nový rámec PAL 3A a 3B: 3A je skládání skillů do funkčních postupů a AI code review, 3B udržitelný projektový kontext pro agenta.
- Cílem na léto je zapojit do kontribuce všechny vývojáře, ne jen dosavadní desítku nejaktivnějších.
- Experiment AFK: agent dostane jen link na ticket s hotovým PRD a sám ho zpracuje – den na plánování, noc na paralelní běh agentů.
- Druhý letní prototyp: automatizovaná validace UI na iOSu, Androidu i na frontendu.
🧭 Adoption level a proficiency level: dvě různé škály
Ackee sleduje AI adopci na dvou nezávislých osách. Adoption level popisuje, jak hluboko je agentický vývoj zapojený na konkrétním projektu – vyjadřuje ho číslo levelu, ke kterému má projekt podle předem daných cílů dosáhnout. Proficiency level (AEPL) popisuje totéž u konkrétního člověka: co všechno umí a jak s tím pracuje v praxi.
Rozdíl je záměrný. Projekt může mít vysoký adoption level i s týmem, ve kterém je zrovna někdo na nižším proficiency levelu, a naopak – úroveň projektu a úroveň konkrétního člověka na něm se neplní automaticky společně.
Levely se navíc podle Rostislava Babáčka neplní tím, že se o tématu jednou popovídá na meetingu. Level je splněný, až když ho člověk umí použít v praxi – a to se dá ověřit jen podle toho, co se skutečně děje v nástrojích, které tým používá, ne podle vlastního vyplnění v tabulce.
„Není to tady jenom o pár osobách, ale je to o nás všech. Prostě všichni na tom mají nějaký podíl.“
🧩 Duben a květen 2026: unifikace nástrojů a první čísla
Na začátku dubna 2026 měl tým jasně definovanou startovní čáru: než se dá cokoliv měřit, musí se sjednotit, s čím se vlastně pracuje. Předtím totiž platilo, že si každý vybíral nástroj podle sebe: někdo Claude Code, někdo Codex, někdo Cursor. Cíl na duben 2026 proto zněl jednoduše – sjednotit se po Velikonocích na jednom nástroji a rozjet ho naplno, ne jen ho vyzkoušet.
Cíle na květen 2026 šly ve stejném duchu dál: první pokus rozjet na vybraných projektech reálný feedback loop a zautomatizovat větší kus opakujících se procesů. Reálně se ale oba měsíce trochu slily do jednoho: než se vytvořily tikety a než se všechno definovalo, natáhly se cíle až do dne, kdy se o nich mluvilo na talku.
Výsledek: ze 21 projektů, které si na to tým s projektovými manažery vytipoval, se 18 posunulo na cílový adoption level – 86 %. Jeden zůstal na nižším levelu a dva se nepodařilo posunout vůbec.
📈 Proč si čísla neodpovídají
U proficiency levelů se objevil zajímavější problém než u projektů. Podle vlastního vyplnění v tabulce dosáhlo cílového levelu 25 ze 30 sledovaných vývojářů – 83 %. Jakmile se to ale ověřilo podle skutečné aktivity v Notionu, kde se levely reálně dokumentují, úspěšnost klesla na 73 %, tedy o zhruba 10 procentních bodů níž. Cíl pro druhé kolo byl 75 % – chyběly tak jen 2 procentní body, ale rozdíl mezi „nahlásil jsem“ a „dělám to“ byl dost velký, aby si zasloužil vlastní část talku.
Desetibodová mezera mezi tím, co lidé sami vyplní, a tím, co potvrdí data z nástrojů, které tým skutečně používá, je připomínka pro každý interní tracking – ne jen pro AI adopci. Bez ověření proti reálné aktivitě zůstává self-report jen odhadem toho, jak by to lidé chtěli mít.
To je i důvod, proč nové cíle na léto 2026 míří jinam než jen „splň další číslo v tabulce“.
🛠️ Levely 7 až 9 a PAL 3A/3B: od „umím agenta“ k workflows
Nové levely na léto 2026 jsou kvalitativně jiné než ty předchozí. Doteď šlo hlavně o to, aby lidé uměli agentický nástroj používat. Levely 7 až 9 posouvají cíl k tomu, aby z jednotlivých použití agenta vznikaly celé workflows, kombinace agentických nástrojů se staršími, prověřenými principy softwarového inženýrství jako extreme programming nebo domain-driven design. Cíl je podle Rostislava Babáčka jasně daný: do konce srpna 2026 má být na levelu 9 celý tým.
Vedle toho se zpřesňuje i PAL (Project Adoption Levels) – framework pro adopci agentic engineeringu na úrovni projektu, který Rostislav Babáček představil v článku o Agentic Development Lifecycle. Nově se jeho třetí úroveň dělí na PAL 3A a 3B, ne „3 a 4“, protože jde o dvě prolínající se témata na stejné úrovni, ne o navazující kroky.
Obě části se řeší současně a vzájemně se podmiňují – bez udržitelného kontextu (3B) nemá skládání skillů do workflows (3A) na co navazovat, a naopak. Označení A/B má ukázat, že jde o jeden krok se dvěma stranami, ne o postup po sobě.
PAL 3A je o skládání jednotlivých skillů do funkčních postupů – nemusí to být hned orchestrátor, klidně stačí diagram v README, který popisuje, jak se ticket promění v merge request. Součástí je i rozšířené AI code review přímo v merge requestech na GitLabu, nad rámec základních pravidel navíc s architektonickými good practices a code style guidy, s výhledem na to, aby si agent nalezené problémy do budoucna i sám opravoval.
PAL 3B řeší udržitelný projektový kontext – pro agenta, ale i pro lidi. Index souborů a kontextu, architektonická rozhodnutí, slovník pojmů, mapa závislostí mezi moduly, „handoffy“ pro předání práce při přerušení tasku a „kontrakty“ – API specifikace, schéma databáze, odkazy na Figmu. Bez toho agent (i nový člověk v týmu) opakovaně zjišťuje věci, které už někdo jednou vyřešil.
V diskuzi po talku padla i otázka, jestli by podobný projektový kontext nemělo smysl propojit i s dokumentací směrem ke klientům, ne jen interně. Podle Rostislava Babáčka je to jiný problém: produktová dokumentace pro klienty rychle zastarává a neodpovídá aktuálnímu stavu codebase, zatímco dokumentaci, která reflektuje samotný kód, se už na jednom z projektů daří automatizovaně udržovat. Jak spojit obě roviny, tým ještě úplně vyřešené nemá – podobně jako u skillů v předchozím kole, kde teprve praxe ukázala, které z nich mají smysl, i tohle bude potřeba nejdřív vyzkoušet.
Třetí letní cíl je jednodušší na pochopení, těžší na splnění: aktivita. Dosud do interní kontribuce (vlastních skillů a merge requestů s dopadem přesahujícím jednoho vývojáře) zapojilo jen zhruba 10 lidí. Cílem na léto 2026 je, aby si podobný task z AI backlogu vytáhl každý.
🌙 AFK: agent, který dostane jen link na ticket
Kromě tvrdých cílů běží na léto 2026 i dva experimenty, u kterých je těžké dopředu měřit úspěch – proto zůstávají označené jako „soft“.
První se jmenuje AFK a je z nich odvážnější. Agent nedostane detailní instrukce, jen link na ticket, ke kterému už existuje technické PRD. Zbytek (zpracování, validační smyčky, code review, merge request) má zvládnout sám. Vize je rozdělit práci na den a noc: přes den lidé plánují a píšou PRD k jednotlivým ticketům, přes noc běží paralelně několik agentů, kteří je zpracovávají bez dohledu.
Cíl experimentu není okamžitá dokonalost, ale zjistit, pro jaké typy práce automatizace bez dohledu vůbec dává smysl – testuje se na malých i větších features a na bugfixech zvlášť, protože předpoklad je, že se budou chovat jinak.
📱 Validace UI a další prototypy
Druhý letní prototyp je konkrétnější: vyzkoušet si na iOSu, Androidu i na frontendu automatizované proklikávání UI flows a ověřit, jestli se dá UI testování takhle reálně automatizovat.
Často kladené otázky
🎯 Co si odnést
Měřit AI adopci číslem je snadné, ověřit, co to číslo skutečně znamená, je ta těžší část. Rozdíl mezi 83 a 73 procenty ukazuje, že bez porovnání se skutečnou aktivitou zůstává i dobře myšlený tracking jen odhadem. A posun z „umím použít agenta“ k levelům 7 až 9, tedy k celým workflows a udržitelnému projektovému kontextu, je připomínka, že agentický vývoj nekončí tím, že si nástroj zapneme, ale tím, jak dobře ho zapojíme do zbytku své práce.
Talk podle Rostislava Babáčka nekončil oslavou splněných čísel, ale výzvou do dalšího kola: „Pojďme se posunout k tomu, že neděláme jenom hezký agenty s hezkýma stickerskama, ale ať ty agenty nám fungujou a dávají nám dobrý output.“
Širší rámec, do kterého PAL i AEPL zapadají, popisuje článek o Agentic Development Lifecycle zmíněný výš. A protože cílem na léto 2026 je, aby skilly a znalosti kolovaly mezi lidmi a ne jen v hlavách pár nadšenců, hodí se k tomu i článek o sdílení AI know-how přes Claude Code pluginy.
Podobné postřehy z Ackee najdete v newsletteru – přihlaste se a příští takový obsah vám přijde přímo do schránky.
