Shanea Leven, Fundadora e CEO da Empromptu AI – Série de Entrevistas

Shanea Leven, Fundadora e CEO da Empromptu AI, é uma veterana líder de produtos com experiência extensa em construir plataformas de desenvolvedores e produtos impulsionados por IA em grandes empresas de tecnologia. Antes de lançar a Empromptu em 2025, ela fundou a CodeSee, uma plataforma de desenvolvedores de IA que ajuda as equipes a visualizar e entender bases de código complexas, que foi adquirida pela GitKraken em 2024. No início de sua carreira, ela ocupou cargos de liderança de produtos seniores em empresas como Docker, Cloudflare, eBay e Google (GOOGL ), onde trabalhou em iniciativas que variavam desde APIs de pagamento do Google Assistant até programas de educação para desenvolvedores usados por centenas de milhares de aprendizes.

Empromptu AI é uma plataforma empresarial projetada para ajudar as organizações a construir e implantar aplicações de IA integradas com mais facilidade. A plataforma combina desenvolvimento de aplicações, integração de dados, governança, avaliações, memória e orquestração de modelos em um único ambiente, permitindo que as empresas passem de experimentação rápida de IA para sistemas de produção com os controles e confiabilidade necessários para uso empresarial.

Você passou mais de 15 anos construindo plataformas de desenvolvedores em empresas como Google, eBay, Cloudflare e Docker antes de fundar a CodeSee, que foi posteriormente adquirida pela GitKraken, e agora lidera a Empromptu AI. Como essas experiências moldaram sua perspectiva sobre por que tantas ferramentas de IA falham assim que saem do estágio de demonstração, e qual problema específico você estava determinado a resolver quando fundou a Empromptu?

Uma das coisas que você aprende ao construir plataformas de desenvolvedores é que os problemas mais difíceis nunca são os que estão na demonstração. A demonstração sempre funciona. O verdadeiro teste é o que acontece quando milhares de desenvolvedores usam o sistema, quando os dados são confusos, quando as integrações quebram e quando os negócios reais dependem disso.

Na Google, Cloudflare, Docker e eBay, eu passei anos trabalhando em plataformas que tinham que operar em escala global. Esses ambientes ensinam algo rapidamente: confiabilidade, governança e observabilidade não são recursos que você adiciona mais tarde. Eles são a arquitetura.

Quando comecei a construir aplicações de IA, os modelos eram terríveis e, à medida que começaram a melhorar, notei que a indústria estava repetindo o mesmo erro que vimos em ondas anteriores de software. Em ferramentas de desenvolvimento, há um conceito que parece ter sido esquecido. Quão rápido você pode chegar ao “hello world”? Hoje, a versão gerativa de “hello world” é um protótipo de aplicação SaaS completo. Mas agora não apenas codificamos aplicações SaaS; codificamos aplicações de IA completas. Uma IA que constrói IA requer outros sistemas para colocar essa IA em produção.

Você pode gerar uma aplicação de IA ou recurso funcionando rapidamente, o que é emocionante e genuinamente útil. Mas os sistemas predominantes ainda carecem da infraestrutura necessária para ambientes de produção. Coisas como pipelines de dados estruturados, frameworks de avaliação, controles de governança, monitoramento e gerenciamento de contexto de longo prazo foram perdidos, mas colocamos tudo isso enquanto mantínhamos todas as partes incríveis do “vibe coding”.

Quando meu co-fundador e eu fundamos a Empromptu, o problema que queríamos resolver era simples: como tornar as aplicações de IA prontas para produção desde o início?

Ao invés de tratar a governança, preparação de dados, avaliação e otimização como ferramentas separadas ou processos posteriores, construímos tudo diretamente na plataforma. A ideia é que as equipes devem ser capazes de construir aplicações de IA rapidamente, mas com a mesma confiabilidade, qualidade e controle que elas esperam de sistemas de software empresariais.

Você tem sido abertamente crítica sobre a lacuna entre demonstrações de IA impressionantes e sistemas prontos para produção. Do seu ponto de vista, quais são os erros arquitetônicos mais comuns que as equipes cometem ao tentar transformar um protótipo de IA em um produto confiável usado por clientes reais?

O erro mais comum que as equipes cometem é supor que o modelo é o produto.

Nos protótipos iniciais, o modelo faz a maior parte do trabalho visível. Você o promove, ele produz uma resposta e, se a resposta parecer boa, o sistema parece funcionar. Isso cria a ilusão de que melhorar o modelo é o principal desafio.

Mas em sistemas de produção, o modelo é apenas um componente em uma arquitetura muito maior.

O primeiro erro é tratar os dados como uma afterthought. Nos protótipos, as equipes frequentemente testam com conjuntos de dados pequenos e limpos. Uma vez que o sistema se conecta a dados operacionais reais, as coisas mudam rapidamente. Os dados chegam incompletos, inconsistentes, duplicados ou em formatos inesperados. Sem um pipeline de dados estruturado para normalizar e validar as entradas, o sistema se torna instável, independentemente de quão bom o modelo seja.

O segundo erro é a falta de frameworks de avaliação. Muitas equipes lançam recursos de IA sem definir o que “bom” realmente significa. Eles podem verificar manualmente as saídas durante o desenvolvimento, mas não constroem pipelines de avaliação automatizados que continuamente medem a precisão, deriva e casos de bordo uma vez que o sistema está ao vivo. Sem esses guardrails, as falhas são frequentemente descobertas pelos clientes em vez dos engenheiros.

Um terceiro problema é a falta de mecanismos de governança e controle. Os sistemas de IA são probabilísticos, o que significa que podem se comportar de maneira diferente sob condições ligeiramente diferentes. Em ambientes regulamentados ou de alto risco, essa imprevisibilidade precisa ser limitada por políticas determinísticas, fluxos de trabalho de aprovação e logs de auditoria que capturam como as decisões foram tomadas.

O que isso realmente se resume é que os sistemas de IA de produção não são apenas modelos. Eles são sistemas operacionais.

As empresas que estão tendo sucesso com a IA hoje são aquelas que tratam pipelines de dados, avaliação, governança e monitoramento como infraestrutura central, não como recursos opcionais.

Muitas plataformas de codificação de IA prometem que qualquer pessoa pode construir uma aplicação usando prompts simples. Por que essas ferramentas frequentemente funcionam bem para demonstrações, mas lutam quando as empresas tentam implantá-las em ambientes de produção reais?

Muitas dessas plataformas funcionam bem para demonstrações porque são otimizadas para o momento da criação, não para o ciclo de vida de um sistema real.

Mas há uma diferença fundamental entre usar IA para gerar uma página de destino e usar IA para construir uma aplicação de IA.

Uma página de destino é principalmente um software estático. Uma vez que renderiza corretamente, o trabalho está basicamente feito. O sistema não precisa tomar decisões probabilísticas, ingerir dados em constante mudança ou se adaptar a comportamentos de usuário imprevisíveis.

As aplicações de IA são completamente diferentes. Elas são sistemas dinâmicos que dependem de pipelines de dados, comportamento de modelo, frameworks de avaliação e monitoramento contínuo. A aplicação precisa gerenciar contexto, detectar quando as saídas se desviam, lidar com casos de bordo e operar com segurança quando o modelo encontra situações que nunca viu antes.

A maioria das ferramentas de codificação baseadas em prompts não aborda essas camadas porque elas são projetadas para obter algo funcionando rapidamente. Elas geram código que produz um resultado visível, o que é perfeito para um ambiente de demonstração. Mas os sistemas de produção exigem um conjunto muito maior de capacidades: tratamento de dados estruturados, controles de governança, pipelines de avaliação, observabilidade e mecanismos para atualizar o comportamento com segurança ao longo do tempo.

Então, quando as empresas tentam implantar esses sistemas em ambientes reais, a lacuna se torna óbvia. O protótipo funcionou porque o ambiente era controlado. A produção é confusa.

A Empromptu se concentra em transformar o software existente em sistemas nativos de IA, em vez de forçar as empresas a reconstruir tudo do zero. O que essa transformação realmente envolve no nível de infraestrutura e produto?

No nível do produto, cada aplicação é totalmente autossuficiente e containerizada. Criamos tudo o que você precisa, desde front-ends, back-ends, bancos de dados, modelos, avaliações, regras e tudo é super flexível, dependendo das necessidades da empresa.

Temos várias opções para aplicativos de IA:

“Headless”, então, se um cliente já tiver uma interface do usuário, podemos conectá-la ao nosso sistema e enviar os dados de volta.

Completamente containerizado, então eles podem ser implantados em nossa infraestrutura ou dentro da infraestrutura do cliente, então eles são on-prem por padrão.

Ou podemos simplesmente gerá-los e implantá-los diretamente na nuvem para a opção mais conveniente.

Qualquer código que eles tenham, podemos importá-lo diretamente para nosso sistema e torná-lo um agente, se ainda não for um agente. Por exemplo, vemos isso com vários clientes que tentaram construir seus aplicativos em plataformas populares como Lovable, Replit, Bolt ou Base44. Muitas vezes, elas não funcionam. Mas os clientes já investiram muito tempo e energia nesse aplicativo, então ingerimos, reescrevemos e fazemos com que todo o trabalho de IA funcione.

E podemos fazer isso porque temos várias tecnologias personalizadas e proprietárias, como:

• Motor de contexto adaptável para gerenciar contexto
• Memória infinita para ingerir aplicações de código de longa execução
• Modelos de dados personalizados e pipelines de dados dourados para garantir que possamos lidar com qualquer limpeza de dados e rotulagem sintética necessária

Sua plataforma destaca contexto, avaliação, governança e dados estruturados como componentes centrais dos sistemas de IA. Por que esses elementos são frequentemente negligenciados quando as equipes correm para adicionar recursos de IA aos seus produtos?

Porque são difíceis de fazer! Meu co-fundador, Dr. Sean Robinson, lidera nosso laboratório de pesquisa e é um astrofísico computacional que inventou várias tecnologias inspiradas em minhas ideias loucas, mas também nas necessidades de nossos clientes e no rumo do mercado. Nossa experiência combinada em construir muitas aplicações agentes, colocar satélites no espaço e construir nas maiores empresas de tecnologia do mundo nos dá insights que nos ajudam a resolver problemas complicados melhor do que outras pessoas podem.

Você trabalha com muitos fundadores que nunca escreveram código antes. Quais são os maiores mal-entendidos que os fundadores não técnicos têm quando tentam construir aplicações de IA pela primeira vez?

Acho que há dois grandes mal-entendidos:

O primeiro é que a IA é mágica. A IA não é mágica. É apenas boa engenharia. E, eventualmente, você atinge um limite no que pode fazer nessas plataformas sem um engenheiro real.

O segundo é que eles têm habilidades técnicas de gerenciamento de produtos excelentes. Tenho um background em gerenciamento de produtos técnicos e a habilidade de traduzir uma visão, às vezes uma visão muito grande, em pequenos pedaços transportáveis com a especificação técnica certa para articular exatamente o que você quer. Isso é uma habilidade muito difícil que leva tempo.

Por exemplo, digamos que você está construindo um aplicativo que faz upload de um PDF e salva esse PDF para que você possa voltar e visualizá-lo mais tarde. Isso é um conceito chamado persistência. Esse PDF é codificado em código e salvo em um banco de dados.

Mas, se você não soubesse que isso era chamado de persistência, como você seria capaz de digitar? Certifique-se de que esses dados persistam. A escolha de palavras técnicas é como falar uma língua diferente. Há uma diferença entre escrever em linguagem natural e escrever em linguagem técnica.

Muitas startups assumem que a solução para construir produtos de IA é simplesmente contratar mais engenheiros. Por que você acredita que essa abordagem frequentemente falha, e o que os fundadores devem estar pensando em vez disso ao construir produtos impulsionados por IA?

Contratar mais engenheiros é às vezes a resposta certa. Se você está construindo um produto tecnicamente profundo ou trabalhando na fronteira da pesquisa de modelos, você absolutamente precisa de equipes de engenharia sólidas. Não há substituto para bons engenheiros quando se trata de resolver problemas difíceis.

Mas o erro que muitas startups cometem é supor que mais engenheiros automaticamente resolve o desafio de construir um produto de IA.

Na realidade, os problemas mais difíceis em produtos de IA não são apenas problemas de engenharia. São problemas de sistemas, assim como todos os outros problemas de engenharia. Os engenheiros são especificamente ensinados a pensar em sistemas. Mas o desenvolvimento gerativo é diferente do desenvolvimento determinístico. Muitos de nós fizeram essa transição quando estávamos mudando da programação orientada a objetos para a programação funcional. São ambas programações? Sim, absolutamente, mas são diferentes? São uma forma diferente de pensar? Sim, claro.

As aplicações de IA estão na interseção de dados, design de produto, fluxos de trabalho operacionais e comportamento de modelo. Você pode contratar uma equipe incrível de engenheiros, mas se os pipelines de dados forem instáveis, os critérios de avaliação forem incertos ou o sistema carecer de governança e monitoramento, o produto ainda lutará quando atingir os usuários reais.

Outro problema é que muitas equipes pulam diretamente para a construção antes de terem definido como o sistema de IA se comportará em produção. Perguntas como como o sistema será avaliado, como os casos de bordo serão tratados, como as decisões serão registradas e como os modelos serão atualizados ao longo do tempo frequentemente vêm muito mais tarde. Nesse ponto, a arquitetura já é difícil de alterar.

O que os fundadores realmente devem estar pensando é o modelo operacional do sistema de IA.

Quem é o dono do pipeline de dados?

Como o desempenho do modelo é medido continuamente, não apenas durante o desenvolvimento?

O que acontece quando o sistema encontra uma situação que nunca viu antes?

Como você atualiza o comportamento com segurança sem quebrar fluxos de trabalho downstream?

Às vezes, resolver esses problemas significa contratar mais engenheiros. Mas também pode significar escolher a infraestrutura certa, definir fortes restrições de produto e construir sistemas que permitem que equipes pequenas operem de forma confiável em escala.

As empresas que estão tendo sucesso com a IA hoje não são necessariamente aquelas com as maiores equipes de engenharia. São aquelas que tratam a IA como um sistema de longo prazo que precisa de disciplina de dados, avaliação, governança e melhoria contínua construída desde o início.

Você argumentou que alguns dos atuais modelos de negócios em ferramentas de desenvolvedor de IA não estão alinhados com a construção de produtos duráveis. Quais incentivos no ecossistema atual de ferramentas de IA você acredita que estão levando as empresas no caminho errado?

Um dos principais desalinhamentos de incentivos agora é que muitas ferramentas de desenvolvedor de IA são otimizadas para métricas de crescimento em vez de durabilidade do produto.

Muitas empresas nesse espaço são recompensadas por quão rapidamente os usuários podem criar algo impressionante. Se uma ferramenta pode gerar um aplicativo funcionando, um recurso ou uma demonstração em alguns minutos, isso impulsiona inscrições, compartilhamento nas redes sociais e entusiasmo dos investidores. Do ponto de vista da adoção do produto, isso faz sentido.

Mas esses incentivos frequentemente param no momento da criação.

O trabalho mais difícil em software de IA acontece após esse ponto. É quando a confiança é construída. Quando você pode confiar na qualidade. Que o usuário queira voltar novamente e novamente sem a frustração de IA de saídas ruins. Precisa dar respostas boas mesmo diante da ignorância humana ou da maldade.

Outro problema é que muitas ferramentas são otimizadas para geração de código em vez de design de sistema. Gerar código rapidamente é útil, mas construir um produto de IA envolve mais do que produzir código. Requer definir como o sistema gerencia o contexto, como as decisões são avaliadas, como as falhas são tratadas e como o comportamento evolui com segurança ao longo do tempo.

As empresas que alinham seus incentivos em torno de ajudar os clientes a executar sistemas de IA de forma confiável, e não apenas construí-los rapidamente, são aquelas que criarão valor duradouro nesse ecossistema.

Alguns de seus clientes incluem empreendedores que estão construindo produtos muito específicos, como ferramentas de saúde especializadas ou empresas focadas em sustentabilidade, frequentemente sem equipes de engenharia tradicionais. Quais padrões você viu entre os fundadores que com sucesso transformam essas ideias em produtos de IA funcionais? 

Um dos padrões mais interessantes que vemos é que os fundadores que têm sucesso não são necessariamente os mais técnicos. Eles são os que entendem extremamente bem o problema que estão resolvendo.

Muitos dos empreendedores que usam a Empromptu são especialistas em domínio. Eles podem vir de saúde, finanças, sustentabilidade ou outra indústria especializada. O que eles trazem é um conhecimento profundo dos fluxos de trabalho, regulamentações e decisões que existem nesse ambiente. Esse contexto é incrivelmente valioso ao projetar um produto de IA, pois define o que o sistema realmente precisa fazer.

Os fundadores que têm sucesso tendem a abordar a IA menos como um experimento tecnológico e mais como um sistema de produto. Eles começam fazendo perguntas muito concretas. Quais decisões o IA deve ajudar os usuários a tomar? Quais fontes de dados ele precisa acessar? O que uma resposta correta realmente parece nesse domínio? Quais guardrails precisam existir para que o sistema se comporte de forma responsável?

Outro padrão é que eles pensam cuidadosamente sobre a estrutura. As equipes bem-sucedidas rapidamente percebem que as saídas de IA são apenas tão boas quanto o contexto e os dados que as alimentam. Eles investem tempo no início para definir pipelines de dados, organizar fontes de conhecimento e criar critérios de avaliação claros para o que “bom” parece.

Também vemos fundadores bem-sucedidos abraçando a colaboração humano-IA em vez de tentar automatizar tudo imediatamente. Eles projetam fluxos de trabalho onde a IA lida com análise repetitiva ou síntese de dados, enquanto os humanos permanecem responsáveis por julgamento e decisões finais. Esse equilíbrio torna os sistemas muito mais confiáveis, especialmente em campos como saúde ou finanças.

De muitas maneiras, a maior mudança é a mentalidade. Os fundadores que têm sucesso não pensam na IA como um recurso que estão adicionando. Eles pensam na IA como uma nova camada operacional para como o produto funciona.

À medida que os sistemas de IA se tornam mais integrados às operações comerciais centrais, quais capacidades definirão a próxima geração de plataformas de aplicativos de IA? 

Eu sei que isso é louco e posso estar dizendo algo sacrílego, mas as pessoas serão capazes de “vibe-code” seus próprios modelos personalizados. Algo que nosso laboratório de pesquisa está chamando de modelos nano especialistas ajudará a controlar os custos.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Empromptu AI.