Шейна Левен, засновник і генеральний директор Empromptu AI – Серія інтерв’ю

Шейна Левен, засновник і генеральний директор Empromptu AI, – ветеран продукту з великим досвідом будівництва платформ для розробників і продуктів, керованих штучним інтелектом, у великих технологічних компаніях. До заснування Empromptu у 2025 році вона заснувала CodeSee, платформу для розробників штучного інтелекту, яка допомагає командам візуалізувати та зрозуміти складні кодові бази, яку придбала GitKraken у 2024 році. Раніше в своїй кар’єрі вона займала керівні посади у сфері продукту в компаніях, включаючи Docker, Cloudflare, eBay і Google (GOOGL ), де працювала над ініціативами, починаючи від API для оплати Google Assistant і закінчуючи програмами навчання розробників, які використовували сотні тисяч учнів.

Empromptu AI – це корпоративна платформа, розроблена для того, щоб допомогти організаціям будувати та розгортати інтегровані застосунки штучного інтелекту легше. Платформа поєднує розвиток застосунків, інтеграцію даних, управління, оцінки, пам’ять і оркестрацію моделей у єдиному середовищі, що дозволяє компаніям переходити від швидкої експериментації штучного інтелекту до систем виробництва з необхідними засобами контролю та надійністю для корпоративного використання.

Ви провели понад 15 років, будуючи платформи для розробників у компаніях, таких як Google, eBay, Cloudflare і Docker, перш ніж заснувати CodeSee, яке пізніше було придбане GitKraken, і тепер очолюєте Empromptu AI. Як ці досвіди сформували вашу точку зору на те, чому так багато інструментів штучного інтелекту не проходять стадію демо, і яку конкретну проблему ви були вирішені вирішити, коли заснували Empromptu?

Одним з речей, яких ви вчитеся, будуючи платформи для розробників, є те, що найскладніші проблеми ніколи не виникають на стадії демо. Демо завжди працює. Реальна перевірка відбувається, коли тисячі розробників використовують систему, коли дані нечіткі, коли інтеграції порушуються, і коли реальні підприємства залежать від цього.

У Google, Cloudflare, Docker і eBay я провела роки, працюючи над платформами, які мали працювати у глобальному масштабі. Ці середовища швидко вчать вас одному: надійність, управління та спостережливість не є функціями, які ви додаєте пізніше. Це архітектура.

Коли я почала будувати застосунки штучного інтелекту, моделі були поганими, і коли вони почали покращуватися, я помітила, що галузь повторює ту саму помилку, яку ми бачили у попередніх хвилях програмного забезпечення. У інструментах для розробників є концепція, яка, здається, була забута. Як швидко ви можете отримати “привіт, світ”? Сьогодні ж генерація застосунку SaaS-прототипу – це повноцінний робочий прототип. Але ми зараз не тільки генеруємо застосунки SaaS; ми генеруємо цілі застосунки штучного інтелекту. Штучний інтелект, який будує штучний інтелект, потребує інших систем, щоб розмістити цей штучний інтелект у виробництві.

Ви можете швидко згенерувати робочий застосунок штучного інтелекту або функцію, що є цікавим і справді корисним. Але переважаючі системи все ще не мають інфраструктури, необхідної для середовищ виробництва. Речі, такі як структуровані потоки даних, кадри оцінки, засоби управління та моніторинг, а також управління контекстом на довгий термін були пропущені, але ми включили їх, зберігаючи всі чудові частини генерації.

Коли мій співзасновник і я заснували Empromptu, проблема, яку ми хотіли вирішити, була простою: як зробити застосунки штучного інтелекту готовими до виробництва з самого початку?

Натомість than розглядати управління, готовність даних, оцінку та оптимізацію як окремі інструменти або процеси після факту, ми включили їх безпосередньо у платформу. Ідея полягає в тому, що команди повинні бути в змозі будувати застосунки штучного інтелекту швидко, але з тією ж надійністю, якістю та контролем, які вони очікують від корпоративних програмних систем.

Ви були відкритими щодо розриву між вражаючими демонстраціями штучного інтелекту та системами, готовими до виробництва. З вашої точки зору, які найпоширеніші архітектурні помилки, які команди роблять при спробі перетворити прототип штучного інтелекту у надійний продукт, який використовують реальні клієнти?

Найпоширенішою помилкою, яку роблять команди, є припущення, що модель є продуктом.

У ранньому прототипі модель виконує більшу частину видимої роботи. Ви її запускаєте, вона видає відповідь, і якщо відповідь виглядає добре, система здається робочою. Це створює ілюзію, що поліпшення моделі є основним викликом.

Але у системах виробництва модель є лише одним компонентом у набагато більшій архітектурі.

Перша помилка полягає в тому, що дані розглядаються як післядум. У прототипах команди часто тестують із малими, чистими наборами даних. Як тільки система підключається до реальних операційних даних, все змінюється швидко. Дані надходять не повністю, нестійко, дублікатами або у несподіваних форматах. Без структурованого потоку даних для нормалізації та перевірки входів система стає ненадійною, незалежно від того, наскільки хороша модель.

Друга помилка полягає в відсутності кадрів оцінювання. Багато команд запускають функції штучного інтелекту без визначення того, що таке “добре” насправді означає. Вони можуть вручну перевірити виходи під час розробки, але вони не будують автоматизовані потоки оцінювання, які безперервно вимірюють точність, зсув та крайні випадки, коли система живе. Без цих поручнів невдачі часто виявляються клієнтами, а не інженерами.

Третій vấn đề полягає в відсутності засобів управління та контролю. Системи штучного інтелекту є ймовірнісними, що означає, що вони можуть поводитися по-різному в трохи різних умовах. У регульованих або високих ставках середовищах ця непередбачуваність повинна бути обмежена детерміністичними політиками, робочими потоками схвалення та журналами аудиту, які фіксують, як приймаються рішення.

До чого це насправді зводиться, так це те, що продукти штучного інтелекту не є лише моделями. Це операційні системи.

Компанії, які зараз успішно працюють зі штучним інтелектом, є тими, які розглядають потоки даних, оцінювання, управління та моніторинг як ядро інфраструктури, а не опціональні додатки.

Багато платформ кодування штучного інтелекту обіцяють, що будь-хто може побудувати застосунок, використовуючи прості запити. Чому ці інструменти часто працюють добре для демонстрацій, але борються, коли компанії намагаються розгорнути їх у реальних середовищах виробництва?

Багато цих платформ працюють добре для демонстрацій, оскільки вони оптимізовані для моменту створення, а не життєвого циклу реальної системи.

Але існує фундаментальна різниця між використанням штучного інтелекту для генерації посадкової сторінки та використанням штучного інтелекту для побудови застосунку штучного інтелекту.

Посадкова сторінка в основному є статичним програмним забезпеченням. Як тільки вона відображається правильно, робота майже закінчена. Система не повинна приймати ймовірнісні рішення, споживати постійно змінювані дані або адаптуватися до непередбачуваної поведінки користувача.

Застосунки штучного інтелекту є зовсім іншими. Це динамічні системи, які залежать від потоків даних, поведінки моделі, кадрів оцінювання та безперервного моніторингу. Застосунок повинен керувати контекстом, виявляти, коли виходи зсуваються, обробляти крайні випадки та працювати безпечно, коли модель зустрічає ситуації, яких вона не бачила раніше.

Більшість інструментів кодування, керованих запитами, не адресують ці шари, оскільки вони розроблені для того, щоб щось працювало швидко. Вони генерують код, який видає видимий результат, який є ідеальним для середовища демонстрації. Але системи виробництва вимагають набагато більших можливостей: обробку структурованих даних, засоби управління, потоки оцінювання, спостережливість та механізми для безпечного оновлення поведінки з часом.

Тому, коли компанії намагаються розгорнути ці системи у реальних середовищах, розрив стає очевидним. Прототип працював, оскільки середовище було контрольованим. Виробництво – це не так.

Empromptu зосереджується на перетворенні існуючого програмного забезпечення у системи, рідні для штучного інтелекту, а не на примусі компаній будувати все з нуля. Що таке перетворення на рівні інфраструктури та продукту?

На рівні продукту кожен застосунок повністю самодостатній і контейнеризований. Ми створюємо все, що вам потрібно, від фронт-ендів, бек-ендів, баз даних, моделей, оцінок, llms opps правил і все це надзвичайно гнучке, залежно від потреб підприємства.

У нас є кілька різних варіантів для застосунків штучного інтелекту:

“Безголовий”, якщо клієнт вже має фронт-енд, ми можемо підключити його до нашої системи та повернути дані назад

Повністю контейнеризований, так що їх можна розгорнути на нашій інфраструктурі або всередині інфраструктури клієнта, так що вони за замовчуванням знаходяться локально.

Або ми можемо просто згенерувати їх та розгорнути їх безпосередньо у хмару для найбільш зручного варіанту.

Будь-який код, який у них є, ми можемо імпортувати його безпосередньо у нашу систему та агентифікувати його, якщо воно ще не агентифіковано. Наприклад, ми бачимо це у багатьох клієнтів, які намагалися побудувати свої застосунки на популярних платформах, таких як Lovable, Replit, Bolt або Base44. Часто вони не працюють. Але клієнти вже вклали багато часу, енергії та кредитів у цей застосунок, так що ми його споживаємо, переписуємо, робимо всі роботи штучного інтелекту.

І ми можемо це робити, оскільки у нас є кілька власних, пропріетарних технологій, таких як:

• Адаптивний двигун контексту для керування контекстом
• Нескінченна пам’ять для споживання довгих застосунків
• Власні моделі даних та золоті потоки даних, щоб забезпечити можливість обробки будь-якої очистки даних та синтетичних міток, які потрібні

Ваша платформа підкреслює контекст, оцінювання, управління та структуровані дані як ядро компонентів систем штучного інтелекту. Чому ці елементи так часто пропускаються, коли команди поспішно додають функції штучного інтелекту до своїх продуктів?

Бо вони важко робити! Мій співзасновник, доктор Шон Робінсон, очолює наш дослідницький центр, і він є комп’ютерним астрофізиком, який винайшов кілька технологій, надихнутих моїми безумними ідеями, а також потребами наших клієнтів та тим, куди рухається ринок. Наш спільний досвід у будівництві багатьох агентських застосунків, запуску супутників у космос та будівництва у найбільших технологічних компаніях світу надає нам уявлення, які допомагають нам краще вирішувати складні проблеми.

Ви працюєте з багатьма засновниками, які ніколи не писали код раніше. Які найбільші помилки не-технічних засновників, коли вони вперше намагаються побудувати застосунки штучного інтелекту?

Я думаю, що існує дві великі помилки:

Перша полягає в тому, що штучний інтелект є магією. Штучний інтелект не є магією. Це просто хороша інженерія. І врешті-решт ви натикаєтеся на межу того, що ви можете зробити на цих платформах без справжнього інженера.

Друга полягає в тому, що вони мають великі технічні продукційні навички. У мене є досвід технічного продукту, і навичка перекладу бачення, іноді дуже великого бачення, у малі шипувані шматки з правильною технічною специфікацією для визначення того, що ви хочете. Це насправді дуже важка навичка, яка потребує часу.

Наприклад, скажіть, ви будуєте застосунок, який завантажує PDF і зберігає цей PDF, щоб ви могли повернутися та переглянути його пізніше. Це називається збереженням. Цей PDF кодується у код та зберігається у базі даних.

Але якщо ви не знаєте, що це називається збереженням, як ви будете能够 набрати? Перевірте, щоб ці дані збереглися. Технічний вибір слів – це як говорити іншою мовою. Є різниця між написанням у природній мові та написанням у технічній мові.

Багато стартапів припускають, що рішення для побудови продуктів штучного інтелекту полягає просто у наймі більше інженерів. Чому ви вважаєте, що цей підхід часто не працює, і про що засновники повинні думати замість цього, коли будують продукти, керовані штучним інтелектом?

Найм інженерів іноді є правильною відповіддю. Якщо ви будуєте глибоко технічний продукт або працюєте на передовій моделі дослідження, вам абсолютно потрібні сильні інженерні команди. Не існує заміни хорошим інженерам, коли справа стосується вирішення складних проблем.

Але помилка, яку роблять багато стартапів, полягає в тому, що вони припускають, що більше інженерів автоматично вирішує проблему побудови продукту штучного інтелекту.

На самом деле найскладніші проблеми у продуктах штучного інтелекту часто не є чисто інженерними проблемами. Це системні проблеми, як і кожна інша інженерна проблема. Інженери спеціально вчаться думати у системах. Але генерація розвитку відрізняється від детерміністичного розвитку. Багато з нас зробили цей перехід, коли ми перейшли від об’єктно-орієнтованого програмування до функціонального програмування. Чи є це програмуванням? Так, абсолютно, але чи є це іншим способом мислення? Так, звичайно.

Застосунки штучного інтелекту знаходяться на перетині даних, продукту, операційних робочих потоків та поведінки моделі. Ви можете найняти неймовірну команду інженерів, але якщо потоки даних ненадійні, критерії оцінювання нечіткі або система не має засобів управління та моніторингу, продукт все одно буде боротися, коли він досягне реальних користувачів.

Інша проблема полягає в тому, що багато команд переходять безпосередньо до будівництва, перш ніж вони визначили, як система штучного інтелекту буде поводитися у виробництві. Питання, такі як як система буде оцінюватися, як крайні випадки будуть оброблені, як рішення будуть реєструватися, а як моделі будуть оновлюватися з часом, часто приходять набагато пізніше. До того часу архітектура вже складна для зміни.

Про що засновники повинні насправді думати, так це про оперативну модель своєї системи штучного інтелекту.

Хто володіє потоком даних?

Як вимірюється продуктивність моделі безперервно, а не тільки під час розробки?

Що відбувається, коли система зустрічає ситуацію, якої вона не бачила раніше?

Як ви оновлюєте поведінку безпечно, не порушуючи подальші робочі потоки?

Іноді вирішення цих проблем означає найм більше інженерів. Але це також може означати вибір правильної інфраструктури, визначення сильних продукційних обмежень та будівництво систем, які дозволяють малим командам працювати надійно у масштабі.

Компанії, які зараз успішно працюють зі штучним інтелектом, не є обов’язково тими, у яких найбільші інженерні команди. Це компанії, які розглядають штучний інтелект як довготривалу систему, яка потребує дисципліни даних, оцінювання, управління та безперервного покращення, закладеного з самого початку.

Ви стверджували, що деякі з поточних бізнес-моделей у інструментах розробників штучного інтелекту не відповідають будівництву тривалих продуктів. Які стимули у поточній екосистемі інструментів штучного інтелекту, на вашу думку, ведуть компанії у неправильному напрямку?

Одним з найбільших розходжень стимулів зараз є те, що багато інструментів розробників штучного інтелекту оптимізовані для метрик зростання, а не для тривалості продукту.

Багато компаній у цій сфері винагороджуються за те, як швидко користувачі можуть створити щось вражаюче. Якщо інструмент може згенерувати робочий застосунок, функцію або демонстрацію за кілька хвилин, це стимулює реєстрацію, соціальне обміну та інвестиційне збудження. З точки зору прийняття продукту це має сенс.

Але ці стимули часто зупиняються на моменті створення.

Тяжча робота у програмному забезпеченні штучного інтелекту відбувається після цього моменту. Це момент, коли будується довіра. Коли ви можете покладатися на якість. Це користувач хоче повернутися знову і знову без розчарування штучного інтелекту поганого виходу. Потрібно давати хороші відповіді, навіть у разі людської невідANCH або злих намірів.

Інша проблема полягає в тому, що багато інструментів оптимізовані для генерації коду, а не для проектування системи. Генерація коду швидко є корисною, але будівництво продукту штучного інтелекту включає більше, ніж генерація коду. Це вимагає визначення того, як система керує контекстом, як оцінюються рішення, як обробляються невдачі та як поведінка еволюціонує безпечно з часом.

Компанії, які виравнюють свої стимули навколо допомоги клієнтам у роботі систем штучного інтелекту надійно, а не тільки у будівництві їх швидко, будуть створювати тривалу цінність у цій екосистемі.

Деякі з ваших клієнтів включають підприємців, які будують дуже конкретні продукти, такі як спеціалізовані інструменти охорони здоров’я чи бізнеси, орієнтовані на сталість, часто без традиційних інженерних команд. Які закономірності ви бачили серед засновників, які успішно перетворюють ці ідеї у робочі продукти штучного інтелекту?

Одним з найцікавіших закономірностей, які ми бачимо, є те, що засновники, які успішно працюють, не обов’язково є найбільш технічними. Вони ті, хто розуміє проблему, яку вони вирішують, надзвичайно добре.

Багато підприємців, які використовують Empromptu, є експертами у своїй галузі. Вони можуть походити з охорони здоров’я, фінансів, сталості або іншої спеціалізованої галузі. Що вони привносять, це глибокі знання робочих потоків, правил та рішень, які існують у цьому середовищі. Це контекст надзвичайно цінний при проектуванні продукту штучного інтелекту, оскільки воно визначає, що система повинна робити насправді.

Засновники, які успішно працюють, підходять до штучного інтелекту менше як до технологічного експерименту, а більше як до продукту системи. Вони починають з дуже конкретних питань. Які рішення повинні допомогти штучний інтелект користувачам приймати? Які джерела даних йому потрібно доступу? Що таке правильна відповідь у цій галузі? Які поручні повинні існувати, щоб система поводилася відповідально?

Інша закономірність полягає в тому, що вони думають про структуру. Успішні команди швидко розуміють, що виходи штучного інтелекту є лише такими хорошими, як контекст та дані, які їх годують. Вони інвестують час спочатку у визначення потоків даних, організації джерел знань та створення чітких критеріїв оцінювання того, що таке “добре” виглядає.

Ми також бачимо успішних засновників, які приймають співробітництво людини та штучного інтелекту замість того, щоб намагатися автоматизувати все одразу. Вони проектують робочі потоки, у яких штучний інтелект обробляє повторювані аналіз або синтез даних, тоді як люди залишаються відповідальними за суд та остаточні рішення. Це баланс робить системи набагато надійнішими, особливо у галузях, таких як охорона здоров’я чи фінанси.

У багатьох випадках найбільший зсув – це зміна мислення. Засновники, які успішно працюють, не думають про штучний інтелект як про функцію, яку вони додають. Вони думають про нього як про новий оперативний шар того, як їхній продукт працює.

Як системи штучного інтелекту стають все більш інтегрованими у核心 бізнес-операцій, які можливості визначатимуть наступне покоління платформ застосунків штучного інтелекту?

Я знаю, що це безумно, і я можу говорити щось святотатське, але люди будуть能够 вибрати свій власний звичайний код для своїх моделей. Щось, що наш дослідницький центр називає експертними нано-моделями, допоможе контролювати витрати.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Empromptu AI.