Co umíme dokázat: pět projektů a pět principů
Místo výčtu CV pět reálných projektů, z každého jeden princip, jak přemýšlíme o práci. Enterprise výkon, odolná integrace pod zátěží, kompletní produkt od nuly, AI uvnitř reálných systémů a AI uvnitř fintech systému, který obchoduje s vlastním stavem.
Když mě někdo osloví na novou zakázku, nezačínám tím, čím se chlubíme. Začínám tím, co jsme reálně postavili a co z toho plyne pro něj. Tady je pět projektů. Každý ukazuje jinou schopnost a z každého plyne jeden princip, podle kterého pracuju dál.
Enterprise výkon: bottleneck není tam, kde se na něj sahá nejdřív
V ČSOB jsem dělal na generování smluv. Trvalo to dvě hodiny. Po mé práci to trvalo tři minuty. To je čtyřicetinásobné zrychlení a nevzniklo přepsáním do modernějšího frameworku ani přidáním serverů.
Podobný příběh je Atlas Copco. SAP datová pipeline napsaná jako jeden SQL skript o patnácti tisících řádcích. Po refaktoru tři tisíce řádků, tedy o osmdesát procent míň, a převod na event-driven na Azure Functions. Runtime se z několika dní vrátil na zhruba čtyři hodiny z Evropy a šest z Asie. Globálně nasazené SAP downloadery do datových skladů, které předtím doháněly samy sebe.
Princip je v obou případech stejný. Nejdřív najít skutečný bottleneck, ne ten první, který je vidět. Většinou to nejsou „pomalé servery", ale datové struktury, chybějící caching, SQL napsané proti tomu, jak databáze pracuje, nebo synchronní krok, který má být událostí. Když se trefíte do správného místa, číslo se nezlepší o procenta, ale o řády. Když ne, koupíte si větší stroj a problém máte dál.
Odolná integrace pod zátěží: stát neodpustí fire-and-forget
TrafinOil potřeboval posílat faktury do KSeF, tedy do polského státního systému e-fakturace. Takový systém je asynchronní, rate-limited, občas nedostupný a má vlastní stav. To není endpoint, kterému pošlete request a věříte, že to prošlo. To je dlouhoběžící stavový workflow.
Postavil jsem ho jako durable pipeline. Idempotentní submit, takže opakování nezduplikuje doklad. Retry s exponenciálním backoffem, když je systém přetížený. Rate limiting, aby nás stát neodřízl. Reconciliation, která periodicky kontroluje, že realita sedí. UPO potvrzení jako důkaz doručení a audit log u každého přechodu stavu. Ověřeno v produkci na víc než čtyřiceti tisících dokumentech, sto procent doručeno. K tomu migrace dat na Dynamics 365 Business Central.
Že to takhle musí vypadat, mám potvrzené dost drsně. Předchozí pipeline byla fire-and-forget a tiše ztrácela doklady. Forenzně jsem dohledal a obnovil patnáct tisíc sto čtyřicet jedna chybějících dokumentů, o kterých nikdo nevěděl, že chybí. To je ten rozdíl. Fire-and-forget vypadá v demu úplně stejně jako durable workflow. Liší se až ve chvíli, kdy stát neodpoví, a v tu chvíli buď máte audit log a reconciliation, nebo hledáte patnáct tisíc faktur zpětně.
Mimochodem, výkon a odolnost nejdou proti sobě. Noční dataloader na stejném projektu jsem zkrátil z dvaceti hodin na třicet minut. Robustnost neznamená pomalost.
Princip: u externího systému, který je asynchronní, rate-limited a má vlastní stav, rozpočítávám plnou mašinérii hned, ne incident po incidentu. Durable stav, idempotence, reconciliation, observabilita každého přechodu. Ne proto, že je to elegantní, ale protože levnější varianta se zaplatí později a draž.
Kompletní produkt od nuly: čtyři měsíce, ne čtyři roky
Carivio, neboli TaxiLight, je kompletní taxi dispatching platforma. Tři platformy, tedy backend, web a mobil. Jako SolutionBox jsme to dodali za čtyři měsíce a běží to. Zhruba padesát živých vozů jezdí v provozu, dá se to vidět na transportprague.com.
Pár čísel, aby bylo jasné, co „kompletní" znamená. Backend kolem sto dvaceti osmi tisíc řádků kódu. Čtyřicet osm feature modulů. Sto sedm EF migrací. Šest rolí. Čtyři SignalR hub endpointy pro real-time. Aukční model jízd, kde se nabídka rozesílá řidičům přes SignalR, geoprostorové dotazy na GPS, background-location na mobilu, který musí přežít reálné telefony Samsung, OnePlus, Huawei a jejich agresivní zabíjení aplikací na pozadí. K tomu offline queue a recovery, když systém appku zabije.
Princip tady není „umíme rychle". Princip je, že kompletní produkt od nuly má spoustu věcí, které v demu nevidíte a které rozhodují, jestli to v provozu drží. Background location na reálných OEM telefonech, recovery po killnutí aplikace, real-time, který nezahltí síť duplicitními eventy. Tohle se nedá dodělat „potom". Buď to do návrhu patří od začátku, nebo se appka chová jako rozbitá a nikdo neví proč.
AI uvnitř reálných systémů: nejdřív základ, pak model
A teď k AI, protože to je dnes otázka číslo jedna. Rovnou jednu věc narovinu: nejsem ML researcher. Nedělám fine-tuning ani MLOps a netrénuju modely. Dělám aplikační a integrační AI uvnitř produkčních systémů. To je jiná disciplína a je dobré to říct předem.
Pro město Zlín jsme s Continerem postavili občanský RAG chatbot s přesností kolem devadesáti procent na živých datech. Pod ním je multi-agentní engine s hybridním retrievalem, který kombinuje vyhledávání v dokumentech s dotazy nad strukturovanými municipálními daty a sám se opraví, když dotaz selže. Vyhrálo to regionální hackathon, Innovation Day.
Tahle logika se táhne i ostatními věcmi, co děláme. AI agent na extrakci dat z faktur, který čte doklady a zapisuje je do existujícího ERP, ale s human-in-the-loop a audit logem, ne jako černá skříňka. Vlastní produkční AI code-review služba, která komentuje pull requesty s deduplikací a kontextem branche. Automatizace e-mailů a veřejných zakázek, kde entity extraction přes embeddings a RAG hledá relevantní příležitosti. Z Continera pak Artima.ai, all-in-one nástroj na social-media marketing, který generuje fotky a videa AI a plánuje publikaci, nebo HDTS, computer-vision systém, který z videa rozpozná úhly bruslení a koučuje hokejistu v reálném čase.
Princip: nejdřív stavím čistou produkce-ready základnu a teprve na ni dávám LLM nebo RAG. Většina týmů to dělá opačně, vypustí PoC bez základů a rok ho pak dohání. Já jdu od základů nahoru, protože LLM volání bez cost-trackingu, guardrailů a observability je v enterprise systému závazek, ne feature. Audit tokenů, budget gate, guardraily proti prompt-injection a halucinacím, log u každého volání. To je to, co odlišuje AI demo od AI v provozu.
AI uvnitř fintech systému: model, který obchoduje s vlastním stavem
Pátý projekt jde o krok dál. Robootec, který stavím s Continerem jako architekt, je AI algoritmická obchodní platforma. Není to chatbot, kterému něco napíšete a on vám odpoví. Je to systém, který bere data, vyhodnocuje je a obchoduje, takže každé rozhodnutí má důsledek a vlastní stav, který musí někde žít.
Vstupem nejsou jen ceny. Kombinuje AI news-sentiment, tedy čtení zpráv modelem, makro data a technické indikátory, a z toho generuje signály. Stack je .NET 10 na backendu a Next.js na frontendu, CQRS uvnitř, multi-provider LLM orchestrace, real-time přes SignalR a SSE a observabilita přes OpenTelemetry.
Pár věcí stojí za to vypíchnout, protože je to ta nudnější, ale rozhodující část AI v produkci. Multi-provider LLM orchestrace s prompt cachingem, abych nebyl závislý na jednom poskytovateli. Lokální inference sentimentu, takže se počítá u nás a ne každé volání jde ven. Budget gate před každým requestem, který hlídá, kolik tokenů a peněz jde do modelu, dřív než se odešle. A bezstavový signal engine, kde přidání nové strategie nerozbije ty stávající.
Kde to teď je, řeknu narovinu. PoC běží živě. Autonomní AI, které říkáme „vibe trading", tedy aby systém obchodoval sám, je ve vývoji, ne hotové. Stavím to ze stejného důvodu jako všechno ostatní: u systému, který sahá na peníze, je cost-tracking, durable stav a observabilita podmínka, ne nadstavba.
Princip: AI dává smysl, když je zapojená do reálného systému s daty a stavem, ne jako izolovaný chatbot vedle. Teprve když model čte živá data, něco s nimi udělá a to rozhodnutí má následek, který se musí dohledat a zaplatit, ukáže se, jestli kolem něj máte postavený systém, nebo jen demo. Proto u Robootcu řeším cost gate a stavový engine dřív než autonomní obchodování.
A stejnou logiku máme i interně. ModularPlatform je náš modulární základ pro read-heavy aplikace, pořád ve vývoji. .NET modulární monolit s architektonickými hranicemi vynucenými mechanicky přes ArchUnitNET, durable messaging přes Wolverine s outboxem, inboxem a sagami, Postgres row-level security pro izolaci tenantů, crypto-shred mazání kvůli GDPR, Stripe na platby a Next.js 15 s React 19 na frontendu. Existuje proto, abychom nezačínali každý produkt od nuly a měli osvědčený základ místo opakovaného stavění téže infrastruktury. Zdrojový kód zůstává klientovi, žádný vendor lock-in.
Jak takhle přemýšlíme o nové zakázce
Těchto pět projektů má společný vzorec. Nejdřív se ptám, kde je skutečný problém, ne kde to nejvíc bolí na první pohled. Pak rozhodnu, kolik odolnosti zakázka opravdu potřebuje, protože durable workflow a fire-and-forget se liší až pod zátěží, ne v demu. Pak stavím základ tak, aby v provozu držel, včetně věcí, které v demu nevidíte. A teprve nakonec, když dává smysl, přidávám AI, s cost-trackingem a observabilitou od začátku, ať už jde o chatbota nad městskými daty, nebo o model, který obchoduje s vlastním stavem.
Takže když přijde nová zakázka, neslibuju framework ani buzzword. Ptám se, co se reálně počítá, co se musí ošetřit, než to půjde do provozu, a kde je ta jedna změna, která posune číslo o řád místo o procenta. To je práce, za kterou se nestydím.