Čím víc pracuji s AI při skutečném vývoji, tím méně mě zajímá otázka, kolik kódu dokáže napsat. Mnohem víc přemýšlím nad tím, co její schopnosti udělají se způsobem, jakým skládáme týmy a celé technologické firmy.
Když se dnes bavíme o AI ve vývoji, často skončíme u produktivity.
Kolik procent kódu zvládne AI. Kolik hodin ušetří vývojáři. Kolik práce dokáže jeden člověk udělat oproti minulosti.
Je to pochopitelné. Je to dobře měřitelné.
Jenže při vlastní práci začínám vidět něco, co mi připadá strategicky mnohem zajímavější.
Nemění se jen množství práce, které jeden člověk zvládne. Mění se rozsah problému, který dokáže jeden člověk držet pohromadě.
A pokud se změní rozsah jednotlivce, možná bychom měli znovu otevřít otázku, jak kolem něj stavíme celou organizaci.
Kdybych zapomněl, jak jsme týmy stavěli posledních dvacet let
Zkouším si někdy položit jednoduchou otázku.
Kdybych dnes stavěl softwarovou firmu úplně od začátku a neměl v hlavě současné role, oddělení ani způsob práce, postavil bych ji stejně?
Nejsem si tím jistý.
Vezměme vznik nové business aplikace.
Ještě nedávno bych kolem ní přirozeně poskládal architekta, několik vývojářů, testery a podle potřeby analytika, UX, DevOps a další odbornosti.
Každý drží část problému.
Je to model, který známe a umíme řídit. Má ale jednu cenu, kterou už skoro nevnímáme.
Kontext neustále cestuje mezi lidmi.
Někdo pochopí potřebu zákazníka. Další ji analyzuje. Někdo navrhne rozhraní. Architekt vytvoří technické řešení. Vývojář ho realizuje. Tester ověří výsledek.
Každý jednotlivý krok může být proveden velmi dobře.
Přesto při každém předání něco vysvětlujeme, interpretujeme a znovu skládáme dohromady.
Dlouho jsme tuto cenu přijímali, protože jeden člověk jednoduše nemohl všechny tyto činnosti zvládnout.
Dnes začínám pochybovat, jestli to stále platí ve stejné míře.
AI podle mě zvětšuje hlavně rozsah člověka
Představme si zkušeného člověka, který rozumí vývoji, architektuře, produktu a dokáže mluvit se zákazníkem.
Dříve mohl mít dostatečné znalosti ve všech těchto oblastech, ale narazil na jednoduchý problém.
Kapacitu.
Nemohl současně navrhovat systém, tvořit obrazovky, implementovat všechny části, psát testy, kontrolovat výsledek a řešit provoz.
AI tuto hranici začíná posouvat.
Část realizace může předat agentům.
Najednou nemusí fyzicky vytvořit každý výstup. Může se mnohem více soustředit na rozhodování, směr a kontrolu toho, jestli jednotlivé části dohromady stále dávají smysl.
A tím se podle mě mění podstata jeho práce.
Jeho největší hodnotou už nemusí být:
Kolik toho dokáže vytvořit vlastníma rukama?
Ale:
Jak velkou část problému dokáže pochopit, držet v souvislostech a dovést k výsledku?
Tahle změna mi připadá mnohem důležitější než samotná rychlost psaní kódu.
Možná nepotřebujeme vlastníky částí. Potřebujeme víc vlastníků výsledku.
Když tuhle myšlenku rozvedu, začíná mi vycházet trochu jiný obraz zkušeného člověka v technologické firmě.
Není to jen programátor s AI.
A není to ani tradiční architekt, který navrhne řešení a následně jeho realizaci předá někomu jinému.
Je to člověk, který dokáže být u problému od začátku.
Pochopit, co se zákazník snaží vyřešit.
Pomoci problém strukturovat.
Převést ho do produktu.
Udělat hlavní architektonická rozhodnutí.
S pomocí AI velkou část řešení vytvořit.
A dostat ho až do provozu.
Jeho odpovědnost nekončí předáním diagramu nebo user story.
Končí funkčním výsledkem.
A právě tady začínám vidět jednu z možností, jak by se technologické organizace mohly měnit.
Méně lidí, kteří vlastní pouze jednu část procesu. Více lidí, kteří dokážou nést odpovědnost za celek.
Šířka ale nesmí předstírat hloubku
Tady je pro mě důležitá hranice.
Nemyslím si, že AI vytvoří člověka, který je zároveň nejlepší UX designer, enterprise architekt, security specialista, databázový expert, marketér i vývojář.
A ani bych se o to nesnažil.
Vidím to spíš jinak.
End-to-end člověk potřebuje dostatečný přehled, aby dokázal dělat rozumná rozhodnutí a poznal, kdy už jeho znalost nestačí.
V tu chvíli potřebuje specialistu.
Může navrhnout velkou část UI a u složitého procesu přizvat UX člověka.
Může vytvořit architekturu a zásadní rozhodnutí otevřít s dalšími architekty.
U bezpečnosti mohou být oblasti, kde nezávislou kontrolu neřeším podle pocitu, ale mám ji jako pevnou součást procesu.
Proto si nemyslím, že specialisté zmizí.
Spíš si začínám představovat, že je nebudeme potřebovat ve stejné intenzitě uvnitř každého jednotlivého týmu.
Mohou se stát sdílenou odbornou vrstvou firmy.
A to má ještě jeden význam.
Nechci, aby se z dialogu mezi jedním silným člověkem a AI stal uzavřený svět.
Potřebuji, aby měl svoje rozhodnutí s kým konfrontovat.
Aby firma dál sdílela zkušenost.
A aby jednotlivé projekty neztrácely společný směr.
Jak by tedy taková firma mohla vypadat?
Tady si pomáhám myšlenkovým experimentem.
Představím si firmu o padesáti lidech, která vytváří a následně dlouhodobě rozvíjí software pro zákazníky.
Neberu následující čísla jako doporučenou organizační strukturu. Zajímají mě spíš poměry a hlavně důvod, proč bych jednotlivé typy práce oddělil.
Možná bych deset lidí použil pro vznik nových systémů.
Byli by to velmi zkušení lidé s velkým rozsahem. Technicky silní, ale zároveň schopní pracovat se zákazníkem, produktem a nejistotou.
Jejich úkolem by nebylo strávit dalších pět let rozvojem stejné aplikace.
Jejich největší hodnotu vidím v situaci, kdy ještě není jasné, jak má řešení vlastně vypadat.
Vzali by problém, vytvořili základ systému, nastavili pravidla, komponenty, infrastrukturu i způsob práce s agenty.
A potom by přišel podle mě jeden z nejdůležitějších okamžiků celého modelu.
Systém by předali.
Nejlepší člověk nemusí dělat každou další změnu
Jakmile aplikace stojí, její architektura je stabilní a další rozvoj probíhá uvnitř známých pravidel, mění se povaha práce.
U nové business funkcionality už možná nepotřebuji člověka, který dokáže od nuly vytvořit celý enterprise systém.
Potřebuji zkušeného vývojáře, který se v systému zorientuje, umí řídit AI agenty, dokáže jejich práci zkontrolovat a pozná, kdy požadavek začíná překračovat současnou architekturu.
Ve svém modelovém padesátičlenném týmu bych proto další část kapacity vyčlenil právě na tuto práci.
Ne jako levnější náhradu lidí, kteří systém vytvořili.
Ale jako jinou roli v jiné fázi života produktu.
Tady začínám vidět zajímavou ekonomiku.
Největší úspora nemusí vzniknout tím, že zkušenému člověku zaplatím méně. Vznikne tím, že jeho nejdražší schopnost používám jen na problémy, které ji opravdu potřebují.
Jakmile je cesta známá, může pokračovat někdo další.
Člověka, který umí cestu hledat, potřebuji znovu tam, kde žádná ještě není.
A kam bych přesunul uvolněnou kapacitu?
Tady se pro mě celá úvaha přestává týkat pouze IT.
Pokud díky AI potřebuji menší množství lidské práce k samotné realizaci, první otázka nemusí být:
Koho už nepotřebuji?
Možná je zajímavější:
Kam můžu tuto kapacitu přesunout, aby firma vytvářela větší hodnotu?
Velkou část bych chtěl mít blíž k zákazníkovi.
Dnes bývá support často reaktivní.
Zákazník něco nahlásí. My problém vyřešíme.
Jenže pokud aplikace dobře měří své chování a AI dokáže pomáhat s jeho interpretací, můžeme některé problémy vidět dříve, než je zákazník vůbec pojmenuje.
To podle mě otevírá mnohem zajímavější roli.
Ne člověka, který jen přijme ticket.
Ale člověka, který se dokáže ptát:
Co se tady zákazník vlastně snaží udělat?
Proč se mu to nedaří?
Co potřebuje?
A je v tom něco, co bychom mohli vyřešit nejen pro něj, ale třeba i pro další zákazníky?
V takovém světě se část supportu přirozeně přibližuje customer success.
A možná i obchodu.
Mezi problémem a vývojem ale pořád něco chybí
To, že vidím potřebu zákazníka, ještě neznamená, že ji mám okamžitě naprogramovat.
Někdo musí přemýšlet:
Má tento problém dostatečnou hodnotu?
Koho dalšího se týká?
Je jeho řešení opakovatelné?
Patří do produktu?
Dá se monetizovat?
Nebo bychom jen draze automatizovali výjimku jednoho zákazníka?
Proto bych část lidí držel právě mezi zákazníkem a delivery.
Lidi, kteří dokážou z nejasného signálu vytvořit konkrétní příležitost.
Tady se pro mě začínají potkávat technologie, produkt a obchod.
A možná právě sem bych v budoucnu přesouval část kapacity, kterou dnes spotřebujeme samotnou výrobou softwaru.
Ve skutečnosti tedy neměním jen tým. Měním tok práce.
Když si celý model odmyslím od konkrétních počtů lidí, začne mi připadat poměrně jednoduchý.
Někde objevíme potřebu.
Někdo jí porozumí a rozhodne, zda stojí za řešení.
Pokud jde o běžnou změnu uvnitř existujícího systému, pokračuje k lidem, kteří tento systém rozvíjejí.
Pokud jde o něco, co mění jeho základ, dostává se znovu k lidem schopným pracovat s nejistotou a navrhnout nový celek.
Ti změnu vytvoří.
Stabilizují.
A znovu předají.
Nejde tedy tolik o konkrétní organizační diagram.
Jde o schopnost firmy posílat problém k takové úrovni zkušenosti, kterou právě potřebuje.
To mi připadá jako mnohem zajímavější způsob uvažování než prosté „AI nám zvýší produktivitu vývojářů o X procent“.
Jenže právě tady vzniká nový problém
Celý model má jednu poměrně zásadní slabinu.
Čím širší rozsah dáme jednomu zkušenému člověku, tím větší závislost na něm můžeme vytvořit.
Zná zákazníka.
Zná produkt.
Navrhl architekturu.
Ví, proč jsou komponenty právě takto.
Nastavil agenty.
Pamatuje si rozhodnutí, která nikde nejsou napsaná.
A protože je velmi produktivní, je lákavé nechávat všechno dál u něj.
Výsledek může na první pohled vypadat skvěle.
Menší tým. Vyšší rychlost. Menší koordinace.
Ale pak člověk odejde na jiný projekt a zjistíme, že každý důležitější požadavek se k němu stejně vrací.
V takové chvíli jsme podle mě novou organizaci nevytvořili.
Pouze jsme velký tým vyměnili za velmi efektivní single point of failure.
A právě to je místo, kde se pro mě strategie začíná překládat do konkrétního způsobu práce.
Schopnost firmy vzniká až ve chvíli, kdy dokáže pokračovat někdo další
Pokud chci tento model skutečně škálovat, nestačí mi, že jeden člověk vytvoří výborný systém.
Potřebuji, aby během práce zároveň vytvářel podmínky pro své vlastní předání.
A tím se najednou výrazně zvyšuje význam věcí, které jsme dříve mohli vnímat jen jako technickou disciplínu.
- Standardy
- Konzistentní architektura
- Reusable komponenty
- Pojmenování
- Testy
- Observabilita
- Zaznamenaná rozhodnutí
- Instrukce pro agenty
Najednou nejsou jen otázkou kvality kódu.
Jsou součástí toho, jak firma snižuje svou závislost na jednotlivci.
Téhle části se chci věnovat samostatně, protože podle mě rozhoduje o tom, jestli celý model může fungovat.
V navazujícím článku proto rozeberu, jak bych poznával, že systém už skutečně dokáže převzít někdo další:
AI ve vývoji: jak z výkonu jednotlivce udělat schopnost celé firmy (připravujeme)
Pro CEO z toho podle mě vznikají jiné otázky
Když se na to podívám z pohledu vedení firmy, najednou mě přestává zajímat jen počet lidí ve vývoji.
Začínám se ptát jinak.
Kde v našem procesu dnes skutečně vzniká hodnota?
Které lidi používáme na práci, která už nepotřebuje jejich úroveň zkušenosti?
Kolik kapacity spotřebujeme samotnou výrobou a kolik jí věnujeme hledání dalších potřeb zákazníka?
Jak odměňovat člověka, který díky AI dokáže nést několikanásobně větší odpovědnost?
A jedna otázka mi připadá ještě důležitější.
Jak budeme vychovávat další takové lidi?
Pokud AI postupně převezme část práce, na které jsme tradičně nechávali vyrůst juniory, nestačí změnit jen delivery.
Budeme muset změnit i způsob, jakým ve firmě vzniká zkušenost.
Tohle podle mě může být nakonec větší organizační problém než samotné zavedení AI nástrojů.
CTO podle mě čeká podobná změna z druhé strany
Pro CTO se tím podle mě neposouvá jen technologie.
Posouvá se i samotný smysl technického prostředí firmy.
Pokud chci, aby několik lidí bezpečně zvládalo větší rozsah, potřebuji jim připravit prostředí, které je předvídatelné.
Čím více bude každý projekt unikátní, tím více bude závislý na člověku, který ho vytvořil.
Čím více dokážu sjednotit principy, stavební bloky, způsob observability, security, delivery i práce agentů, tím snáz se zkušenost jednoho projektu může přenášet do dalšího.
CTO tak podle mě nebude řešit pouze:
Jakou technologii použijeme?
Ale stále více:
Jak vytvoříme prostředí, ve kterém může jeden schopný člověk bezpečně obsáhnout větší celek, aniž by se stal jeho jediným nositelem?
Možná nestavíme menší verzi dnešní firmy
Tohle je pro mě asi nejdůležitější bod celé úvahy.
Nejsem přesvědčený, že správnou odpovědí na AI bude jednoduše dnešní organizace s menším počtem lidí.
Když přijde technologie, která zásadně změní možnosti jednotlivce, má podle mě smysl alespoň na chvíli zapomenout, jak dnes firma vypadá, a znovu se podívat na problém, který řešíme.
Co vlastně potřebujeme?
- Potřebujeme pochopit problémy zákazníků.
- Vybrat ty, které stojí za řešení.
- Navrhnout smysluplné řešení.
- Vytvořit ho.
- Bezpečně ho provozovat.
- Rozvíjet ho.
- A znovu hledat další hodnotu.
Historické role jsou jen jeden způsob, jak jsme si tuto práci rozdělili.
AI nám možná umožní vytvořit jiný.
Ne nutně správnější pro každou firmu.
Ale podle mě dostatečně odlišný na to, aby stálo za to ho začít zkoumat.
Otázka, se kterou bych začal
Kdybych měl jako CEO nebo CTO udělat první krok, nezačínal bych počítáním licencí na AI ani tím, kolik vývojářů dokážeme ušetřit.
Vzal bych jeden skutečný projekt a položil si otázku:
Kdybych ho dnes stavěl od začátku s možnostmi, které máme, rozdělil bych odpovědnost mezi stejné lidi stejným způsobem?
Pokud ano, dobře.
Pokud ne, začíná být zajímavé hledat proč.
Kde pořád potřebujeme hlubokou specializaci?
Kde nám AI dovoluje spojit odpovědnost?
Které předávky už nepřinášejí hodnotu?
A kde naopak potřebujeme přidat lidskou diskusi, kontrolu nebo kontakt se zákazníkem?
Nejde mi o to předem znát správnou organizační strukturu.
Jde mi o to nevycházet automaticky z předpokladu, že struktura, která dávala smysl před AI, je zároveň nejlepší strukturou pro dobu s AI.
Právě tam bych dnes začal hledat.
Co bude následovat
V tomto článku jsem záměrně zůstal u strategie a rozložení práce.
Celý model ale stojí na jedné praktické podmínce:
člověk, který s AI vytvoří celý systém, se nesmí stát jediným člověkem, který v něm umí pokračovat.
V navazujícím článku proto půjdu o úroveň níž a rozeberu, jak bych předatelnost systému skutečně ověřoval — od práce dalšího seniora přes agentní testy až po signály v samotném repozitáři.
AI ve vývoji: jak z výkonu jednotlivce udělat schopnost celé firmy (připravujeme)