London AIE Summit 2026: Jak ve skutečnosti vypadá AI inženýrství

London AI Engineer Summit 2026 měl být oslavou pokroku. Místo toho působil jako zrcadlo nastavené profesi uprostřed nervového zhroucení.

Tři dny na začátku dubna se stovky AI inženýrů, stavitelů platforem a výzkumníků sešlo, aby sdíleli, co se naučili. Co se objevilo, byl vzor: všichni staví s agenty, nikdo nepřišel na to, jak je ovládat, průmysl je rozdělen v tom, zda jít rychle nebo myslet pečlivě, a celý předpoklad, že nás AI učiní produktivnějšími, byl obrácen v něco temnějšího.

Toto je to, co jsme se skutečně naučili.

Proč AI inženýři kódují s agenty, které nemohou ovládat?

Nejupřímnější konverzace na summitu se odehrála na chodbě, ne na pódiu. Inženýr ze středně velké fintech společnosti popsal problém takto: „Spustím prompt a tři hodiny poté můj agent přepsal polovinu kódové základny, přidal funkce, které jsem nežádal, a spotřeboval 800 liber výpočetního výkonu. Nemůžu od stolu."

Toto je FOMAT: Fear of Missing Attention Time. Není to vtip – je to definující úzkost AI inženýrství roku 2026.

Překážka orchestrace

Všichni na summitu používali agenty. GitHub Copilot, Claude, vlastní agentní frameworky – nástroje dozrály. Ale orchestrace ne. Propast mezi „mám agenta" a „můj agent dělá to, co jsem zamýšlel, a nic víc" je obrovská.

Problém se projevuje třemi způsoby:

Rozjetí tokenů. Agenti nemají přirozené body zastavení. Bez explicitních zábradlí stále iterují. „Jen ještě jeden refactoring," myslí si agent, a najednou jste spálili svůj měsíční rozpočet.

Rozšíření rozsahu. Požadavek „vylepšit zpracování chyb" se stává „přepsat celý systém zpracování chyb, přidat pozorovatelnost, refaktorovat vrstvu logování a implementovat distribuované trasování". Agent se nemýlil – byl důkladný. Ale nebylo to to, co jste žádali.

Nepředvídatelná latence. Nemůžete vědět, jak dlouho bude agentní úloha trvat. Závisí to na tom, kolik dílčích úloh se agent rozhodne vytvořit, kolik selhání narazí a zda se rozhodne opakovat nebo změnit směr. To činí agentně řízené workflow nemožné plánovat v produkčních systémech.

Jaký byl konsenzus summitu (a jaký nebyl)

O řešeních nebyl konsenzus. Některé týmy používají tvrdé limity tokenů. Jiné implementují „kontrolní body agenta" – nutí agenty pozastavit se a požádat o povolení, než budou pokračovat. Několik jich přechází k hierarchickým systémům agentů, kde „manažerský agent" dohlíží na pracovní agenty a může je přerušit.

Přístup FlowHunt – explicitní definice workflow s uzly agentů, ošetřovači chyb a logikou větvení – byl několikrát zmíněn jako potenciální vzor. Myšlenka: nenechat agenty rozhodovat o struktuře workflow. Definujte ji předem, pak nechte agenty provádět jednotlivé kroky.

Ale i to působilo jako náplast. Skutečný problém je, že chování agenta je inherentně pravděpodobnostní. Můžete snížit rozptyl, ale nemůžete ho eliminovat.

Jak rozkol OpenAI-Anthropic přetvořil význam „dobrého kódu"?

V pondělí ráno vystoupil Ryan Lopopolo z OpenAI na pódium a přednesl keynote, který lze shrnout jako: Přestaňte číst kód. Staňte se tokenovým miliardářem.

Jeho argument: Ve světě agentů je objem kódu tou metrikou, která se počítá. Váš agent by měl generovat tisíce řádků denně. Vaším úkolem je definovat specifikaci výstupu a nechat agenta maximalizovat propustnost. Čtení a porozumění každého řádku je překážkou. Důvěřujte testům. Důvěřujte agentovi. Jděte rychle.

Do středy přednesl Mario Zechner z Anthropic protikeynote: Zpomalte a čtěte ten zatracený kód.

Jeho argument: Rychlost je past. Každý řádek kódu, který váš agent napíše, je závazek. Musíte mu rozumět, uvažovat o něm a být schopni ho udržovat. Týmy, které vyhrají za pět let, jsou ty, které upřednostní jasnost a záměr před rychlostí. Agenti by měli být nástroji pro přemýšlení, ne pro bezmyšlenkovité generování kódu.

Spektrum

Summit se zhruba rozdělil do tří táborů:

Žádná strana se nemýlí. Neshoda je o tom, jak vypadá selhání. Lopopolo optimalizuje pro rychlost iterace. Zechner optimalizuje pro udržitelnost. V roce 2026 se týmy učí, že nemůžete optimalizovat pro obojí.

Problém pohovoru

Jeden konkrétní důsledek: najímání je rozbité. Pokud jste tokenový maximalista, nezáleží vám na tom, zda kandidát umí kódovat – záleží vám na tom, zda umí efektivně promptovat a hodnotit výstup agenta. Pokud dáváte přednost kódu, chcete vidět hluboké technické uvažování.

Takže když kandidát vejde do pohovoru, ani tazatel, ani kandidát neví, proti jakému rámci jsou hodnoceni. Jeden účastník summitu to popsal jako „pohovory v mlze".

Připraveni rozšířit své podnikání?

Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.

Požádat o demo Přihlásit se

Proč IDE umírají, zatímco provoz GitHubu exploduje?

GitHub hlásil 15násobný meziroční nárůst provozu. Cloudflare hlásil podobné špičky. Mezitím tradiční IDE – VS Code, JetBrains, Sublime – zaznamenávají klesající využití mezi AI-nativními týmy.

Zdá se to rozporné, dokud nepochopíte, co se vlastně děje.

IDE bylo lokálním nástrojem pro přemýšlení

IDE bylo navrženo pro jednoho vývojáře, který psal kód lokálně. Mělo zvýraznění syntaxe, automatické doplňování, nástroje pro ladění a strom souborů. Bylo to samostatné prostředí.

Tento model se rozpadá, když je vaším „vývojářem" agent. Agent nepotřebuje zvýraznění syntaxe. Nepotřebuje debugger. Potřebuje:

• Přístup k více souborům současně
• Schopnost spustit kód a vidět výsledky
• Integraci se správou verzí
• Funkce spolupráce (protože agent a člověk pracují společně)

To vše nyní žije v prohlížeči. GitHub Codespaces, VS Code Web a podobné nástroje nahrazují lokální IDE.

Co skutečně roste

Nárůst provozu GitHubu nejsou vývojáři píšící kód v prohlížeči. Jsou to vývojáři, kteří kontrolují, komentují a sluučují kód generovaný agenty. Je to vrstva spolupráce, která exploduje, ne vrstva editace.

Proto Cloudflare také vidí špičky provozu – vývojáři používají cloudovou infrastrukturu ke spouštění agentů a orchestraci workflow. Model „lokální IDE + lokální vývojové prostředí" je nahrazován „cloud-native orchestrací agentů + kontrolou v prohlížeči".

L33T C0d3 je mrtvý

Jedna session měla přesně tento název. Pointa: romantická představa brilantního inženýra, sám u klávesnice, tvořícího elegantní kód – to skončilo. Kód je nyní kolaborativní výstup mezi člověkem a agentem. Dovednosti, na kterých záleží, jsou:

• Prompt engineering (jak specifikovat, co chcete)
• Hodnocení výstupu (je kód agenta dobrý?)
• Architektonické myšlení (v jaké struktuře by měl agent pracovat?)
• Integrace (jak zapadá kód generovaný agentem do existujících systémů?)

Psaní elegantního kódu již není primární dovedností. Je to něco, co dělají agenti. Lidé dělají všechno ostatní.

Co se vlastně děje s MCP – mrtvý nebo vzkvétá?

Toto byla nejmatoucí debata na summitu.

Na jedné straně jednotliví AI inženýři a správci frameworků agentů říkali: „MCP je mrtvý. Nepotřebujeme ho. Naši agenti mohou prostě volat API přímo."

Na druhé straně podnikoví architekti a bezpečnostní týmy říkali: „Přijetí MCP se zrychluje rychleji, než pro něj můžeme budovat nástroje."

Oba výroky jsou pravdivé. Popisují různé populace.

Proč si AI inženýři myslí, že MCP je mrtvý

Pro samostatného vývojáře budujícího jednoduchého agenta přidává MCP tření. Musíte:

• Definovat MCP servery pro své nástroje
• Spravovat režii protokolu
• Zpracovat autentizaci a autorizaci
• Nasadit a udržovat servery

Je snazší prostě dát agentovi přímý přístup k API a nechat ho zjistit zbytek.

Proč podniky rychle přijímají MCP

Pro organizaci provozující agenty v produkci je MCP najednou nezbytný. Zde je proč:

Bezpečnostní izolace. Nechcete, aby agenti měli přímý přístup k vaší databázi, platebnímu systému nebo datům zákazníků. MCP vám umožňuje vytvořit řízené rozhraní, které agenti mohou volat bez odhalení základních systémů.

Auditovatelnost. Každá akce agenta prochází MCP serverem, který ji loguje. Máte úplný záznam o tom, co agent udělal a proč.

Správa přihlašovacích údajů. Místo vkládání API klíčů do promptů agentů nebo proměnných prostředí MCP servery spravují přihlašovací údaje bezpečně.

Omezení rychlosti a vymáhání kvót. Můžete kontrolovat, kolik zdroje může agent spotřebovat.

Podle CData Software 80 % společností z žebříčku Fortune 500 hodnotí nebo implementuje MCP od začátku roku 2026, primárně z těchto důvodů.

Řešení

Konsenzus summitu: MCP není mrtvý. Prostě není relevantní pro 80 % vývoje AI, které je experimentální a sólové. Ale pro 20 %, které je produkční a více-týmové, se MCP stává základem.

Proto se MCP Apps množí. Anthropic, OpenAI a třetí strany budují předpřipravené MCP servery pro běžné nástroje (Salesforce, Slack, Jira, databáze). Podniky mohou tyto přijmout bez budování vlastních serverů.

Přihlaste se k odběru newsletteru

Získejte nejnovější tipy, trendy a nabídky zdarma.

E-mailová adresa

Přihlásit se

Dělá nás AI produktivnějšími, nebo jen více přepracovanými?

Tady se summit ztemnil.

AI měla být silovým multiplikátorem. Trávili byste méně času na rutinních úkolech a více času na strategickém myšlení. Produktivita by raketově stoupla.

Místo toho produktivita raketově stoupla – a stejně tak očekávání pracovní zátěže.

Jevonsův paradox v reálném čase

Jevonsův paradox, původně aplikovaný na spotřebu uhlí, říká: Když se zdroj stane efektivnějším, celková spotřeba roste, protože zdroj se stává levnějším a atraktivnějším.

V termínech AI: Agenti učinili generování kódu levnějším a rychlejším, takže manažeři nyní od každého inženýra očekávají:

• Dodat 10x více výstupu
• Psát komplexní dokumentaci
• Budovat plné testovací sady
• Podporovat internacionalizaci (i18n)
• Zvládat okrajové případy
• Dělat to vše sólově

Zisky produktivity byly spotřebovány nafouknutými očekáváními.

Co inženýři řekli

Jeden inženýr z londýnského startupu: „Dříve jsem psal 500 řádků kódu denně a cítil se produktivně. Nyní píšu 5 000 řádků denně – generovaných agenty – a jsem vyčerpaný, protože musím vše zkontrolovat, otestovat, zdokumentovat a vysvětlit zúčastněným stranám. Pracuji 60 hodin týdně."

Další: „Můj manažer říká: ‚Teď máš agenta, takže bys měl být schopen zvládnout dvakrát tolik projektů.‘ Nejsem produktivnější. Jen jsem zaneprázdněnější."

Výzkumník: „Agenti jsou dobří v generování kódu. Nejsou dobří v rozhodování, jaký kód generovat. Toto rozhodovací břemeno se zcela přesunulo na lidi. Neautomatizujeme tu těžkou část; automatizujeme tu jednoduchou část a nutíme lidi více přemýšlet."

Slepé místo produktivity

California Management Review Kalifornské univerzity v Berkeley publikoval v lednu 2026 výzkum dokumentující tento jev. Klíčová myšlenka: Nasazení AI nesnižuje práci; mění povahu práce.

Stará práce: Psaní kódu. Nová práce: Řízení agentů, hodnocení výstupů, udržování kvality, zvládání rozšiřování rozsahu.

Nová práce je kognitivně těžší, i když je to méně psaní.

Proč Evropa tak váhá ohledně AI inženýrství?

Summit měl silný evropský kontingent a jejich poselství bylo konzistentní: Evropa se nepohybuje tak rychle jako USA v přijímání AI inženýrství.

Regulační převis

Evropský AI Act se stále implementuje. Společnosti si nejsou jisté odpovědností. Pokud AI agent učiní rozhodnutí, které poškodí zákazníka, kdo je odpovědný? Společnost? Dodavatel modelu? Inženýr?

Tato nejistota ochromuje. Mnoho evropských společností čeká, aby vidělo, jak dopadnou první soudní spory, než budou budovat seriózní agentní systémy.

Mezera v dovednostech

Tradiční softwaroví inženýři v Evropě se nestávají AI inženýry stejnou rychlostí jako v USA. Existuje skepse, zda se dovednosti přenášejí. Mnoho evropských inženýrů čeká, aby vidělo, zda je AI inženýrství skutečnou kariérní cestou nebo cyklem humbuku.

Obavy o soukromí

Evropa je také opatrnější ohledně nakládání s daty. Agenti potřebují přístup k datům, aby byli užiteční. Ale evropské společnosti váhají dát agentům přístup k datům zákazníků, i s bezpečnostními opatřeními MCP.

Cesta vpřed

Evropští inženýři na summitu nebyli anti-AI. Byli pro opatrnost. Sentiment: „USA se pohybují rychle a rozbíjejí věci. My se budeme pohybovat pomaleji a pokusíme se toho moc nerozbít. Za pět let uvidíme, kdo měl pravdu."

Jak se role AI inženýrů vlastně mění?

Do konce summitu se objevil vzor: Tradiční role softwarového inženýrství jsou vydlabávány a nahrazovány třemi novými archetypy.

Tři role

Žádná z těchto rolí nezahrnuje psaní kódu v tradičním smyslu. Všechny zahrnují řízení, hodnocení a zdokonalování chování agenta.

Co mizí

Role „juniorního inženýra" jsou zkomprimovány. Už neexistuje jasná cesta od „umím psát jednoduchý kód" k „umím architekturu systémů". Mezikroky jsou automatizovány.

Toto vytváří sráz dovedností: buď jste dobří v promptování a hodnocení (v takovém případě jste cenní), nebo ne (v takovém případě konkurujete agentům).

Co roste

Rostou role vyžadující vkus, úsudek a architektonické myšlení. Stejně tak role vyžadující hlubokou doménovou odbornost (protože agenti potřebují lidi, aby hodnotili, zda řeší správný problém).

Na summitu nebyl konsenzus, zda je to dobré nebo špatné. Někteří to viděli jako osvobození od rutinního kódování. Jiní jako hrozbu pro profesi.

Co se změnilo mezi prosincem 2025 a únorem 2026?

Jedna část summitu byla věnována konkrétnímu bodu zvratu: něco se posunulo v ekosystému AI agentů kolem nového roku.

Samo-zlepšující se software se stal skutečností

OpenClaw a podobné frameworky začaly umožňovat agentům iterativně vylepšovat své vlastní výstupy bez neustálého lidského promptování. Místo „agente, napiš funkci pro výpočet X" se to stalo „agente, napiš funkci pro výpočet X a pokračuj v jejím zlepšování, dokud neprojde všemi testy a nezvládne okrajové případy."

Klíčová myšlenka, kterou vyslovili různí výzkumníci: Přestaňte agenty žádat o triviální rady.

Místo toho, abyste požádali agenta, aby „vylepšil tuto funkci", požádejte ho, aby „udělal tuto funkci neprůstřelnou." Nechte ho rozhodnout, co to znamená. Agent bude:

• Psát testy
• Hledat okrajové případy
• Refaktorovat pro srozumitelnost
• Přidat zpracování chyb
• Dokumentovat logiku

To vše, aniž by byl žádán o každý krok.

To změnilo mentální model z „agent jako nástroj" na „agent jako autonomní přispěvatel". A změnilo to dynamiku pracovní zátěže: místo aby agenti snížili lidskou práci, zvýšili ji (protože lidé nyní museli hodnotit mnohem sofistikovanější výstup agenta).

Rozpory, se kterými žijeme

Summit skončil bez řešení, což působilo upřímně. Zde jsou rozpory, které definují AI inženýrství v dubnu 2026:

Rozpor 1: Agenti jsou dostatečně mocní, aby byli nebezpeční (FOMAT je skutečný), ale ne dostatečně mocní, aby se jim dalo důvěřovat bez dohledu.

Rozpor 2: Rychlost a kvalita jsou zacházeny jako protiklady, ale obojí je nezbytné.

Rozpor 3: MCP je současně mrtvé (pro jednotlivce) a vzkvétá (pro podniky).

Rozpor 4: AI nás učinila produktivnějšími, ale také přepracovanějšími.

Rozpor 5: Všichni staví s agenty, ale nikdo nepřišel na to, jak s nimi stavět dobře.

Rozpor 6: AI inženýrství je skutečná kariérní cesta, ale dovednosti, o kterých jsme si mysleli, že budou důležité (psaní kódu), již nejsou.

Toto nejsou problémy, které se mají řešit. Jsou to napětí, která je třeba řídit. Týmy, které vyhrají v roce 2026, jsou ty, které uznávají tyto rozpory, místo aby předstíraly, že neexistují.

Často kladené otázky

Co si odnášíme

Londýnský summit byl snímkem profese v přechodu. AI inženýrství je skutečné, ale není to to, co jsme si mysleli, že bude. Je to chaotičtější, rozporuplnější a více závislé na lidech, než humbuk naznačoval.

Nejlepší inženýři na summitu nebyli ti s nejsofistikovanějšími agenty. Byli to ti, kteří pochopili, že agenti jsou nástrojem pro přemýšlení, ne náhradou za něj. Byli to ti, kteří vybudovali procesy pro řízení chování agenta, hodnocení výstupu a udržování kvality. Byli to ti, kteří přijali, že zisky produktivity přicházejí s novými druhy práce, ne s méně prací.

Pokud v roce 2026 stavíte AI systémy, lekce summitu jsou jasné:

1. Orchestrace je důležitější než schopnost agenta. Průměrný agent s dobrou orchestrací porazí brilantního agenta bez kontrol.

2. Jasnost je cennější než rychlost. Rychle jít a rozbíjet věci funguje, dokud ne. V měřítku to nefunguje.

3. Podnikové přijetí je skutečné, ale individuální přijetí je stále experimentální. Pokud jste sólový vývojář, můžete jít rychle. Pokud jste tým, potřebujete zábradlí.

4. Dovednosti, na kterých záleží, se změnily. Prompt engineering, hodnocení výstupu a architektonické myšlení jsou nové základní kompetence.

5. Očekávejte, že budete pracovat tvrději, ne snadněji. AI je multiplikátor produktivity, ale zisky jsou spotřebovány vyššími očekáváními. Plánujte podle toho.

Summit neodpověděl na otázku „Jak vypadá AI inženýrství?" Ukázal nám odpověď: vypadá jako my, pokoušející se to vymyslet v reálném čase.

{{ cta-dark-panel heading=“Přestaňte ručně orchestrovat agenty” description=“Workflow builder FlowHunt vám umožňuje definovat chování agenta, nastavit zábradlí a automatizovat vícekrokové AI úlohy. Žádný další FOMAT. Žádné další hádání, co vaši agenti dělají.” ctaPrimaryText=“Vyzkoušet FlowHunt zdarma” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Rezervovat demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}