Pokud by AI existoval od samého začátku: Levnější kód nezjednodušil rozhodování o tom, co postavit

Velkou část historie softwaru byla drahá částí jeho budování. Týmy strávily měsíce přeměnou nápadů na funkční kód a tato vzácnost formovala vše o tom, jak byla práce organizována.

Roadmapy byly sekvenovány kolem dostupné inženýrské kapacity; architekti si vydobyli své místo u stolu, protože rozuměli systémům, kterým nikdo jiný nerozuměl; produktoví manažeři trávili týdny překladem vágních obchodních požadavků na něco, co by mohl vývojář zpracovat. Psaní softwaru bylo úzkým místem a přirozeně, psaní bylo tam, kde byla páka.

To už není pravda a tato změna nastala rychleji, než většina lídrů vývoje měla čas ji zpracovat.

Nástroje pro kódování AI zkolabovaly náklady na implementaci. Takže práce, která dříve trvala týmu inženýrů týdny, nyní trvá agentovi pár hodin. A zjevným předpokladem bylo, že rychlejší budování by se přímo přeložilo do rychlejšího doručování hodnoty.

Co se ve skutečnosti stalo, je však složitější: týmy mohou nyní produkovat více softwaru, než vědí, co s ním, a věc, která je zpomaluje, se tiše přesunula někam jinam.

“Nejde aplikovat AI na rozbitý proces,” řekl Pablo Gamba, ředitel technologií pro Ameriku ve společnosti intive, globálním startupu pro software a AI řešení. “Je to jako dát rychlejší lopatu dělníku. Bude pracovat rychleji, ale pouze ve špatném směru.”

Rychlejší provedení, stejná stará omezení

Každá velká inflexe v technologii – internet, cloud a outsourcing – následovala stejný tvar. Něco, co bylo dříve drahé, se stalo levným téměř přes noc a všechno, co firma postavila na předpokladu této ceny, muselo být strženo a přestavěno.

Tentokrát se levně stává aplikovaná technická inteligence sama, která se právě tak stala tím, za co služby firmy a inženýrské týmy strávily desetiletími, za co účtovaly, tvrdí Gamba.

Levnější provedení nezpůsobí, že omezení zmizí, ale pouze se přesune na méně viditelné místo. Úzké místo kódování, například, se při migraci po proudu urychlilo, ale překážka je nyní v kontrolě kódu. Automatizace kontroly kódu a objeví se v testování a nasazení; automatizace toho a nakonec se dostane na lidi, kteří píší specifikace, se kterými agenti pracují.

Protože agent může postavit pouze to, co je popsáno přesně enough, aby na to mohl jednat bez hádání.

To je past, do které mnoho týmů právě teď spěchá, často bez povšimnutí. Pokud můžete postavit téměř cokoliv za zlomek času, který to dříve trval, náklady na postavení špatné věci se zvýší, ne sníží, protože zjistíte, že jste se mýlili rychleji a s více již odeslaným.

Předpoklad, který dříve vyvstal pomalu, během týdnů manuálního kódování, může nyní stát před tím, než někdo uvědomí, že je třeba ho zpochybnit. Priorizace, ne syrový výstup, nakonec rozhodne, zda investice do AI skutečně zaplatí.

V tomto paradigmatu Gamba věří, že společnosti by měly sledovat ne rychlost vývoje, ale celý cyklus od záměru po produkci. “Pokud zlepšíte rychlost vývoje, ale kontrola kvality je vaše úzké místo, jste se k ní prostě dostali rychleji. Pak opravíte kontrolu kvality a úzké místo se přesune na požadavky,” řekl.

Čísla to potvrzují. Podniky Fortune 50, které používají AI-pomocený vývoj, odesílají commity 3-4krát rychleji než jejich kolegové, podle výzkumu Cloud Security Alliance, ale zavádějí nové bezpečnostní zjištění přibližně desetkrát častěji.

Rychlost bez jasného cíle v tomto smyslu ne pouze plýtvá úsilím, ale také zvyšuje riziko rychleji, než většina bezpečnostních týmů může držet krok.

Získání požadavků do jazyka, který AI skutečně využije

Pokud definice je tam, kde skutečně spočívá omezení, řešení není více dokumentace. Je to jiná dokumentace, napsaná v podobě, kterou může AI systém vykonat bez vyplňování mezer sám.

To znamená vyřazení požadavkové dokumentace napsané pro lidskou interpretaci s úsudkem a nahrazení ji strukturovanými akceptačními kritérii, explicitními doménovými modely a kontraktními testy, které jasně stanoví, co funkce nikdy nedělá, stejně jako to, co dělá.

Agenti, stejně jako junior inženýři, vyplňují nejasnost sebevědomým odhadem. Rozdíl spočívá v tom, že odhad juniora přichází zabalený v jisté nejistotě, vlajce seniorovi kolegovi, pocitu, že něco nemusí být v pořádku.

Odhad agenta vypadá jinak. Přichází jako čistý, plynulý, plně vytvořený kód a v něm není žádná rezerva, ani když je špatný.

Napsání specifikace dostatečně přesné, aby přežila tu mezeru, začíná připomínat méně psaní produktového briefu a více psaní smlouvy. Jmenujete každého aktéra, mapujete každou stavovou přechod, kterou systém smí provést, a zohledňujete hraniční případy místo toho, abyste je tiše nechali na šťastné cestě, jak to dosud dělají většina požadavkových dokumentů.

Týmy, které s tím nakládají jako s dokumentační povinností, se učí tvrdou cestou, že vágní záměr produkuje vágní software rychlostí stroje.

Týmy, které skutečně zachycují produktivitu, jsou ty, které píší specifikace jako samostatný inženýrský obor, se stejnou kontrolou verzí, cykly recenze a testovací přísností, které dříve byly vyhrazeny pro kód samotný.

Podle Gamba je AI-rodinný není povolení přeskočit proces, ale požadavek na kompletní redesign. “Mnoho organizací se snaží aplikovat AI na staré procesy. To není transformace. AI-rodinné organizace začínají s jinou otázkou: pokud by AI existoval od samého začátku, jak bychom navrhli tento proces dnes?”

Správci backlogs, kurátoři záměru

Produkt, architektura a inženýrství dříve běžely jako tři samostatné funkce s čistými předávkami mezi nimi: produkt rozhoduje, co postavit, architektura určuje, jak, inženýrství dodává.

Jakmile se implementace stane levnou a rychlou, tyto předávky se stanou nejpomalejší částí celého řetězce. Co zde nakonec záleží, je ten, kdo může držet celý obraz najednou, přeložit záměr do něčeho, co může agent vykonat, a chytit špatný předpoklad, než se stane odeslaným kódem, který nikdo nechtěl.

To, co nakonec záleží, je ten, kdo může držet celý obraz najednou, přeložit záměr do něčeho, co může agent vykonat, a chytit špatný předpoklad, než se stane odeslaným kódem, který nikdo nechtěl.

“Zamyslete se nad tím, co se děje se softwarem inženýra. Už nejsou pouze kódování. Dozorují výstup agentů, definují specifikace, připravují testy, ověřují výsledky. To spojuje, co dříve byly tři samostatné role do jedné,” řekl Gamba.

Jinými slovy, co je nyní cenné, není znalost, jak napsat lístek nebo spustit sprint. Je to znalost, co vypadá “skvěle” ještě předtím, než práce začne, být schopen rozlišit, co je intelektuálně zajímavé a co zákazníci skutečně potřebují, a mít odvahu rychle ukončit nápad, když zjevně nesplňuje tuto laťku.

Tyto soudy dříve rozložené napříč produktovým manažerem, architektem a technickým lídrem porovnávajícím poznámky se nyní stále více soustředí na toho, kdo je nejblíže k definování práce na prvním místě.

A je také důležité si uvědomit: nic z toho nezpůsobí, že tituly zmizí. Ale linie mezi nimi se stávají stále obtížnějšími, zatímco lidé, kteří prosperují v tomto rozostření, jsou ti, kteří jednají jako kurátoři záměru.

Rychlé provedení bez zábran není výhrou

Existuje riziko, které je snadné ztratit ze zřetele, jakmile je záměr jasný a AI potrubí skutečně funguje: rychlé, dobře definované provedení může stále zavést selhání, které by pomalejší, více lidsky zprostředkovaný proces chytil téměř náhodou.

Čísla zde nejsou ani close. Veracodeho jarní testování 2026 napříč předními modely zjistilo, že pouze 55 % úkolů generování kódu produkovalo zabezpečený výstup, když nebyla poskytnuta žádná explicitní bezpečnostní směrnice, číslo, které se téměř nezměnilo za dva roky, a to i přesto, že funkční přesnost skočila významně.

Je zřejmé, že získání syntaxe správně přestalo být těžkou částí před nějakým časem. Soudy, které lidský inženýr dříve činil instinktivně při psaní, kolem zabezpečení, dodržování předpisů a toho, co by se mělo a nemělo dotknout, jsou části, které jsou těžké nahradit.

To znamená, že stejná přísnost uplatněná na definování, co postavit, musí být prodloužena na definování, co je zakázáno, jako jsou hranice dodržování předpisů, pravidla zpracování dat a etické omezení stanovená se stejnou péčí jako funkční požadavky.

Nechat tyto implicitní a doufat, že agent je správně odvodí, je stejná chyba, jako nechat produktové požadavky vágní a doufat, že build nějak dopadne dobře.

Co vypadá vedení

Nic z toho nehovoří proti AI-urychlenému vývoji; budování nikdy nebylo rychlejší nebo levnější a není možné vrátit to zpět do lahve.

Ale co se nestalo jednodušší a možná dokonce obtížnějším, je rozhodnout s opravdovou přesností, co je stojí za to postavit, popsat to dostatečně přesně pro stroj, aby na to mohl věrně vykonat, a nakreslit linie, které mu nejsou dovoleny překročit.

Na úrovni podniku jsou týmy, které se dostávají dopředu, nejsou ty, které mají nejrychlejší kódovací agenty, to je jasné. Jsou to ty, které vyřešily, dříve než jejich konkurenti, že definice byla vždycky tvrdším problémem – a začaly s ním nakládat takto.