Shanea Leven, zakladatelka a CEO Empromptu AI – rozhovor

Shanea Leven, zakladatelka a CEO Empromptu AI, je zkušená produktová leaderka s rozsáhlými zkušenostmi s budováním vývojářských platforem a produktů poháněných umělou inteligencí ve velkých technologických společnostech. Předtím, než spustila Empromptu v roce 2025, založila CodeSee, platformu pro vývojáře umělé inteligence, která pomáhá týmům vizualizovat a pochopit složité kódy, která byla později získaná společností GitKraken v roce 2024. V počátcích své kariéry zastávala seniorní roli produktového vedení ve společnostech jako Docker, Cloudflare, eBay a Google (GOOGL ), kde pracovala na iniciativách od platebních API Google Assistant po vzdělávací programy pro vývojáře, které využily stovky tisíc studentů.

Empromptu AI je podniková platforma navržená pro pomoc organizacím budovat a nasazovat integrované aplikace umělé inteligence snadněji. Platforma kombinuje vývoj aplikací, integraci dat, správu, hodnocení, paměť a orchestraci modelů do jediného prostředí, což umožňuje společnostem přecházet z rychlé experimentace s umělou inteligencí na systémy připravené pro podnikové použití s požadovanými kontrolami a spolehlivostí.

Strávila jste více než 15 let budováním vývojářských platforem ve společnostech jako Google, eBay, Cloudflare a Docker, než jste založila CodeSee, které bylo později získané GitKraken, a nyní vedete Empromptu AI. Jak tyto zkušenosti ovlivnily váš pohled na to, proč tolik nástrojů umělé inteligence selhává, když opouští demo fázi, a jaký konkrétní problém jste chtěla vyřešit, když jste založila Empromptu?

Jedna z věcí, které se naučíte budováním vývojářských platforem, je, že nejobtížnější problémy nejsou nikdy ty, které jsou v demo. Demo vždy funguje. Skutečný test je to, co se stane, když tisíce vývojářů používají systém, když jsou data špinavá, když se integrace rozpadají a když skutečné podniky závisí na něm.

V Google, Cloudflare, Docker a eBay jsem strávila roky prací na platformách, které musely fungovat v globálním měřítku. Tyto prostředí vám rychle naučí, že spolehlivost, správa a pozorovatelnost nejsou funkcemi, které přidáte později. Jsou to architektura.

Když jsem začala budovat aplikace umělé inteligence, modely byly hrozné a když se začaly zlepšovat, všimla jsem si, že průmysl opakoval stejnou chybu, kterou jsme viděli v předchozích vlnách softwaru. Ve vývojářských nástrojích existuje koncept, který se zdá být zapomenut. Jak rychle můžete dosáhnout “hello world”? Dnes je generativní verze “hello world” plně funkční prototyp SaaS. Ale nyní nebudujeme pouze SaaS aplikace; budujeme celé aplikace umělé inteligence. Umělá inteligence, která buduje umělou inteligenci, vyžaduje další systémy, aby ji umístila do produkce.

Můžete vygenerovat funkční aplikaci umělé inteligence nebo funkci rychle, což je vzrušující a skutečně užitečné. Ale dominantní systémy stále postrádají infrastrukturu potřebnou pro produkční prostředí. Věci jako strukturované datové potrubí, evaluační rámce, mechanismy správy, monitorování a dlouhodobá správa kontextu byly vynechány, ale my jsme je přidali, zatímco jsme zachovali všechny úžasné části “vibe codingu”.

Když můj spoluzakladatel a já založili Empromptu, problém, který jsme chtěli vyřešit, byl jednoduchý: jak udělat aplikace umělé inteligence připravené pro produkci od začátku?

Místo toho, aby se správa, připravenost dat, hodnocení a optimalizace léčily jako samostatné nástroje nebo post-factum procesy, postavili jsme je přímo do platformy. Nápad je, že týmy by měly být schopny budovat aplikace umělé inteligence rychle, ale s tou samou spolehlivostí, kvalitou a kontrolou, kterou očekávají od podnikových softwarových systémů.

Byla jste otevřená o propasti mezi působivými demo umělé inteligence a produkčními systémy. Z vašeho pohledu, jaké jsou nejčastější architektonické chyby, které týmy dělají, když se snaží převést prototyp umělé inteligence na spolehlivý produkt používaný skutečnými zákazníky?

Nejčastější chyba, kterou týmy dělají, je předpoklad, že model je produkt.

V raných prototypách dělá model většinu viditelné práce. Promptujete ho, produkuje odpověď a pokud odpověď vypadá dobře, systém se zdá funkční. To vytváří iluzi, že zlepšení modelu je hlavní výzvou.

Ale v produkčních systémech je model pouze jednou součástí mnohem větší architektury.

První chyba je léčba dat jako dopothought. V prototypách týmy často testují s malými, čistými datovými sadami. Jakmile se systém připojí k reálným provozním datům, věci se rychle mění. Data přicházejí neúplná, nekonzistentní, duplikovaná nebo v neočekávaných formátech. Bez strukturovaného datového potrubí, které normalizuje a ověřuje vstupy, se systém stává nespolehlivým, bez ohledu na to, jak dobrý je model.

Druhá chyba je absence evaluačních rámců. Mnoho týmů spouští funkce umělé inteligence bez definice toho, co “dobré” vlastně znamená. Mohou ručně kontrolovat výstupy během vývoje, ale nestaví automatizované evaluační potrubí, které kontinuálně měří přesnost, drift a edge případy, jakmile je systém živý. Bez těchto zábran jsou selhání často objevena zákazníky místo inženýrů.

Třetí problém je absence mechanismů správy a kontroly. Systémy umělé inteligence jsou probabilistické, což znamená, že se mohou chovat jinak za slightly odlišných podmínek. V regulovaných nebo high-stakes prostředích musí být tato nepředvídatelnost omezena deterministickými politikami, schvalovacími pracovními postupy a auditními protokoly, které zachycují, jak byly učiněny rozhodnutí.

Co to vlastně znamená, je, že produkční systémy umělé inteligence nejsou pouze modely. Jsou to provozní systémy.

Společnosti, které dnes úspěšně využívají umělou inteligenci, jsou ty, které považují datové potrubí, hodnocení, správu a monitorování za základní infrastrukturu, ne za volitelné doplňky.

Mnohé platformy pro kódování umělé inteligence slibují, že kdokoli může postavit aplikaci pomocí jednoduchých promptů. Proč tyto nástroje často fungují dobře pro demonstrace, ale bojují, když společnosti se snaží nasadit je v reálném produkčním prostředí?

Mnohé z těchto platforem fungují dobře pro demonstrace, protože jsou optimalizovány pro okamžik tvorby, ne pro životní cyklus skutečného systému.

Ale existuje zásadní rozdíl mezi používáním umělé inteligence k vygenerování landing page a používáním umělé inteligence k vybudování aplikace umělé inteligence.

Landing page je většinou statický software. Jakmile se vykreslí správně, práce je téměř hotová. Systém nemusí dělat probabilistické rozhodnutí, přijímat neustále se měnící data nebo adaptovat se na nepředvídatelné chování uživatelů.

Aplikace umělé inteligence jsou úplně jiné. Jsou to dynamické systémy, které závisí na datových potrubích, chování modelu, evaluačních rámcích a kontinuálním monitorování. Aplikace musí spravovat kontext, detekovat, kdy výstupy driftují, zpracovávat edge případy a fungovat bezpečně, když model narazí na situace, které neviděl dříve.

Většina nástrojů pro kódování promptů neřeší tyto vrstvy, protože jsou navrženy pro to, aby něco fungovalo rychle. Generují kód, který produkuje viditelný výsledek, což je perfektní pro demo prostředí. Ale produkční systémy vyžadují mnohem větší sadu schopností: strukturované zpracování dat, mechanismy správy, evaluační potrubí, pozorovatelnost a mechanismy pro bezpečné aktualizace chování v čase.

Takže když společnosti se snaží nasadit tyto systémy v reálném prostředí, propast se stává zjevnou. Prototyp fungoval, protože prostředí bylo kontrolované. Produkce je špinavá.

Empromptu se zaměřuje na transformaci stávajících softwarů na systémy nativní pro umělou inteligenci, místo toho, aby donutila společnosti přestavět vše od začátku. Co tato transformace vlastně zahrnuje na úrovni infrastruktury a produktu?

Na úrovni produktu je každá aplikace plně samostatná a kontejnerizovaná. Vytvoříme všechno, co potřebujete, od front-endů, back-endů, databází, modelů, evaluačních modelů, pravidel a všeho, co je super flexibilní v závislosti na potřebách podniku.

Máme několik různých možností pro aplikace umělé inteligence:

“Headless”, takže pokud zákazník již má front-end, můžeme ho připojit k našemu systému a odeslat data zpět

Plně kontejnerizované, takže je lze nasadit na naší infrastruktuře nebo v infrastruktuře zákazníka, takže jsou výchozími na-prem

Nebo je můžeme vygenerovat a nasadit přímo do cloudu pro nejpohodlnější možnost

Libovolný kód, který mají, můžeme importovat přímo do našeho systému a agentovat, pokud již není agentován. Například vidíme to u mnoha zákazníků, kteří se pokusili postavit své aplikace na populárních platformách, jako je Lovable, Replit, Bolt nebo Base44. Často nefungují. Ale zákazníci již investovali spoustu času a energie a kreditů do této aplikace, takže ji ingestujeme, přepíšeme a učiníme, aby umělá inteligence fungovala.

A můžeme to udělat, protože máme řadu vlastních, proprietárních technologií, jako jsou:

• Adaptivní kontextový motor pro správu kontextu
• Neomezená paměť pro ingestování dlouhodobě běžících aplikací
• Vlastní datové modely a zlaté datové potrubí pro zajištění zpracování jakýchkoli požadavků na čištění a syntetické označení dat

Vaše platforma zdůrazňuje kontext, hodnocení, správu a strukturovaná data jako základní součásti systémů umělé inteligence. Proč jsou tyto prvky tak často přehlíženy, když týmy spěchají přidat funkce umělé inteligence do svých produktů?

Protože jsou těžké! Můj spoluzakladatel, Dr. Sean Robinson, vede náš výzkumný ústav, a je to výpočetní astrofyzik, který vynalezl řadu technologií inspirovaných mými šílenými nápady, ale také potřebami našich zákazníků a tím, kam směřuje trh. Naše kombinovaná zkušenost s budováním mnoha agenčních aplikací, umístěním satelitů do vesmíru a budováním v největších technologických společnostech na světě nám dává znalosti, které nám pomáhají lépe řešit složité problémy než jiní lidé.

Pracujete s mnoha zakladateli, kteří nikdy předtím neprogramovali. Jaké jsou největší mýty, které nemají techničtí zakladatelé, když se poprvé snaží postavit aplikace umělé inteligence?

Myslím, že existují dva velké mýty:

První je, že umělá inteligence je magie. Umělá inteligence není magie. Je to prostě dobré inženýrství. A nakonec narazíte na limit toho, co můžete udělat na těchto platformách bez skutečného inženýra.

Druhý je, že mají skvělé technické produktové dovednosti. Mám zkušenosti s technickým produktovým managementem a dovedností přeložit vizi, někdy velmi velkou vizi, do malých odesílatelných částí s pravými technickými specifikacemi, aby přesně vyjádřily, co chcete. To je vlastně velmi obtížná dovednost, která vyžaduje čas.

Příklad: řekněme, že stavíte aplikaci, která nahrává PDF a ukládá ho, aby jste ho mohli později znovu otevřít. To je koncept nazývaný persistencia. Ten PDF se zakóduje do kódu a uloží do databáze.

Ale pokud nevíte, že se to nazývá persistencia, jak budete moci napsat? Ujistěte se, že tato data persistují. Technický výběr slov je jako mluvení jiným jazykem. Existuje rozdíl mezi psaním v přirozeném jazyce a psaním v technickém jazyce.

Mnohé startupy předpokládají, že řešení pro stavbu produktů umělé inteligence spočívá v najmutí více inženýrů. Proč si myslíte, že tento přístup často selhává, a co by měli zakladatelé místo toho zvažovat, když staví produkty poháněné umělou inteligencí?

Najmutí více inženýrů je někdy správnou odpovědí. Pokud stavíte hluboce technický produkt nebo pracujete na hranici modelového výzkumu, absolutně potřebujete silné inženýrské týmy. Není žádná náhrada za dobré inženýry, když jde o řešení tvrdých problémů.

Ale chyba, kterou mnohé startupy dělají, je předpoklad, že více inženýrů automaticky řeší výzvu stavby produktu umělé inteligence.

Ve skutečnosti jsou nejobtížnější problémy v produktech umělé inteligence často nečisté inženýrské problémy. Jsou to systémové problémy, jako je každý jiný inženýrský problém. Inženýři jsou speciálně vyučeni myslet v systémech. Ale generativní vývoj je jiný než deterministický vývoj. Mnozí z nás udělali tento přechod, když jsme přecházeli z objektově orientovaného programování na funkcionální programování. Jsou to programování? Ano, absolutně, ale jsou to jiný způsob myšlení? Ano, samozřejmě.

Aplikace umělé inteligence se nacházejí na průsečíku dat, produktového designu, provozních pracovních postupů a chování modelu. Můžete najmout úžasný tým inženýrů, ale pokud datové potrubí jsou nespolehlivá, evaluační kritéria jsou nejasná nebo systém postrádá správu a monitorování, produkt bude stále bolet, až se dostane k reálným uživatelům.

Jinou otázkou je, že mnohé týmy skáčou přímo do stavby, aniž by definovaly, jak se systém umělé inteligence bude chovat v produkci. Otázky, jako je, jak bude systém hodnocen, jak budou zpracovány edge případy, jak budou rozhodnutí protokolována a jak budou modely aktualizovány v čase, často přicházejí mnohem později. V té době je architektura již obtížně změnitelná.

Co by zakladatelé měli opravdu zvažovat, je provozní model svého systému umělé inteligence.

Kdo vlastní datové potrubí?

Jak je měřena kontinuální výkonnost modelu, nejen během vývoje?

Co se stane, když systém narazí na situaci, kterou neviděl dříve?

Jak aktualizujete chování bezpečně, aniž byste porušili 다운strömové pracovní postupy?

Často řešení těchto problémů znamená najmutí více inženýrů. Ale může to také znamenat výběr správné infrastruktury, definici silných produktových omezení a budování systémů, které umožňují malým týmům fungovat spolehlivě v měřítku.

Společnosti, které dnes úspěšně využívají umělou inteligenci, nejsou nutně ty, které mají největší inženýrské týmy. Jsou to ty, které považují umělou inteligenci za dlouhodobě běžící systém, který potřebuje disciplínu dat, hodnocení, správu a kontinuální zlepšování od začátku.

Byla jste otevřená o tom, že některé současné obchodní modely v nástrojích pro vývojáře umělé inteligence nejsou v souladu se stavbou trvanlivých produktů. Jaké pobídky v současném ekosystému nástrojů umělé inteligence si myslíte, že vedou společnosti ve špatném směru?

Jedna z největších nesouladů pobídek je, že mnohé nástroje pro vývojáře umělé inteligence jsou optimalizovány pro růstové metriky spíše než pro trvanlivost produktu.

Mnohé společnosti v tomto prostoru jsou odměňovány za to, jak rychle uživatelé mohou vytvořit něco působivého. Pokud nástroj může vygenerovat funkční aplikaci, funkci nebo demo za několik minut, to pohání registrace, sdílení na sociálních sítích a nadšení investorů. Z pohledu přijetí produktu to má smysl.

Ale tyto pobídky často zastavují v okamžiku tvorby.

Těžší práce na softwaru umělé inteligence se děje po tomto bodě. To je okamžik, kdy se buduje důvěra. Když můžete spoléhat na kvalitu. Že uživatel chce vrátit se znovu a znovu bez frustrace z špatného výstupu. Potřebuje poskytnout dobré odpovědi, i když čelí lidské nevědomosti nebo zlomyslnosti.

Jinou otázkou je, že mnohé nástroje jsou optimalizovány pro generování kódu spíše než pro systémový design. Generování kódu rychle je užitečné, ale stavba produktu umělé inteligence zahrnuje více než produkci kódu. Zahrnuje definici, jak systém spravuje kontext, jak jsou rozhodnutí hodnocena, jak jsou zpracovávána selhání a jak se chování vyvíjí bezpečně v čase.

Společnosti, které zarovnávají své pobídky kolem pomoci zákazníkům provozovat systémy umělé inteligence spolehlivě, ne pouze je budovat rychle, jsou ty, které vytvoří trvalou hodnotu v tomto ekosystému.

Některé z vašich zákazníků zahrnují podnikatele, kteří staví velmi specifické produkty, jako jsou specializované zdravotnické nástroje nebo podniky zaměřené na udržitelnost, často bez tradičních inženýrských týmů. Jaké vzorce jste viděli mezi zakladateli, kteří úspěšně mění tyto nápady na funkční produkty umělé inteligence?

Jedním z nejzajímavějších vzorců, které vidíme, je, že zakladatelé, kteří úspěšní, nejsou nutně ti nejtechničtější. Jsou ti, kteří rozumí problému, který řeší, extrémně dobře.

Mnozí z našich zákazníků jsou odborníci z domény. Mohou pocházet ze zdravotnictví, financí, udržitelnosti nebo jiné specializované oblasti. Co přinášejí, je hluboká znalost pracovních postupů, předpisů a rozhodnutí, která existují v tomto prostředí. Tento kontext je nesmírně cenný při navrhování produktu umělé inteligence, protože definuje, co systém vlastně potřebuje udělat.

Zakladatelé, kteří úspěšní, se přiblíží k umělé inteligenci méně jako technologickému experimentu a více jako produktovému systému. Začínají pokládat velmi konkrétní otázky. Jaká rozhodnutí by měla umělá inteligence pomoci uživatelům učinit? Jaká data zdroje potřebuje přístup? Co vypadá správná odpověď v této doméně? Jaké zábrany potřebují existovat, aby systém se choval zodpovědně?

Dalším vzorcem je, že úspěšně myslí na strukturu. Úspěšné týmy rychle uvědomí, že výstupy umělé inteligence jsou pouze tak dobré, jako je kontext a data, která je krmí. Investují čas dopředu do definice datových potrubí, organizování znalostních zdrojů a vytváření jasných evaluačních kritérií pro to, co “dobré” vypadá.

Vidíme také úspěšné zakladatele, kteří přijímají spolupráci mezi lidmi a umělou inteligencí, místo toho, aby se snažili automatizovat vše okamžitě. Navrhuje pracovní postupy, kde umělá inteligence zpracovává opakovanou analýzu nebo syntézu dat, zatímco lidé zůstávají odpovědní za soud a konečná rozhodnutí. Tato rovnováha dělá systémy mnohem spolehlivější, zejména v oblastech, jako je zdravotnictví nebo finance.

Ve mnoha ohledech je největší posun změnou myšlení. Zakladatelé, kteří úspěšní, nemyslí na umělou inteligenci jako na funkci, kterou přidávají. Myslí na ni jako na novou provozní vrstvu, která určuje, jak jejich produkt funguje.

Jakmile se systémy umělé inteligence stanou více integrovanými do jádra podnikových operací, jaké schopnosti budou definovat další generaci platforem aplikací umělé inteligence?

Vím, že to je šílené a možná říkám něco rouhavého, ale lidé budou moci “vibe-code” své vlastní vlastní modely. Něco, co náš výzkumný ústav nazývá expertní nano modely, bude pomáhat kontrolovat náklady.

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