Shanea Leven, grundare och VD på Empromptu AI – Intervjuerien

Shanea Leven, grundare och VD på Empromptu AI, är en erfaren produktledare med omfattande erfarenhet av att bygga utvecklarplattformar och AI-drivna produkter på stora teknikföretag. Innan hon lanserade Empromptu 2025 grundade hon CodeSee, en AI-utvecklarplattform som hjälper team att visualisera och förstå komplexa kodbas, som förvärvades av GitKraken 2024. Tidigare i sin karriär hade hon seniora produktledarroller på företag som Docker, Cloudflare, eBay och Google, där hon arbetade med initiativ som sträckte sig från Google Assistant-betalnings-API till utvecklarutbildningsprogram som användes av hundratusentals lärande.

Empromptu AI är en företagsplattform som är utformad för att hjälpa organisationer att bygga och distribuera integrerade AI-applikationer mer lätt. Plattformen kombinerar applikationsutveckling, dataintegrering, styrning, utvärdering, minne och modellorkestrering i en enda miljö, vilket möjliggör för företag att gå från snabb AI-experiment till produktionsklara system med de kontroller och tillförlitlighet som krävs för företagsanvändning.

Du har tillbringat över 15 år med att bygga utvecklarplattformar på företag som Google, eBay, Cloudflare och Docker innan du grundade CodeSee, som senare förvärvades av GitKraken, och nu leder Empromptu AI. Hur har dessa erfarenheter format din syn på varför så många AI-verktyg misslyckas när de lämnar demo-stadiet, och vilket specifikt problem var du fast besluten att lösa när du grundade Empromptu?

En av de saker man lär sig när man bygger utvecklarplattformar är att de svåraste problemen aldrig är de som finns i demo. Demo fungerar alltid. Den riktiga utmaningen är vad som händer när tusentals utvecklare använder systemet, när data är smutsig, när integrationer bryts och när riktiga företag är beroende av det.

På Google, Cloudflare, Docker och eBay tillbringade jag år med att arbeta på plattformar som måste fungera på global skala. Dessa miljöer lär dig något snabbt: tillförlitlighet, styrning och övervakning är inte funktioner som du lägger till senare. De är arkitekturen.

När jag började bygga AI-applikationer var modellerna hemskt dåliga och när de började bli bättre märkte jag att branschen upprepade samma misstag som vi såg i tidigare vågor av programvara. I utvecklarverktyg finns det ett koncept som tycks ha glömts bort. Hur snabbt kan du komma till “Hej världen”? Idag är den generativa versionen av “Hej världen” en fullt fungerande SaaS-prototyp. Men vi känner inte bara “vibe code” SaaS-applikationer; vi känner “vibe code” hela AI-applikationer. En AI som bygger AI kräver andra system för att sätta den AI i produktion.

Du kan generera en fungerande AI-applikation eller funktion snabbt, vilket är spännande och genuint användbart. Men de dominerande systemen saknar fortfarande den infrastruktur som behövs för produktionsmiljöer. Saker som strukturerade data-pipelines, utvärderingsramverk, styrningskontroller, övervakning och långsiktig kontext hantering missades men vi har lagt till dem medan vi behållit alla de fantastiska delarna av “vibe coding”.

När min medgrundare och jag grundade Empromptu var problemet vi ville lösa enkelt: hur kan vi göra AI-applikationer produktionsklara från början?

Istället för att behandla styrning, databeredskap, utvärdering och optimering som separata verktyg eller efterföljande processer byggde vi dem direkt in i plattformen. Idén är att team ska kunna bygga AI-applikationer snabbt, men med samma tillförlitlighet, kvalitet och kontroll som de förväntar sig från företagssystem.

Du har varit öppen om gapet mellan imponerande AI-demon och produktionsklara system. Från din synvinkel, vad är de vanligaste arkitektoniska misstagen som team gör när de försöker vända en AI-prototyp till en tillförlitlig produkt som används av riktiga kunder?

Det vanligaste misstaget som team gör är att anta att modellen är produkten.

I tidiga prototyper gör modellen det mesta av det synliga arbetet. Du promptar den, den producerar ett svar och om svaret ser bra ut verkar systemet fungera. Det skapar illusionen att att förbättra modellen är den största utmaningen.

Men i produktions-system är modellen bara en komponent i en mycket större arkitektur.

Det första misstaget är att behandla data som en eftertanke. I prototyper testar team ofta med små, rena dataset. När systemet ansluter till riktiga operativa data förändras saker snabbt. Data anländer ofullständig, inkonsekvent, dubblerad eller i oväntade format. Utan en strukturerad data-pipeline för att normalisera och validera indata blir systemet otillförlitligt oavsett hur bra modellen är.

Det andra misstaget är avsaknaden av utvärderingsramverk. Många team lanserar AI-funktioner utan att definiera vad “bra” faktiskt betyder. De kan manuellt kontrollera utdata under utveckling, men de bygger inte automatiserade utvärderings-pipelines som kontinuerligt mäter noggrannhet, drift och kantfall när systemet är live. Utan dessa skyddsräcken upptäcks fel ofta av kunder istället för ingenjörer.

En tredje fråga är bristen på styrnings- och kontrollmekanismer. AI-system är probabilistiska, vilket betyder att de kan bete sig annorlunda under något olika förhållanden. I reglerade eller högrisk-miljöer måste den osäkerheten begränsas med deterministiska policys, godkännandeflöden och revisionsloggar som fångar hur beslut fattades.

Detta handlar egentligen om att produktions-AI-system inte bara är modeller. De är operativa system.

De företag som lyckas med AI idag är de som behandlar data-pipelines, utvärdering, styrning och övervakning som kärninfrastruktur, inte valfria tillägg.

Många AI-kodningsplattformar lovar att vem som helst kan bygga en applikation med enkla prompter. Varför fungerar dessa verktyg ofta bra för demonstrationer men kämpar när företag försöker distribuera dem i riktiga produktionsmiljöer?

Många av dessa plattformar fungerar bra för demonstrationer eftersom de är optimerade för skapelseögonblicket, inte livscykeln för ett riktigt system.

Men det finns en grundläggande skillnad mellan att använda AI för att generera en landningssida och att använda AI för att bygga en AI-applikation.

En landningssida är i huvudsak statisk programvara. När den renderas korrekt är jobbet i stort sett klart. Systemet behöver inte fatta probabilistiska beslut, ta in konstant föränderlig data eller anpassa sig till oförutsägbar användarbetende.

AI-applikationer är helt annorlunda. De är dynamiska system som förlitar sig på data-pipelines, modellbeteende, utvärderingsramverk och kontinuerlig övervakning. Applikationen måste hantera kontext, upptäcka när utdata förskjuts, hantera kantfall och fungera säkert när modellen möter situationer den inte har sett förut.

De flesta prompt-drivna kodningsverktyg hanterar inte dessa lager eftersom de är utformade för att få något att fungera snabbt. De genererar kod som producerar ett synligt resultat, vilket är perfekt för en demo-miljö. Men produktions-system kräver en mycket större uppsättning funktioner: strukturerad data-hantering, styrningskontroller, utvärderings-pipelines, övervakning och mekanismer för att säkert uppdatera beteende över tid.

Så när företag försöker distribuera dessa system i riktiga miljöer blir gapet uppenbart. Prototypen fungerade eftersom miljön var kontrollerad. Produktion är smutsig.

Empromptu fokuserar på att omvandla befintlig programvara till AI-nativa system snarare än att tvinga företag att bygga allt från scratch. Vad innebär den här omvandlingen egentligen på infrastruktur- och produkt-nivå?

På produkt-nivå är varje applikation helt självinnehållande och containeriserad. Vi skapar allt som behövs, från front-end, back-end, databaser, modeller, utvärderingar, LLM-åtgärder och regler, och allt är super flexibelt beroende på företagets behov.

Vi har flera olika alternativ för AI-applikationer:

“Headless” så att om en kund redan har en front-end kan vi ansluta den till vårt system och skicka tillbaka data

Fullyt containeriserad så att de kan distribueras på vår infrastruktur eller inom kundens infrastruktur, så att de är on-prem som standard.

Eller så kan vi generera dem och distribuera dem direkt till molnet för det mest bekväma alternativet.

Om de har kod kan vi importera den direkt till vårt system och “agentisera” den om den inte redan är “agentiserad”. Till exempel ser vi detta med många kunder som har försökt bygga sina appar på populära plattformar som Lovable, Replit, Bolt eller Base44. Ofta fungerar de inte. Men kunderna har redan investerat mycket tid och energi och krediter i den här applikationen, så vi tar in den, skriver om den och ser till att all AI-funktionalitet fungerar.

Och vi kan göra detta eftersom vi har flera anpassade, proprietära teknologier, såsom:

• Anpassningsbar kontext-motor för att hantera kontext
• Oändligt minne för att ta in långvariga kod-applikationer
• Anpassade data-modeller och “gulda” data-pipelines för att säkerställa att vi kan hantera all data-rening och syntetisk märkning som krävs

Er plattform betonar kontext, utvärdering, styrning och strukturerad data som kärnkomponenter i AI-system. Varför försummas dessa element så ofta när team skyndar sig att lägga till AI-funktioner i sina produkter?

För att de är svåra att göra! Min medgrundare, Dr. Sean Robinson, leder vår forskningsavdelning, och han är en beräknings-astrofysiker som har uppfunnit flera teknologier inspirerade av mina “tokiga” idéer, men också av våra kunders behov och var marknaden är på väg. Vår kombinerade erfarenhet av att bygga många agenter-applikationer, sätta satelliter i rymden och bygga på de största teknikföretagen i världen ger oss insikter som hjälper oss att lösa komplicerade problem bättre än andra kan.

Arbetar du med många grundare som aldrig har skrivit kod tidigare. Vad är de största missuppfattningarna som icke-tekniska grundare har när de först försöker bygga AI-applikationer?

Jag tror att det finns två stora missuppfattningar:

Den första är att AI är magi. AI är inte magi. Det är bara bra ingenjörskap. Och så småningom når du en gräns för vad du kan göra på dessa plattformar utan en riktig ingenjör.

Den andra är att de har utmärkta tekniska produktledningsfärdigheter. Jag har en bakgrund inom teknisk produktledning och färdigheten att översätta en vision, ibland en mycket stor vision, ner till små levererbara bitar med rätt teknisk specifikation för att artikulera exakt vad du vill ha. Det är faktiskt en mycket svår färdighet som tar tid.

Till exempel, låt säga att du bygger en app som laddar upp en PDF och sparar den PDF så att du kan komma tillbaka och visa den senare. Det är ett koncept som kallas persistence. Den där PDF:en kodas till kod och sparas till en databas.

Men om du inte visste att det kallades persistence, hur ska du kunna skriva? Se till att den här datan består. Tekniskt ordval är som att tala ett annat språk. Det finns en skillnad mellan att skriva på naturligt språk och att skriva på tekniskt språk.

Många startups antar att lösningen på att bygga AI-produkter är att anställa fler ingenjörer. Varför tror du att den här strategin ofta misslyckas, och vad bör grundare tänka på istället när de bygger AI-drivna produkter?

Att anställa fler ingenjörer är ibland rätt svaret. Om du bygger ett djupt tekniskt produkt eller arbetar på gränsen för modellforskning behöver du absolut starka ingenjörsteam. Det finns inget substitut för bra ingenjörer när det gäller att lösa svåra problem.

Men misstaget som många startups gör är att anta att fler ingenjörer automatiskt löser utmaningen att bygga en AI-produkt.

I verkligheten är de svåraste problemen i AI-produkter ofta inte rent tekniska problem. De är systemproblem, precis som alla andra ingenjörsproblem. Ingenjörer är specifikt utbildade för att tänka i system. Men generativ utveckling är annorlunda än deterministisk utveckling. Många av oss gjorde den här förändringen när vi gick från objektorienterad programmering till funktionsprogrammering. Är de båda programmering? Ja, absolut, men är de olika? Är de ett annat sätt att tänka? Ja, självklart.

AI-applikationer befinner sig i skärningspunkten mellan data, produkt-design, operativa arbetsflöden och modellbeteende. Du kan anställa ett otroligt team av ingenjörer, men om data-pipelines är otillförlitliga, utvärderingskriterierna är oklara eller systemet saknar styrning och övervakning, kommer produkten fortfarande att kämpa när den når riktiga användare.

En annan fråga är att många team hoppar rakt in i byggandet innan de har definierat hur AI-systemet ska bete sig i produktion. Frågor som hur systemet ska utvärderas, hur kantfall ska hanteras, hur beslut ska loggas och hur modeller ska uppdateras över tid kommer ofta mycket senare. Då är arkitekturen redan svår att ändra.

Vad grundare verkligen bör tänka på är den operativa modellen för sitt AI-system.

Vem äger data-pipelinen?

Hur mäts modellprestanda kontinuerligt, inte bara under utveckling?

Vad händer när systemet möter en situation det inte har sett förut?

Hur uppdaterar du beteende säkert utan att bryta nedströms arbetsflöden?

Ibland innebär att lösa dessa problem att anställa fler ingenjörer. Men det kan också innebära att välja rätt infrastruktur, definiera starka produktbegränsningar och bygga system som tillåter små team att operera tillförlitligt i stor skala.

De företag som lyckas med AI idag är inte nödvändigtvis de som har de största ingenjörsteamen. De är de som behandlar AI som ett långvarigt system som behöver data-disciplin, utvärdering, styrning och kontinuerlig förbättring byggt in från början.

Du har hävdat att vissa av de nuvarande affärsmodellerna i AI-utvecklarverktyg inte är i linje med att bygga hållbara produkter. Vilka incitament i den nuvarande AI-verktygs-ekosystemet tror du leder företag i fel riktning?

En av de största incitaments-missmatchningarna just nu är att många AI-utvecklarverktyg är optimerade för tillväxt-mått snarare än produkt-hållbarhet.

Många företag i det här området belönas för hur snabbt användare kan skapa något imponerande. Om ett verktyg kan generera en fungerande app, en funktion eller en demo på några minuter, driver det registreringar, social delning och investerar-upphetsning. Från ett produktsynsätt är det meningsfullt.

Men dessa incitament slutar ofta vid skapelse-ögonblicket.

Det svårare arbetet i AI-programvara sker efter det ögonblicket. Det är när förtroende byggs. När du kan lita på kvalitet. Att användaren vill komma tillbaka igen och igen utan AI-frustrationen av dålig utdata. Behöver ge bra svar även i ansiktet av mänsklig okunskap eller illvillighet.

En annan fråga är att många verktyg är optimerade för kod-generering snarare än system-design. Att generera kod snabbt är användbart, men att bygga en AI-produkt innebär mer än att producera kod. Det kräver att definiera hur systemet hanterar kontext, hur beslut utvärderas, hur fel hanteras och hur beteende utvecklas säkert över tid.

De företag som anpassar sina incitament kring att hjälpa kunder att köra AI-system tillförlitligt, snarare än att bygga dem snabbt, är de som kommer att skapa varaktigt värde i det här ekosystemet.

Några av dina kunder inkluderar entreprenörer som bygger mycket specifika produkter, såsom specialiserade hälsoverktyg eller hållbarhets-fokuserade företag, ofta utan traditionella ingenjörsteam. Vilka mönster har du sett bland grundarna som lyckas vända dessa idéer till fungerande AI-produkter?

En av de mest intressanta mönstren vi ser är att de grundare som lyckas inte nödvändigtvis är de mest tekniska. De är de som förstår problemet de löser extremt väl.

Många av entreprenörerna som använder Empromptu är branschexperter. De kan komma från hälsovård, finans, hållbarhet eller en annan specialiserad bransch. Vad de bidrar med är djup kunskap om arbetsflöden, regler och beslut som finns i den miljön. Den kontexten är otroligt värdefull när du designar en AI-produkt eftersom den definierar vad systemet faktiskt behöver göra.

De grundare som lyckas tenderar att närma sig AI mer som ett produktsystem snarare än en teknisk experiment. De börjar med att ställa mycket konkreta frågor. Vilka beslut ska AI hjälpa användare med? Vilka datakällor behöver den komma åt? Vad ser ett korrekt svar ut som i den här branschen? Vilka skyddsräcken behöver finnas för att systemet ska bete sig ansvarsfullt?

En annan mönster är att de tänker noga på struktur. Lyckade team inser snabbt att AI-utdata är bara så bra som kontexten och data som matar dem. De investerar tid i förväg för att definiera data-pipelines, organisera kunskapskällor och skapa tydliga utvärderingskriterier för vad “bra” betyder.

Vi ser också lyckade grundare som omfamnar mänsklig-AI-samarbete snarare än att försöka automatisera allt direkt. De designar arbetsflöden där AI hanterar repetitiv analys eller data-syntes, medan människor förblir ansvariga för bedömning och slutliga beslut. Den balansen gör systemen mycket mer tillförlitliga, särskilt inom områden som hälsovård eller finans.

På många sätt är den största förändringen en förändring av synsätt. De grundare som lyckas ser inte AI som en funktion de lägger till. De ser det som ett nytt operativt lager för hur deras produkt fungerar.

När AI-system blir mer integrerade i kärn-verksamhetsprocesser, vilka funktioner kommer att definiera nästa generation av AI-applikationsplattformar?

Jag vet att detta är galet och jag kanske säger något som är kätterskt, men människor kommer att kunna “vibe-code” sina egna anpassade modeller. Något som vår forskningsavdelning kallar expert nano-modeller kommer att hjälpa till att kontrollera kostnader.

Tack för den underbara intervjun, läsare som vill lära sig mer kan besöka Empromptu AI.