Shanea Leven, Założyciel i CEO Empromptu AI – Seria wywiadów

Shanea Leven, Założyciel i CEO Empromptu AI, to doświadczony lider produktowy z ogromnym doświadczeniem w budowaniu platform dla deweloperów i produktów opartych na sztucznej inteligencji w dużych firmach technologicznych. Przed założeniem Empromptu w 2025 roku, założyła CodeSee, platformę dla deweloperów opartą na sztucznej inteligencji, która pomaga zespołom wizualizować i rozumieć złożone bazy kodu, która została przejęta przez GitKraken w 2024 roku. Wcześniej w swojej karierze, pełniła seniorowe role w zarządzaniu produktami w firmach, w tym Docker, Cloudflare, eBay i Google (GOOGL ), gdzie pracowała nad projektami od API płatności Google Assistant do programów edukacji dla deweloperów używanych przez setki tysięcy uczniów.

Empromptu AI to platforma przedsiębiorstw, zaprojektowana, aby pomóc organizacjom w łatwiejszym budowaniu i wdrażaniu zintegrowanych aplikacji opartych na sztucznej inteligencji. Platforma łączy rozwój aplikacji, integrację danych, zarządzanie, oceny, pamięć i orchestrację modeli w jednym środowisku, umożliwiając firmom przechodzenie od szybkiego eksperymentowania z sztuczną inteligencją do systemów produkcyjnych z wymaganymi kontrolami i niezawodnością dla użycia przedsiębiorstw.

Spędziła Pani ponad 15 lat budując platformy dla deweloperów w firmach takich jak Google, eBay, Cloudflare i Docker, zanim założyła CodeSee, które później zostało przejęte przez GitKraken, a teraz kieruje Empromptu AI. Jak te doświadczenia ukształtowały Pani perspektywę na temat tego, dlaczego wiele narzędzi AI zawodzi, gdy opuszczają etap demonstracji, i jaki konkretny problem chciała Pani rozwiązać, zakładając Empromptu?

Jedną z rzeczy, które się uczymy, budując platformy dla deweloperów, jest to, że najtrudniejsze problemy nigdy nie są tymi, które występują w demonstracji. Demonstracja zawsze działa. Prawdziwy test to to, co się dzieje, gdy tysiące deweloperów używa systemu, gdy dane są nieładne, gdy integracje się łamią, a gdy prawdziwe firmy zależą od niego.

W Google, Cloudflare, Docker i eBay spędziłam lata pracując nad platformami, które musiały działać w skali globalnej. Te środowiska uczą nas czegoś szybko: niezawodność, zarządzanie i obserwowalność nie są funkcjami, które dodaje się później. Są one architekturą.

Gdy zaczęłam budować aplikacje oparte na sztucznej inteligencji, modele były okropne, a gdy zaczęły się poprawiać, zauważyłam, że branża powtarza ten sam błąd, jaki widzieliśmy we wcześniejszych falach oprogramowania. W narzędziach deweloperskich jest pojęcie, które wydaje się być zapomniane. Jak szybko można dostać się do “hello world”? Dziś wersja generatywna “hello world” to pełny, działający prototyp SaaS. Ale teraz nie tylko kodujemy aplikacje SaaS; kodujemy całe aplikacje oparte na sztucznej inteligencji. Sztuczna inteligencja, która buduje sztuczną inteligencję, wymaga innych systemów, aby umieścić tę sztuczną inteligencję w produkcji.

Można wygenerować działającą aplikację opartą na sztucznej inteligencji lub funkcję szybko, co jest ekscytujące i naprawdę przydatne. Ale dominujące systemy nadal brakuje infrastruktury potrzebnej do środowisk produkcyjnych. Rzeczy takie jak strukturalne potoki danych, ramy oceny, mechanizmy zarządzania, monitorowanie i zarządzanie kontekstem długoterminowym były pomijane, ale wprowadziliśmy je, zachowując przy tym wszystkie wspaniałe części kodowania wibrującego.

Gdy moja współzałożycielka i ja założyliśmy Empromptu, problem, który chcieliśmy rozwiązać, był prosty: jak zrobić aplikacje oparte na sztucznej inteligencji gotowe do produkcji od samego początku?

Zamiast traktować zarządzanie, gotowość danych, ocenę i optymalizację jako oddzielne narzędzia lub procesy po fakcie, zbudowaliśmy je bezpośrednio w platformie. Pomysł jest taki, że zespoły powinny być w stanie budować aplikacje oparte na sztucznej inteligencji szybko, ale z taką samą niezawodnością, jakością i kontrolą, jakich oczekują systemy oprogramowania przedsiębiorstw.

Była Pani otwarta o lukach między imponującymi demonstracjami AI a systemami gotowymi do produkcji. Z Pani perspektywy, jakie są najczęstsze błędy architektoniczne, które zespoły popełniają, próbując przekształcić prototyp AI w niezawodny produkt używany przez prawdziwych klientów?

Najczęstszym błędem, który popełniają zespoły, jest założenie, że model jest produktem.

W wczesnych prototypach model wykonuje większość widocznej pracy. Podajesz mu dane, on produkuje odpowiedź, a jeśli odpowiedź wygląda dobrze, system wydaje się działać. To tworzy iluzję, że poprawa modelu jest głównym wyzwaniem.

Ale w systemach produkcyjnych model jest tylko jednym z wielu elementów w o wiele większej architekturze.

Pierwszym błędem jest traktowanie danych jako rzeczy pobocznej. W prototypach zespoły często testują z małymi, czystymi zbiorami danych. Gdy system łączy się z prawdziwymi danymi operacyjnymi, wszystko zmienia się szybko. Dane przychodzą niepełne, niespójne, powtarzające się lub w nieoczekiwanych formatach. Bez strukturalnego potoku danych, który normalizuje i waliduje dane wejściowe, system staje się niezawodny, niezależnie od tego, jak dobry jest model.

Drugim błędem jest brak ram oceny. Wiele zespołów uruchamia funkcje AI bez określenia, co oznacza “dobry” wynik. Mogą one sprawdzić ręcznie dane wyjściowe podczas rozwoju, ale nie budują zautomatyzowanych potoków oceny, które ciągle mierzą dokładność, dryf i przypadki brzegowe, gdy system jest już uruchomiony. Bez tych barier, awarie są często odkrywane przez klientów, a nie przez inżynierów.

Trzecią kwestią jest brak mechanizmów zarządzania i kontroli. Systemy AI są probabilistyczne, co oznacza, że mogą zachowywać się inaczej w nieco innych warunkach. W regulowanych lub wysokostakowych środowiskach ta nieprzewidywalność musi być ograniczona za pomocą deterministycznych zasad, przepływów zatwierdzania i rejestrów, które rejestrują, jak podjęto decyzje.

To, co to naprawdę polega, to to, że systemy produkcyjne AI nie są tylko modelami. Są to systemy operacyjne.

Firmy, które odnoszą sukcesy z AI dzisiaj, są tymi, które traktują potoki danych, ocenę, zarządzanie i monitorowanie jako podstawową infrastrukturę, a nie opcjonalne dodatki.

Wiele platform kodowania AI obiecuje, że każdy może zbudować aplikację za pomocą prostych poleceń. Dlaczego te narzędzia często działają dobrze w demonstracjach, ale mają trudności, gdy firmy próbują wdrożyć je w środowiskach produkcyjnych?

Wiele z tych platform działa dobrze w demonstracjach, ponieważ są zoptymalizowane pod kątem momentu tworzenia, a nie całego cyklu życia systemu.

Ale jest fundamentalna różnica między używaniem AI do generowania strony docelowej a używaniem AI do budowania aplikacji opartej na sztucznej inteligencji.

Strona docelowa jest w większości oprogramowaniem statycznym. Gdy renduje się poprawnie, praca jest w zasadzie skończona. System nie musi podejmować probabilistycznych decyzji, nie musi pobierać stale zmieniających się danych ani dostosowywać się do nieprzewidywalnego zachowania użytkownika.

Aplikacje oparte na sztucznej inteligencji są zupełnie inne. Są to dynamiczne systemy, które polegają na potokach danych, zachowaniu modelu, ramach oceny i ciągłym monitorowaniu. Aplikacja musi zarządzać kontekstem, wykrywać, gdy dane wyjściowe dryfują, obsługiwać przypadki brzegowe i działać bezpiecznie, gdy model napotyka sytuacje, których nie widział wcześniej.

Większość narzędzi do kodowania opartego na poleceniach nie rozwiązuje tych warstw, ponieważ są one zaprojektowane, aby coś działać szybko. Generują kod, który produkuje widoczny wynik, co jest idealne dla środowiska demonstracyjnego. Ale systemy produkcyjne wymagają znacznie większego zestawu możliwości: strukturalne zarządzanie danymi, mechanizmy zarządzania, potoki oceny, obserwowalność i mechanizmy bezpiecznego aktualizowania zachowania w czasie.

Więc gdy firmy próbują wdrożyć te systemy w środowiskach produkcyjnych, luka staje się oczywista. Prototyp działał, ponieważ środowisko było kontrolowane. Produkcja jest brudna.

Empromptu koncentruje się na przekształcaniu istniejącego oprogramowania w systemy rodzime AI, zamiast zmuszania firm do odbudowywania wszystkiego od podstaw. Co takie przekształcenie naprawdę obejmuje na poziomie infrastruktury i produktu?

Na poziomie produktu każda aplikacja jest w pełni samodzielna i konteneryzowana. Tworzymy wszystko, co potrzebne, od front-endów, back-endów, baz danych, modeli, ocen, reguł i wszystko jest super elastyczne, w zależności od potrzeb przedsiębiorstwa.

Mamy kilka różnych opcji dla aplikacji AI:

“Bezgłowy”, jeśli klient już ma front-end, możemy połączyć go z naszym systemem i odesłać dane z powrotem

W pełni konteneryzowany, więc mogą być wdrożone na naszej infrastrukturze lub w infrastrukturze klienta, więc są domyślnie na-prem.

Lub możemy je po prostu wygenerować i wdrożyć bezpośrednio w chmurze, dla najwygodniejszej opcji.

Jeśli mają jakiś kod, możemy go bezpośrednio zaimportować do naszego systemu i uczynić go agentem, jeśli nie jest już agentem. Widzimy to u wielu klientów, którzy próbowali zbudować swoje aplikacje na popularnych platformach, takich jak Lovable, Replit, Bolt lub Base44. Często one nie działają. Ale klienci już zainwestowali wiele czasu i energii w tę aplikację, więc importujemy ją, przepisujemy i sprawiamy, aby wszystko działało na AI.

I możemy to robić, ponieważ mamy kilka niestandardowych, własnych technologii, takich jak:

• Adaptacyjny silnik kontekstowy do zarządzania kontekstem
• Nieskończona pamięć do pobierania długotrwałych aplikacji
• Niestandardowe modele danych i potoki danych złota, aby upewnić się, że możemy obsłużyć każde czyszczenie danych i etykietowanie syntetyczne, które jest wymagane

Państwa platforma podkreśla kontekst, ocenę, zarządzanie i strukturalne dane jako podstawowe składniki systemów AI. Dlaczego te elementy są tak często pomijane, gdy zespoły spieszą się, aby dodać funkcje AI do swoich produktów?

Ponieważ są one trudne do zrobienia! Mój współzałożyciel, Dr Sean Robinson, kieruje naszym laboratorium badawczym i jest astrofizykiem komputacyjnym, który wynalazł wiele technologii inspirowanych moimi szalonymi pomysłami, ale także potrzebami naszych klientów i tym, gdzie zmierza rynek. Nasze połączone doświadczenie w budowaniu wielu aplikacji agentywnych, umieszczaniu satelitów w przestrzeni i budowaniu w największych firmach technologicznych na świecie daje nam wgląd, który pomaga nam rozwiązywać skomplikowane problemy lepiej niż inni.

Pracuje Pani z wieloma założycielami, którzy nigdy nie pisali kodu. Jakie są największe złudzenia, które nie-techniczni założyciele mają, gdy po raz pierwszy próbują zbudować aplikacje oparte na sztucznej inteligencji?

Myślę, że są dwie duże złudzenia:

Pierwsze to to, że AI jest magią. AI nie jest magią. To po prostu dobre inżynierowanie. I w końcu osiągasz limit tego, co możesz zrobić na tych platformach bez prawdziwego inżyniera.

Drugie to to, że mają doskonałe umiejętności techniczne w zarządzaniu produktem. Mam doświadczenie w technicznym zarządzaniu produktem i umiejętność tłumaczenia wizji, czasem bardzo dużej wizji, na małe, dostarczalne fragmenty z odpowiednim technicznym określeniem, aby określić dokładnie, co się chce. To jest naprawdę trudna umiejętność, która wymaga czasu.

Na przykład, jeśli budujesz aplikację, która uploaduje plik PDF i zapisuje ten plik PDF, aby móc do niego wrócić później, to jest pojęcie zwane trwałością. Ten plik PDF jest zakodowany w kod i zapisany do bazy danych.

Ale jeśli nie wiesz, że to nazywa się trwałością, jak będziesz w stanie to napisać? Upewnij się, że te dane są trwałe. Wybór słów technicznych jest jak mówienie w innym języku. Jest różnica między pisanym w języku naturalnym a pisanym w języku technicznym.

Wiele startupów zakłada, że rozwiązaniem budowy produktów AI jest po prostu zatrudnienie większej liczby inżynierów. Dlaczego uważa Pani, że taki podejście często zawodzi, i co powinni myśleć założyciele, gdy budują produkty oparte na sztucznej inteligencji?

Zatrudnienie większej liczby inżynierów jest czasem odpowiedzią. Jeśli budujesz głęboko techniczny produkt lub pracujesz na granicy badań modelu, absolutnie potrzebujesz silnych zespołów inżynierskich. Nie ma substytutu dla dobrych inżynierów, gdy chodzi o rozwiązywanie trudnych problemów.

Ale błąd, który popełnia wiele startupów, to założenie, że więcej inżynierów automatycznie rozwiązuje wyzwanie budowy produktu AI.

W rzeczywistości najtrudniejsze problemy w produktach AI często nie są czysto inżynierskimi problemami. Są to problemy systemowe, tak jak każdy inny problem inżynierski. Inżynierowie są specjalnie nauczani, aby myśleć w systemach. Ale rozwój generatywny jest inny niż rozwój deterministyczny. Wielu z nas zrobiło ten przełom, gdy przechodziliśmy od programowania obiektowego do programowania funkcyjnego. Czy to programowanie? Tak, absolutnie, ale czy to inny sposób myślenia? Tak, oczywiście.

Aplikacje oparte na sztucznej inteligencji znajdują się na przecięciu danych, projektu produktu, przepływów operacyjnych i zachowania modelu. Możesz zatrudnić niesamowity zespół inżynierów, ale jeśli potoki danych są niezawodne, kryteria oceny są niejasne lub system brakuje zarządzania i monitorowania, produkt będzie nadal miał trudności, gdy dotrze do prawdziwych użytkowników.

Inny problem polega na tym, że wiele zespołów skacze prosto do budowy, zanim zdefiniują, jak system AI będzie się zachowywał w produkcji. Pytania, takie jak jak system będzie oceniany, jak będą obsługiwane przypadki brzegowe, jak decyzje będą rejestrowane, a jak modele będą aktualizowane w czasie, często pojawiają się znacznie później. Wtedy architektura jest już trudna do zmiany.

Co założyciele powinni naprawdę myśleć, to model operacyjny ich systemu AI.

Kto jest odpowiedzialny za potok danych?

Jak jest mierzona wydajność modelu w sposób ciągły, a nie tylko podczas rozwoju?

Co się dzieje, gdy system napotyka sytuację, której nie widział wcześniej?

Jak aktualizować zachowanie w sposób bezpieczny, nie łamiąc przepływów podrzędnych?

Czasem rozwiązywanie tych problemów oznacza zatrudnienie większej liczby inżynierów. Ale może to również oznaczać wybór odpowiedniej infrastruktury, określenie silnych ograniczeń produktu i budowanie systemów, które pozwalają małym zespołom działać niezawodnie w skali.

Firmy, które odnoszą sukcesy z AI dzisiaj, nie są koniecznie tymi, które mają największe zespoły inżynierskie. Są to te, które traktują AI jako długotrwały system, który potrzebuje dyscypliny danych, oceny, zarządzania i ciągłej poprawy, wbudowanej od samego początku.

Uważa Pani, że niektóre z obecnych modeli biznesowych w narzędziach deweloperskich AI nie są zgodne z budowaniem trwałych produktów. Jakie zachęty w obecnym ekosystemie narzędzi AI prowadzą firmy w złym kierunku?

Jednym z największych niezgodności zachęt jest to, że wiele narzędzi deweloperskich AI jest zoptymalizowanych pod kątem wskaźników wzrostu, a nie trwałości produktu.

Wiele firm w tym sektorze jest nagradzanych za to, jak szybko użytkownicy mogą stworzyć coś imponującego. Jeśli narzędzie może wygenerować działającą aplikację, funkcję lub demonstrację w kilka minut, to napędza rejestracje, udostępnianie w mediach społecznościowych i entuzjazm inwestorów. Z punktu widzenia adopcji produktu to ma sens.

Ale te zachęty często kończą się w momencie tworzenia.

Trudniejsza praca w oprogramowaniu AI następuje po tym punkcie. To jest moment, gdy buduje się zaufanie. Gdy można polegać na jakości. Gdy użytkownik chce wrócić ponownie i ponownie, bez frustracji AI z powodu złych wyników. Musi dostarczać dobre odpowiedzi, nawet w obliczu ludzkiej ignorancji lub złośliwości.

Inny problem polega na tym, że wiele narzędzi jest zoptymalizowanych pod kątem generowania kodu, a nie projektowania systemu. Generowanie kodu szybko jest pomocne, ale budowanie produktu AI obejmuje więcej niż produkcję kodu. Wymaga określenia, jak system zarządza kontekstem, jak decyzje są oceniane, jak awarie są obsługiwane i jak zachowanie ewoluuje w sposób bezpieczny w czasie.

Firmy, które dopasowują swoje zachęty do pomocy klientom w uruchamianiu systemów AI w sposób niezawodny, a nie tylko w budowaniu ich szybko, są tymi, które będą tworzyć trwałą wartość w tym ekosystemie.

Niektórzy z Państwa klientów to przedsiębiorcy budujący bardzo specyficzne produkty, takie jak specjalistyczne narzędzia zdrowotne lub biznesy zorientowane na zrównoważony rozwój, często bez tradycyjnych zespołów inżynierskich. Jakie wzorce widzi Pani wśród założycieli, którzy udaje się przekształcić te pomysły w działające produkty AI?

Jednym z najbardziej interesujących wzorców, które widzimy, jest to, że założyciele, którzy odnoszą sukces, niekoniecznie są najbardziej techniczni. Są tymi, którzy rozumieją problem, który rozwiązują, niezwykle dobrze.

Wielu z naszych klientów to eksperci branżowi. Mogą pochodzić z opieki zdrowotnej, finansów, zrównoważonego rozwoju lub innej specjalistycznej branży. To, co przynoszą, to głęboka wiedza o przepływach pracy, regulacjach i decyzjach, które istnieją w tym środowisku. Ten kontekst jest niezwykle cenny przy projektowaniu produktu AI, ponieważ definiuje, co system naprawdę musi robić.

Założyciele, którzy odnoszą sukces, tendencję mają podejść do AI bardziej jak do systemu produktu, a nie jak do eksperymentu technologicznego. Zaczynają od zadawania bardzo konkretnych pytań. Jakie decyzje powinna pomóc AI podjąć użytkownikom? Jakie źródła danych są potrzebne? Co jest poprawną odpowiedzią w tej dziedzinie? Jakie barierki muszą istnieć, aby system zachowywał się odpowiedzialnie?

Inny wzorzec to to, że myślą starannie o strukturze. Zespoły, które odnoszą sukces, szybko zdają sobie sprawę, że dane wyjściowe AI są tylko tak dobre, jak kontekst i dane, które je karmią. Inwestują czas na początku w definiowanie potoków danych, organizowanie źródeł wiedzy i tworzenie jasnych kryteriów oceny, co oznacza “dobry” wynik.

Widzimy również, że założyciele, którzy odnoszą sukces, przyjmują współpracę człowiek-AI zamiast próbować automatyzować wszystko od razu. Projektują przepływy pracy, w których AI obsługuje powtarzalną analizę lub syntezę danych, a ludzie pozostają odpowiedzialni za osąd i ostateczne decyzje. To równowaga sprawia, że systemy są o wiele bardziej niezawodne, zwłaszcza w dziedzinach takich jak opieka zdrowotna lub finanse.

W wielu ways, największa zmiana to nastawienie. Założyciele, którzy odnoszą sukces, nie myślą o AI jako o funkcji, którą dodają. Myślą o niej jako o nowej warstwie operacyjnej, jak działa ich produkt.

Gdy systemy AI stają się coraz bardziej zintegrowane z podstawowymi operacjami biznesowymi, jakie możliwości będą definiować następną generację platform aplikacji AI?

Wiemy, że to jest szalone i możemy mówić coś świętokradzkiego, ale ludzie będą w stanie wibrująco zakodować własne niestandardowe modele. Coś, co nasze laboratorium badawcze nazywa modelami nano-ekspertów, pomoże kontrolować koszty.

Dziękujemy za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Empromptu AI.