Shanea Leven, grundlægger og administrerende direktør i Empromptu AI – Interviewserie

Shanea Leven, grundlægger og administrerende direktør i Empromptu AI, er en erfaren produktleder med omfattende erfaring med at bygge udviklerplatforme og AI-drevne produkter i større teknologivirksomheder. Før hun startede Empromptu i 2025, grundlagde hun CodeSee, en AI-udviklerplatform, der hjælper hold med at visualisere og forstå komplekse kodebaser, som blev købt af GitKraken i 2024. Tidligere i sin karriere havde hun seniort produktlederroller i virksomheder som Docker, Cloudflare, eBay og Google (GOOGL ), hvor hun arbejdede med initiativer, der strakte sig fra Google Assistant-betaling-API’er til udvikleruddannelsesprogrammer, der blev brugt af hundredtusinder af lærende.

Empromptu AI er en enterprise-platform, der er designet til at hjælpe organisationer med at bygge og implementere integrerede AI-applikationer nemmere. Platformen kombinerer applikationsudvikling, dataintegration, governance, evaluering, hukommelse og modelorkestrering i et enkelt miljø, hvilket giver virksomhederne mulighed for at gå fra hurtig AI-eksperimentering til produktionsklare systemer med de kontroller og pålidelighed, der kræves for enterprise-brug.

De har brugt mere end 15 år på at bygge udviklerplatforme i virksomheder som Google, eBay, Cloudflare og Docker, før de startede CodeSee, som senere blev købt af GitKraken, og nu leder Empromptu AI. Hvordan har disse erfaringer formet deres perspektiv på, hvorfor så mange AI-værktøjer fejler, når de forlader demo-stadiet, og hvilket specifikt problem var de fast besluttede på at løse, da de startede Empromptu?

En af de ting, man lærer, når man bygger udviklerplatforme, er, at de sværeste problemer aldrig er dem i demoen. Demoen virker altid. Den virkelige test er, hvad der sker, når tusinder af udviklere bruger systemet, når data er beskidt, når integrationerne fejler, og når virksomheder afhænger af det.

Hos Google, Cloudflare, Docker og eBay tilbragte jeg år med at arbejde på platforme, der skulle fungere på globalt niveau. Disse miljøer lærer én noget hurtigt: pålidelighed, governance og overvågning er ikke funktioner, man tilføjer senere. De er arkitekturen.

Da jeg startede med at bygge AI-applikationer, var modellerne forfærdelige, og da de begyndte at blive bedre, lagde jeg mærke til, at branchen gentog den samme fejl, vi så i tidligere bølger af software. I udviklerværktøjer er der et begreb, der synes at være blevet glemt. Hvordan hurtigt kan man nå “hej verden”? I dag er den generative version af “hej verden” en fuldt fungerende SaaS-prototype. Men vi kode ikke kun SaaS-applikationer; vi kode hele AI-applikationer. En AI, der bygger AI, kræver andre systemer for at sætte AI’en i produktion.

Man kan generere en fungerende AI-applikation eller funktion hurtigt, hvilket er spændende og virkelig nyttigt. Men de dominerende systemer mangler stadig den infrastruktur, der er nødvendig for produktionsmiljøer. Ting som strukturerede datapipelines, evalueringssystemer, governancekontroller, overvågning og langsigtede kontekststyring blev overset, men vi har sat dem ind, samtidig med at vi har beholdt alle de fantastiske dele af vibe-kodning.

Da min medstifter og jeg startede Empromptu, var problemet, vi ville løse, simpelt: Hvordan kan vi gøre AI-applikationer produktionsklare fra starten?

I stedet for at behandle governance, dataklarhed, evaluering og optimering som separate værktøjer eller efterfølgende processer, byggede vi dem direkte ind i platformen. Idéen er, at hold skal kunne bygge AI-applikationer hurtigt, men med samme pålidelighed, kvalitet og kontrol, som de forventer fra enterprise-software-systemer.

De har været åbne om hullerne mellem imponerende AI-demonstrationer og produktionsklare systemer. Fra deres perspektiv, hvad er de mest almindelige arkitektoniske fejl, hold gør, når de forsøger at omdanne en AI-prototype til et pålideligt produkt, der bruges af rigtige kunder?

Den mest almindelige fejl, hold gør, er at antage, at modellen er produktet.

I tidlige prototyper gør modellen det meste af det synlige arbejde. Du giver den en prompt, den producerer et svar, og hvis svaret ser godt ud, ser systemet ud til at fungere. Det skaber illusionen om, at forbedring af modellen er den største udfordring.

Men i produktionsystemer er modellen kun en komponent i en langt større arkitektur.

Den første fejl er at behandle data som en eftertanke. I prototyper tester hold ofte med små, rene datasæt. Når systemet kobles til rigtige operationelle data, ændrer tingene sig hurtigt. Data ankommer ufuldstændige, inkonsistente, duplikerede eller i uventede formater. Uden en struktureret datapipeline til at normalisere og validere indgange, bliver systemet upålideligt, uanset hvor god modellen er.

Den anden fejl er manglen på evalueringssystemer. Mange hold lancerer AI-funktioner uden at definere, hvad “godt” faktisk betyder. De kan manuelt spot-checke outputs under udvikling, men de bygger ikke automatiske evalueringssystemer, der kontinuerligt måler nøjagtighed, drift og edge-cases, når systemet er live. Uden disse sikkerhedsforanstaltninger opdages fejl ofte af kunder i stedet for ingeniører.

En tredje problemstilling er manglen på governance- og kontrollmekanismer. AI-systemer er probabilistiske, hvilket betyder, at de kan opføre sig forskelligt under lidt forskellige betingelser. I regulerede eller højrisikomiljøer skal denne upålidelighed begrænses med deterministiske politikker, godkendelsesworkflows og audit-logs, der optager, hvordan beslutninger blev truffet.

Hvad dette virkelig kommer ned til, er, at produktions-AI-systemer ikke kun er modeller. De er operationelle systemer.

De virksomheder, der lykkes med AI i dag, er dem, der behandler datapipelines, evaluering, governance og overvågning som kerneinfrastruktur, ikke valgfrie tilføjelser.

Mange AI-kodningsplatforme lover, at alle kan bygge en applikation ved hjælp af simple prompts. Hvorfor fungerer disse værktøjer ofte godt til demonstrationer, men kæmper, når virksomheder forsøger at implementere dem i rigtige produktionsmiljøer?

Mange af disse platforme fungerer godt til demonstrationer, fordi de er optimeret til øjeblikket for skabelse, ikke livscyklussen for et rigtigt system.

Men der er en fundamental forskel mellem at bruge AI til at generere en landingsside og at bruge AI til at bygge en AI-applikation.

En landingsside er mest statisk software. Når den renderes korrekt, er jobbet stort set gjort. Systemet behøver ikke at træffe probabilistiske beslutninger, indtage konstant ændrende data eller tilpasse sig uforudsigelige brugeradfærd.

AI-applikationer er helt anderledes. De er dynamiske systemer, der afhænger af datapipelines, modeladfærd, evalueringssystemer og kontinuerlig overvågning. Applikationen skal håndtere kontekst, opdage, når outputs drifter, håndtere edge-cases og fungere sikkert, når modellen møder situationer, den ikke har set før.

De fleste prompt-drevne kodningsværktøjer behandler ikke disse lag, fordi de er designet til at få noget til at fungere hurtigt. De genererer kode, der producerer et synligt resultat, hvilket er perfekt til en demo-miljø. Men produktionsystemer kræver en langt større sæt af funktioner: struktureret datahåndtering, governancekontroller, evalueringssystemer, overvågning og mekanismer for sikkert opdatering af adfærd over tid.

Så når virksomheder forsøger at implementere disse systemer i rigtige miljøer, bliver hullerne åbenlyse. Prototypen fungerede, fordi miljøet var kontrolleret. Produktion er beskidt.

Empromptu fokuserer på at omdanne eksisterende software til AI-native systemer i stedet for at tvinge virksomheder til at bygge alt fra bunden. Hvad indebærer denne transformation faktisk på infrastruktur- og produkt niveau?

På produkt niveau er hver applikation fuldt selvstændig og containeriseret. Vi skaber alt, hvad du har brug for, fra frontender, backender, databaser, modeller, evals, llms-ops-regler og alt er super fleksibelt afhængigt af virksomhedens behov.

Vi har en række forskellige muligheder for AI-applikationer:

“Headless”, så hvis en kunde allerede har en frontend, kan vi koble det til vores system og sende data tilbage

Fullyt containeriseret, så de kan implementeres på vores infrastruktur eller inden for kundens infrastruktur, så de er on-prem som standard.

Eller vi kan bare generere dem og implementere dem direkte i skyen for den mest bekvemme mulighed.

Enhver kode, de har, kan vi importere direkte ind i vores system og agentificere, hvis den ikke allerede er agentificeret. For eksempel ser vi dette hos en række kunder, der har forsøgt at bygge deres applikationer på populære platforme som Lovable, Replit, Bolt eller Base44. Ofte fungerer de ikke. Men kunderne har allerede investeret meget tid og energi og kredit i denne applikation, så vi indtager den, omskriver den, får alt AI-arbejdet til at fungere.

Og vi kan gøre dette, fordi vi har en række tilpassede, proprietære teknologier, såsom:

• Adaptiv kontekstmotor til at håndtere kontekst
• Uendelig hukommelse til at indtage langvarige kodeapplikationer
• Tilpassede datamodeller og gyldne datapipelines til at sikre, at vi kan håndtere enhver datarensning og syntetisk mærkning, der kræves

Deres platform betoner kontekst, evaluering, governance og struktureret data som kernekomponenter af AI-systemer. Hvorfor overses disse elementer så ofte, når hold skynder sig at tilføje AI-funktioner til deres produkter?

Fordi de er svære at gøre! Min medstifter, Dr. Sean Robinson, leder vores forskningslaboratorium, og han er en computermæssig astrofysiker, der har opfundet en række teknologier inspireret af mine vanvittige ideer, men også vores kunders behov og hvor markedet er på vej. Vores kombinerede erfaring med at bygge mange agente applikationer, sætte satellitter i rummet og bygge på de største teknologivirksomheder i verden giver os indsigt, der hjælper os med at løse komplicerede problemer bedre end andre kan.

De arbejder med mange grundlæggere, der aldrig har skrevet kode før. Hvilke er de største misforståelser, ikke-tekniske grundlæggere har, når de første gang forsøger at bygge AI-applikationer?

Jeg tror, der er to store misforståelser:

Den første er, at AI er magi. AI er ikke magi. Det er bare god ingeniørarbejde. Og til sidst rammer man en grænse for, hvad man kan gøre på disse platforme uden en rigtig ingeniør.

Den anden er, at de har gode tekniske produktledelsesfærdigheder. Jeg har en baggrund i teknisk produktledelse, og færdigheden i at oversætte en vision, undertiden en meget stor vision, ned i små, leverable bidder med den rigtige tekniske specifikation til at articulere præcis, hvad du vil have. Det er faktisk en meget svær færdighed, der tager tid.

For eksempel, lad os sige, du bygger en app, der uploader en PDF og gemmer den PDF, så du kan vende tilbage og se den senere. Det er et begreb, der hedder persistence. Denne PDF bliver kodet til kode og gemt i en database.

Men hvis du ikke vidste, at det hed persistence, hvordan vil du kunne skrive? Sørg for, at denne data bliver vedligeholdt. Teknisk ordvalg er som at tale et andet sprog. Der er en forskel mellem at skrive i naturligt sprog og at skrive i teknisk sprog.

Mange startups antager, at løsningen på at bygge AI-produkter er simpelthen at hyre flere ingeniører. Hvorfor tror de, at denne tilgang ofte fejler, og hvad skal grundlæggere tænke på i stedet, når de bygger AI-drevne produkter?

At hyre flere ingeniører er undertiden det rigtige svar. Hvis du bygger et dybt teknisk produkt eller arbejder på fronten af modelresearch, har du absolut brug for stærke ingeniørhold. Der er ingen erstatning for gode ingeniører, når det kommer til at løse svære problemer.

Men fejlen, mange startups begår, er at antage, at flere ingeniører automatisk løser udfordringen med at bygge et AI-produkt.

I virkeligheden er de sværeste problemer i AI-produkter ofte ikke kun tekniske problemer. De er systemproblemer ligesom alle andre tekniske problemer. Ingeneriører er specifikt undervist i at tænke i systemer. Men generativ udvikling er anderledes end deterministisk udvikling. Mange af os gjorde dette skift, da vi skiftede fra objektorienteret programmering til funktionsprogrammering. Er det programmering? Ja, absolut, men er det en anden måde at tænke på? Ja, naturligvis.

AI-applikationer ligger på skæringen af data, produkt-design, operationelle workflows og modeladfærd. Du kan hyre et fantastisk hold af ingeniører, men hvis datapipelines er upålidelige, evalueringssystemerne er uklare eller systemet mangler governance og overvågning, vil produktet stadig kæmpe, når det når rigtige brugere.

Et andet problem er, at mange hold springer direkte ind i bygning, før de har defineret, hvordan AI-systemet vil opføre sig i produktion. Spørgsmål som, hvordan systemet vil blive evaluering, hvordan edge-cases vil blive behandlet, hvordan beslutninger vil blive logget, og hvordan modeller vil blive opdateret over tid, kommer ofte meget senere. På det tidspunkt er arkitekturen allerede svær at ændre.

Hvad grundlæggere virkelig skal tænke på, er det operationelle model for deres AI-system.

Hvem ejer datapipelinen?

Hvordan måles modelpræstation kontinuerligt, ikke kun under udvikling?

Hvad sker der, når systemet møder en situation, det ikke har set før?

Hvordan opdaterer man adfærd sikkert uden at bryde nedstrøms workflows?

Sommetider løser disse problemer at hyre flere ingeniører. Men det kan også betyde at vælge den rigtige infrastruktur, definere stærke produktbegrænsninger og bygge systemer, der giver små hold mulighed for at fungere pålideligt på stor skala.

De virksomheder, der lykkes med AI i dag, er ikke nødvendigvis dem med de største ingeniørhold. De er dem, der behandler AI som et langvarigt system, der kræver datadisciplin, evaluering, governance og kontinuerlig forbedring bygget ind fra starten.

De har argumenteret for, at nogle af de nuværende forretningsmodeller i AI-udviklerværktøjer ikke er i overensstemmelse med at bygge holdbare produkter. Hvilke incitamenter i den nuværende AI-værktøjsøkosystem tror de, fører virksomheder i den forkerte retning?

En af de største incitamentsforskelle lige nu er, at mange AI-udviklerværktøjer er optimeret til vækstmetrikker i stedet for produkt holdbarhed.

Mange virksomheder i denne branche belønnes for, hvor hurtigt brugere kan skabe noget imponerende. Hvis et værktøj kan generere en fungerende app, en funktion eller en demo på få minutter, driver det tilmeldinger, sociale delinger og investorbegejstring. Fra et produktadoptionssynspunkt giver det mening.

Men disse incitamenter stopper ofte ved skabelseøjeblikket.

Det hårdere arbejde i AI-software sker efter dette punkt. Det er, hvor tillid bygges. Når man kan regne med kvalitet. At brugeren vil vende tilbage igen og igen uden AI-frustration over dårlige outputs. Har brug for at give gode svar, selv i ansigtet af menneskelig uvidenhed eller ondsindet.

Et andet problem er, at mange værktøjer er optimeret til kodegenerering i stedet for systemdesign. At generere kode hurtigt er nyttigt, men at bygge et AI-produkt indebærer mere end at producere kode. Det kræver at definere, hvordan systemet håndterer kontekst, hvordan beslutninger evalueres, hvordan fejl håndteres, og hvordan adfærd udvikler sig sikkert over tid.

De virksomheder, der alignerer deres incitamenter omkring at hjælpe kunder med at køre AI-systemer pålideligt, ikke kun bygge dem hurtigt, er dem, der vil skabe varig værdi i denne økosystem.

Nogle af deres kunder inkluderer iværksættere, der bygger meget specifikke produkter, såsom specialiserede sundhedsredskaber eller bæredygtighedsfokuserede virksomheder, ofte uden traditionelle ingeniørhold. Hvilke mønstre har de set blandt grundlæggerne, der succesfuldt omdanner disse ideer til fungerende AI-produkter?

Et af de mest interessante mønstre, vi ser, er, at de grundlæggere, der lykkes, ikke nødvendigvis er de mest tekniske. De er dem, der forstår problemet, de løser, ekstremt godt.

Mange af de iværksættere, der bruger Empromptu, er domæneeksperter. De kan komme fra sundhedssektoren, finanssektoren, bæredygtighed eller en anden specialiseret branche. Hvad de bringer, er dyb viden om workflows, reguleringer og beslutninger, der findes i den pågældende branche. Denne kontekst er utrolig værdifuld, når man designer et AI-produkt, fordi det definerer, hvad systemet faktisk skal gøre.

De grundlæggere, der lykkes, tilgangen til AI mindre som en teknologi-eksperiment og mere som et produktsystem. De starter med at stille meget konkrete spørgsmål. Hvordan skal AI hjælpe brugerne med at træffe beslutninger? Hvilke datasources har det brug for at adgang til? Hvad ser et korrekt svar ud i denne branche? Hvilke sikkerhedsforanstaltninger skal eksistere, så systemet opfører sig ansvarligt?

Et andet mønster er, at de tænker omhyggeligt over struktur. Succesfulde hold erkender hurtigt, at AI-outputs kun er så gode som konteksten og data, der fødes ind i dem. De investerer tid forud i at definere datapipelines, organisere kildesources og skabe klare evalueringsskriterier for, hvad “godt” ser ud i denne branche.

Vi ser også succesfulde grundlæggere omfavne menneske-AI-samarbejde i stedet for at forsøge at automatisere alt med det samme. De designer workflows, hvor AI håndterer repetitive analyse eller datasyntese, mens mennesker forbliver ansvarlige for dømmekraft og endelige beslutninger. Den balance gør systemer langt mere pålidelige, især i brancher som sundhedssektoren eller finanssektoren.

På mange måder er den største ændring mindset. De grundlæggere, der lykkes, tænker ikke på AI som en funktion, de tilføjer. De tænker på det som et nyt operativt lag for, hvordan deres produkt fungerer.

Når AI-systemer bliver mere integreret i kerneforretningsoperationer, hvilke funktioner vil definere den næste generation af AI-applikationsplatforme?

Jeg ved, det er vanvittigt, og jeg må sige noget, der kan være kættersk, men folk vil være i stand til at vibe-kode deres egne brugerdefinerede modeller. Noget, vores forskningslaboratorium kalder expert nano-modeller, vil hjælpe med at kontrollere omkostningerne. Tak for det fantastiske interview, læsere, der ønsker at lære mere, skal besøge Empromptu AI.