Há cerca de um ano, fiquei obcecado por uma ideia: entender se era possível aplicar na Pomelo a forma de operar das empresas AI-Native, mas em outra escala. Ao analisar essas empresas, comecei a identificar padrões que se repetiam: times pequenos, agentes participando ativamente do trabalho do dia a dia, especificações como eixo de coordenação e uma velocidade de execução difícil de alcançar com estruturas tradicionais.
A pergunta deixou de ser tecnológica e passou a ser organizacional. Era possível aplicar esses princípios na Pomelo, uma empresa que atende centenas de clientes, processa milhões de transações e opera emissão em escala global? A resposta é sim:
Em 12 meses, multiplicamos por 6X o throughput de engenharia;- Melhoramos em 3,2X o time to delivery;
- Melhoramos praticamente todos os indicadores de saúde da nossa plataforma, incluindo uptime, capacidade de processamento e resiliência operacional;
E, talvez mais importante ainda, começamos a transformar a forma como construímos nosso produto, como nos organizamos e como nosso time e nossa plataforma operam. Conheça os detalhes a seguir.
Por onde comecei?
A primeira constatação ao analisar empresas AI-Native foi quase incômoda: o que tradicionalmente exigia times de dez ou quinze pessoas passou a ser feito por três ou quatro pessoas trabalhando com agentes. Não porque trabalhassem mais ou fossem melhores, mas porque operavam sob uma lógica completamente diferente.
Por isso, posso afirmar uma coisa: pensar que a inteligência artificial se limita a automatizar fluxos ou gerar código é uma visão míope. A mudança real acontece quando você para de adaptar a organização que já existe e começa a repensá-la a partir dessa nova lógica. E o verdadeiro desafio é fazer isso em um negócio em plena operação, com centenas de pessoas atendendo centenas de clientes em quase dez países.
O contexto é a matéria-prima
Para que um agente funcione, sua principal matéria-prima é o contexto. Sem contexto, ele não sabe o que fazer nem o que responder; com o contexto certo, amplifica a capacidade de qualquer pessoa ou time.
Em uma organização AI-Native, a documentação deixa de ser um entregável criado uma vez e rapidamente desatualizado para se tornar o lugar onde uma ideia evolui: começa em uma conversa sobre um problema de negócio, passa pela uma definição de produto e pelas decisões técnicas, até se transformar no contexto consumido pelos agentes responsáveis por construir e validar. Deixa de ser apenas "documentação" e passa a ser "especificação": a linguagem comum que conecta negócio, produto, engenharia e agentes. Quando isso acontece, a qualidade das conversas melhora e boa parte das perdas de contexto entre times começa a desaparecer.
Daí que o Spec Driven Development (SDD) começou a fazer sentido para nós, não como metodologia, mas como uma consequência natural de trabalhar com a IA. Hoje, quando você define algo, o Claude pergunta se você quer criar uma especificação. Em uma startup de três a dez pessoas, isso flui quase naturalmente. Nosso desafio era outro: fazer com que centenas de pessoas produzissem especificações com um nível consistente de qualidade; que negócio, produto e engenharia compartilhassem um único framework de trabalho; e que os agentes recebessem contexto estruturado sem que o ganho de velocidade comprometesse a qualidade.
Um dos aprendizados mais importantes foi entender que o SDD não escala simplesmente porque as pessoas passam a escrever especificações melhores. Ele escala quando a organização consegue transformar seu conhecimento em contexto continuamente acessível e utilizável pelos agentes.
Primeiro, a infraestrutura
Por isso, antes de transformar nossa forma de trabalhar, transformamos a infraestrutura. Incorporamos uma camada de MCPs como principal fonte de contexto para os agentes e como mecanismo para conectar sistemas, conhecimento e skills: uma layer de capacidades distribuídas pela organização. Em outras palavras, preparamos nossa infraestrutura para um cenário em que pessoas e agentes trabalham juntos.
Sobre essa base, construímos uma camada de agentes conectados a esse contexto e um AI Gateway que nos permitiu governar modelos, custos, ambientes e responsabilidades em outra escala. Hoje, 100% do nosso uso de IA passa por esse gateway, e os produtos novos já nascem MCP-first. Nada disso é necessário para uma empresa AI-Native pequena, mas se torna fundamental quando se opera em escala.
Com essas mudanças, conseguimos dar aos agentes o contexto de produtos que já existiam e comprovamos algo essencial: quanto melhor o contexto, melhor o desempenho dos agentes. Isso nos levou ao próximo passo: transformar essa dinâmica em uma prática contínua, simples e automática, como acontece em uma empresa AI-Native. Para isso, tivemos que repensar todos os nossos processos.
Os processos determinam como a informação flui: como uma necessidade de negócio se transforma em uma definição de produto, depois em especificação funcional e, por fim, em definição técnica. Uma das surpresas mais interessantes desse percurso foi perceber que as especificações funcionais que hoje construímos com a IAI atingem um nível de profundidade, precisão e contexto que dificilmente uma pessoa conseguiria produzir sozinha. O resultado é um input muito mais completo para produto, arquitetura, engenharia e agentes.
A iteração constante entre negócio, produto e tecnologia, amplificada pela IA, acaba produzindo algo mais importante do que ganhos de produtividade: cria as condições para construir uma organização melhor. Esse é o conceito que realmente permite evoluir. Não se trata apenas de melhorar as ferramentas, mas de transformar os processos para evoluir a organização.
Uma nova geração de builders
Quando se fala do futuro do desenvolvimento de software, a conversa costuma se resumir a uma pergunta bastante limitada: a IA vai substituir os desenvolvedores? Acho que estamos olhando para a perspectiva errada. A transformação real não está em quanto código um developer escreve, mas no que passa a significar construir software.
Nesse modelo, o engenheiro deixa de ser principalmente um implementador e passa a desenhar uma fábrica de software. Define especificações, desenha agentes, decide qual contexto eles recebem, estabelece mecanismos de validação e controles de qualidade, garante segurança, escalabilidade e observabilidade, e valida se o resultado gerado pelo sistema corresponde à intenção original. Para que os agentes funcionem, existe uma enorme quantidade de engenharia por trás: acesso à informação, contexto, conhecimento organizacional e pessoas capazes de desenhá-los, construí-los, orquestrá-los e mantê-los funcionando em escala.
As especificações se tornam uma peça central porque permitem transmitir intenção em escala: não só ajudam uma pessoa a entender o que precisa ser construído, como também permitem coordenar um conjunto de agentes trabalhando sobre uma mesma necessidade.
O gargalo deixou de ser construir e passou a ser revisar: hoje produzimos mais do que conseguimos revisar. E esse é exatamente o problema que queremos ter. Quando a velocidade de construção deixa de ser o fator limitante, a qualidade das decisões passa a ocupar o centro da discussão.
Menos camadas, mais times: os micro-squads
Ouvimos cada vez mais que a inteligência artificial está eliminando o middle management, quase sempre com a mesma explicação: eficiência, redução de custos, menos camadas. Depois de um ano de aprendizado, acho que a eficiência é uma consequência, não a causa. O que realmente acontece é que a IA amplia a capacidade dos dois extremos da organização ao mesmo tempo.
De um lado, as pessoas com mais contexto aumentam enormemente sua capacidade de analisar, desenhar, decidir e liderar. Do outro, quem está mais próximo da execução passa a trabalhar com por agentes que ajudam a construir, validar, documentar, revisar e operar. Quando a capacidade aumenta nos dois extremos, boa parte do trabalho que historicamente ficava no meio se redistribui de forma natural. Não porque alguém decida eliminá-lo, mas porque ele deixa de ser necessário. Ao longo deste ano, isso significou remover uma ou duas camadas de management por área: não como resultado de cortes, mas porque a própria mudança tornou essas camadas desnecessárias e nos permitiu expandir horizontalmente e multiplicar nossos micro-squads, aumentando nossa capacidade de produção e o throughput de engenharia.
A distância entre uma ideia e sua execução diminui, e boa parte da energia antes dedicada à coordenação passa a estar disponível para construir. Foi aí que surgiram os micro-squads: times menores e mais autônomos, dentro de uma organização mais horizontal. O objetivo deixou de ser otimizar uma estrutura por mandato e passou a ser multiplicar a quantidade de times capazes de gerar entregas concretas.
Para mim, essa é uma das diferenças mais importantes entre adotar ferramentas de IA e construir uma organização AI-Native: a primeira busca eficiência; a segunda busca transformar a organização em uma versão melhor do que era antes.
Não é só software
Se eu tivesse que resumir todo esse percurso em uma única ideia, seria esta: a inteligência artificial não está mudando apenas a forma como construímos software. Estamos diante de um salto geracional na forma de construir negócios digitais.
Surge uma nova geração de engenheiros com capacidades amplificadas pela IA, em linha com um conceito sobre o qual venho escrevendo há anos e que hoje é mais relevante do que nunca: o product engineer. Um papel de tecnologia muito mais amplo do que o tradicional, que exige não apenas domínio da tecnologia usada para construir software, mas também um entendimento profundo do produto, do negócio e da operação da empresa de ponta a ponta.
Encaro isso pelo que é: um compromisso com a evolução. Não com uma ideia abstrata de transformação, mas com a evolução rumo a uma Pomelo melhor do que a que tínhamos há um ano. E isso está só começando.
