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 equipes a visualizar e entender código complexo, que foi adquirida pela GitKraken em 2024. No início de sua carreira, ela ocupou cargos de liderança de produtos sênior em empresas como Docker, Cloudflare, eBay e Google, onde trabalhou em iniciativas que variam desde APIs de pagamento do Google Assistant até programas de educação de desenvolvedores usados por centenas de milhares de aprendizes.

Empromptu AI é uma plataforma de empresa projetada para ajudar organizações a construir e implantar aplicações de IA integradas mais facilmente. 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 de IA rápida 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 estão desorganizados, 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 aplicativo SaaS completo. Mas agora não apenas codificamos aplicativos SaaS; codificamos aplicações de IA inteiras. Uma IA que constrói IA requer outros sistemas para colocar essa IA em produção.

Você pode gerar um aplicativo de IA 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, estruturas de avaliação, controles de governança, monitoramento e gerenciamento de contexto de longo prazo foram perdidos, mas colocamos todos esses elementos em nossa plataforma, mantendo todas as partes incríveis da codificação por vibração.

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?

Em vez de tratar governança, preparação de dados, avaliação e otimização como ferramentas separadas ou processos posteriores, construímos esses elementos 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 de produção prontos. Na sua perspectiva, 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ê fornece um prompt, 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 pouco confiável, independentemente de quão bom seja o modelo.

O segundo erro é a ausência de estruturas de avaliação. Muitas equipes lançam recursos de IA sem definir o que “bom” realmente significa. Elas podem verificar manualmente as saídas durante o desenvolvimento, mas não constroem pipelines de avaliação automatizados que continuamente medem a precisão, o drift e os 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 constrangida com políticas determinísticas, fluxos de trabalho de aprovação e logs de auditoria que capturam como as decisões foram tomadas.

Isso realmente se resume ao fato de 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, e não como recursos opcionais.

Muitas plataformas de codificação de IA prometem que qualquer pessoa pode construir um aplicativo 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 um aplicativo de IA.

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

Os aplicativos de IA são completamente diferentes. Eles são sistemas dinâmicos que dependem de pipelines de dados, comportamento de modelo, estruturas de avaliação e monitoramento contínuo. O aplicativo 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 por prompt 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 é desordenada.

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 aplicativo é totalmente autocontido e containerizado. Nós criamos tudo o que você precisa, desde front-ends, back-ends, bancos de dados, modelos, avaliações, regras e tudo mais, e é super flexível, dependendo das necessidades da empresa.

Nós temos várias opções para aplicativos de IA:

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

Totalmente containerizado, então eles podem ser implantados em nossa infraestrutura ou dentro da infraestrutura do cliente, então eles são implantados localmente 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 não for um agente ainda. Por exemplo, vemos isso com muitos clientes que tentaram construir seus aplicativos em plataformas populares como Lovable, Replit, Bolt ou Base44. Muitas vezes, eles não funcionam. Mas os clientes já investiram muito tempo e energia e créditos nesse aplicativo, então nós 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 enfatiza 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 ele é 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 muitos aplicativos 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. Eu 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 pedaços de entrega pequenos 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 carrega um PDF e o salva para que você possa voltar e visualizá-lo mais tarde. Isso é um conceito chamado persistência. Esse PDF é codificado e salvo em um banco de dados.

Mas se você não soubesse que isso era chamado de persistência, como você poderia 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 ao construir produtos de 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, 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.

Os aplicativos 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 são pouco confiáveis, os critérios de avaliação são incertos, ou o sistema carece 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 mudar.

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 os 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 as que têm as maiores equipes de engenharia. São as 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 desenvolvedores 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?

Uma das maiores discrepâncias de incentivos no momento é que muitas ferramentas de desenvolvedores 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 poucos 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 no software de IA acontece após esse ponto. É quando a confiança é construída. Quando você pode confiar na qualidade. Quando o usuário quer voltar novamente e novamente sem a frustração de IA de saída ruim. Precisa fornecer 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 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 as que criarão valor duradouro nesse ecossistema.

Alguns de seus clientes incluem empreendedores que constróem 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 o problema que estão resolvendo extremamente bem.

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 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. Elas investem tempo antes de definir pipelines de dados, organizar fontes de conhecimento e criar critérios de avaliação claros para o que “bom” significa.

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.

Em muitos aspectos, a maior mudança é de 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 seu 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 poderão codificar por vibração seus próprios modelos personalizados. Algo que nosso laboratório de pesquisa está chamando de modelos nano especializados ajudará a controlar os custos.

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