Co budou dělat developeři?

V poslední době se hodně mluví o tom, že díky AI je angličtina nový programovací jazyk. Vzniká tak dojem, že programovat může každý. Jak už to u marketingových sloganů bývá, skutečnost je složitější. V tomto článku se proto podívám na vývoj softwaru trochu do hloubky a pokusím se ukázat, jak se podle mě role developera v době AI změní.

Jednoduchou aplikaci dnes skutečně může napromptovat téměř každý. Přirozeným jazykem popíše, co má dělat, AI vytvoří implementaci a po několika iteracích vznikne funkční software.

Ale jak už zjistila řada vibe-coderů, s rostoucí složitostí softwaru je stále těžší udržet celou věc pohromadě. Každý komplexní systém má nějaký vnitřní model. Někdy je explicitně popsaný, často ale jeho velká část existuje jen v hlavách developerů. AI se ho může pokusit odvodit z kódu, ticketů a dalších artefaktů, mnohem spolehlivěji ale funguje, když je tento model zachycený explicitně. Práce developera se tak přesouvá od samotné implementace k udržování modelu systému a k architektonickým rozhodnutím kolem něj.

Těžiště práce developera se přesune od implementace k modelování systému a architektuře.

Když přirozený jazyk přestane stačit

Složité systémy nelze dlouhodobě popisovat jen prózou. Ne proto, že by to nezvládla AI, ale hlavně proto, že to nezvládneme my lidé.

Jak přibývají pravidla, logika, data a jejich vazby, začneme se v popisu ztrácet. Vrstvíme pravidla na pravidla, vznikají rozpory a nejednoznačnosti a postupně ztrácíme přehled o tom, co je vlastně aktuální požadovaný stav systému.

Přirozený jazyk nestačí k jednoznačnému popisu komplexního systému.

AI se sice umí doptat, ale pokud odpověď neznáme ani my, je to málo platné. Chybějící odpověď nakonec nahradí vlastním předpokladem a tím se rozbíhá spirála, ve které se systém postupně vzdaluje původnímu záměru.

Matematici tento problém řešili dávno před vznikem počítačů. Matematická notace nevznikla proto, že by matematici neuměli psát věty, ale protože při určité úrovni složitosti potřebovali přesnější způsob práce s významem.

Software má stejný problém: pokud chceme komplexitu zvládnout, potřebujeme přesnější a strukturovanější popis než prózu.

Návrat ke kořenům

Před patnácti lety jsme běžně pracovali tak, že business formuloval potřebu a analytik z ní vytvořil konzistentní a strukturovaný popis systému. Ten zachycoval datový model, pravidla, algoritmy, invarianty, oprávnění a další důležité prvky. Byl to popis dostatečně abstraktní, aby nebyl závislý na konkrétní technologii, a zároveň dostatečně přesný, aby se podle něj dal systém konzistentně rozvíjet.

Problém byl, že tento kanonický model systému lidé příliš nemilovali.

Business ho často neuměl dobře číst. Developeři ho považovali za zbytečnou formalitu a raději šli programovat. Analytik proto nebyl jen autorem modelu, ale také překladačem mezi světy: pomáhal businessu model pochopit a developerům převést ho do stories, tasků a konkrétní implementace.

Řada týmů pak tuto disciplínu postupně opustila a nahradila ji backlogem. Tím ale nevznikl popis systému, jen historie jeho změn.

Backlog popisuje změny. Kanonický model popisuje aktuální stav systému.

S živými developery mohl takový přístup fungovat překvapivě dlouho, protože velká část skutečného modelu systému zůstávala v jejich hlavách. Znali důvody historických rozhodnutí, věděli, kde jsou citlivá místa, a dokázali odhadnout, co nová změna může rozbít.

Problém nastal ve chvíli, kdy se tým obměnil.

Pak přichází věta, kterou zná skoro každý, kdo někdy přebíral cizí systém:

„To se musí celé přepsat.“

Často to není důkaz, že předchozí tým napsal špatný software. Je to spíš důkaz, že spolu s lidmi zmizela i část modelu systému, která nikdy nebyla nikde zachycená.

AI mění ekonomiku vývoje

Kanonický model, který byl pro lidi často nepohodlnou mezivrstvou, je pro AI naopak velmi vhodným vstupem. Přesně definovaná data, invarianty, stavy, algoritmy a kontrakty jsou mnohem spolehlivější než historie ticketů a znalosti ukryté v hlavách několika seniorních lidí.

Co bylo pro developera často jen dokumentací, se pro AI může stát skutečným zadáním.

AI tím dramaticky zlevňuje převod modelu do implementace. A jakmile je implementace levná, hodnota se přesouvá o úroveň výš: k tomu, kdo dokáže systém správně popsat a jeho model dlouhodobě udržet konzistentní.

Co tedy bude dělat developer

Role developera nezmizí, ale zásadně se změní.

Jedna část jeho práce bude analytická. Developer bude muset pochopit business, zachytit logiku systému v kanonickém modelu a udržovat ho při dalším rozvoji konzistentní.

Druhá část jeho práce bude architektonická. Developer bude mimo jiné rozhodovat o hranicích služeb a vlastnictví dat, určovat, co musí být transakční a kde lze naopak připustit dočasnou nekonzistenci dat. Bude navrhovat rozhraní a způsob nasazení. Zároveň bude řešit, jak systém zapadne do infrastruktury firmy.

Developer samozřejmě bude muset rozumět i výslednému kódu. Jeho práce ale nebude spočívat v tom, že po AI ručně přečte každý vygenerovaný řádek. Důležitější bude ověřit, že výsledný software odpovídá kanonickému modelu a architektonickým rozhodnutím. Stále větší část této kontroly mohou převzít testy, kontrakty a další automatické mechanismy.

T-shape už nestačí

To je nepříjemná zpráva hlavně pro úzce zaměřené specialisty. Bude stále těžší stavět svou hodnotu například jen na tom, že jsem frontend developer a čekám na perfektně připravený ticket v backlogu. Klasický T-shaped profil s jednou hlubokou specializací už nemusí stačit.

Budoucí developer bude muset mít mnohem širší záběr. Jeho profil bude připomínat spíš hrábě. Bude muset dostatečně rozumět doméně, datům, architektuře, bezpečnosti i infrastruktuře, aby dokázal držet systém pohromadě.

Specializace nezmizí. Přestane ale stačit.

Může z toho vzniknout jedna role, nebo dvě. Jedna bude bližší businessu a kanonickému modelu, druhá technologiím a architektuře. Podstatné je, že hodnota se přesouvá od psaní kódu k práci s komplexitou.

AI z developerů neudělá promptery. Spíš je donutí vrátit se k samotnému softwarovému inženýrství.

Kód bude levnější. Správná rozhodnutí ne.
Budoucí developer tak nebude vlastnit kód. Bude vlastnit komplexitu systému.