Шейна Левен, Основатель и Генеральный Директор 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 я провел годы, работая над платформами, которые должны были работать в глобальном масштабе. Эти среды быстро учат вас чему-то: надежность, управление и наблюдаемость не являются функциями, которые можно добавить позже. Они являются архитектурой.

Когда я начал создавать приложения ИИ, модели были ужасными, и когда они начали улучшаться, я заметил, что отрасль повторяет одну и ту же ошибку, которую мы видели в предыдущих волнах программного обеспечения. В инструментах разработки есть концепция, которая, кажется, была забыта. Как быстро можно добраться до “Hello World”? Сегодня генеративная версия “Hello World” – это полноценный рабочий прототип SaaS. Но теперь мы не только кодируем приложения SaaS; мы кодируем entire приложения ИИ. ИИ, который строит ИИ, требует других систем, чтобы поместить этот ИИ в производство.

Вы можете сгенерировать рабочее приложение ИИ или функцию быстро, что является интересным и действительно полезным. Но преобладающие системы все еще не имеют необходимой инфраструктуры, необходимой для производственных сред. Такие вещи, как структурированные конвейеры данных, кадры оценки, механизмы управления, мониторинг и управление контекстом в долгосрочной перспективе, были пропущены, но мы добавили их, сохраняя при этом все удивительные части кодирования настроек.

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

Вместо того, чтобы рассматривать управление, готовность данных, оценку и оптимизацию как отдельные инструменты или процессы после факта, мы построили их直接 в платформу. Идея заключается в том, что команды должны быть в состоянии создавать приложения ИИ быстро, но с той же надежностью, качеством и контролем, который они ожидают от корпоративных программных систем.

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

Самая распространенная ошибка, которую совершают команды, заключается в том, что они предполагают, что модель – это продукт.

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

Но в производственных системах модель – это только один компонент в гораздо более крупной архитектуре.

Первая ошибка заключается в том, что данные рассматриваются как после мысли. В прототипах команды часто тестируют с небольшими, чистыми наборами данных. Как только система подключается к реальным операционным данным, все меняется быстро. Данные приходят не полные, не последовательные, дублируются или в неожиданных форматах. Без структурированного конвейера данных для нормализации и проверки входных данных система становится ненадежной, независимо от того, насколько хороша модель.

Вторая ошибка заключается в отсутствии кадров оценки. Многие команды запускают функции ИИ без определения того, что означает “хорошо”. Они могут вручную проверять выходные данные во время разработки, но они не строят автоматические конвейеры оценки, которые постоянно измеряют точность, дрейф и граничные случаи, когда система находится в живом режиме. Без этих ограничений неудачи часто обнаруживаются клиентами, а не инженерами.

Третья проблема заключается в отсутствии механизмов управления и контроля. Системы ИИ являются вероятностными, что означает, что они могут вести себя по-разному в слегка разных условиях. В регулируемых или высокорисковых средах эта непредсказуемость должна быть ограничена детерминированными политиками, рабочими процессами утверждения и журналами аудита, которые захватывают, как были приняты решения.

Все это сводится к тому, что производственные системы ИИ – это не просто модели. Они являются операционными системами.

Компании, которые преуспевают в ИИ сегодня, – это те, которые рассматривают конвейеры данных, оценку, управление и мониторинг как основную инфраструктуру, а не необязательные дополнения.

Многие платформы кодирования ИИ обещают, что любой может создать приложение, используя простые запросы. Почему эти инструменты часто работают хорошо для демонстраций, но испытывают трудности, когда компании пытаются развернуть их в реальных производственных средах?

Многие из этих платформ работают хорошо для демонстраций, потому что они оптимизированы для момента создания, а не для жизненного цикла реальной системы.

Но существует фундаментальная разница между использованием ИИ для генерации посадочной страницы и использованием ИИ для создания приложения ИИ.

Посадочная страница – это в основном статическое программное обеспечение. Как только она отображается правильно, работа в основном выполнена. Система не должна принимать вероятностные решения, обрабатывать постоянно меняющиеся данные или адаптироваться к непредсказуемому поведению пользователя.

Приложения ИИ – это совершенно khác. Они являются динамическими системами, которые полагаются на конвейеры данных, поведение модели, кадры оценки и непрерывный мониторинг. Приложение должно управлять контекстом, обнаруживать, когда выходные данные отклоняются, обрабатывать граничные случаи и работать безопасно, когда модель сталкивается с ситуациями, которые она не видела раньше.

Большинство инструментов кодирования, основанных на запросах, не решают эти проблемы, потому что они предназначены для того, чтобы что-то работать быстро. Они генерируют код, который производит видимый результат, который идеален для демонстрационной среды. Но производственные системы требуют гораздо большего набора возможностей: структурированная обработка данных, механизмы управления, конвейеры оценки, наблюдаемость и механизмы для безопасного обновления поведения с течением времени.

Итак, когда компании пытаются развернуть эти системы в реальных средах, разрыв становится очевидным. Прототип работал, потому что среда была контролируемой. Производство – это беспорядок.

Empromptu фокусируется на преобразовании существующего программного обеспечения в системы, родные для ИИ, а не на том, чтобы заставлять компании перестраивать все с нуля. Что это преобразование фактически включает на уровне инфраструктуры и продукта?

На уровне продукта каждое приложение полностью само содержится и контейнеризируется. Мы создаем все, что вам нужно, от интерфейсов, бэкендов, баз данных, моделей, оценок, правил и всего остального, и все это очень гибко в зависимости от потребностей предприятия.

У нас есть несколько вариантов для приложений ИИ:

«Безголовый», поэтому, если у клиента уже есть интерфейс, мы можем подключить его к нашей системе и отправить данные обратно

Полностью контейнеризированный, поэтому они могут быть развернуты на нашей инфраструктуре или в инфраструктуре клиента, поэтому они по умолчанию находятся на месте.

Или мы можем просто сгенерировать их и развернуть напрямую в облаке для наиболее удобного варианта.

Любой код, который у них есть, мы можем импортировать напрямую в нашу систему и агентифицировать его, если он еще не агентифицирован. Например, мы видим это у многих клиентов, которые пытались построить свои приложения на популярных платформах, таких как Lovable, Replit, Bolt или Base44. Часто они не работают. Но клиенты уже вложили много времени и энергии в это приложение, поэтому мы его импортируем, переписываем и делаем все, чтобы ИИ работал.

И мы можем сделать это, потому что у нас есть несколько собственных, проприетарных технологий, таких как:

• Адаптивный контекстный движок для управления контекстом
• Бесконечная память для импорта долгосрочных приложений
• Пользовательские модели данных и золотые конвейеры данных, чтобы обеспечить возможность обработки любых необходимых очистки и синтетического маркирования данных

Ваша платформа подчеркивает контекст, оценку, управление и структурированные данные в качестве основных компонентов систем ИИ. Почему эти элементы так часто упускаются из виду, когда команды спешат добавить функции ИИ к своим продуктам?

Потому что они трудно сделать! Мой сооснователь, доктор Шон Робинсон, возглавляет наш исследовательский центр, и он является вычислительным астрофизиком, который изобрел несколько технологий, вдохновленных моими сумасшедшими идеями, но также потребностями наших клиентов и тем, куда движется рынок. Наш совокупный опыт в создании многих агентных приложений, запуске спутников в космос и работе в крупнейших технологических компаниях мира дает нам представление, которое помогает нам решать сложные проблемы лучше, чем другие.

Вы работаете с многими основателями, которые никогда не писали код раньше. Какие самые большие заблуждения не технических основателей, когда они впервые пытаются создать приложения ИИ?

Я думаю, что есть два больших заблуждения:

Первое – это то, что ИИ – это магия. ИИ – это не магия. Это просто хорошая инженерия. И в конце концов, вы достигаете предела того, что можно сделать на этих платформах без настоящего инженера.

Второе – это то, что у них есть отличные технические навыки управления продуктом. У меня есть опыт в техническом управлении продуктом, и навык перевода видения, иногда очень большого видения, в небольшие отгрузочные части с правильной технической спецификацией для артикуляции именно того, что вы хотите. Это на самом деле очень трудный навык, который требует времени.

Например, скажем, вы строите приложение, которое загружает PDF и сохраняет этот PDF, чтобы вы могли вернуться и просмотреть его позже. Это концепция, называемая сохранением. Этот PDF кодируется в код и сохраняется в базе данных.

Но если вы не знали, что это называется сохранением, как вы будете able набрать? Убедитесь, что эти данные сохраняются. Технический выбор слов – это как говорить на другом языке. Есть разница между написанием на естественном языке и написанием на техническом языке.

Многие стартапы предполагают, что решение проблемы создания продуктов ИИ заключается просто в том, чтобы нанять больше инженеров. Почему вы считаете, что этот подход часто терпит неудачу, и о чем основатели должны думать вместо этого, когда создают продукты, основанные на ИИ?

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

Но ошибка, которую совершают многие стартапы, заключается в том, что они предполагают, что больше инженеров автоматически решает проблему создания продукта ИИ.

На самом деле, самые сложные проблемы в продуктах ИИ часто не являются чисто инженерными проблемами. Они являются системными проблемами, как и каждая другая инженерная проблема. Инженеры специально обучены думать в системах. Но генеративное развитие отличается от детерминированного развития. Многие из нас сделали этот переход, когда мы переходили от объектно-ориентированного программирования к функциональному программированию. Это программирование? Да, абсолютно, но это другой способ мышления? Да, конечно.

Приложения ИИ находятся на пересечении данных, дизайна продукта, операционных рабочих процессов и поведения модели. Вы можете нанять невероятную команду инженеров, но если конвейеры данных ненадежны, критерии оценки неясны или система лишена управления и мониторинга, продукт все равно будет бороться, когда он достигнет реальных пользователей.

Другая проблема заключается в том, что многие команды переходят直接 к созданию, прежде чем они определили, как система ИИ будет вести себя в производстве. Вопросы, такие как как система будет оцениваться, как будут обрабатываться граничные случаи, как будут регистрироваться решения и как модели будут обновляться с течением времени, часто приходят гораздо позже. К тому времени архитектура уже трудна для изменения.

О чем основатели должны действительно думать, так это об операционной модели своей системы ИИ.

Кто владеет конвейером данных?

Как измеряется производительность модели непрерывно, а не только во время разработки?

Что происходит, когда система сталкивается с ситуацией, которую она не видела раньше?

Как вы обновляете поведение безопасно, не нарушая рабочие процессы вниз по потоку?

Иногда решение этих проблем действительно означает нанять больше инженеров. Но это также может означать выбор правильной инфраструктуры, определение сильных ограничений продукта и создание систем, которые позволяют небольшим командам работать надежно в масштабе.

Компании, которые преуспевают в ИИ сегодня, не обязательно являются теми, у которых есть самые крупные инженерные команды. Они являются теми, кто рассматривает ИИ как долгосрочную систему, которая требует дисциплины данных, оценки, управления и непрерывного совершенствования, встроенных с самого начала.

Вы утверждали, что некоторые из текущих бизнес-моделей в инструментах разработки ИИ не соответствуют созданию прочных продуктов. Какие стимулы в текущей экосистеме инструментов ИИ, по вашему мнению, толкают компании в неправильном направлении?

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

Многие компании в этой области вознаграждены за то, как быстро пользователи могут создать что-то впечатляющее. Если инструмент может сгенерировать рабочее приложение, функцию или демонстрацию за несколько минут, это стимулирует регистрацию, обмен в социальных сетях и волнение инвесторов. С точки зрения принятия продукта это имеет смысл.

Но эти стимулы часто останавливаются на моменте создания.

Более сложная работа в программном обеспечении ИИ происходит после этой точки. Это то место, где строится доверие. Когда можно полагаться на качество. Когда пользователь хочет вернуться снова и снова без разочарования ИИ от плохих выходных данных. Нужно давать хорошие ответы, даже перед лицом человеческого невежества или злонамеренности.

Другой проблемой является то, что многие инструменты оптимизированы для генерации кода, а не для проектирования системы. Быстрая генерация кода полезна, но создание продукта ИИ включает в себя больше, чем просто производство кода. Это требует определения того, как система управляет контекстом, как оцениваются решения, как обрабатываются неудачи и как поведение эволюционирует безопасно с течением времени.

Компании, которые выравнивают свои стимулы вокруг помощи клиентам в работе систем ИИ надежно, а не просто в создании их быстро, – это те, которые создадут прочную ценность в этой экосистеме.

Некоторые ваши клиенты включают предпринимателей, строящих очень специфические продукты, такие как специализированные инструменты здравоохранения или бизнес, ориентированный на устойчивость, часто без традиционных команд инженеров. Какие закономерности вы видели среди основателей, которые успешно превращают эти идеи в рабочие продукты ИИ?

Одна из наиболее интересных закономерностей, которую мы видим, заключается в том, что основатели, которые преуспевают, не обязательно являются наиболее техническими. Они являются теми, кто понимает проблему, которую они решают, чрезвычайно хорошо.

Многие предприниматели, использующие Empromptu, – это эксперты в области. Они могут прийти из здравоохранения, финансов, устойчивости или другой специализированной отрасли. То, что они привносят, – это глубокое знание рабочих процессов, правил и решений, существующих в этой среде. Этот контекст чрезвычайно ценен при проектировании продукта ИИ, поскольку он определяет, что система должна делать.

Основатели, которые преуспевают, подходят к ИИ менее как к технологическому эксперименту и более как к системе продукта. Они начинают с того, что задают очень конкретные вопросы. Какие решения должна помочь ИИ пользователям? Какие источники данных ему нужны? Что такое правильный ответ в этой области? Какие ограничения должны существовать, чтобы система вела себя ответственно?

Другой закономерностью является то, что они тщательно думают о структуре. Успешные команды быстро осознают, что выходные данные ИИ так хороши, как контекст и данные, которые их кормят. Они инвестируют время в определение конвейеров данных, организации источников знаний и создания четких критериев оценки того, что означает “хорошо” в этой области.

Мы также видим успешных основателей, которые принимают сотрудничество человека и ИИ вместо того, чтобы пытаться автоматизировать все сразу. Они проектируют рабочие процессы, в которых ИИ обрабатывает повторный анализ или синтез данных, а люди остаются ответственными за суждение и окончательные решения. Этот баланс делает системы намного более надежными, особенно в таких областях, как здравоохранение или финансы.

Во многих отношениях самый большой сдвиг – это изменение мышления. Основатели, которые преуспевают, не думают об ИИ как о функции, которую они добавляют. Они думают об ИИ как о новом операционном слое для того, как работает их продукт.

Когда системы ИИ становятся более интегрированными в основные бизнес-операции, какие возможности будут определять следующее поколение платформ приложений ИИ?

Я знаю, что это сумасшедшее, и я могу сказать что-то святотатственное, но люди смогут кодировать свои собственные пользовательские модели. Что-то, что наш исследовательский центр называет экспертными нано-моделями, поможет контролировать затраты.

Спасибо за отличное интервью. Читателям, которые хотят узнать больше, следует посетить Empromptu AI.