Shanea Leven, Oprichter en CEO bij Empromptu AI – Interviewreeks

Shanea Leven, Oprichter en CEO bij Empromptu AI, is een ervaren productleider met uitgebreide ervaring in het bouwen van ontwikkelaarsplatforms en AI-gedreven producten bij grote technologiebedrijven. Voordat ze Empromptu in 2025 lanceerde, richtte ze CodeSee op, een AI-ontwikkelaarsplatform dat teams helpt om complexe codebases te visualiseren en te begrijpen, dat in 2024 door GitKraken werd overgenomen. Eerder in haar carrière had ze senior productleiderschapsrollen bij bedrijven zoals Docker, Cloudflare, eBay en Google (GOOGL ), waar ze werkte aan initiatieven die variëren van Google Assistant-betaling-API’s tot ontwikkelaarseducatieprogramma’s die door honderdduizenden leerlingen worden gebruikt.

Empromptu AI is een ondernemingsplatform dat bedrijven helpt om geïntegreerde AI-toepassingen gemakkelijker te bouwen en te implementeren. Het platform combineert applicatieontwikkeling, gegevensintegratie, governance, evaluaties, geheugen en modelorkestratie in een enkele omgeving, waardoor bedrijven kunnen overstappen van snelle AI-experimenten naar productieklare systemen met de benodigde controles en betrouwbaarheid voor ondernemingsgebruik.

U heeft meer dan 15 jaar ontwikkelaarsplatforms gebouwd bij bedrijven als Google, eBay, Cloudflare en Docker voordat u CodeSee oprichtte, dat later door GitKraken werd overgenomen, en nu Empromptu AI leidt. Hoe hebben die ervaringen uw perspectief gevormd op waarom zo veel AI-hulpmiddelen falen zodra ze de demofase verlaten, en welk specifiek probleem was u vastbesloten om op te lossen toen u Empromptu oprichtte?

Een van de dingen die u leert bij het bouwen van ontwikkelaarsplatforms, is dat de moeilijkste problemen nooit degenen in de demo zijn. De demo werkt altijd. De echte test is wat er gebeurt wanneer duizenden ontwikkelaars het systeem gebruiken, wanneer de gegevens rommelig zijn, wanneer de integraties breken en wanneer echte bedrijven ervan afhankelijk zijn.

Bij Google, Cloudflare, Docker en eBay heb ik jaren gewerkt aan platforms die op mondiaal niveau moesten functioneren. Die omgevingen leren u snel dat betrouwbaarheid, governance en observatie niet functies zijn die u later toevoegt. Ze zijn de architectuur.

Toen ik begon met het bouwen van AI-toepassingen, waren de modellen verschrikkelijk en toen ze begonnen te verbeteren, merkte ik dat de industrie dezelfde fout maakte die we in eerdere golven van software zagen. In ontwikkelaarstools is er een concept dat leek te zijn vergeten. Hoe snel kunt u “hallo wereld” krijgen? Vandaag is de generatieve versie van “hallo wereld” een volledig werkend SaaS-prototype. Maar we coderen nu niet alleen SaaS-toepassingen; we coderen complete AI-toepassingen. Een AI die AI bouwt, vereist andere systemen om die AI in productie te brengen.

U kunt een werkende AI-toepassing of -functie snel genereren, wat spannend en echt nuttig is. Maar de meeste systemen ontbreken nog steeds aan de infrastructuur die nodig is voor productieomgevingen. Dingen zoals gestructureerde datapipelines, evaluatiekaders, governancecontroles, monitoring en langetermijncontextbeheer werden gemist, maar we hebben ze toegevoegd terwijl we alle geweldige aspecten van vibe-coding behouden.

Toen mijn mede-oprichter en ik Empromptu oprichtten, was het probleem dat we wilden oplossen eenvoudig: hoe maken we AI-toepassingen vanaf het begin productieklaar?

In plaats van governance, gegevensgereedheid, evaluatie en optimalisatie als afzonderlijke tools of nasleepprocessen te behandelen, hebben we ze rechtstreeks in het platform ingebouwd. Het idee is dat teams AI-toepassingen snel moeten kunnen bouwen, maar met dezelfde betrouwbaarheid, kwaliteit en controle die ze van ondernemingssystemen verwachten.

U bent openhartig over de kloof tussen indrukwekkende AI-demos en productieklare systemen. Vanuit uw perspectief, wat zijn de meest voorkomende architectonische fouten die teams maken wanneer ze proberen een AI-prototype om te zetten in een betrouwbaar product dat door echte klanten wordt gebruikt?

De meest voorkomende fout die teams maken, is ervan uitgaan dat het model het product is.

Bij vroege prototypes doet het model het meeste zichtbare werk. U geeft het een prompt, het produceert een antwoord en als het antwoord er goed uitziet, lijkt het systeem te werken. Dat creëert de illusie dat het verbeteren van het model de belangrijkste uitdaging is.

Maar in productiesystemen is het model slechts één onderdeel in een veel grotere architectuur.

De eerste fout is het behandelen van gegevens als een afterthought. In prototypes testen teams vaak met kleine, schone datasets. Zodra het systeem verbinding maakt met echte operationele gegevens, verandert alles snel. Gegevens komen onvolledig, onconsistent, gedupliceerd of in onverwachte formaten binnen. Zonder een gestructureerde datapipeline om invoer te normaliseren en te valideren, wordt het systeem onbetrouwbaar, ongeacht hoe goed het model is.

De tweede fout is het ontbreken van evaluatiekaders. Veel teams lanceren AI-functies zonder te definiëren wat “goed” eigenlijk betekent. Ze kunnen handmatig output controleren tijdens de ontwikkeling, maar ze bouwen geen geautomatiseerde evaluatiepijpleidingen die continu de nauwkeurigheid, drift en randgevallen meten zodra het systeem live is. Zonder die railingen worden fouten vaak door klanten ontdekt in plaats van door ingenieurs.

Een derde probleem is het ontbreken van governance- en controlemechanismen. AI-systemen zijn probabilistisch, wat betekent dat ze onder licht verschillende omstandigheden anders kunnen gedragen. In gereguleerde of hoge-inzetomgevingen moet die onvoorspelbaarheid worden beperkt met deterministische beleidsregels, goedkeuringsworkflows en auditlogs die vastleggen hoe beslissingen werden genomen.

Dit komt eigenlijk neer op het feit dat productie-AI-systemen niet alleen modellen zijn. Ze zijn operationele systemen.

De bedrijven die vandaag succesvol zijn met AI, zijn degenen die datapipelines, evaluatie, governance en monitoring behandelen als core-infrastructuur, niet als optionele add-ons.

Veel AI-coderingsplatforms beloven dat iedereen een toepassing kan bouwen met eenvoudige prompts. Waarom werken deze tools vaak goed voor demonstraties, maar worstelen ze eenmaal bedrijven proberen ze in echte productieomgevingen te implementeren?

Veel van deze platforms werken goed voor demonstraties omdat ze zijn geoptimaliseerd voor het moment van creatie, niet voor de levensduur van een echt systeem.

Maar er is een fundamenteel verschil tussen het gebruik van AI om een landingspagina te genereren en het gebruik van AI om een AI-toepassing te bouwen.

Een landingspagina is meestal statische software. Zodra deze correct wordt weergegeven, is de taak grotendeels voltooid. Het systeem hoeft geen probabilistische beslissingen te nemen, geen constant veranderende gegevens te verwerken of zich aan te passen aan onvoorspelbaar gebruikersgedrag.

AI-toepassingen zijn compleet anders. Ze zijn dynamische systemen die afhankelijk zijn van datapipelines, modelgedrag, evaluatiekaders en continue monitoring. De toepassing moet context beheren, detecteren wanneer output afwijkt, randgevallen afhandelen en veilig opereren wanneer het model situaties tegenkomt die het nog nooit eerder heeft gezien.

De meeste prompt-gedreven coderingstools lossen deze lagen niet op omdat ze zijn ontworpen om snel iets werkends te krijgen. Ze genereren code die een zichtbaar resultaat produceert, wat perfect is voor een demomilieu. Maar productiesystemen vereisen een veel grotere set mogelijkheden: gestructureerde dataprocessing, governancecontroles, evaluatiepijpleidingen, observatie en mechanismen voor het veilig bijwerken van gedrag in de loop van de tijd.

Dus wanneer bedrijven proberen deze systemen in echte omgevingen te implementeren, wordt de kloof duidelijk. Het prototype werkte omdat de omgeving gecontroleerd was. Productie is rommelig.

Empromptu richt zich op het transformeren van bestaande software in AI-native systemen in plaats van bedrijven te dwingen alles van scratch opnieuw op te bouwen. Wat houdt die transformatie in op het niveau van infrastructuur en product?

Op productniveau is elke toepassing volledig zelfstandig en gecontaineriseerd. We creëren alles wat u nodig heeft, van front-ends, back-ends, databases, modellen, evaluaties, LLM’s, regels en alles is superflexibel, afhankelijk van de behoeften van de onderneming.

We hebben verschillende opties voor AI-toepassingen:

“Headless”, dus als een klant al een front-end heeft, kunnen we dit verbinden met ons systeem en de gegevens terugsturen

Volledig gecontaineriseerd, zodat ze kunnen worden geïmplementeerd op onze infrastructuur of binnen de infrastructuur van de klant, dus standaard on-premises.

Of we kunnen ze gewoon genereren en rechtstreeks naar de cloud implementeren voor de meest handige optie.

Elke code die ze hebben, kunnen we rechtstreeks in ons systeem importeren en agentificeren als deze nog niet is geagentificeerd. We zien dit bijvoorbeeld bij klanten die hebben geprobeerd hun toepassingen te bouwen op populaire platforms zoals Lovable, Replit, Bolt of Base44. Vaak werken deze niet. Maar klanten hebben al veel tijd en energie en credits in deze toepassing geïnvesteerd, dus we nemen deze over, herschrijven deze, zorgen ervoor dat alle AI-aspecten werken.

En we kunnen dit doen omdat we een aantal aangepaste, eigendomsrechtelijke technologieën hebben, zoals:

• Adaptive context engine om context te beheren
• Infinite geheugen om langlopende code-toepassingen te verwerken
• Aangepaste datamodellen en gouden datapipelines om ervoor te zorgen dat we alle benodigde gegevensreiniging en synthetische labeling kunnen uitvoeren

Uw platform benadrukt context, evaluatie, governance en gestructureerde gegevens als core-onderdelen van AI-systemen. Waarom worden deze elementen zo vaak over het hoofd gezien wanneer teams haasten om AI-functies aan hun producten toe te voegen?

Omdat ze moeilijk te doen zijn! Mijn mede-oprichter, Dr. Sean Robinson, leidt ons onderzoekscentrum en is een computationeel astrofysicus die een aantal technologieën heeft uitgevonden die zijn geïnspireerd door mijn gekke ideeën, maar ook door de behoeften van onze klanten en de richting van de markt. Onze gezamenlijke ervaring in het bouwen van veel agente-toepassingen, het lanceren van satellieten in de ruimte en het bouwen bij de grootste technologiebedrijven ter wereld geeft ons inzichten die ons helpen om ingewikkelde problemen beter op te lossen dan anderen.

U werkt met veel oprichters die nog nooit code hebben geschreven. Wat zijn de grootste misvattingen die niet-technische oprichters hebben wanneer ze voor het eerst proberen AI-toepassingen te bouwen?

Ik denk dat er twee grote misvattingen zijn:

De eerste is dat AI magie is. AI is geen magie. Het is gewoon goede techniek. En uiteindelijk bereikt u een limiet van wat u kunt doen op deze platforms zonder een echte ingenieur.

De tweede is dat ze grote technische productbeheersvaardigheden hebben. Ik heb een achtergrond in technisch productbeheer en de vaardigheid om een visie, soms een heel grote visie, te vertalen naar kleine, verzendbare stukken met de juiste technische specificatie om exact te articuleren wat u wilt. Dat is eigenlijk een heel moeilijke vaardigheid die tijd kost.

Als voorbeeld, stel dat u een app bouwt die een PDF uploadt en deze PDF opslaat zodat u deze later kunt bekijken. Dat is een concept dat persistente opslag wordt genoemd. Die PDF wordt gecodeerd naar code en opgeslagen in een database.

Maar als u niet weet dat dit persistente opslag wordt genoemd, hoe gaat u dit dan typen? Zorg ervoor dat deze gegevens persistent zijn. Technische woordkeuze is als het spreken van een andere taal. Er is een verschil tussen schrijven in natuurlijke taal en schrijven in technische taal.

Veel startups gaan ervan uit dat de oplossing voor het bouwen van AI-producten simpelweg het inhuren van meer ingenieurs is. Waarom denkt u dat deze aanpak vaak faalt, en waar moeten oprichters aan denken wanneer ze AI-gebaseerde producten bouwen?

Het inhuren van meer ingenieurs is soms het juiste antwoord. Als u een diep technisch product bouwt of werkt aan de frontier van modelonderzoek, heeft u absoluut sterke ingenieursteams nodig. Er is geen vervanging voor goede ingenieurs wanneer het gaat om het oplossen van moeilijke problemen.

Maar de fout die veel startups maken, is ervan uitgaan dat meer ingenieurs automatisch de uitdaging van het bouwen van een AI-product oplossen.

In werkelijkheid zijn de moeilijkste problemen in AI-producten vaak geen zuivere ingenieursproblemen. Ze zijn systeemproblemen, net als elk ander ingenieursprobleem. Ingenieurs worden specifiek geleerd om in systemen te denken. Maar generatieve ontwikkeling is anders dan deterministische ontwikkeling. Veel van ons hebben deze overgang gemaakt toen we overschakelden van object-georiënteerd programmeren naar functioneel programmeren. Zijn het beiden programmeren? Ja, absoluut, maar zijn ze verschillend? Zijn ze een andere manier van denken? Ja, natuurlijk.

AI-toepassingen zitten op het snijvlak van gegevens, productontwerp, operationele workflows en modelgedrag. U kunt een geweldig team van ingenieurs inhuren, maar als de datapipelines onbetrouwbaar zijn, de evaluatiecriteria onduidelijk zijn of het systeem geen governance en monitoring heeft, zal het product nog steeds worstelen zodra het bij echte gebruikers komt.

Een ander probleem is dat veel teams rechtstreeks naar het bouwen springen voordat ze hebben gedefinieerd hoe het AI-systeem in productie zal gedragen. Vragen zoals hoe het systeem zal worden geëvalueerd, hoe randgevallen zullen worden afgehandeld, hoe beslissingen zullen worden gelogd en hoe modellen zullen worden bijgewerkt in de loop van de tijd, komen vaak veel later. Dan is de architectuur al moeilijk te veranderen.

Waar oprichters echt aan moeten denken, is het operationele model van hun AI-systeem.

Wie is de eigenaar van de datapipeline?

Hoe wordt de prestatie van het model continu gemeten, niet alleen tijdens de ontwikkeling?

Wat gebeurt er wanneer het systeem een situatie tegenkomt die het nog nooit eerder heeft gezien?

Hoe werkt u het gedrag veilig bij zonder downstream-workflows te breken?

Soms lost het oplossen van deze problemen inderdaad het inhuren van meer ingenieurs op. Maar het kan ook betekenen dat u de juiste infrastructuur kiest, sterke productbeperkingen definieert en systemen bouwt die kleine teams in staat stellen om betrouwbaar te opereren op grote schaal.

De bedrijven die vandaag succesvol zijn met AI, zijn niet noodzakelijkerwijs degenen met de grootste ingenieursteams. Ze zijn degenen die AI behandelen als een langlopend systeem dat gegevensdiscipline, evaluatie, governance en continue verbetering vanaf het begin nodig heeft.

U heeft betoogd dat sommige van de huidige businessmodellen in AI-ontwikkelaarstools niet in overeenstemming zijn met het bouwen van duurzame producten. Wat zijn de stimulansen in het huidige AI-tooling-ecosysteem die u denkt dat bedrijven in de verkeerde richting leiden?

Een van de grootste stimulansen die momenteel niet overeenkomen, is dat veel AI-ontwikkelaarstools zijn geoptimaliseerd voor groeimetrics in plaats van productduurzaamheid.

Veel bedrijven in deze ruimte worden beloond voor hoe snel gebruikers iets indrukwekkends kunnen creëren. Als een tool een werkende app, een functie of een demo in een paar minuten kan genereren, stimuleert dit inschrijvingen, sociale deling en investeerdersenthusiasme. Vanuit het oogpunt van productadoptie heeft dit zin.

Maar deze stimulansen stoppen vaak bij het moment van creatie.

Het moeilijkere werk in AI-software gebeurt na dat punt. Dat is wanneer vertrouwen wordt opgebouwd. Wanneer u kunt vertrouwen op kwaliteit. Dat de gebruiker terug wil komen zonder de AI-frustratie van slechte output. Moet goede antwoorden geven, zelfs in het gezicht van menselijke onwetendheid of kwaadaardigheid.

Een ander probleem is dat veel tools zijn geoptimaliseerd voor codegeneratie in plaats van systeemontwerp. Code genereren is handig, maar het bouwen van een AI-product vereist meer dan het produceren van code. Het vereist het definiëren van hoe het systeem context beheert, hoe beslissingen worden geëvalueerd, hoe fouten worden afgehandeld en hoe gedrag veilig evolueert in de loop van de tijd.

De bedrijven die hun stimulansen rond het helpen van klanten om AI-systemen betrouwbaar te laten draaien, niet alleen om ze snel te bouwen, zijn degenen die duurzame waarde in dit ecosysteem zullen creëren.

Sommige van uw klanten zijn ondernemers die zeer specifieke producten bouwen, zoals gespecialiseerde gezondheidstools of duurzaamheidsgerichte bedrijven, vaak zonder traditionele ingenieursteams. Wat zijn de patronen die u hebt gezien onder de oprichters die deze ideeën succesvol omzetten in werkende AI-producten?

Een van de meest interessante patronen die we zien, is dat de oprichters die slagen niet noodzakelijkerwijs de meest technische zijn. Ze zijn degenen die het probleem dat ze oplossen extreem goed begrijpen.

Veel van de ondernemers die Empromptu gebruiken, zijn domeinexperts. Ze kunnen afkomstig zijn uit de gezondheidszorg, financiën, duurzaamheid of een andere gespecialiseerde industrie. Wat ze meebrengen, is diepe kennis van de workflows, regelgeving en beslissingen die in die omgeving bestaan. Die context is enorm waardevol bij het ontwerpen van een AI-product, omdat het definieert wat het systeem eigenlijk moet doen.

De oprichters die slagen, benaderen AI minder als een technologie-experiment en meer als een product-systeem. Ze beginnen met het stellen van concrete vragen. Welke beslissingen moet de AI helpen bij het nemen van gebruikers? Welke gegevensbronnen moet het toegang tot hebben? Wat ziet een correct antwoord eruit in deze domein? Welke railingen moeten bestaan zodat het systeem verantwoordelijk gedraagt?

Een ander patroon is dat ze zorgvuldig nadenken over structuur. Succesvolle teams realiseren zich snel dat AI-outputs alleen zo goed zijn als de context en gegevens die ze voeden. Ze investeren tijd om datapipelines te definiëren, kennisbronnen te organiseren en duidelijke evaluatiecriteria te creëren voor wat “goed” betekent.

We zien ook succesvolle oprichters die menselijke AI-samenwerking omarmen in plaats van alles meteen te proberen te automatiseren. Ze ontwerpen workflows waarin de AI repetitieve analyse of gegevenssynthese afhandelt, terwijl mensen verantwoordelijk blijven voor oordeel en definitieve beslissingen. Die balans maakt systemen veel betrouwbaarder, vooral in domeinen zoals gezondheidszorg of financiën.

Op veel manieren is de grootste verschuiving een verschuiving in mentaliteit. De oprichters die slagen, denken niet aan AI als een functie die ze toevoegen. Ze denken aan AI als een nieuwe operationele laag voor hoe hun product werkt.

Naarmate AI-systemen meer geïntegreerd raken in kernbedrijfsoperaties, welke capaciteiten zullen de volgende generatie AI-toepassingsplatforms definiëren?

Ik weet dat dit gek is en ik zeg misschien iets heiligs, maar mensen zullen in staat zijn om hun eigen aangepaste modellen te vibe-coderen. Iets wat ons onderzoekscentrum expert nano-modellen noemt, zal helpen om kosten te controleren.

Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen Empromptu AI bezoeken.