Myslitelé
Copilot to napsal, ale kdo to vlastní? Mezery v řízení, které mohou vývojářské týmy přehlédnout

Inženýr otevře Copilot, aby pomohl vytvořit kód pro web klienta. Během několika sekund získá kód, který by dříve trval podstatně déle, než by byl ručně napsán. Pro mnoho webových vývojářů a firem optimalizujících své weby je běžné se ptát: je tento kód spolehlivý? Je bezpečný? Měl by být před nasazením zkontrolován? Tyto otázky spadají pod jedno hlavní téma: kdo bude zodpovědný za kódování s pomocí AI? A co je nejdůležitější, kdo vlastní zisk na produktivitě?
Pokud AI umožní inženýrskému týmu dokončit více práce ve stejném čase, může z ekonomické hodnoty těžit všichni. Může to být vývojář, který šetří čas, zaměstnavatel, který získává více hodnoty z ušetřených hodin, nebo klient, který dostane to, za co zaplatil, s volnými hodinami navíc. Bez ohledu na to, jaký přínos ušetřený čas přináší, hlavní otázkou zůstává, jak je práce řízena a oceňována.
AI a kódování se stává nevyhnutelným
Nástroje pro AI kódování rychle získávají popularitu a pronikají do mainstreamového vývoje. Podle 2025 Stack Overflow Developer Survey, 84% respondentů používalo nebo plánovalo používat AI nástroje ve svém vývojovém procesu.
Ačkoli se zavádění AI do pracovních postupů webových vývojářů stává běžnějším, stále existuje váhavost ohledně její spolehlivosti. Tato samá anketa zjistila, že 46 % nemá plnou důvěru v přesnost výstupu AI a přibližně 66 % uvádí AI řešení, která jsou „téměř správná, ale ne úplně“, jako zdroj frustrace.
Debata o AI kódování, která se formuje, se týká spíše její spolehlivosti než toho, zda tento kód vytváří větší hodnotu a kdo je zodpovědný za to, aby tak bylo.
AI narušuje vztah mezi hodinami a výstupem
Odměňování vývoje softwaru vždy vycházelo z předpokladu, že výstup inženýrství úzce souvisí s úsilím inženýrů. Generativní AI však tuto rovnici nyní komplikují.
Kontrolovaný experiment zahrnující 95 vývojářů zjistil, že účastníci s přístupem k GitHub Copilot dokončili konkrétní úkol JavaScript HTTP serveru o 55,8 % rychleji než ti bez přístupu.
To ukazuje, že AI může urychlit vývoj, potenciálně bez ústupu na kvalitě. Tyto údaje jsou však úspěšné jen proto, že experiment sledoval velmi specifický programovací úkol. I když byl úkol dokončen rychleji, neznamená to, že Copilot učiní celou inženýrskou organizaci o 55,8 % produktivnější.
Další výzkumná studie ilustruje tento koncept. zkouška zahrnující 96 softwarových inženýrů Google na plný úvazek zjistila, že vývojáři používající AI dokončili úkol podnikové úrovně přibližně za 96 minut, ve srovnání s 114 minutami u těch bez ní. Upravený odhad výzkumníků naznačil přibližně 21 % zkrácení doby dokončení.
Studie však nezkoumá kvalitu kódu generovaného AI, ani se nevyjadřuje k otázkám spravedlnosti týkajícím se spolehnutí na tuto technologii.
Existují také důkazy, že AI zpomaluje dobu kódování. randomizovaná studie společnosti METR zahrnovala 16 zkušených vývojářů open source, kteří pracovali na 246 reálných problémech v repozitářích, které dobře znali. S využitím nástrojů dostupných na začátku roku 2025, včetně Claude Sonnet 3.5 a 3.7 a Cursor Pro, trvalo dokončení úkolů přibližně o 19 % déle, i když mnoho lidí předpokládalo, že tyto nástroje ušetří čas.
Společně tyto studie vyvracejí očekávání, že AI umožní vývojářům pracovat rychleji. Naopak činí čas vývojářů a jejich hodnotu méně předvídatelnou pro firmy poskytující webové služby i pro klienty, kteří je přijímají.
Cenový problém, o kterém se nikdo nezmiňuje
Time & Material (T&M) je běžný model ve webovém vývoji pro nákup softwaru, protože řeší opakující se problém odvětví: probíhající projekt.
V tomto modelu, místo aby bylo nutné definovat každou funkci nebo úkol před zahájením vývoje, mohou klienti platit za inženýrský čas, jak projekt postupuje a mění se.
Nicméně AI vytváří v tomto osvědčeném modelu problémy. Když je odměna přímo vázána na inženýrské hodiny, může efektivnější vývojový čas vést k menšímu počtu fakturovatelných hodin pro klienty. Pokud AI dosáhne stejných výsledků v kratším čase, technologie může vytvořit hodnotu pro klienty, ale snížení fakturovatelných hodin znamená menší příjem pro poskytovatele.
Řešením není povzbuzovat vývojáře, aby pracovali pomaleji. Model T&M nyní čelí strukturálnímu problému v tom, jak jsou navrženy ceny a pobídky. Používání hodinových sazeb k určení hodnoty může být omezující. Kupující může přesně vědět, kolik stojí každá inženýrská hodina, ale stále být nejistý ohledně celkové investice potřebné k dosažení požadovaného výsledku.
Jak AI mění produktivitu inženýrství, může se otázka posunout z:
- “Kolik stojí hodina vývojáře?” → “Co se stane s hodnotou, když je potřeba méně hodin vývojáře?”
Zjištění METR tuto otázku komplikují. Pokud vývojáři věří, že ušetří čas, když ve skutečnosti trvají déle, není ani přijetí AI, ani vnímaná produktivita dostatečná k prokázání finanční hodnoty. Proto organizace potřebují řízení, které dokáže změřit, co se ve skutečnosti stalo.
Proto organizace potřebují řízení, které dokáže změřit, co se ve skutečnosti stalo.
Mezera v řízení má čtyři vlastníky
Diskuse o řízení vývoje s podporou AI musí jít dál než jen o zásady, které upravují, jaké nástroje mohou vývojáři používat.
Existují alespoň čtyři typy vlastnictví, které by inženýrské organizace měly definovat.
1. Kdo vlastní kód?
AI může vygenerovat implementaci, ale nemůže být výmluvou pro vývoj bez odpovědnosti. Někdo stále musí být zodpovědný za revizi, testování a schválení kódu, dokud nedosáhne produkční fáze.
2. Kdo vlastní riziko?
Rychlejší kód je cenný jen tehdy, pokud nezpůsobuje problémy jinde. Empirická studie kódu generovaného AI identifikovala bezpečnostní slabiny v 29,5 % zkoumaných úryvků v Pythonu a 24,2 % úryvků v JavaScriptu. Výzkum také odhalil slabiny napříč 43 kategoriemi Common Weakness Enumeration.
Studie však zjistila, že vrácení varování statické analýzy zpět do Copilot Chat může opravit až 55,5 % identifikovaných bezpečnostních problémů. Výzkum ukazuje, jak AI může vytvářet i řešit problémy v kódu, ale organizace potřebují mít procesy, které určí, jak ověřovat její výstupy.
NIST’s SP 800‑218A odráží tento princip tím, že rozšiřuje svůj Secure Software Development Framework o osvědčené postupy, které řeší generativní AI a modely dvojího použití.
3. Kdo vlastní zisk na produktivitě?
Obchodní dohody od samého začátku jsou zásadní pro určení, kdo by měl získat přínosy z efektivity. AI může pomoci klientům utratit méně, umožnit týmům dodat více softwaru, nebo na konci projektu neposkytnout žádný finanční přínos.
Co zůstává stejné, je potřeba transparentních procesů a dodání kvalitní, dohodnuté práce.
4. Kdo vlastní prioritizaci?
AI může generování funkcí učinit levnějším a rychlejším, ale nemůže rozhodnout, zda jsou tyto funkce potřebné.
Ve skutečnosti může zvýšení kapacity vývoje učinit prioritizaci důležitější. Když týmy mohou rychleji stavět a experimentovat, někdo stále musí určit, které výsledky ospravedlňují dostupný rozpočet a které nápady by měly být opuštěny.
Řízení AI se stává finanční otázkou
Tyto otázky činí řízení AI čím dál tím relevantnějším. Představte si dva vývojové partnery účtující podobné hodinové sazby.
Jeden integroval AI do silného inženýrského procesu a dosahuje požadovaného výsledku podstatně rychleji, zatímco druhý trvá déle. Pouhé porovnání jejich hodinových sazeb neposkytuje kupujícímu mnoho informací o procesech, které budou provádět.
Kupující budou muset vyhodnotit:
- Celková očekávaná investice
- Odpovědnost za překročení rozpočtu
- Kontroly kvality u práce generované AI
- Jak jsou sdíleny přínosy efektivity
T&M může zůstat užitečný pro obě strany, pokud si vědomě uvědomí nejistotu ve službách. Fixní cenové dohody mohou také fungovat, pokud jsou požadavky a výstupy stabilní.
AI však také přináší alternativní struktury, které stojí za prozkoumání. Jeden přístup je stanovit maximální finanční hranici při zachování flexibilního rozsahu. Poté lze funkce prioritizovat podle obchodní hodnoty v rámci tohoto modelu.
Pokud se inženýrství stane efektivnějším, mohou přínosy přejít do rozšířené schopnosti produktu místo dalších fakturovatelných hodin. Komerční pobídky by měly podporovat stejný výsledek jako inženýrské pobídky, čímž vytvoří užitečnější software co nejefektivněji.
Stejná AI konverzace
Vedoucí inženýrství potřebují pochopit, jak komerční pobídky ovlivňují dodávky. Finanční a nákupní týmy potřebují dostatečnou přehlednost do AI‑asistovaného inženýrství, aby mohly posoudit, zda tvrzená efektivita přináší měřitelnou hodnotu.
To znamená, že vyspělá AI správa nemůže končit u schválených seznamů modelů, bezpečnostních kontrol, datových zásad nebo požadavků na revizi kódu. Musí řešit odpovědnost, finanční riziko, prioritizaci a vlastnictví zisků na produktivitě.
Existuje však druhá otázka vlastnictví, která by mohla mít mnohem větší dopad na rozpočty technologií: Kdo vlastní hodnotu vytvořenou nebo ztracenou, když AI mění rychlost, s jakou se software vytváří?
Organizace, které určí, zda rychlejší inženýrství skutečně produkuje lepší produkty, kontrolují investice a dosahují měřitelných obchodních výsledků, budou těmi, které zůstanou před konkurencí.
Kdyby váš vývojový tým zítra přijal AI, řekne vám vaše současná správa a komerční model vůbec, zda se dodávka stala hodnotnější?












