Shanea Leven, grunnlegger og CEO i Empromptu AI – Intervju-serie

Shanea Leven, grunnlegger og CEO i Empromptu AI, er en veteran produktleder med omfattende erfaring med å bygge utviklerplattformer og AI-drevne produkter i større teknologiselskaper. Før hun lanserte Empromptu i 2025, grunnla hun CodeSee, en AI-utviklerplattform som hjelper team å visualisere og forstå komplekse kodebaserte systemer, som ble kjøpt av GitKraken i 2024. Tidligere i sin karriere hadde hun senior produktlederroller i selskaper som Docker, Cloudflare, eBay og Google (GOOGL ), hvor hun arbeidet med initiativer som varierte fra Google Assistant-betaling API-er til utviklerutdanningsprogrammer brukt av hundretusener av lærende.

Empromptu AI er en bedriftsplattform designet for å hjelpe organisasjoner å bygge og distribuere integrerte AI-applikasjoner mer enkelt. Plattformen kombinerer applikasjonsutvikling, dataintegrasjon, styring, evaluering, minne og modellorkestrering i ett enkelt miljø, som gjør det mulig for selskaper å gå fra rask AI-eksperimentering til produksjonsklare systemer med kontroll og pålitelighet som kreves for bedriftsbruk.

Du tilbrakte mer enn 15 år med å bygge utviklerplattformer i selskaper som Google, eBay, Cloudflare og Docker før du grunnla CodeSee, som senere ble kjøpt av GitKraken, og nå leder Empromptu AI. Hvordan har disse erfaringene formet din perspektiv på hvorfor så mange AI-verktøy feiler når de forlater demo-stadiet, og hvilket spesifikt problem var du bestemt på å løse når du grunnla Empromptu?

En av tingene du lærer når du bygger utviklerplattformer er at de hardeste problemene aldri er de som er i demoen. Demoen fungerer alltid. Den virkelige prøven er hva som skjer når tusenvis av utviklere bruker systemet, når dataene er ufullstendige, når integrasjonene bryter sammen, og når virkelige forretninger avhenger av det.

Hos Google, Cloudflare, Docker og eBay tilbrakte jeg år med å arbeide på plattformer som måtte fungere på global skala. Disse miljøene lærer deg noe raskt: pålitelighet, styring og overvåking er ikke funksjoner du legger til senere. De er arkitekturen.

Når jeg begynte å bygge AI-applikasjoner, var modellene dårlige, og da de begynte å bli bedre, merket jeg at industrien gjentok samme feil vi så i tidligere bølger av programvare. I utviklerverktøy finnes det et konsept som synes å ha blitt glemt. Hvor raskt kan du komme til “hello world”? I dag er den generative versjonen av “hello world” en fullt fungerende SaaS-prototype. Men nå bygger vi ikke bare “vibe code” SaaS-applikasjoner; vi bygger hele AI-applikasjoner. En AI som bygger AI krever andre systemer for å sette AI-en i produksjon.

Du kan generere en fungerende AI-applikasjon eller funksjon raskt, som er spennende og virkelig nyttig. Men de dominerende systemene mangler fortsatt infrastrukturen som trengs for produksjonsmiljøer. Ting som strukturerte datapipelines, evalueringssystemer, styringskontroller, overvåking og langtidskontekststyring ble glømt, men vi har lagt dem til mens vi beholdt alle de fantastiske delene av “vibe coding”.

Når min medgrunnlegger og jeg grunnla Empromptu, var problemet vi ville løse enkelt: hvordan kan vi gjøre AI-applikasjoner produksjonsklare fra starten?

I stedet for å behandle styring, dataklarhet, evaluering og optimalisering som separate verktøy eller etterfølgende prosesser, bygde vi dem direkte inn i plattformen. Idéen er at teamene skal kunne bygge AI-applikasjoner raskt, men med samme pålitelighet, kvalitet og kontroll som forventes fra bedriftsprogramvare.

Du har vært åpen om gapet mellom imponerende AI-demonstrasjoner og produksjonsklare systemer. Fra din perspektiv, hva er de vanligste arkitektoniske feilene teamene gjør når de prøver å omdanne en AI-prototype til et pålitelig produkt som brukes av virkelige kunder?

Den vanligste feilen teamene gjør er å anta at modellen er produktet.

I tidlige prototyper gjør modellen det meste av det synlige arbeidet. Du prompter den, den produserer et svar, og hvis svaret ser bra ut, ser systemet ut til å fungere. Dette skaper illusjonen om at å forbedre modellen er den største utfordringen.

Men i produksjonssystemer er modellen bare en komponent i en mye større arkitektur.

Den første feilen er å behandle data som en ettertanke. I prototyper tester teamene ofte med små, rene datasett. Når systemet kobles til virkelige operasjonelle data, endrer tingene seg raskt. Data ankommer ufullstendig, inkonsistent, duplisert eller i uventede formater. Uten en strukturert datapipeline for å normalisere og validere inndata, blir systemet uansvarlig uavhengig av hvor god modellen er.

Den andre feilen er mangelen på evalueringssystemer. Mange team lanserer AI-funksjoner uten å definere hva “god” faktisk betyr. De kan manuelt sjekke utdata under utvikling, men de bygger ikke automatiske evalueringssystemer som kontinuerlig måler nøyaktighet, drift og randtilfeller når systemet er i drift. Uten disse sikkerhetsforankrene, oppdages feil ofte av kunder i stedet for ingeniører.

En tredje problemstilling er mangelen på styrings- og kontrollmekanismer. AI-systemer er probabilistiske, noe betyr at de kan oppføre seg forskjellig under litt forskjellige forhold. I regulerte eller høyrisikomiljøer må denne usikkerheten begrenses med deterministiske politikker, godkjenningsarbeidsflyter og revisjonslogger som fanger hvordan beslutninger ble tatt.

Dette handler virkelig om at produksjons-AI-systemer ikke bare er modeller. De er operasjonelle systemer.

Selskapene som lykkes med AI i dag er de som behandler datapipelines, evaluering, styring og overvåking som kjerneinfrastruktur, ikke valgfrie tillegg.

Mange AI-kodingplattformer lover at alle kan bygge en applikasjon ved hjelp av enkle promter. Hvorfor fungerer disse verktøyene ofte bra for demonstrasjoner, men sliter når selskaper prøver å distribuere dem i virkelige produksjonsmiljøer?

Mange av disse plattformene fungerer bra for demonstrasjoner fordi de er optimert for øyeblikket av skapelse, ikke livssyklusen til et virkelig system.

Men det er en grunnleggende forskjell på å bruke AI til å generere en landingsside og å bruke AI til å bygge en AI-applikasjon.

En landingsside er i hovedsak statisk programvare. Når den renderes riktig, er jobben i stor grad gjort. Systemet trenger ikke å fatte probabilistiske beslutninger, inngående konstant endrede data eller tilpasse seg uforutsigbare brukeratferd.

AI-applikasjoner er helt forskjellige. De er dynamiske systemer som avhenger av datapipelines, modellatferd, evalueringssystemer og kontinuerlig overvåking. Applikasjonen må håndtere kontekst, oppdage når utdata glir, håndtere randtilfeller og fungere trygt når modellen møter situasjoner den ikke har sett før.

De fleste prompt-drevne kodingverktøyene håndterer ikke disse lagene fordi de er designet for å få noe til å fungere raskt. De genererer kode som produserer et synlig resultat, som er perfekt for et demo-miljø. Men produksjonssystemer krever en mye større sett med funksjoner: strukturert datahåndtering, styringskontroller, evalueringssystemer, overvåking og mekanismer for å oppdatere atferd trygt over tid.

Så når selskaper prøver å distribuere disse systemene i virkelige miljøer, blir gapet åpenbart. Prototypen fungerte fordi miljøet var kontrollert. Produksjon er uforutsigbar.

Empromptu fokuserer på å transformere eksisterende programvare til AI-naturlige systemer i stedet for å tvinge selskaper til å bygge alt fra bunnen av. Hva innebærer denne transformasjonen faktisk på infrastruktur- og produktivt nivå?

På produktivt nivå er hver applikasjon fullstendig selvinnholdende og containerisert. Vi skaper alt du trenger, fra frontender, backender, databaser, modeller, evalueringsverktøy, regler og alt er veldig fleksibelt avhengig av bedriftens behov.

Vi har flere forskjellige alternativer for AI-applikasjoner:

“Headless”, så hvis en kunde allerede har en frontend, kan vi koble det til vårt system og sende dataene tilbake

Fullstendig containerisert, så de kan distribueres på vår infrastruktur eller innenfor kundens infrastruktur, så de er på-prem som standard.

Eller vi kan bare generere dem og distribuere dem rett til skyen for det mest praktiske alternativet.

Alle koder de har, kan vi importere direkte inn i vårt system og “agentisere” den hvis den ikke allerede er agentisert. For eksempel ser vi dette hos en rekke kunder som har prøvd å bygge sine applikasjoner på populære plattformer som Lovable, Replit, Bolt eller Base44. Ofte fungerer de ikke. Men kundene har allerede brukt mye tid og energi og kreditter på denne applikasjonen, så vi inngår den, skriver den om og får all AI-en til å fungere.

Og vi kan gjøre dette fordi vi har en rekke tilpassede, proprietære teknologier, som:

• Adaptiv kontekstmotor for å håndtere kontekst
• Uendelig minne for å inngå lange kjørende kodeapplikasjoner
• Tilpassede datamodeller og gylne datapipelines for å sikre at vi kan håndtere all datarengjøring og syntetisk merking som kreves

Din plattform betoner kontekst, evaluering, styring og strukturert data som kjernekomponenter i AI-systemer. Hvorfor er disse elementene så ofte oversett når teamene skynder seg for å legge til AI-funksjoner i sine produkter?

Fordi de er vanskelige å gjøre! Min medgrunnlegger, Dr. Sean Robinson, leder vårt forskningslaboratorium, og han er en komputasjonell astrofysiker som har oppfunnet en rekke teknologier inspirert av mine gale ideer, men også våre kunders behov og hvor markedet er på vei. Vår kombinerede erfaring med å bygge mange agente applikasjoner, sette satellitter i rommet og bygge i de største teknologiselskapene i verden gir oss innsikt som hjelper oss å løse kompliserte problemer bedre enn andre kan.

Du arbeider med mange grunnleggere som aldri har skrevet kode før. Hva er de største misforståelsene ikke-tekniske grunnleggere har når de først prøver å bygge AI-applikasjoner?

Jeg tror det er to store misforståelser:

Den første er at AI er magi. AI er ikke magi. Det er bare god ingeniørarbeid. Og til slutt når du når grensen for hva du kan gjøre på disse plattformene uten en virkelig ingeniør.

Den andre er at de har gode tekniske produktledelsesferdigheter. Jeg har en bakgrunn i teknisk produktledelse og evnen til å oversette en visjon, noen ganger en veldig stor visjon, ned i små leveringsklare deler med riktig teknisk spesifikasjon for å angi nøyaktig hva du vil. Det er faktisk en veldig vanskelig ferdighet som tar tid.

For eksempel, la oss si at du bygger en app som laster opp en PDF og lagrer den PDF-en så du kan gå tilbake og se den senere. Det er et konsept som kalles varighet. Denne PDF-en blir kodet og lagret i en database.

Men hvis du ikke visste at det var kalt varighet, hvordan vil du være i stand til å skrive? Sikre at denne dataen varer. Teknisk ordvalg er som å snakke et annet språk. Det er en forskjell på å skrive i naturlig språk og å skrive i teknisk språk.

Mange startup-selskaper antar at løsningen på å bygge AI-produkter er bare å ansette flere ingeniører. Hvorfor tror du at denne tilnærmingen ofte feiler, og hva bør grunnleggere tenke på i stedet når de bygger AI-drevne produkter?

Å ansette flere ingeniører er noen ganger det riktige svaret. Hvis du bygger et dypt teknisk produkt eller arbeider på grensen av modellforskning, trenger du absolutt sterke ingeniørteam. Det finnes ingen erstatning for gode ingeniører når det gjelder å løse vanskelige problemer.

Men feilen mange startup-selskaper gjør er å anta at flere ingeniører automatisk løser utfordringen med å bygge et AI-produkt.

I virkeligheten er de hardeste problemene i AI-produkter ofte ikke ren ingeniørarbeid. De er systemproblemer, akkurat som alle andre ingeniørproblemer. Ingenicører er spesifikt lært til å tenke i systemer. Men generativ utvikling er forskjellig fra deterministisk utvikling. Mange av oss gjorde denne skiftet da vi gikk fra objektorientert programmering til funksjonell programmering. Er de begge programmering? Ja, absolutt, men er de forskjellige? Er de en annen måte å tenke på? Ja, selvfølgelig.

AI-applikasjoner befinner seg i skjæringspunktet mellom data, produktutforming, operasjonelle arbeidsflyter og modellatferd. Du kan ansette et fantastisk team av ingeniører, men hvis datapipelines er uansvarlige, evalueringsskriteriene er uklare eller systemet mangler styring og overvåking, vil produktet likevel slite når det når virkelige brukere.

Et annet problem er at mange team hopper rett inn i bygging før de har definert hvordan AI-systemet vil oppføre seg i produksjon. Spørsmål som hvordan systemet vil bli evaluert, hvordan randtilfeller vil bli håndtert, hvordan beslutninger vil bli logget og hvordan modeller vil bli oppdatert over tid, kommer ofte mye senere. Da er arkitekturen allerede vanskelig å endre.

Hva grunnleggere virkelig bør tenke på er driftsmodellen for deres AI-system.

Hvem eier datapipelinen?

Hvordan måles modellprestasjon kontinuerlig, ikke bare under utvikling?

Hva skjer når systemet møter en situasjon det ikke har sett før?

Hvordan oppdaterer du atferd trygt uten å bryte nedstrøms arbeidsflyter?

Av og til løser disse problemene å ansette flere ingeniører. Men det kan også bety å velge riktig infrastruktur, definere sterke produktbegrensninger og bygge systemer som tillater små team å operere pålitelig i stor skala.

Selskapene som lykkes med AI i dag er ikke nødvendigvis de med de største ingeniørteamene. De er de som behandler AI som et langvarig system som trenger datadisiplin, evaluering, styring og kontinuerlig forbedring bygget inn fra starten.

Du har argumentert for at noen av de nåværende forretningsmodellene i AI-utviklerverktøy ikke er i linje med å bygge varige produkter. Hva incitamenter i det nåværende AI-verktøymiljøet tror du leder selskaper i feil retning?

En av de største incitamentsfeilene nå er at mange AI-utviklerverktøy er optimert for vekstmetrikk i stedet for produktvarighet.

Mange selskaper i denne bransjen belønnes for hvor raskt brukerne kan skape noe imponerende. Hvis et verktøy kan generere en fungerende app, en funksjon eller en demo på noen minutter, driver det oppmeldinger, sosial deling og investeringsentusiasme. Fra et produktadopsjonsperspektiv har det mening.

Men disse incitamentene stopper ofte ved skapelseøyeblikket.

Det hardeste arbeidet i AI-programvare skjer etter dette punktet. Da bygges tillit. Når du kan stole på kvalitet. At brukeren vil komme tilbake igjen og igjen uten AI-frustrasjonen av dårlig utgang. Trenger å gi gode svar selv i møte med menneskelig uvitenhet eller ondsinn.

Et annet problem er at mange verktøy er optimert for kodegenerering i stedet for systemdesign. Å generere kode raskt er nyttig, men å bygge et AI-produkt involverer mer enn å produsere kode. Det krever å definere hvordan systemet håndterer kontekst, hvordan beslutninger blir evaluert, hvordan feil blir håndtert og hvordan atferd utvikler seg trygt over tid.

Selskapene som alignerer incitamentene rundt å hjelpe kundene å kjøre AI-systemer pålitelig, ikke bare bygge dem raskt, er de som vil skape varig verdi i dette økosystemet.

Noen av dine kunder inkluderer grunnleggere som bygger svært spesifikke produkter, som spesialiserte helseverktøy eller bærekraftfokuserte bedrifter, ofte uten tradisjonelle ingeniørteam. Hva mønster har du sett blant grunnleggerne som lykkes i å omdanne disse idéene til fungerende AI-produkter?

En av de mest interessante mønstrene vi ser er at grunnleggerne som lykkes ikke nødvendigvis er de mest tekniske. De er de som forstår problemet de løser ekstremt godt.

Mange av grunnleggerne som bruker Empromptu er domene-eksperter. De kan komme fra helse, finans, bærekraft eller en annen spesialisert bransje. Hva de bringer er dypt kunnskap om arbeidsflytene, reguleringene og beslutningene som finnes i den miljøet. Denne konteksten er usedvanlig verdifull når du designer et AI-produkt fordi den definerer hva systemet faktisk må gjøre.

Grunnleggerne som lykkes tenderer til å nærme seg AI mindre som en teknologi-eksperiment og mer som et produktsystem. De starter med å stille konkrete spørsmål. Hvilke beslutninger skal AI-en hjelpe brukerne med? Hvilke datakilder trenger den å få tilgang til? Hva ser et korrekt svar ut som i denne domenen? Hvilke sikkerhetsforankrer må finnes for å sikre at systemet oppfører seg ansvarlig?

Et annet mønster er at de tenker nøye på struktur. Suksessfulle team ser raskt at AI-utdata bare er like gode som konteksten og dataene som mates inn. De investerer tid oppfront for å definere datapipelines, organisere kunnskapskilder og skape klare evalueringsskriterier for hva “god” ser ut som i denne domenen.

Vi ser også at suksessfulle grunnleggere omfavner menneske-AI-samarbeid i stedet for å prøve å automatisere alt med en gang. De designer arbeidsflyter hvor AI-en håndterer repetitive analyser eller datasyntese, mens menneskene forblir ansvarlige for dømmekraft og endelige beslutninger. Denne balansen gjør systemene langt mer pålitelige, spesielt i felt som helse eller finans.

På mange måter er den største skiftet tankesett. Grunnleggerne som lykkes tenker ikke på AI som en funksjon de legger til. De tenker på det som et nytt operasjonslag for hvordan deres produkt fungerer.

Når AI-systemer blir mer integrert i kjerneforretninger, hva vil være de avgjørende evnene for den neste generasjonen AI-applikasjonsplattformer?

Jeg vet dette er galt og jeg kan si noe som er kjettersk, men folk vil kunne “vibe-code” sine egne tilpassede modeller. Noe vårt forskningslaboratorium kaller “ekspert nano-modeller” vil hjelpe med å kontrollere kostnadene.

Takk for det flotte intervjuet, lesere som ønsker å lære mer kan besøke Empromptu AI.