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 s rozvojem 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 hlavní obchodní ředitel a ředitel prodeje ve společnosti Devart, kde vedl strategii vstupu na trh, 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, je společnost nejznámější svými nástroji pro správu databází dbForge, které podporují hlavní databázové systémy, včetně SQL Server, MySQL, Oracle (ORCL ) a PostgreSQL. Devart také vyvíjí datové konektivitní ř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í s umělou inteligencí do svých produktů prostřednictvím nástrojů, jako je dbForge AI Assistant, který pomáhá vývojářům generovat, optimalizovat, odstraňovat a vysvětlovat dotazy SQL pomocí přirozeného jazyka.

Přestěhoval jste se 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 tato cesta ovlivnila váš přístup k integraci umělé inteligence do produktové strategie a rozhodování ve velkém měřítku?

Prodej mi naučil měřit ROI na vše. Přechod do role CRO mi umožnil tuto disciplínu rozšířit na všechny funkce. Řízení obchodních jednotek mě donutilo aplikovat ji na umělou inteligenci samotnou.

Mám praktický pohled na umělou inteligenci. Není to, že bych ji podezříval: tři ze čtyř našich produktových sázek pro rok 2026 jsou AI-nativní. 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 si platí svou cestu, nebo zemře. Řídím naše nasazení AI 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.

Naším severním hvězdným metrikem je Výnos na zaměstnance a náš cíl je více než zdvojnásobit ho do konce roku 2028. Nerozmezíte tuto mezeru náborováním. Rozmezíte ji změnou toho, jak vypadá práce, a umělá inteligence je jediným realistickým mechanismem v tomto měřítku.

Můj filtr pro každou iniciativu AI, interní nebo produktovou, je stejný: co je měřená hodnota, kdo za to platí a jak víme, že to funguje? Cokoliv, co nevyhovuje těmto třem otázkám, nepatří do produkce. Náklad na to, že se to pokazí, se rychle hromadí 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 integrujete umělou inteligenci do těchto produktů tak, aby poskytla 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 několika sekund a nesnesou, když jim jsou prodávány marketingové hračky vydávané za inovace. Před dvěma lety, kdy hype kolem AI vyvrcholil a konkurenti spěchali přidávat chatovací panely na každý UI prvek, byla pokušení následovat skutečná. Viděl jsem ten vzorec dříve, v mobilních zařízeních, cloudu, low-code, a odmítal jsem ho opakovat.

Disciplína byla přímá: zákaznická hodnota na prvním místě. Budování funkcí AI, které nikdo nepož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 especialmente pravda, když vaše publikum může rozpoznat rozdíl okamžitě.

Co se změnilo v roce 2026, je, že AI 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 co mohou dělat dnes, není inkrementální. Je to úplně jiná kategorie schopností. Nyní můžeme řešit problémy, které byly dříve skutečně nevyřešitelné: zabezpečený přístup k podnikovým datům pro agenty AI, 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 AI učinila základní problém řešitelným. To je laťka, kterou si sami stanovujeme: skutečný produkt AI je ten, kde odstranění vrstvy AI rozbití produktu. Průmysl strávil dva roky označováním chatovacích panelů jako “produkty AI”. Ty jsou funkce, ne produkty.

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

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ářů pracujících s databázemi v příštích několika letech?

Hodnota znalosti syntaxe SQL se rychle znehodnocuje. Pokud AI může vygenerovat komplexní více-tabulkový 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ý zastánci úplné automatizace vždycky vynechávají. Chyba AI na frontendu je špatně umístěný tlačítko, které můžete obnovit. Chyba AI 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 zcela mění roli. Během následujících dvou až tří let se vývojáři databází a DBA vyvinou z kodérů na architekty a auditory. Jejich primární práce se přesune do tří věcí:

• Navrhování spolehlivých architektur, které AI nemůže sama rozumět, protože jí chybí obchodní kontext.
• Nastavení tvrdých bezpečnostních pravidel a politik pro agenty AI, kteří se dotýkají produkčních systémů.
• Přezkum 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ů AI. Nástroje, jako je dbForge, se musí vyvinout z tradičních IDE do center řízení a auditu. Práce se stane méně psaním SQL ručně a více kontrolou toho, co AI generuje, validací a vynucením hranic, které AI 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 AI a bezpečností produkce. Premiální hodnota na odbornosti na databáze nezmizí; posune se směrem k designu, správě a úsudku, kde AI nemůže sama fungovat.

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

Současná AI je stále uvězněna v povrchové automatizaci. Generování základního dotazu SQL nebo boilerplate kódu již není působivé. Větším problémem je, že většina systémů AI se chová jako slepí pisatelé, nikoli jako systémoví architekti. Mohou generovat syntaxi, ale nevědí, v jakém prostředí operují. Skutečný průlom nastane, když AI 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 nevědí, co jsou to plány vykonání, fragmentace indexů, vzorce distribuce dat nebo skutečná obchodní logika za daty. Bez tohoto hlubšího porozumění se mnoho optimalizačních rad stává statistickým odhadem maskovaným jako 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. Špatný UPDATE může vymazat kritické záznamy. Na této úrovni se i malé chyby stávají velmi drahý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 AI bez silných záruk kolem izolace dat a kontroly. Dokud dodavatelé nevyřeší tento problém řádně, adopce AI v regulovaných odvětvích zůstane omezená.

Průlom nastane, když AI začne fungovat více jako backgroundový architekt nebo analytik.

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

Další posun je AI, která funguje více jako senior DBA na pozadí. Kontinuální analýza pracovních zátěží, identifikace úzkých míst, návrh indexů, identifikace rizikových dotazů a odchycení problémů, než systémy selžou.

Pak je tu stroj na strojové operace, kde autonomní agenti monitorují zátěž databáze, testují strategie optimalizace v izolovaných prostředích a nasazují vylepš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.

Jako někdo, kdo vedl strategii výnosů a vstupu na trh, jak umělá inteligence mění modely cen, balíčky produktů a zákaznickou akvizici ve softwarových firmách?

Tradiční playbook pro vstup na trh 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 hodnoceních našich produktů v roce 2026 dosahujeme reality bez kliknutí. AI vyhledávání dodává odpovědi přímo na stránce výsledků a zbavuje webové stránky provozu. Silná umístění již neodpovídají za leady tak, jako tomu bylo před dvěma lety.

Před pěti lety stačila silná strategie obsahu k pohánění růstu. Dnes je to základní předpoklad. LLM vyhodnocují 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á, AI systémy přestanou vás konzistentně zobrazovat. Neztrácíte pouze provoz. Zmizíte z nákupního procesu úplně. To horší je, že celý trh panikaří do placené reklamy, což pohání CPC na absurdní úrovně a tiše ničí ekonomiku většiny firem SaaS.

Tato změna zasahuje tradiční firmy vývojářských nástrojů obzvláště tvrdě. Kanály akvizice SEO, které financovaly 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í.

Evoluce cen: od míst k PLG 3.0. Vstupujeme do další fáze PLG. Cenová strategie na základě míst začíná selhávat, když jeden agent AI může udělat práci několika zaměstnanců. V takovém prostředí přestává smysluplně fungovat cenová strategie založená na počtu zaměstnanců. Společnosti, které své produkty nepřepakuji podle hodnoty místo počtu zaměstnanců, ztratí MRR v příštích 24 měsících.

Další krok je PLG 3.0: okamžik, kdy autonomní agent AI, 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.

Mnohé organizace bojují s přechodem od experimentování s AI k skutečnému dopadu v produkci. Jaké jsou klíčové faktory, které určují, zda iniciativy AI skutečně uspějí?

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

Stále vidím stejné chyby opakované ve firmách, které bojují s přechodem AI z experimentování do skutečného dopadu v produkci.

První chyba je budování funkcí AI, které nikdo nepožadoval. Jakmile je funkce AI nařízena bez skutečné potřeby uživatele, tým pracuje zpětně od technologie, aby vynalezl případ použití. Výsledek je předvídatelný: chatovací panel připevněný k existujícímu UI, autocomplete, který překáží, nebo tlačítko “sumarizovat”, které produkuje horší výstup, než by uživatel sám napsal. Tyto funkce se dodávají, získávají tiskovou zprávu a tiše podávají horší výkony, než se očekávalo.

Druhým problémem je, že týmy výrazně podceňují rozdíl mezi čistými demonstračními daty a skutečnými produkčními daty. Dema AI běží na čistých, kurátorovaných příkladech. Produkce běží na skutečném chaosu zákaznických dat: duplikáty, 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ů si to nevšimne, dokud uživatelé nestěžují. Náklad na toto zjištění v produkčním důvěryhodnosti je zřídka ziskový.

Jiným častým selháním je uživatelská výzkum. Standardní produktové rozhovory nefungují pro funkce AI. Uživatelé nemohou artikulovat, co chtějí od AI, protože nevědí, co je možné. Zeptání se “použili byste AI pro X?” dostane zdvořilé ano odpovědi, které nemají předvídatelnou hodnotu pro adopci. Efektivní výzkum produktu AI vyžaduje ukázku prototypů, pozorování skutečného použití a měření, zda uživatelé vrátí, když novinka pomine. Málo produktových týmů přestavilo svou výzkumnou praxi pro toto. Stále běží playbooky z roku 2019 na problémy z roku 2026.

A konečně, mnoho firem měří aktivitu AI místo skutečného dopadu. “Dvě stě lidí použilo funkci AI tento týden” je metrika adopce, ne metrika dopadu. Skutečný dopad je cyklus času snížený, kvalita vylepšená, výnosy vygenerované nebo náklady odstraněné. Pokud nemůžete nakreslit přímou linku z funkce AI k číslu na P&L, nemáte produkční dopad. Máte 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 budování bez AI. 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 v politice, která zakazuje nebo omezuje funkce AI ve softwaru dodavatelů. Pokud váš produkt pevně spojuje AI do základní zkušenosti bez možnosti jej zakázat nebo obejít, nezískáte svou publikum přidáním AI. Ztratíte segment své stávající.

Toto je přesně problém, který řešíme s AI Connectivity. Týmy pro shodu v regulovaných odvětvích si nestěžují na AI samotnou. Stěžují si na data, která opouští jejich perimetr. Řešením není odstranit AI, ale poskytnout jim architekturu AI, která odpovídá jejich omezením. Proto AI Connectivity dodává jako on-premise: schopnost AI zůstává, data nikdy neopouští zákaznickou infrastrukturu a nákup projde kontrolou na první kolo místo třetího.

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

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

Bolest je skutečná. Typická firma 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 analytiku a stále více vektorový sklad pro vložené údaje. Každý z nich má svůj vlastní dialekt, své vlastní nástroje, své vlastní režimy správy. 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 smí je dotknout.

AI sama o sobě neřeší tuto složitost. Zesiluje kontext, který dostane. Osm nespojených databází s žádnou jednotnou 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 AI na stacku.

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

To je architektura, kterou budujeme směrem k AI Connectivity: on-premise MCP server s multi-databázovou podporou, semantická vrstva, která zachycuje obchodní definice jednou místo toho, aby každý agent AI musel znovu učit, role-založená kontrola přístupu na úrovni SQL operací a plné auditní protokoly.

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

Vy vedl velké mezioborové týmy. Jak AI mění interní spolupráci a rozhodování mezi produktem, inženýrstvím, marketingem a prodejem?

Most cross-funkční tření bylo vlastně jen lidé čekající na informace z jiných týmů. AI kolabuje toto tření rychleji, než by to mohla udělat jakákoli manažerská struktura.

Posuny jsou praktické a okamžité.

V produkci 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 aby podával ticket do Jiry a čekal tři dny.

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

V prodeji 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 důvěryhodnou technickou odpověď v reálném čase a prodejní cyklus se zkracuje.

Rozhodnutí se přesouvají do konverzace místo do follow-up. Vzorec “nechám se vrátit k vám s tím číslem” umírá. Schůzky se zkracují, protože AI zpracovává pre-čtení a souhrny, které dříve spotřebovávaly první polovinu každé relace.

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

Každá firma 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é tickety, hodiny odpracované. Používáme aktivitu jako proxy pro hodnotu, protože skutečná hodnota byla těžko měřitelná. AI láme tento proxy trvale. Když agent AI může napsat 10 000 řádků kódu nebo uzavřít 500 podpůrných ticketů za minutu, měření aktivity se stává nebezpečně zavádějícím.

Přecházíme explicitně k 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ří se dříve skrývali za vysokou aktivitou, se stanou viditelnými okamžitě 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 AI-pomocného vývoje a nástrojů bez kódu se blížíme k budoucnosti, kde 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-projektem databáze a podnikovou legacy databází, jako by to byly stejné věci. Není tomu tak.

Pro malé zelené projekty je demokratizace již zde. Osobně jsem postavil malé aplikace od nuly bez hlubokých znalostí správy databází. Pokud celý váš schéma fits do kontextového okna LLM, AI funguje jako kouzlo. Občanský 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é báze: kontextová zeď. Nemůžete vejít patnáct let nevyžádané evoluce schématu, mezi-databázových závislostí a vlastních trigger logiky do promptu. Když AI ztratí kontext na velké databázi, halucinace se nezhoršují elegantně. Mnohonásobně se množí.

Riziko, které se málo diskutuje, je falešná důvěra v měřítku. Přirozené jazykové rozhraní jsou jedinečně dobré v produkci vypadajících, ale jemně chybných odpovědí. Pokud SQL dotaz má chybu syntaxe, dostanete chybové hlášení. Pokud přirozené jazykové rozhraní špatně interpretuje “aktivní zákazníky”, protože vaše data mají šest různých definic aktivity, dostanete číslo. Číslo vypadá v pořádku. Může být o 30% nižší. Uživatel nemá způsob, jak to vědět.

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

Citizen DBA je mýtus v měřítku.

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 AI fungovat bezpečně nahoře.

Strukturální fix je semantická vrstva: kontrolovaná slovní zásoba, kde obchodní definice jsou pevné a opakovaně použitelné napříč každou interakcí AI. To je jádro architektury, kterou budujeme do Insightis. Bez ní se přístupnost stává závadou.

Pohledem do budoucnosti, co vypadá “AI-nativní” vývojářský nástroj a jak by se týmy měly začít připravovat na tuto změnu dnes?

AI-nativní nástroj není chatbot připevněný k IDE. Most toho, co se prodává jako “AI-nativní” dnes, je chatovací rozhraní plus model autocomplete. To je základní předpoklad, ne destinace.

Pro mě je skutečný AI-nativní nástroj ten, který potřebuje tři věci.

První je hluboký kontext. AI 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 vložených promptů do chatovacího okna. Most current tools selže v tomto testu. Jejich kontext resetuje se každou relací a uživatel platí cenu za jeho opětovné budování.

Druhým je, že nástroje samy potřebují komunikovat mezi sebou správně. Vaše IDE musí mluvit s vaší databází, databáze s vaším stackem pozorovatelnosti a CI/CD s vaším AI recenzentem 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 kdy viděl v infrastruktuře vývojářů.

Třetím je, že produkční AI vyžaduje vážné bezpečnostní zábrany. Náhled na radius před destruktivními operacemi. Analýza závislostí. Automatizované plány rollback. Auditní stopy výchozím stavem. AI 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ž AI má ho v roce 2027, jsou ty, které dokumentují dnes.

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

Týmy, které dělají tato rozhodnutí dnes, budou definovat příští dekádu, jak se software buduje. 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.