Agentic Development: Jak přejít na AI vývoj – praktický plán

Spotify hlásí, že jejich nejlepší vývojáři od prosince nesáhli na kód. Uber v březnu 2026 reportoval, že 84 % jejich developerů jsou aktivní uživatelé agentického toolingu a 65–72 % kódu generuje AI.

V Ackee jsme se mohli dívat a čekat… Rozhodli jsme se místo toho postavit vlastní framework, jak agentic development zavést strukturovaně, bez chaosu a bez toho, aby to byl jen módní buzzword a my mohli psát na linkáč, jak nám už neujíždí vlak.

ℹ️ TL;DR – co si z toho odnést

• SDLC v klasické podobě přestává platit – přichází ADLC, kde developer orchestruje agenty místo psaní každého řádku kódu.
• Agentic engineering vyžaduje strukturu – není to vibecoding a merged PR bez review.
• Tooling sjednocený na jedné platformě (Claude) funguje lépe než roztříštěná kombinace nástrojů – sdílená knowledge base má pak větší smysl.
• Měřit adopci dává smysl na 2 osách – projekt (PAL) a jednotlivec (Proficiency Level) – obojí musí jít ruku v ruce.
• Kdo začne dřív, bude mít náskok, který se těžko dohání – to platí pro firmy i pro jednotlivé vývojáře.

✅ TL;DR – akční kroky

1. Zaveďte ADLC postupně: začněte PAL1 (kontext + nastavení), ne rovnou E2E.
2. Učte se psát kontext: investice do promptů šetří čas i tokeny.
3. Centralizujte tooling: jednotný Claude setup s MCP minimalizuje chaos.
4. Měřte lidi i projekty: PAL + proficiency levels = bezpečný rollout.
5. Kontrolujte agent-generated PR: review a testy jsou nezbytné, ne úplně volná ruka.

🔚 Proč SDLC přestalo fungovat – a co ho nahrazuje

Software Development Lifecycle, tak jak ho známe, předpokládá, že člověk píše kód. Tenhle předpoklad je dnes zpochybnitelný. Nastupuje Agentic Development Lifecycle = ADLC – kde agenti plánují, implementují, testují a debugují.

Nejde o dystopii. Jde o to, že repetitivní části práce, které stejně nikoho nebavily – přebírá agent, zatímco člověk řeší to, co agenti neumějí: kontext, rozhodnutí, odpovědnost.

Co agentic development v praxi neznamená (🤫 spoiler: vibecoding)

Tohle konkrétně se v podobných debatách nejčastěji ztrácí: agentic engineering není vibecoding. Není to „nechám si vygenerovat komponent, mergnu to a jdu na oběd." Vyžaduje strukturu, pravidla a hlavně trpělivost.

Je to proces se striktními pravidly, ne bezhlavé mergování. Developer musí rozumět tomu, co agent dělá, umět zkontrolovat výstup a vědět, kdy agenta zastavit. To se nenaučíte za odpoledne.

Lze použít stejnou analogii z nedávné minulosti: iOS tým v Ackee se taky musel smířit s nástupem Kotlin Multiplatform. Nelíbilo se jim to, bolelo to – ale vzali to jako příležitost, ne jako hrozbu. Stejný mindset teď potřebuje celý dev tým vůči AI.

⚒️ Jak jsme vyřešili tooling, aneb jeden setup pro celou firmu

Chaos v toolingu zabíjí adopci. Pokud má polovina týmu Cursor, čtvrtina GitHub Copilot a zbytek zkouší různé Codexy, nikdo nesdílí knowledge a každý vynalézá kolo zvlášť. Proto jsme se sjednotili na platformě Anthropic.

Konkrétní setup vypadá takto:

• Claude Code pro vývojáře (CLI nástroj, který pracuje přímo v terminálu a IDE).
• Claude Cowork pro back office a projektové manažery.
• Claude Chat jako standardní konverzační rozhraní.
• Všechny komponenty podporují MCP (Model Context Protocol) pro napojení na externí nástroje a systémy.

Proč Anthropic a ne OpenAI? Data z Ramp AI Indexu ze začátku roku 2026 ukazují, že 73,3 % firem, které poprvé utrácejí za AI, volí Claude – OpenAI má 26,7 %. Anthropic začíná dominovat právě v enterprise segmentu, kde záleží na konzistenci a bezpečnosti dat.

📊 Jak měříme, kde na té cestě jsme: PAL a Proficiency Levels

Aby adopce nebyla punk a black box, zavedli jsme 2 měřící systémy:

1. Project Adoption Levels (PAL)

Sledují, jak moc je AI integrovaná na konkrétním projektu:

• PAL1: Baseline kontext a nastavení projektu pro agenta.
• PAL2: Vlastní skills, agenti, MCP integrace, hooks.
• PAL3: Komponentní orchestrace a agentic loop.
• PAL4: E2E agentic workflows = agenti běží v autonomní smyčce (plánování → volání nástrojů → testování → review).

2. Agentic Engineering Proficiency Levels

Měří individuální skill každého vývojáře – od Level 0 (Beginner) přes Level 3 (Context Builder) až po Level 11 (Builder & Harness Engineer), který staví vlastní agenty a nástroje. Podrobný rozpis všeho, co by měl vývojář na daném Levelu zvládnout, máme sepsáno v interním Notionu, do kterého mají všichni developeři přístup.

Klíčové pravidlo: Aby projekt mohl být na PAL1, musí vývojáři na něm dosáhnout aspoň Levelu 3–4.

🎯 Konkrétní cíle, ne vize.

Frameworky bez deadlinů jsou jen hezká prezentace. Proto máme 3 konkrétní milníky od začátku integrace:

1. Do konce 1. měsíce: Všichni vývojáři mají rozběhnutý Claude Code, projekty jsou na PAL1 a developeři minimálně na Proficiency Levelu 3–4.
2. Do konce 2. měsíce: Posun na PAL2, kdy AI autonomně odbavuje repetitivní úkoly a je zaveden automatizovaný feedback loop.
3. Od 3. měsíce a dál: Míříme k PAL3 a PAL 4, tedy k plnému agentic loopu na největších projektech.

Adopce se měří i tvrdě: v Claude Code analytikách je vidět, kdo nástroj skutečně používá. Limity licence se dají navýšit – ale jen těm, kteří je poctivě vyčerpají prací.

💡 Co z toho plyne pro každého vývojáře osobně

Tohle není jen firemní iniciativa. Je to věc, která se dotkne konkurenceschopnosti každého jednotlivce na trhu práce. Pokud se na tuhle změnu vykašlete, budete ztrácet pozici. Firmy, které AI neadoptují, budou dávat vyšší odhady a prohrávat projekty s těmi, které ji adoptují.

Na druhé straně: cílem Ackee není nahradit lidi. Cílem je dávat lepší nabídky, brát víc projektů a mít méně regresních bugů. To jsou věci, ze kterých má prospěch vývojář stejně jako firma.

Chcete pomoct zavést agentic development do praxe?

Bavíme se o tom, jak podobný přístup zavést u klientů. Pokud jako firma řešíte digitální produkt a zajímá vás, co to znamená konkrétně pro váš tým nebo projekt, 👉 ozvěte se – rádi o tom s váma pokecáme.

Tenhle článek vznikl z interního lightning talku Rosti. 👉 Přihlaste se k newsletteru – dostanete příští takový obsah přímo do schránky.