Rozhovory
Shanea Leven, zakladatelka a CEO ve společnosti Empromptu AI – Interview Series

Shanea Leven, zakladatelka a CEO ve společnosti 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 významných technologických společnostech. Předtím, než v roce 2025 spustila Empromptu, založila společnost CodeSee, platformu pro vývojáře poháněnou umělou inteligencí, která pomáhá týmům vizualizovat a pochopit komplexní kódy, kterou v roce 2024 získala společnost GitKraken. Na počátku své kariéry zastávala seniorní produktové vedení ve společnostech jako Docker, Cloudflare, eBay a Google, kde pracovala na iniciativách od platebních API pro 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á tak, aby pomohla 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ého experimentování s umělou inteligencí na systémy připravené pro produkci s potřebnými kontrolami a spolehlivostí pro podnikové použití.
Vousvědli 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žili CodeSee, které později získala společnost GitKraken, a nyní vedete Empromptu AI. Jak tyto zkušenosti ovlivnily váš pohled na to, proč tolik nástrojů umělé inteligence selhává, jakmile opustí demo fázi, a jaký konkrétní problém jste se rozhodli vyřešit, když jste založili Empromptu?
Jedna z věcí, které se naučíte budováním vývojářských platforem, je, že nejtěžší problémy nejsou nikdy ty 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 nich.
V Googlu, Cloudflare, Dockeru a eBay jsem strávila roky prací na platformách, které musely fungovat ve 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í nekódujeme pouze statické webové aplikace; kódujeme celé aplikace umělé inteligence. Umělá inteligence, která buduje umělou inteligenci, vyžaduje další systémy, které tuto umělou inteligenci dostanou do produkce.
Můžete rychle vygenerovat funkční aplikaci umělé inteligence nebo funkci, což je vzrušující a skutečně užitečné. Ale převládající systémy stále postrádají infrastrukturu potřebnou pro produkční prostředí. Věci jako strukturované datové potrubí, evaluační rámce, kontrolní mechanismy, monitorování a dlouhodobá správa kontextu byly přehlédnuty, ale my jsme je do naší platformy začlenili, zatímco jsme zachovali všechny skvělé části kódování.
Když můj spoluzakladatel a já založili Empromptu, problém, který jsme chtěli vyřešit, byl jednoduchý: jak můžeme 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 procesy po faktu, jsme je postavili přímo do platformy. Nápad je, že týmy by měly být schopny budovat aplikace umělé inteligence rychle, ale se stejnou spolehlivostí, kvalitou a kontrolou, jakou očekávají od podnikových softwarových systémů.
Byli jste otevřeni o propasti mezi působivými demo umělé inteligence a systémy připravenými pro produkci. Z vašeho pohledu, jaké jsou nejčastější architektonické chyby, kterých se týmy dopouští, když se snaží změnit 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 vypadá 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 skutečným provozním datům, věci se rychle změ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ů spustí funkce umělé inteligence bez definice, co “dobré” vlastně znamená. Mohli by ručně kontrolovat výstupy během vývoje, ale nestaví automatizované evaluační potrubí, které nepřetržitě 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 kontrolních a řídících mechanismů. Systémy umělé inteligence jsou pravděpodobnostní, což znamená, že se mohou chovat jinak při mírně odlišných podmínkách. V regulovaných nebo vysoce rizikových prostředích musí být tato nepředvídatelnost omezena deterministickými zásadami, schvalovacími pracovními postupy a auditními protokoly, které zachycují, jak byla rozhodnutí učiněna.
To se vlastně sníží na to, ž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í, evaluační rámce, 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 do skutečných produkčních prostředí?
Mnohé z těchto platforem fungují dobře pro demonstrace, protože jsou optimalizovány pro okamžik vytvoření, ne pro životní cyklus skutečného systému.
Ale existuje zásadní rozdíl mezi použitím umělé inteligence pro generování landing page a použitím umělé inteligence pro postavení 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 pravděpodobnostní rozhodnutí, přijímat neustále se měnící data nebo přizpůsobovat se nepředvídatelnému chování uživatelů.
Aplikace umělé inteligence jsou úplně jiné. Jsou dynamické systémy, které spoléhají na datové potrubí, chování modelu, evaluační rámce a nepřetržité monitorování. Aplikace musí spravovat kontext, detekovat, kdy výstupy driftují, zpracovávat edge případy a fungovat bezpečně, když se model setká se situacemi, které neviděl dříve.
Většina nástrojů pro kódování umělé inteligence poháněných promptem nezahrnuje tyto vrstvy, protože jsou navrženy tak, aby něco fungovalo rychle. Generují kód, který produkuje viditelný výsledek, což je ideální pro demo prostředí. Ale produkční systémy vyžadují mnohem širší sadu schopností: strukturované zpracování dat, kontrolní mechanismy, evaluační potrubí, pozorovatelnost a mechanismy pro bezpečné aktualizace chování v průběhu času.
Takže když společnosti se snaží nasadit tyto systémy do skutečných prostředí, mezera se stává zřejmou. 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 základu. Co tato transformace vlastně zahrnuje na úrovni infrastruktury a produktu?
Na úrovni produktu je každá aplikace plně samostatná a kontejnerizovaná. Vytvoříme vše, co potřebujete, od frontendů, backendů, databází, modelů, evalů, llms opps pravidel a všeho, a je to 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á frontend, 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.
Jakýkoli kód, který mají, můžeme přímo importovat do našeho systému a agentifikovat, pokud již není agentifikován. Například vidíme to u mnoha zákazníků, kteří se snažili postavit své aplikace na populárních platformách, jako je Lovable, Replit, Bolt nebo Base44. Často nefungují. Ale zákazníci již investovali mnoho času a energie a kreditů do této aplikace, takže ji ingestujeme, přepíšeme a učiníme všechny funkce umělé inteligence pracovat.
A můžeme to udělat, protože máme několik vlastních, proprietárních technologií, jako je:
- Adaptivní kontextový engine pro správu kontextu
- Neomezená paměť pro ingestování aplikací s dlouhotrvajícím kódem
- Vlastní datové modely a zlaté datové potrubí, aby zajistily, že můžeme zpracovat jakékoli čištění dat a syntetické označení, které je požadováno
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ý laboratoř, a je to computační astrofyzik, který vynalezl několik 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šenosti s budováním mnoha agentic aplikací, vypouštěním satelitů do vesmíru a budováním v největších technologických společnostech na světě nám dávají poznatky, které nám pomáhají řešit složitější problémy lépe než jiní.
Pracujete s mnoha zakladateli, kteří nikdy předtím nekódovali. Jaké jsou největší mýty, které mají nezkušení zakladatelé, když se poprvé snaží postavit aplikace umělé inteligence?
Domnívám se, ž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é manažerské dovednosti. Mám zkušenosti s technickým produktovým managementem a dovednostmi pro překlad vize, někdy velmi velké vize, do malých odesílacích částí s pravými technickými specifikacemi, aby přesně vyjádřily, co chcete. To je vlastně velmi těžká dovednost, která vyžaduje čas.
Například řekněme, že stavíte aplikaci, která nahrává PDF a ukládá ji, aby jste ji mohli později prohlédnout. 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ý slovník 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 postavení produktů umělé inteligence spočívá v najmutí více inženýrů. Proč se domnívá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ávná odpověď. 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áhrady 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 postavení produktu umělé inteligence.
Ve skutečnosti jsou nejtěžší problémy v produktech umělé inteligence často nečisté inženýrské problémy. Jsou to systémy problémy, stejně jako 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í. Je to programování? Ano, absolutně, ale je to jiné? Je to jiný způsob myšlení? Ano, samozřejmě.
Aplikace umělé inteligence leží 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 bojoval, až se dostane k skutečným uživatelům.
Další problém je, že mnoho týmů skočí přímo do budování, aniž by definovali, jak se systém umělé inteligence bude chovat v produkci. Otázky, jako jak bude systém hodnocen, jak budou zpracovávány edge případy, jak budou rozhodnutí logována a jak budou modely aktualizovány v průběhu času, často přicházejí mnohem později. Do té doby je architektura již těžká na změnu.
Co by zakladatelé měli skutečně zvažovat, je provozní model jejich systému umělé inteligence.
Kdo vlastní datové potrubí?
Jak je měřena výkon modelu nepřetržitě, ne pouze během vývoje?
Co se stane, když se systém setká se situací, kterou neviděl dříve?
Jak aktualizujete chování bezpečně, aniž byste porušili downstream pracovní postupy?
Někdy ř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ě ve velkém 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ý systém, který potřebuje disciplínu dat, hodnocení, správu a nepřetržité zlepšování od samého začátku.
Domníváte se, ž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é ekosystémech nástrojů umělé inteligence podle vás vedou společnosti špatným směrem?
Jedna z největších nesrovnalostí pobídek je, že mnoho nástrojů pro vývojáře umělé inteligence je optimalizováno 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 může nástroj vygenerovat funkční aplikaci, funkci nebo demo v několika minutách, to pohání registrace, sdílení na sociálních sítích a vzrušení investorů. Z pohledu přijetí produktu to má smysl.
Ale tyto pobídky často zastavují v okamžiku vytvoření.
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. Když uživatel chce vrátit se znovu a znovu bez frustrace z umělé inteligence z důvodu špatného výstupu. Potřebujete poskytnout dobré odpovědi, i když se setkáte s lidskou nevědomostí nebo zlomyslností.
Dalším problémem je, že mnoho nástrojů je optimalizováno pro generování kódu spíše než pro návrh systému. Generování kódu rychle je užitečné, ale stavba produktu umělé inteligence zahrnuje více než generování 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 průběhu času.
Společnosti, které sladí své pobídky s tím, aby pomáhaly 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ěkteří vaši zákazníci 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ří uspějí, nejsou nutně nejvíce techničtí. Jsou to ti, kteří rozumějí problému, který řeší, extrémně dobře.
Mnozí z našich zákazníků jsou odborníci na danou oblast. Mohli by pocházet ze zdravotnictví, financí, udržitelnosti nebo jiné specializované oblasti. Co přinášejí, je hluboké poznání 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 skutečně potřebuje udělat.
Zakladatelé, kteří uspějí, se méně soustředí na to, aby se chovali jako technologický experiment, a více jako produktový systém. Začínají pokládáním velmi konkrétních otázek. Jaká rozhodnutí by měla umělá inteligence pomoci uživatelům učinit? Jaká data jsou potřebná pro přístup? Co vypadá správná odpověď ve této oblasti? Jaké zábrany potřebují existovat, aby se systém choval zodpovědně?
Dalším vzorcem je, že ú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é” znamená.
Také vidíme, že úspěšní zakladatelé 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 úsudek 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ší změna v myšlení. Zakladatelé, kteří uspějí, 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.
Jak se systémy umělé inteligence stávají více integrovanými do základních podnikových operací, jaké schopnosti budou definovat další generaci platforem aplikací umělé inteligence?
Vím, že tohle je šílené a možná říkám něco rouhavého, ale lidé budou moci vibrovat své vlastní vlastní modely. Něco, co náš výzkumný laboratoř 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.












