Anton Onufriienko, generální ředitel společnosti Devart – Interview Series

Anton Onufriienko, generální ředitel společnosti Devart, je technologický manažer a operátor s hlubokými zkušenostmi se škálováním softwarových firem, řízením růstu výnosů a vedením velkých mezioborových týmů v oblasti SaaS, podnikového softwaru a finančních služeb. Během své kariéry se posunul od budování prodejních organizací a spouštění startupů až po dohled nad plnou P&L operací pro hlavní obchodní jednotky, včetně největší divize Devartu s více než 130 zaměstnanci. Předtím, než se stal generálním ředitelem, působil jako Chief Revenue Officer a Head of Sales ve společnosti Devart, kde vedl go-to-market strategii, transformaci cen a mezinárodní růstové iniciativy. Je také CEO společnosti TMetric, platformy pro sledování času a ziskovosti, která pomáhá službám založeným na službách získat provozní přehled.

Devart je softwarová společnost specializující se na vývoj databází, datové konektivity, integraci a produktivity pro vývojáře, DBA, analytiky a podnikové týmy. Založena v roce 1997, společnost je nejznámější svými nástroji pro správu databází dbForge, které podporují hlavní systémy databází, včetně SQL Server, MySQL, Oracle a PostgreSQL. Devart také vyvíjí datové konektivní řešení, jako jsou ODBC, ADO.NET, Python a Delphi konektory, spolu se Skyvia, cloudovou platformou pro integraci dat bez kódu pro ETL, automatizaci, zálohování a orchestraci pracovních postupů. Společnost slouží více než 500 000 uživatelům po celém světě, včetně významného podílu organizací Fortune 100, a stále více se zaměřuje na integraci funkcí umělé inteligence do svých produktů prostřednictvím nástrojů, jako je dbForge AI Assistant, který pomáhá vývojářům generovat, optimalizovat, odstraňovat chyby a vysvětlovat dotazy SQL pomocí přirozeného jazyka.

Přestoupil jste z budování a vedení prodejních týmů na řízení plné P&L operací a nyní řídíte největší obchodní jednotku Devartu. Jak vám tato cesta změnila přístup k integraci umělé inteligence do produktové strategie a rozhodování ve velkém měřítku?

Prodej mě naučil měřit ROI na všechno. Přechod do role CRO mě donutil aplikovat tuto disciplínu napříč funkcemi. Řízení obchodní jednotky mě donutilo aplikovat ji i na samotnou umělou inteligenci.

Mám praktický pohled na umělou inteligenci. Není to, že bych byl skeptický: tři ze čtyř našich produktových sázek pro rok 2026 jsou nativní pro umělou inteligenci. Ale věřím, že hype brání skutečným a trvalým výsledkům.

Existuje meme, který shrnuje, kde se často průmysl mýlí. Společnosti vyměňují předplatné SaaS za 400 dolarů za domácí nástroje, které stojí 1 000 dolarů měsíčně za poplatky za API a vyžadují neustálé opravy. To není skutečná změna, je to jen drahá show.

Poučení, které jsem získal z prodeje, je jednoduché: každá iniciativa musí zaplatit své náklady, nebo zemře. Řídím naše nasazení umělé inteligence stejným způsobem, jako jsem dříve řídil prodejní území. Explicitní hypotéza ROI pro každý pracovní postup, třívlnové nasazení a zdokumentovaný dopad před škálováním.

Náš Severní hvězdný metrický ukazatel je Výnos na zaměstnance, a náš cíl je více než zdvojnásobit ho do konce roku 2028. Nelze uzavřít tuto mezeru najímáním. Je třeba změnit, jak vypadá práce, a umělá inteligence je jediným realistickým mechanismem pro toto měřítko.

Můj filtr pro každou iniciativu umělé inteligence, interní nebo produktové, je stejný: co je měřená hodnota, kdo za to platí a jak víme, že to funguje? Cokoliv, co nesplňuje tyto tři otázky, nepatří do produkce. Náklady na chybu se rychle sčítají, a většina společností to zjistí drahým způsobem.

Devart vybudoval silnou pověst kolem nástrojů pro databáze a produktivity vývojářů. Jak začleňujete umělou inteligenci do těchto produktů tak, aby přinášela skutečnou hodnotu a ne pouze povrchovou automatizaci?

Naši uživatelé jsou tvrdí techničtí specialisté: DBA, seniorní inženýři, data architekti. Detekují povrchovou automatizaci během sekund a nesnesou, když se jim prodávají marketingové hračky vydávané za inovace. Před dvěma lety, kdy hype umělé inteligence dosáhl vrcholu a konkurenti se snažili přidat chatovací panely na každý prvek uživatelského rozhraní, byla pokušení následovat skutečná. Viděl jsem tento vzorec dříve, v mobilních zařízeních, cloudu, low-code, a odmítal jsem ho opakovat.

Disciplína byla přímočará: zákaznická hodnota na prvním místě. Budování funkcí umělé inteligence, které nikdo nevyžadoval, které nedodávají skutečnou hodnotu, je nejhorším možným využitím omezených inženýrských zdrojů. To je zejména pravda, když vaše publikum může rozpoznat rozdíl okamžitě.

Co se změnilo v roce 2026, je, že umělá inteligence přešla z hype do skutečné technické revoluce. Mezera mezi tím, co tyto systémy mohly dělat v roce 2023 a tím, co mohou dělat dnes, není inkrementální. Je to úplně jiná kategorie schopností. Můžeme nyní řešit problémy, které byly dříve skutečně nevyřešitelné: zabezpečený přístup k podnikovým datům pro agenty umělé inteligence, kontextová inteligence databáze uvnitř vývojářova IDE a autonomní obchodní analýzy, které nevyžadují dedikovaného analytika.

Toto jsou nové produktové řady, které existují, protože umělá inteligence učinila základní problém řešitelným. To je laťka, kterou si sami nastavujeme: skutečný produkt umělé inteligence je ten, kde odstranění vrstvy umělé inteligence rozbití produktu. Průmysl strávil dva roky tím, že nazýval chatovací panely “produkty umělé inteligence.” Ty jsou funkce, ne produkty.

Vzali jsme si více času, protože jsme chtěli udělat to správně. Příští dvanáct měsíců ukáže, zda tato disciplína zaplatila.

Umělá inteligence stále více píše, optimalizuje a ladí kód. Jak se tato změna promítne do role vývojářů, kteří pracují s databázemi, v příštích několika letech?

Hodnota znalosti syntaxe SQL se rychle znehodnocuje. Pokud může umělá inteligence vygenerovat komplexní vícesloupcový JOIN za sekundy a identifikovat chybějící indexy z logů za minutu, hodnota inženýra již nepřichází z psaní SQL. Ta část práce se stává komoditou.

Ale zde je kritický nuance, který evangelisté totální automatizace vždy přeskočí. Chyba umělé inteligence na frontendu je nesprávně umístěný tlačítko, které můžete obnovit. Chyba umělé inteligence v databázi je vymazání produkčního prostředí, únik PII nebo transakční odstavení celého podniku.

Databáze uchovávají stav. Neshromažďují halucinace.

Tato asymetrie úplně mění roli. V příštích dvou až třech letech se vývojáři databází a DBA budou vyvíjet z kodérů na architekty a auditory. Jejich primární práce se přesune na tři věci:

• Navrhování spolehlivých architektur, které umělá inteligence nemůže sama rozumět, protože jí chybí obchodní kontext.
• Nastavení tvrdých bezpečnostních pravidel a politik pro agenty umělé inteligence, které se dotýkají produkčních systémů.
• Přehled a audit kódu, který stroje generují, předtím, než se dostane do databáze.

Mentální model, ke kterému se neustále vracím, je: inženýři budou řídit armády asistentů umělé inteligence. Nástroje, jako je dbForge, se musí vyvinout z tradičních IDE do center příkazů a auditu. Práce se stává méně psaním SQL ručně a více kontrolou toho, co generuje umělá inteligence, validací a vynucováním hranic, které umělá inteligence nemůže bezpečně překročit.

Profesionální příležitost zde je významná. Vývojáři, kteří se vyvinou na architekty a dohled, zmnohonásobí svou tržní hodnotu. Stávají se nezbytnou vrstvou mezi produktivitou umělé inteligence a bezpečností produkce. Premium na odbornosti databází nezmizí; posune se směrem k designu, správě a úsudku, což je přesně tam, kde umělá inteligence nemůže sama fungovat.

Jaké jsou největší omezení současných nástrojů umělé inteligence v správě databází a kde očekáváte nejvýznamnější průlomy?

Současná umělá inteligence je stále uvězněna v povrchové automatizaci. Generování základního dotazu SELECT nebo kódu boilerplate již není působivé. Větším problémem je, že většina systémů umělé inteligence se stále chová jako slepí pisatelé, spíše než jako architekti systémů. Mohou generovat syntaxi, ale skutečně nerozumí prostředí, ve kterém operují. Skutečný průlom nastane, když umělá inteligence začne rozumět kontextu, závislostem, stavu a obchodnímu logiku společně.

Prvním problémem je problém kontextu. Velké jazykové modely mohou vidět schéma, DDL a názvy sloupců, ale skutečně nerozumí plánům provádění, fragmentaci indexů, vzorcům distribuce dat nebo skutečnému obchodnímu logiku za daty. Bez tohoto hlubšího porozumění se mnoho optimalizačních rad stává statistickým odhadem vydávaným za odbornost.

Druhým problémem je problém halucinace, a podniky mají téměř nulovou toleranci pro něj na úrovni databáze. Halucinovaný JOIN může zpomalit produkční systémy. Nesprávný UPDATE může vymazat kritické záznamy. Na této úrovni se i malé chyby stávají velmi nákladnými velmi rychle.

Třetím problémem je bezpečnost a správa. Žádná vážná podniková společnost nebude vkládat produkční schéma nebo PII do veřejného nástroje umělé inteligence bez silných záruk kolem izolace dat a kontroly. Dokud dodavatelé nevyřeší tento problém řádně, adopce umělé inteligence v regulovaných odvětvích zůstane omezená.

Skutečné průlomy nastanou, když umělá inteligence začne fungovat více jako architekt nebo analytik na pozadí. Kontinuální analýza pracovních postupů, identifikace úzkých míst, návrh indexů, identifikace rizikových dotazů a odchycení problémů předtím, než systémy selžou.

Jedním z částí je sémantická vrstva: přechod od surových názvů tabulek k skutečnému obchodnímu významu. Nejen “tabulka_uživatelé”, ale pochopení konceptů, jako jsou zákaznické kohorty, riziko odchodu, nebo trendy LTV v Q3.

Další posun je v tom, že umělá inteligence bude fungovat více jako seniorní DBA na pozadí. Kontinuální analýza pracovních postupů, identifikace úzkých míst, návrh indexů, identifikace rizikových dotazů a odchycení problémů předtím, než systémy selžou.

Pak je zde strojově-strojová operace, kde autonomní agenti monitorují zátěž databáze, testují strategie optimalizace v izolovaných prostředích a nasazují zlepšení pod lidským dohledem.

Tyto jsou vývojové směry, které budou formovat příštích pět let nástrojů pro databáze.

Jak se umělá inteligence promítne do cenových modelů, balení produktů a zákaznické akvizice ve softwarových společnostech?

Tradiční go-to-market playbook je rozbitý. Vidíme to ve svých číslech a napříč celou kategorií vývojářských nástrojů.

Smrt klasické akvizice. Navzdory významnému zlepšení v search rankingu našich produktů v roce 2026, jsme zasáhli realitu zero-click. Hledání umělé inteligence dodává odpovědi přímo na stránce s výsledky a zbavuje webové stránky provozu. Silné rankingy již neznamenají konverze do leadů tak, jako tomu bylo před dvěma lety.

Před pěti lety stačila silná obsahová strategie k pohánění růstu. Dnes je to základní předpoklad. LLMs vážou sílu značky, pozitivní zmínky a hustotu komunity, když formují odpovědi. Pokud vaše značka není viditelná a důvěryhodná, systémy umělé inteligence přestanou vás konzistentně zobrazovat. Neztrácíte pouze provoz. Zmizíte z nákupního procesu úplně. Situaci zhoršuje, že celý trh panikaří do placené reklamy, což pohání CPC na absurdní úrovně a tiše ničí ekonomiku většiny společností SaaS.

Tento posun zasahuje tradiční společnosti vývojářských nástrojů obzvláště tvrdě. Kanály SEO-driven akvizice, které financovaly jednu generaci B2B SaaS, ztrácejí efektivitu rychle. Každý, kdo na nich stále spoléhá jako na primární růstový páku, by měl aktivně budovat alternativy právě teď: distribuci ekosystému, komunity a partnerství.

Evolve cen: od sedadel k PLG 3.0. Vstupujeme do další fáze PLG. Cenová strategie na základě sedadel začíná selhávat, když jeden agent umělé inteligence může udělat práci několika zaměstnanců. V takovém prostředí přestává mít smysl účtovat podle počtu hlav. Společnosti, které své produkty neprebalí podle hodnoty místo počtu hlav, ztratí MRR v příštích 24 měsících.

Další krok je PLG 3.0: okamžik, kdy autonomní agent umělé inteligence, ne člověk, vyhodnocuje, testuje a nakupuje podnikový software. Hromadná adopce tohoto vzoru je ještě několik let pryč, ale architektura produktů a cen pro strojového kupce je úkolem pro rok 2026, ne 2028.

Co jsou klíčové faktory, které určují, zda iniciativy umělé inteligence skutečně uspějí?

Většina funkcí umělé inteligence selže, ještě předtím, než jsou postaveny. Selžou v místnosti, kde někdo řekne “potřebujeme umělou inteligenci v tomto produktu,” ne proto, že uživatelé o to požádali, ale protože představenstvo chce příběh umělé inteligence, nebo marketing si myslí, že to přiláká novou publikum. To je původní hřích většiny iniciativ umělé inteligence, a tvaruje vše, co následuje.

Stále vidím stejné chyby opakované ve společnostech, které zápasí se změnou umělé inteligence z experimentů na skutečný produkční dopad.

První chyba je budování funkcí umělé inteligence, které nikdo nevyžadoval. Jakmile je funkce umělé inteligence nařízena bez skutečné potřeby uživatele, tým pracuje zpětně od technologie, aby vynalezl použití. Výsledek je předvídatelný: chatovací panel připevněný k existujícímu uživatelskému rozhraní, autocomplete, který překáží, nebo tlačítko “shrnutí”, které produkuje horší výstup, než by uživatel mohl sám napsat. Tyto funkce jsou nasazeny, dostanou tiskovou zprávu a tiše podperformují každou předpověď adopce. Hlubší škoda je, že spotřebovávají inženýrskou kapacitu, která by měla jít do funkcí, které uživatelé skutečně požadovali.

Druhým problémem je, že týmy výrazně podceňují rozdíl mezi čistými demo daty a skutečnými produkčními daty. Dema umělé inteligence běží na čistých, kurátorovaných příkladech. Produkce běží na skutečném nepořádku zákaznických dat: duplicity, chybějící pole, deset různých způsobů, jak napsat stejné jméno produktu, patnáct let legacy edge případů. Model, který dosahuje působivých výsledků v hodnocení, může se výrazně zhoršit na živých datech, a většina týmů toto neobjeví, dokud uživatelé nestěžují. Náklad na toto zjištění v produkčním důvěry je zřídka obnovitelný.

Jiným častým selháním je uživatelský výzkum. Standardní produktové rozhovory nefungují pro funkce umělé inteligence. Uživatelé nemohou artikulovat, co chtějí od umělé inteligence, protože nevědí, co je možné. Zeptání se “použili byste umělou inteligenci, aby udělala X?” dostane zdvořilé ano odpovědi, které nemají předpovědní hodnotu pro adopci. Účinný výzkum produktů umělé inteligence vyžaduje ukázání prototypů, pozorování skutečného použití a měření, zda uživatelé se vrátí, když novinka vyprchá. Málo produktových týmů přestavilo svou výzkumnou praxi pro tento účel. Stále běží playbooky z roku 2019 na problémy z roku 2026.

A konečně, mnoho společností měří aktivitu umělé inteligence místo skutečného dopadu. “Dvě stě lidí použilo funkci umělé inteligence tento týden” je metrika adopce, ne metrika dopadu. Skutečný dopad je cyklus času snížen, kvalita zlepšena, výnosy vygenerovány nebo náklady odstraněny. Pokud nemůžete nakreslit přímou linku od funkce umělé inteligence k číslu na P&L, nemáte produkční dopad. Máte pouze drahou aktivitu.

Existuje pátý faktor, který se stává stále kritičtějším a který většina produktových týmů úplně přehlíží.

Shoda a cesta bez umělé inteligence. Významný podíl podnikových uživatelů ve finančních, zdravotnických, vládních, obranných a právních odvětvích operuje pod zásadami, které zakazují nebo omezují funkce umělé inteligence ve softwaru dodavatelů. Pokud váš produkt pevně spojí umělou inteligenci do jádra zkušenosti bez možnosti ji zakázat nebo obejít, nezískáte novou publikum přidáním umělé inteligence. Ztratíte segment své stávající.

Toto je přesně problém, který řešíme s funkcí Connectivity. Týmy pro shodu v regulovaných odvětvích si nestěžují na umělou inteligenci samotnou. Stěžují si na odchod dat z jejich perimetru. Řešením není odstranit umělou inteligenci; je to dát těmto organizacím architekturu umělé inteligence, která se přizpůsobí jejich omezením. To je proč Connectivity dodává jako on-premise: schopnost umělé inteligence zůstává, data nikdy neopouštějí infrastrukturu zákazníka, a nákup prochází kontrolou v prvním kole místo třetího.

Týmy, které to udělají správně, architekturu pro shodu od samého začátku. Týmy, které to udělají špatně, objeví problém během procesu nákupu, když je již příliš pozdě.

Devart operuje napříč několika databázovými ekosystémy. Jak může umělá inteligence pomoci zjednodušit rostoucí složitost správy dat napříč různými platformami?

Bolest je skutečná. Typická společnost Fortune 500 běží osm až dvanáct různých databázových motorů současně: legacy Oracle pro finance, PostgreSQL pro nové služby, SQL Server pro operace, Snowflake nebo BigQuery pro analýzy, a stále více vektorový sklad pro embeddings. Každý z nich má svůj vlastní dialekt, své vlastní nástroje, svou vlastní správní režii. Vývojář, který vstupuje do tohoto prostředí, může strávit tři měsíce pouze učením, kde data žijí a kdo je povoleno je dotknout.

Umělá inteligence sama o sobě tuto složitost nevyřeší. Zesiluje jakýkoli kontext, který dostane. Osm nespojených databází s žádnou sjednocenou metadata produkuje osm nespojených sad povrchních návrhů. To je přesně selhání, které vidíme v meisten podnikových nasazeních umělé inteligence na stacku.

Příležitost je vrstva kontextu, která sedí mezi agenty umělé inteligence a podkladovými databázemi. Ta, která mluví se všemi, normalizuje metadata, vynucuje sjednocené politiky správy a expozuje čistý MCP rozhraní, aby jakýkoli agent umělé inteligence, ať už Claude, GPT, nebo interní model, pracoval napříč celým majetkem s konzistentními pravidly.

To je architektura, kterou stavíme směrem k s funkcí AI Connectivity: on-premise MCP server s multi-databázovou podporou, sémantická vrstva, která zachytí obchodní definice jednou místo toho, aby každému agentovi umělé inteligence musela znovu učit, role-based přístupová kontrola na úrovni SQL operace a plné auditní protokoly.

Zjednodušení není zdarma. Někdo stále musí modelovat sémantickou vrstvu a nastavit politiku. Ale tato práce se děje jednou, ne opakovaně pro každého agenta umělé inteligence, kterého přidáte.

Jak se umělá inteligence promítne do interní spolupráce a rozhodování mezi produktem, inženýrstvím, marketingem a prodejem?

Most cross-funkční tření bylo opravdu jen lidé čekající na informace z jiných týmů. Umělá inteligence kolabuje toto tření rychleji, než by jakákoliv manažerská struktura mohla.

Posuny jsou praktické a okamžité.

V produktech a inženýrství: produktový manažer položí databázovou otázku v obchodních termínech, “co je variace LTV napříč našimi třemi nejvyššími cenovými pásmy?”, a dostane okamžitě použitelnou odpověď, místo toho, aby musel podat Jira ticket do analytiky a čekat tři dny.

V marketingu a datech: kohortní analýza se děje inline, ne prostřednictvím žádanky. Marketingový manažer položí otázku, dostane čísla a postaví kampaň, vše během jednoho rána.

V prodejích a inženýrství: technické odpovědi pro potenciální zákazníky již nevyžadují plánování hovoru se seniorním inženýrem. Sales rep dostane věrohodnou technickou odpověď v reálném čase, a prodejní cyklus se zkracuje.

Rozhodnutí se pohybují do konverzace místo do follow-up. “Musím se vrátit k vám s tím číslem” vzorec umírá. Schůzky se zkracují, protože umělá inteligence zpracovává pre-reads a souhrny, které dříve spotřebovávaly první polovinu každé schůzky.

Tento kolaps tření nutí hlubší manažerský posun, a je to ten, který většina vedení podceňuje.

Každá společnost prohlašuje, že je zaměřena na výsledky. Podívejte se pod kapotu a většina z nich stále běží na proxy metrikách: story points, řádky kódu, uzavřené tikety, hodiny odpracované. Používáme aktivitu jako proxy pro hodnotu, protože skutečná hodnota byla těžko měřitelná. Umělá inteligence láme tuto proxy navždy. Když agent může napsat 10 000 řádků kódu nebo uzavřít 500 support ticketů za minutu, měření aktivity se stává nebezpečně zavádějícím.

Přecházíme explicitně na True Result-Oriented Management, kde výkon je měřen striktně podle výsledku a úsudku. Kruté v praxi, protože většina systémů výkonu není postavena pro to. Lidé, kteří dříve skrývali za vysokou aktivitou, se stanou okamžitě viditelnými, a vedení musí být ochotno jednat na základě této viditelnosti.

Strukturální důsledky jsou ploché organizační schéma. Koordinační a informační vrstvy se komprimují. Organizace, které se přizpůsobí nejrychleji, budou operovat se strukturálně menšími lidmi na vyšší úrovni.

S rostoucí popularitou nástrojů umělé inteligence a bezkódových nástrojů se blížíme budoucnosti, kdy se správa databází stane přístupnou pro netechnické uživatele?

Existuje nebezpečné zmatení v průmyslu právě teď. Lidé zacházejí se side-project databází a podnikovou legacy databází, jako by byly stejné. Není tomu tak.

Pro malé greenfield projekty je demokratizace již tady. Osobně jsem postavil malé aplikace od začátku bez hlubokých znalostí správy databází. Pokud celý váš schéma fits do kontextového okna LLM, umělá inteligence funguje jako kouzlo. Citizen vývojáři budující interní nástroje na malé škále budou skutečnou a rostoucí kategorií.

Podniková realita je úplně jiná. Velké legacy databáze čelí stejnému problému, jako velké monolitické kódové základny: kontextová zeď. Nemůžete fit patnáct let nedokumentované evoluce schématu, mezi-databázových závislostí a vlastních trigger logiky do promptu. Když umělá inteligence ztratí kontext na velké databázi, halucinace se nezhoršují elegantně. Množí se exponenciálně.

Riziko, které se málo diskutuje, je falešná důvěra ve škále. Přirozené jazykové rozhraní jsou jedinečně dobré v produkci přesvědčivých, ale jemně nesprávných odpovědí. Pokud SQL dotaz má syntaktickou chybu, dostanete chybovou zprávu. Pokud přirozené jazykové rozhraní špatně interpretuje “aktivní zákazníky”, protože vaše data má šest různých definic aktivity, dostanete číslo. Číslo vypadá v pořádku. Může být odlišné o 30%. Uživatel nemá způsob, jak to vědět.

Takže ne, správa podnikových databází se nestane hřištěm pro netechnické uživatele.

Citizen DBA je mýtus ve škále.

Budoucnost patří expertním architektům dat, kteří používají profesionální nástroje k mostění kontextové mezery a budování infrastruktury, která umožňuje umělé inteligenci fungovat bezpečně nahoře.

Strukturální fix je sémantická vrstva: kontrolovaná slovní zásoba, kde obchodní definice jsou fixovány jednou a opakovaně používány napříč každým interakcí umělé inteligence. To je jádro architektury, kterou stavíme do Insightis. Bez ní se přístupnost stává zátěží.

Co vypadá “nativní” vývojářský nástroj umělé inteligence a jak by týmy měly začít připravovat na tuto změnu dnes?

Nativní nástroj umělé inteligence není chatbot připevněný k IDE. Most toho, co se prodává jako “nativní pro umělou inteligenci” dnes, je chatovací rozhraní plus model autocomplete. To je základní předpoklad, ne destinace.

Pro mě je skutečně nativní nástroj umělé inteligence ten, který potřebuje tři věci.

Prvním je hluboký kontext. Musí rozumět vašemu kódu, vaší infrastruktuře, vašim historickým rozhodnutím a vašemu datovému prostředí kontinuálně, ne jen prostřednictvím promptů vložených do chatovacího okna. Most současné nástroje selže v tomto testu. Jejich kontext resetuje se каждým relaunchem, a uživatel platí cenu za jeho opětovné sestavení neustále.

Druhým je, že nástroje samy potřebují komunikovat mezi sebou řádně. Vaše IDE musí mluvit s vaší databází, databáze s vaší stackem pozorovatelnosti, a vaší CI/CD s vaším agentem umělé inteligence, atd. Model Context Protocol se stává standardní vrstvou zde, s 97 miliony stažení SDK měsíčně v Q1 2026, oproti 100 000 na konci roku 2024. To je 970násobný nárůst za patnáct měsíců a nejprudší adopční křivka, kterou jsem viděl v infrastruktuře vývojářů.

Třetím je, že produkční úroveň umělé inteligence vyžaduje vážné bezpečnostní zábrany. Náhled blast radiusu před destruktivními operacemi. Analýza závislostí. Automatizované plány rollbacku. Auditní protokoly výchozím nastavením. Umělá inteligence bez těchto je v pořádku pro prototypy a nebezpečná v produkci.

Jak se připravit, konkrétně.

Auditujte svůj stack proti těmto třem komponentám. Má každý nástroj expozice API a MCP? Mluví s ostatními, nebo sedí v silu? Má bezpečnostní kontroly? Nástroje, které selžou ve dvou z tří, jsou krátkodobé aktiva.

Postavte kontextovou infrastrukturu nyní. Dokumentujte schéma, obchodní definice a architektonická rozhodnutí v strojově čitelných formátech. Bohatý kontext se nestaví za čtvrtletí. Týmy, jejichž umělá inteligence má jej v roce 2027, jsou ty, které dokumentují dnes.

Běžte s umělou inteligencí do produkce, dříve než si myslíte, že jste připraveni. Týmy, které čekají na formální “strategii umělé inteligence”, než nasadí, budou osmnáct měsíců pozadu za týmy, které již učí z reálných produkčních selhání. Vyberte nízko-rizikový případ užití. Nasazení. Postavte svaly.

Týmy, které dělají tato rozhodnutí dnes, budou definovat příští dekádu, jak se software staví. Okno je úzké, a je otevřené právě teď.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Devart.