Shanea Leven, Empromptu AI:n perustaja ja toimitusjohtaja – Haastattelusarja

Shanea Leven, Empromptu AI:n perustaja ja toimitusjohtaja, on kokenut tuotejohtaja, jolla on laaja kokemus kehittää kehittäjäalustoja ja tekoälyohjelmia suurissa teknologiayrityksissä. Ennen Empromptu:n perustamista vuonna 2025 hän perusti CodeSee:n, tekoälyohjelman, joka auttaa tiimejä visualisoimaan ja ymmärtämään monimutkaisia koodipohjia, jonka GitKraken hankki vuonna 2024. Uransa alussa hän toimi seniorituotejohtajana useissa yrityksissä, kuten Docker, Cloudflare, eBay ja Google (GOOGL ), joissa hän työskenteli aloitteiden parissa, kuten Google Assistant -maksu-API:sta kehittäjäkoulutusohjelmiin, joita käytti satoja tuhansia oppijaa.

Empromptu AI on yritysten käyttöön tarkoitettu alusta, joka auttaa organisaatioita kehittämään ja käyttöönottoon integroituja tekoälysovelluksia helpommin. Alusta yhdistää sovelluskehityksen, data-integroinnin, hallinnan, arvioinnit, muistin ja mallien orkestraation yhteen ympäristöön, jolloin yritykset voivat siirtyä nopeasta tekoälykokeilusta tuotantovalmiisiin järjestelmiin, joissa on tarvittavat valvontamekanismit ja luotettavuus.

Olet viettänyt yli 15 vuotta kehittäen kehittäjäalustoja yrityksissä kuten Google, eBay, Cloudflare ja Docker, ennen kuin perustit CodeSee:n, joka myöhemmin siirtyi GitKrakenin omistukseen, ja nyt johtaat Empromptu AI:ta. Miten nämä kokemukset ovat muovanneet näkemyksesi siitä, miksi niin monet tekoälytyökalut epäonnistuvat, kun ne poistuvat demo-vaiheesta, ja mikä ongelma halusit ratkaista perustamalla Empromptu:n?

Yksi asia, jonka oppii kehittäessään kehittäjäalustoja, on, että vaikeimmat ongelmat eivät koskaan ole ne, jotka ovat demossa. Demo toimii aina. Oikea testi on se, mitä tapahtuu, kun tuhannet kehittäjät käyttävät järjestelmää, kun data on epäjohdonmukaista, kun integraatiot menevät rikki ja kun oikeat liiketoiminnat riippuvat siitä.

Googlessa, Cloudflare:ssa, Dockerissa ja eBay:ssa vietin vuosia työskentelemällä alustoilla, jotka olivat toiminnassa globaalissa mittakaavassa. Nämä ympäristöt opettavat nopeasti, että luotettavuus, hallinta ja havainnointi eivät ole ominaisuuksia, joita voidaan lisätä myöhemmin. Ne ovat arkkitehtuuri.

Kun aloin kehittää tekoälysovelluksia, mallit olivat huonoja, ja kun ne alkoivat parantua, huomasin, että teollisuus toisti samaa virhettä, jonka olimme nähneet aiemmissa ohjelmistokehityksen aalloissa. Kehittäjätyökaluissa on käsite, joka näyttää unohtuneen. Kuinka nopeasti pääsee “Hei maailma!” -tilanteeseen? Nykyään generatiivinen versio “Hei maailma!” on täysimittainen SaaS-prototyyppi. Mutta emme enää vain “vibe-koodaa” SaaS-sovelluksia; me “vibe-koodaamme” koko tekoälysovelluksia. Tekoäly, joka luo tekoälyä, vaatii muita järjestelmiä, joilla voidaan ottaa tekoäly tuotantoon.

Voi luoda toimivan tekoälysovelluksen tai -ominaisuuden nopeasti, mikä on jännittävää ja aidosti hyödyllistä. Mutta vallitsevat järjestelmät puuttuvat edelleen tarvittavasta infrastruktuurista tuotantoympäristöihin. Asioita, kuten rakenteisia data-pohjia, arviointikehyksiä, hallintamekanismeja, valvontaa ja pitkäaikaista kontekstin hallintaa, puuttui, mutta olemme lisänneet ne kaikki säilyttäen samalla kaikki “vibe-koodauksen” upeat osat.

Kun minun perustajakumppani ja minä perustimme Empromptu:n, ongelma, jonka halusimme ratkaista, oli yksinkertainen: kuinka tehdä tekoälysovelluksista valmiita tuotantoon alusta alkaen?

Sen sijaan, että kohdeltiin hallintaa, data-valmiutta, arviointia ja optimointia erillisinä työkaluina tai jälkikäteen prosesseina, rakensimme ne suoraan alustaan. Ajatus on, että tiimit voivat luoda tekoälysovelluksia nopeasti, mutta samalla luotettavuudella, laadulla ja hallinnalla, joita odotetaan yrityssovelluksista.

Olet ollut avoin siitä, että on kuilu vaikuttavien tekoälydemon ja tuotantovalmiiden järjestelmien välillä. Mikä on yleisin arkkitehtoninen virhe, jonka tiimit tekevät, kun yrittävät muuttaa tekoälyprototyypin luotettavaksi tuotteeksi, jota käytetään oikeasti?

Yleisin virhe, jonka tiimit tekevät, on olettaa, että malli on tuote.

Alkuvaiheen prototyypeissä malli tekee suurimman osan näkyvää työtä. Kun kysyt mallilta vastausta, se tuottaa vastauksen, ja jos vastaus näyttää hyvältä, järjestelmä näyttää toimivan. Tämä luo illuusion, että mallin parantaminen on päähaaste.

Mutta tuotantojärjestelmissä malli on vain yksi osa paljon laajemmassa arkkitehtuurissa.

Ensimmäinen virhe on kohdella dataa jälkikäteen. Prototyypeissä tiimit usein testaavat pienen, puhdas-datasetin kanssa. Kun järjestelmä yhdistetään oikeaan toiminnalliseen dataan, asiat muuttuvat nopeasti. Data saapuu epätäydellisenä, epäjohdonmukaisena, kopioituna tai odottamattomissa muodoissa. Ilman rakenteista data-pohjaa, joka normalisoi ja validoi syötteitä, järjestelmästä tulee epäluotettava, riippumatta siitä, kuinka hyvä malli on.

Toinen virhe on arviointikehysten puute. Monet tiimit lanseeraavat tekoälyominaisuuksia määrittelemättä, mitä “hyvä” todella tarkoittaa. He saattavat manuaalisesti tarkastaa tuloksia kehityksen aikana, mutta he eivät rakenna automaattisia arviointiputkia, jotka jatkuvasti mittaavat tarkin, siirtymän ja reunatapauksien osalta, kun järjestelmä on käynnissä. Ilman näitä varoitusmerkkejä epäonnistumiset havaitaan usein asiakkaiden sijaan insinöörien toimesta.

Kolmas ongelma on hallintamekanismien puute. Tekoälyjärjestelmät ovat todennäköisyysjärjestelmiä, mikä tarkoittaa, että ne voivat käyttäytyä eri tavoin eri olosuhteissa. Säädellyissä tai korkean panoksen ympäristöissä tämä epävarmuus on rajoitettava deterministisillä käytäntöjä, hyväksymismenettelyillä ja kirjauslokeilla, jotka tallentavat, miten päätökset tehtiin.

Mikä tämä todella tarkoittaa, on, että tuotantotekoälyjärjestelmät eivät ole vain malleja. Ne ovat toiminnallisia järjestelmiä.

Yritykset, jotka menestyvät tekoälyssä tänään, ovat niitä, jotka kohdeltavat data-pohjia, arviointia, hallintaa ja valvontaa ydinalustana, eivät valinnaisina lisäosina.

Monet tekoälykoodausalustat lupaavat, että kuka tahansa voi luoda sovelluksen yksinkertaisilla ohjeilla. Miksi nämä työkalut usein toimivat hyvin esittelyissä, mutta kamppailevat, kun yritykset yrittävät ottaa ne käyttöön oikeissa tuotantoympäristöissä?

Monet näistä alustoista toimivat hyvin esittelyissä, koska ne on optimoitu luomishetkeen, ei koko järjestelmän elinkaareen.

Mutta on perustavanlaatuinen ero siinä, kun käytetään tekoälyä luomaan lading-sivu ja kun käytetään tekoälyä luomaan tekoälysovellus.

Lading-sivu on pääasiassa staattinen ohjelmisto. Kun se renderöi oikein, työ on pääasiassa tehty. Järjestelmällä ei tarvitse tehdä todennäköisyyspäätöksiä, käsitellä jatkuvasti muuttuvaa dataa tai sopeutua odottamattomaan käyttäjän käyttäytymiseen.

Teckoälysovellukset ovat täysin erilaisia. Ne ovat dynaamisia järjestelmiä, jotka riippuvat data-pohjista, mallin käyttäytymisestä, arviointikehyksistä ja jatkuvasta valvonnasta. Sovelluksella on hallittava konteksti, havaittava, kun tulokset poikkeavat, käsitellä reunatapauksia ja toimia turvallisesti, kun malli kohtaa tilanteita, joita se ei ole aiemmin nähnyt.

Useimmat ohjeiden mukaiset koodausvälineet eivät koske näitä kerroksia, koska ne on suunniteltu saamaan jotain toimimaan nopeasti. Ne generoivat koodia, joka tuottaa näkyvän tuloksen, mikä on täydellistä esittely-ympäristössä. Mutta tuotantojärjestelmät vaativat paljon laajempaa joukkoa ominaisuuksia: rakenteista data-käsittely, hallintakehysten, arviointiputkien, havainnoinnin ja mekanismeja turvallisesti käyttäytymisen päivittämiseksi ajan myötä.

Niinpä, kun yritykset yrittävät ottaa nämä järjestelmät käyttöön oikeissa ympäristöissä, kuilu tulee ilmi. Prototyyppi toimi, koska ympäristö oli hallittu. Tuotanto on epäjohdonmukaista.

Empromptu keskittyy muuttamaan olemassa olevaa ohjelmistoa tekoälyominaisuuksilla varustetuksi järjestelmiksi, eikä pakota yrityksiä rakentamaan kaiken alusta alkaen. Mitä tämä muunnos todella tarkoittaa infrastruktuurin ja tuotteen tasolla?

Tuotetasolla jokainen sovellus on täysin itsenäinen ja kontainerisoitu. Luomme kaiken, mitä tarvitaan, eteen- ja taustapuolelle, tietokantoihin, malleihin, arviointeihin, LLM:ihin, sääntöihin ja kaikkeen, ja se on erittäin joustava riippuen yrityksen tarpeista.

Meillä on useita vaihtoehtoja tekoälysovelluksille:

“Päättömät”, jolloin jos asiakkaalla on jo etupuoli, voimme yhdistää sen järjestelmäämme ja lähettää datan takaisin

Täysin kontainerisoitu, jolloin ne voidaan ottaa käyttöön infrastruktuurissamme tai asiakkaan infrastruktuurissa, jolloin ne ovat oletusarvoisesti paikallisia.

Tai voimme vain luoda ne ja ottaa ne käyttöön suoraan pilveen kaikkein kätevimmin.

Mikä tahansa koodi, jonka heillä on, voimme tuoda suoraan järjestelmäämme ja “agenttifoida” sen, jos se ei ole jo “agenttifioitu”. Esimerkiksi näemme tämän useiden asiakkaiden kanssa, jotka ovat yrittäneet luoda sovelluksiaan suositulla alustalla, kuten Lovable, Replit, Bolt tai Base44. Usein ne eivät toimi. Mutta asiakkaat ovat jo panostaneet paljon aikaa ja energiaa ja luottamusta sovellukseen, joten me otamme sen, kirjoitamme sen uudelleen ja teemme kaiken tekoälyn toimivaksi.

Ja voimme tehdä tämän, koska meillä on useita mukautettuja, omistamiamme teknologioita, kuten:

• Adaptiivinen konteksti-moottori kontekstin hallitsemiseksi
• Rajaton muisti pitkäaikaisten sovellusten käsittelyyn
• Mukautettavat data-mallit ja “kultaiset” data-pohjat varmistamaan, että voimme käsitellä kaiken tarvittavan data-puhdistuksen ja synteettisen merkitsemisen

Teidän alustanne korostaa kontekstia, arviointia, hallintaa ja rakenteista dataa tekoälyjärjestelmien ydinominaisuuksina. Miksi nämä elementit usein jäävät huomiotta, kun tiimit kiirehtivät lisäämään tekoälyominaisuuksia tuotteisiinsa?

Koska ne ovat vaikeita. Minun perustajakumppani, tohtori Sean Robinson, johtaa tutkimuslaboratoriota, ja hän on keksinyt useita teknologioita, jotka ovat inspiroineet minun hulluja ideoita, mutta myös asiakkaiden tarpeita ja markkinoiden suuntaa. Yhteinen kokemuksemme monien agenteiden sovellusten kehittämisestä, satelliittien lähettämisestä avaruuteen ja kehittämisestä maailman suurimmissa teknologiayrityksissä antaa meille oivalluksia, jotka auttavat meitä ratkaisemaan monimutkaisia ongelmia paremmin kuin kukaan muu.

Te työskentelet useiden perustajien kanssa, jotka eivät ole koskaan kirjoittaneet koodia aiemmin. Mitkä ovat suurimmat väärinkäsitykset, joita ei-tekniset perustajat usein tekevät, kun he yrittävät luoda tekoälysovelluksia ensimmäisen kerran?

Luulen, että on kaksi suurta väärinkäsitystä:

Ensimmäinen on, että tekoäly on magia. Tekoäly ei ole magiaa. Se on vain hyvää insinööritaitoa. Ja lopulta törmät rajaan siinä, mitä voit tehdä näillä alustoilla ilman oikeaa insinööriä.

Toinen on, että heillä on erinomaiset tekniset tuotejohtamistaidot. Minulla on tausta teknisessä tuotejohtamisessa ja taito kääntää visio, usein hyvin suuri visio, pieniin toimittavissa paloissa oikealla teknisellä määrittelyllä ilmaista, mitä haluat. Se on todella vaikea taito, joka vaatii aikaa.

Esimerkiksi, jos olet rakentamassa sovellusta, joka lataa PDF-tiedoston ja tallentaa sen, jotta voit tarkastella sitä myöhemmin. Se on käsite, jota kutsutaan persistenceksi. Se PDF koodataan ja tallennetaan tietokantaan.

Mutta jos et tiedä, että se on persistence, miten voit kirjoittaa? Varmista, että tämä data säilyy. Tekninen sanavalinta on kuin puhuminen toisella kielellä. On ero puhua luonnollisella kielellä ja puhua teknisellä kielellä.

Monet startup-yritykset olettavat, että ratkaisu tekoälytuotteiden luomiseen on vain palkata enemmän insinöörejä. Miksi uskot, että tämä lähestymistapa usein epäonnistuu, ja mitä perustajat pitäisi ajatella, kun luovat tekoälytuotteita?

Palkata enemmän insinöörejä on toisinaan oikea vastaus. Jos kehitätään syvää teknologiaa tai työskentelet tekoälyn mallintutkimuksen rintamassa, tarvitset ehdottomasti vahvat insinööritiimit. Ei ole korvaajaa hyville insinööreille, kun on kyse vaikeiden ongelmien ratkaisemisesta.

Mutta virhe, jonka monet startup-yritykset tekevät, on olettaa, että enemmän insinöörejä ratkaisee automaattisesti haasteen tekoälytuotteen luomisesta.

Todellisuudessa tekoälytuotteiden vaikeimmat ongelmat eivät ole pelkästään insinööritieteellisiä ongelmia. Ne ovat järjestelmien ongelmia, kuten kaikki muutkin insinööritieteelliset ongelmat. Insinöörit on opetettu ajattelemaan järjestelminä. Mutta generatiivinen kehitys on erilainen kuin deterministinen kehitys. Monet meistä tekivät tämän siirtymän, kun siirryimme oliopohjaisesta ohjelmoinnista funktiopohjaiseen ohjelmointiin. Onko se ohjelmointia? Kyllä, ehdottomasti, mutta onko se erilainen? Onko se erilainen tapa ajatella? Kyllä, totta.

Teckoälysovellukset sijaitsevat datan, tuotesuunnittelun, operatiivisten työnkulkujen ja mallin käyttäytymisen risteyksessä. Voit palkata uskomattoman insinööritiimin, mutta jos data-pohjat ovat epäluotettavia, arviointikriteerit ovat epäselvät tai järjestelmästä puuttuu hallinta ja valvonta, tuote kamppailee edelleen, kun se saavuttaa oikeat käyttäjät.

Toinen ongelma on, että monet tiimit ryntävät rakentamaan ennen kuin he ovat määritelleet, miten tekoälyjärjestelmä toimii tuotannossa. Kysymykset, kuten miten järjestelmää arvioidaan jatkuvasti, miten reunatapauksia käsitellään, miten päätöksiä kirjataan ja miten malleja päivitetään turvallisesti ajan myötä, usein tulevat vasta myöhemmin. Silloin arkkitehtuuri on jo vaikea muuttaa.

Mitä perustajat pitäisi todella ajatella, on tekoälyjärjestelmän operatiivinen malli.

Kuka omistaa data-pohjan?

Miten mallin suorituskykyä mitataan jatkuvasti, ei vain kehityksen aikana?

Mitä tapahtuu, kun järjestelmä kohtaa tilanteen, jota se ei ole aiemmin nähnyt?

Miten käyttäytyminen päivitetään turvallisesti ilman, että seurauksena on virheitä alihankkijoiden työnkulussa?

Joissain tapauksissa ongelman ratkaiseminen vaatii palkata enemmän insinöörejä. Mutta se voi myös tarkoittaa oikean infrastruktuurin valitsemista, vahvojen tuotevaatimusten määrittelyä ja järjestelmien rakentamista, jotka sallivat pienien tiimien toimia luotettavasti suurissa mittakaavoissa.

Yritykset, jotka menestyvät tekoälyssä tänään, eivät välttämättä ole niitä, joilla on suurimmat insinööritiimit. Ne ovat niitä, jotka kohdeltavat tekoälyä pitkäaikaisena järjestelmänä, joka vaatii datakuria, arviointia, hallintaa ja jatkuvaa parantamista alusta alkaen.

Olet väittänyt, että jotkut nykyiset liiketoimintamallit tekoälykehittäjätyökaluissa eivät ole linjassa kestävien tuotteiden luomisen kanssa. Mitkä kannustimet nykyisessä tekoälytyökalujen ekosysteemissä johtavat yrityksiä väärään suuntaan?

Yksi suurimmista kannustimien epäsovusta on, että monet tekoälykehittäjätyökalut on optimoitu kasvumittareiden sijaan tuotteen kestävyyden mukaan.

Monet yritykset tässä alalla palkitaan siitä, kuinka nopeasti käyttäjät voivat luoda jotain vaikuttavaa. Jos työkalu voi generoida toimivan sovelluksen, ominaisuuden tai demon muutamassa minuutissa, se ajaa rekisteröintejä, sosiaalista jakamista ja sijoittajien innostusta. Tuotteen omaksumisen kannalta se on järkevää.

Mutta nämä kannustimet usein loppuvat luomishetkellä.

Tehty työ tekoälyohjelmistossa tapahtuu sen jälkeen. Silloin luodaan luottamus. Kun voit luottaa laatuun. Kun käyttäjä haluaa tulla takaisin uudelleen ja uudelleen ilman tekoälyn pettymyksen huonoa tulostetta. Tarvitsee antaa hyviä vastauksia myös ihmisen tietämättömyyden tai pahantahtoisuuden edessä.

Toinen ongelma on, että monet työkalut on optimoitu koodin generoimiseen eikä järjestelmän suunnitteluun. Koodin generointi nopeasti on hyödyllistä, mutta tekoälytuotteen luominen vaatii enemmän kuin koodin tuottamista. Se vaatii määrittelyä siitä, miten järjestelmä hallitsee kontekstia, miten päätöksiä arvioidaan, miten virheitä käsitellään ja miten käyttäytyminen kehittyy turvallisesti ajan myötä.

Yritykset, jotka linjaavat kannustimensa asiakkaiden avustamiseen tekoälyjärjestelmien luotettavassa suorittamisessa, eivät vain niiden nopeassa luomisessa, ovat ne, jotka luo kestävää arvoa tässä ekosysteemissä.

Jotkut teidän asiakkaanne ovat yrittäjiä, jotka rakentavat erittäin spesifejä tuotteita, kuten erikoistuneita terveydenhuollon työkaluja tai kestävyyden kannalta tärkeitä liiketoimintoja, usein ilman perinteisiä insinööritiimejä. Mitkä ovat mallit, joita olette nähneet niiden perustajien keskuudessa, jotka onnistuvat muuttaa nämä ideat toimiviksi tekoälytuotteiksi?

Yksi mielenkiintoisimmista malleista, jonka näemme, on, että menestyvät perustajat eivät välttämättä ole teknisesti taitavia. He ovat niitä, jotka ymmärtävät ongelmia, joita he ratkaisevat, erittäin hyvin.

Monet Empromptu:n käyttäjistä ovat alan asiantuntijoita. He saattavat tulla terveydenhuollosta, rahoituksesta, kestävyydestä tai jostain muusta erikoistuneesta alasta. Mitä he tuovat, on syvä tietämys työnkuluista, säännöistä ja päätöksistä, jotka ovat olemassa kyseisessä ympäristössä. Tämä konteksti on erittäin arvokasta tekoälytuotteen suunnittelussa, koska se määrittää, mitä järjestelmän todella pitäisi tehdä.

Menestyvät perustajat lähestyvät tekoälyä vähemmän teknologisen kokeilun kaltaisena ja enemmän tuotejärjestelmänä. He alkavat kysymällä konkreettisia kysymyksiä. Mitkä päätökset tekoäly auttaa käyttäjiä tekemään? Mitkä data-lähteet siihen tarvitaan? Mitä oikea vastaus todella on tässä alalla? Mitkä varotoimet on olemassa, jotta järjestelmä toimii vastuullisesti?

Toinen malli on, että he ajattelevat rakenteellisesti. Menestyvät tiimit toteavat nopeasti, että tekoälytulokset ovat vain yhtä hyviä kuin konteksti ja data, jota ne syötetään. He panostavat aikaa etukäteen määrittelemällä data-pohjia, järjestämällä tietämyslähteitä ja luomalla selkeät arviointikriteerit siitä, mitä “hyvä” todella tarkoittaa.

Näemme myös menestyvien perustajien omaksuvan ihmisten ja tekoälyn yhteistyön sen sijaan, että yrittäisivät automatisoida kaiken heti. He suunnittelevat työnkuluja, joissa tekoäly käsittelee toistuvaa analyysiä tai data-synteesiä, kun taas ihmiset vastaavat harkinnasta ja lopullisista päätöksistä. Tämä tasapaino tekee järjestelmistä paljon luotettavampia, erityisesti alalla, kuten terveydenhuolto tai rahoitus.

Monilla tavoin suurin muutos on asenteessa. Menestyvät perustajat eivät ajattele tekoälyä ominaisuutena, jonka he lisäävät. He ajattelevat sitä uutena toimintatapana, jolla heidän tuotteensa toimii.

Kun tekoälyjärjestelmät tulevat yhä enemmän integroiduksi yritysten perustoimintoihin, mitkä ominaisuudet määrittelevät seuraavan sukupolven tekoälysovellus-alustoja?

Tiedän, että tämä on hullua, ja ehkä sanon jotain pyhäinhäväistystä, mutta ihmiset voivat “vibe-koodata” omat mukautetut mallinsa. Jotain, mitä tutkimuslaboratorioimme kutsuu “asiantuntija-nano-malleiksi”, auttaa hallitsemaan kustannuksia.

Kiitos hienosta haastattelusta. Lukijat, jotka haluavat oppia lisää, voivat vierailla Empromptu AI:ssa.