Em 1998, entrei em uma empresa de telecomunicações no Rio de Janeiro como trainee e sentei em frente a uma workstation Sun rodando Solaris. Java tinha apenas três anos de vida. A web era uma curiosidade, não uma plataforma. Renderização no servidor significava scripts CGI. Ninguém tinha ouvido falar de "microsserviços" porque tudo era monolito e ninguém sentia necessidade de dar nome a isso.
Eu tinha vinte anos e não fazia ideia do que estava fazendo.
A primeira coisa que aprendi foi que sistemas em produção não perdoam. Um sistema de billing que cai às 2 da manhã não espera você terminar o café. Uma migração de banco de dados que corrompe registros de chamadas não se importa que tenha funcionado bem em staging. A distância entre "compila" e "roda de forma confiável, em escala, todo dia, por anos" é enorme, e é nesse espaço que a engenharia de verdade acontece.
Vinte e oito anos depois, essa lição não mudou. Todo o resto mudou.
Esta é a história desses vinte e oito anos. Não é uma leitura de currículo — é uma reflexão sobre o que aprendi, o que errei e o que diria para mim mesmo mais jovem se pudesse.
Os primeiros anos: ampliando a lente (1998–2006)
A empresa de telecom foi formativa da forma que os primeiros empregos sempre são. Aprendi Java construindo sistemas reais dos quais pessoas reais dependiam. Aprendi SQL escrevendo consultas contra bancos de dados com milhões de linhas — o que parecia enorme na época e é risivelmente pequeno em retrospecto. Aprendi que os bugs mais difíceis não são aqueles que derrubam seu sistema; são aqueles que silenciosamente produzem respostas erradas por semanas antes que alguém perceba.
De lá fui para um instituto de pesquisa, onde os problemas eram completamente diferentes. Computação acadêmica. Algoritmos. Rigor matemático aplicado a código. O instituto me ensinou que entender a teoria por trás importa — não porque você vai implementar uma árvore rubro-negra do zero em produção, mas porque saber por que um hash map é O(1) amortizado muda a forma como você pensa em design de sistemas.
Depois veio a Alemanha. Uma posição em uma empresa internacional de software de telecom, construindo sistemas que precisavam funcionar em diversos países, idiomas, fusos horários e arcabouços regulatórios. Essa foi minha primeira experiência real com internacionalização — não apenas traduzir strings, mas projetar sistemas que acomodam regras de negócio fundamentalmente diferentes dependendo da geografia. Um número de telefone no Brasil não se parece com um número de telefone na Alemanha. Um ciclo de cobrança em um país tem restrições legais que não existem em outro.
Depois da Alemanha, uma passagem por uma consultoria global. Os anos de consultoria me ensinaram algo que eu não esperava: a diferença entre construir sistemas e aconselhar pessoas que constroem sistemas. Ambos são valiosos. Mas usam músculos diferentes, e confundir os dois é um erro comum.
A lição-chave desses primeiros anos: os fundamentos nunca saem de moda. Estruturas de dados, design de sistemas, metodologia de debugging, escrever código claro. Linguagens mudam. Frameworks mudam. Provedores de nuvem surgem e desaparecem. Mas a capacidade de raciocinar sobre um sistema, rastrear um bug até sua causa raiz e projetar algo que lida com casos de borda com elegância — isso nunca expira. A cada ano que passa, fico mais grato pelo tempo que passei aprendendo fundamentos em vez de correr atrás do framework da moda.
Os anos de mídia: primeiro gosto de escala real (2007–2012)
Mais de cinco anos na maior empresa de mídia do Brasil mudaram minha forma de pensar sobre sistemas. Antes disso, "escala" era um conceito abstrato sobre o qual eu lia. Na empresa de mídia, era a realidade diária.
Milhões de usuários simultâneos. Picos de tráfego em eventos ao vivo que podiam multiplicar por 10 sua linha de base em minutos. Sistemas de entrega de conteúdo que serviam vídeo para um país de 200 milhões de pessoas. Essa foi a era em que aprendi, de forma profunda e dolorosa, que escala muda tudo.
O que funciona para mil usuários não apenas fica lento com um milhão de usuários — ele falha de maneiras fundamentalmente diferentes. Estratégias de cache que fazem sentido em pequena escala viram pesadelos de consistência em grande escala. Padrões de banco de dados elegantes para baixa concorrência viram gargalos sob alta concorrência. Monitoramento que é opcional em um sistema pequeno é existencial em um grande — se você não consegue ver, não consegue consertar, e em escala as coisas quebram constantemente.
A empresa de mídia também me ensinou sobre escala organizacional. Centenas de engenheiros. Dezenas de times. A sobrecarga de coordenação de fazer vinte times concordarem em um contrato de API ou um cronograma de deploy era frequentemente mais difícil que o problema técnico em si. Comecei a entender que os maiores problemas de engenharia não são técnicos — são problemas de comunicação vestindo uma fantasia técnica.
Uma lembrança se destaca. Estávamos construindo uma nova plataforma de gestão de conteúdo, e dois times trabalhavam em funcionalidades sobrepostas há três meses sem perceber. Quando alguém percebeu, ambos já tinham feito deploy em staging. O merge foi brutal — não porque o código fosse ruim (as duas implementações eram sólidas), mas porque ninguém tinha desenhado uma fronteira de sistema num quadro branco e dito "vocês são donos disso, nós somos donos daquilo". Uma reunião de trinta minutos no começo teria economizado três meses de retrabalho.
Essa experiência ficou comigo. Arquitetura técnica sem fronteiras claras de responsabilidade é só um diagrama. A responsabilidade é o que a torna real.
Liderança e consultoria: músculos diferentes (2012–2017)
Depois da empresa de mídia, liderei uma agência digital, fundei minha própria consultoria e aceitei engajamentos de consultoria em diversos lugares do ecossistema tech brasileiro. Esse foi o período em que fiz a transição de "pessoa que constrói sistemas" para "pessoa que lidera as pessoas que constroem sistemas" — e descobri, com alguma humildade, que essas são habilidades muito diferentes.
Ser um bom engenheiro não te torna um bom líder. As habilidades mal se sobrepõem. Como engenheiro, você tem sucesso resolvendo problemas diretamente — você lê o código, encontra o bug, conserta o bug. Como líder, você tem sucesso criando as condições nas quais outras pessoas resolvem problemas bem. Isso significa contratar, mentorar, priorizar, desbloquear e tomar decisões com informação incompleta. Significa aceitar que a solução do time pode ser diferente do que você teria construído, e tudo bem, desde que funcione.
A parte mais difícil foi soltar. Eu tinha passado quinze anos ficando bom em resolver problemas técnicos diretamente. De repente, fazer o trabalho sozinho era a jogada errada — meu trabalho era tornar o time efetivo, não ser o herói que conserta tudo às 2 da manhã. Essa transição levou mais tempo do que gosto de admitir.
Durante esse período, fiz consultoria para um marketplace de e-commerce brasileiro, e a história do hackathon desse engajamento me ensinou uma das lições mais importantes da minha carreira. A empresa tinha um problema massivo de dívida técnica. Centenas de bugs abertos. Uptime rondando 92%. O time de engenharia estava desmoralizado. Ninguém queria trabalhar em bugs porque o roadmap de produto era sempre mais "urgente".
Organizamos um hackathon de dois dias focado inteiramente em matar bugs. Não um hackathon de projetos paralelos — um hackathon do tipo "vamos consertar o máximo de bugs que conseguirmos". O time eliminou 70% dos bugs pendentes em dois dias. O uptime subiu de 92% para 99% nas semanas seguintes. Mas a lição de verdade não era sobre hackathons. Era sobre permissão. O time sabia que os bugs eram importantes. Eles queriam consertá-los. Só precisavam de alguém para dizer "sim, é isso que vamos fazer nos próximos dois dias, o roadmap de produto pode esperar". Os maiores problemas de engenharia frequentemente são culturais, não técnicos. O código nunca foi a parte difícil.
O capítulo da engenharia de dados: o pivot (2017–2024)
Por volta de 2017, fiz um pivot deliberado para engenharia de dados. Não foi uma mudança de carreira aleatória — foi uma aposta em para onde eu achava que a indústria estava indo. Dados estavam se tornando o centro de gravidade de toda empresa de tecnologia séria, e as pessoas capazes de construir sistemas de dados confiáveis e escaláveis eram escassas.
O pivot me levou por alguns dos trabalhos de engenharia mais intensos da minha carreira.
Primeiro, uma empresa de pagamentos fintech. Construir a infraestrutura de dados para uma empresa que movimenta dinheiro é um tipo diferente de engenharia. Cada número tem que estar exatamente certo. "Eventualmente consistente" não é aceitável quando você está reconciliando transações financeiras. A lição: correção supera performance. Um sistema lento que produz números precisos é infinitamente mais valioso que um sistema rápido errado por 0,1%.
Depois, uma plataforma de ad tech entre as 10 maiores. Foi aqui que a escala em petabytes se tornou real. 1,5 bilhão de registros por dia fluindo por pipelines que ajudei a projetar e manter. Jobs Spark processando terabytes em execuções únicas. Otimização de custo não era um "seria bom ter" — era existencial. Quando sua conta mensal de computação está na casa das centenas de milhares, uma melhoria de 5% em eficiência paga o salário de um engenheiro. Reduzi o custo de um pipeline importante em 40% através de otimização de estratégia de partição e tuning cuidadoso do Spark. A lição: o melhor pipeline é aquele que é chato. Confiável. Previsível. Fácil de manter. Ninguém te liga às 3 da manhã por causa de um pipeline chato.
Depois do ad tech, uma plataforma global de viagens. Construir sistemas de dados para uma empresa que opera em dezenas de países, cada um com leis de privacidade de dados, formatos de moeda e regras de negócio diferentes. Foi internacionalização de novo — mas agora com dados. Um usuário na Europa tem direitos sob o GDPR que um usuário no Brasil não tem (o Brasil tem a LGPD, que é similar mas não idêntica). Sua plataforma de dados precisa lidar com tudo isso sem virar um pesadelo de casos especiais.
Depois veio uma startup de logística, onde construí uma plataforma de dados completa do zero. Sem infraestrutura existente. Sem time de dados. Apenas uma empresa em rápido crescimento que precisava tomar decisões baseadas em dados e não tinha como. Projetei a arquitetura, construí os pipelines, montei o warehouse, criei os dashboards e depois treinei o time que manteria tudo depois que saísse. Começar do zero me ensinou que a ordem em que você constrói coisas importa tanto quanto o que você constrói. Se a fundação estiver errada, tudo construído em cima balança.
Um grande provedor de web services fechou essa era. Escala diferente, desafios diferentes, mesmos fundamentos. Cada engajamento reforçou o mesmo padrão: os problemas técnicos têm solução. As partes difíceis são entender o contexto de negócio, definir responsabilidades claras e construir sistemas que humanos consigam de fato manter.
O capítulo da IA: amplificando o julgamento (2024–2026)
O capítulo mais recente começou em 2024, integrando agentes de IA em fluxos de trabalho de dados em uma grande plataforma B2B de dados. Foi aqui que tudo que aprendi em 26 anos convergiu com uma onda tecnológica que acredito ser tão transformadora quanto a internet foi no final dos anos 1990.
O trabalho envolveu Model Context Protocol (MCP), fluxos de trabalho agenticos, guardrails para sistemas de IA em produção e o padrão de base de conhecimento — dar aos agentes de IA uma memória estruturada e persistente sobre sua arquitetura e decisões, para que possam produzir planos de fato úteis em vez de tecnicamente plausíveis mas arquiteturalmente ingênuos.
Eis o que aprendi até agora sobre IA em engenharia de produção:
IA não substitui engenheiros. Ela amplifica o julgamento deles. Um agente de IA com acesso à sua base de código consegue gerar código mais rápido que qualquer humano. Mas o código que ele gera é tão bom quanto o contexto que ele tem. Sem entender por que seu sistema foi construído da forma que foi, quais restrições moldaram a arquitetura, o que falhou no passado — o agente produz trabalho que parece certo mas erra o ponto. O valor não é a IA em si. É a infraestrutura de contexto que você constrói em volta dela.
É por isso que venho escrevendo sobre agentes de IA em pipelines de dados e construção de plataformas de dados — porque o trabalho fundamental de engenharia de estruturar dados, definir responsabilidades claras e documentar decisões se torna mais importante em um mundo aumentado por IA, não menos. IA torna uma boa infraestrutura mais valiosa e uma infraestrutura ruim mais perigosa.
Os times que mais vão se beneficiar da IA não são os com os modelos mais sofisticados. São os com o conhecimento melhor organizado, as fronteiras de sistema mais claras e a maior disciplina em documentar decisões. Vinte e oito anos construindo sistemas de produção me ensinaram que infraestrutura importa. IA torna essa lição dez vezes mais urgente.
O que permaneceu igual em 28 anos
Algumas coisas não mudam. Após quase três décadas, quatro princípios se sustentaram em cada onda tecnológica, cada empresa, cada escala.
Produção não perdoa. Essa foi a primeira lição em 1998 e ainda é a primeira lição em 2026. A distância entre "funciona na minha máquina" e "funciona de forma confiável em produção, em escala, todo dia" é onde toda a engenharia de verdade acontece. Isso não mudou com nuvem, containers, Kubernetes ou IA. Na verdade, o raio de impacto de uma falha em produção só ficou maior.
Os fundamentos nunca expiram. Vi dezenas de frameworks surgirem e caírem. jQuery, Backbone, Angular 1, CoffeeScript, MapReduce — todos foram "essenciais" em algum momento, todos estão mortos ou diminuídos. Mas busca binária ainda funciona. Tabelas hash ainda são O(1). O teorema CAP ainda se aplica. TCP ainda faz o que TCP faz. Se você investe em fundamentos cedo, pode aprender qualquer framework em semanas. Se só aprende frameworks, fica preso reaprendendo do zero a cada poucos anos.
Os problemas mais difíceis são problemas humanos. Todo desafio técnico que encontrei em 28 anos acabou sendo solucionável com tempo e talento suficientes. Mas falha de comunicação entre times? Responsabilidade indefinida? Déficits de confiança? Inércia organizacional? Esses problemas mataram mais projetos do que qualquer limitação técnica jamais matou. A história do hackathon é o exemplo mais claro — o time tinha as habilidades, o código era consertável, a única coisa que faltava era permissão para focar nisso.
Simplicidade vence sempre. Engenheiros júniores constroem sistemas complexos para provar que conseguem. Engenheiros sêniores constroem sistemas simples porque já mantiveram os complexos. A otimização inteligente que economiza 3% de computação mas exige um PhD para debugar quase nunca vale a pena. A solução chata, óbvia e bem documentada, que qualquer engenheiro do time consegue entender e manter — essa é a que sobrevive. Vi arquiteturas "elegantes" demais desmoronarem sob o peso da própria complexidade.
O que mudou completamente
A escala passou de milhares para bilhões. Em 1998, um milhão de linhas em um banco de dados era um sistema de produção sério. Hoje construí pipelines que processam 1,5 bilhão de registros por dia, e isso nem é excepcional pelos padrões modernos. As ferramentas, técnicas e mentalidade exigidas em cada escala são tão diferentes que quase são profissões diferentes. Mas a habilidade central — raciocinar com clareza sobre como os dados fluem por um sistema — é a mesma em qualquer escala.
A nuvem mudou tudo em infraestrutura. Quando comecei, conseguir um novo servidor significava uma ordem de compra, 6 semanas de prazo e uma viagem ao data center. Hoje consigo subir um cluster de cem máquinas em minutos, rodar uma computação e desmontar antes do almoço. Isso mudou não só como construímos sistemas, mas o que imaginamos construir. Categorias inteiras de aplicação que eram impensáveis na era dos racks são triviais na era da nuvem.
IA é a maior mudança desde a internet. Eu estava lá quando a web foi de curiosidade a plataforma. Estou vendo IA fazer a mesma transição agora, e os paralelos são marcantes. Em 1998, as pessoas perguntavam "mas para que você usaria um site?" Hoje perguntam "mas para que você usaria um agente de IA?". A resposta, em ambos os casos, é: coisas que você ainda não imaginou. Os times construindo a infraestrutura agora vão definir as categorias depois.
Trabalho remoto abriu o mundo. Na primeira metade da minha carreira, trabalhar para uma empresa internacional significava se mudar para outro país. Hoje trabalho com times em continentes diferentes do meu escritório em casa. Isso não é apenas conveniência — muda fundamentalmente quem tem acesso a oportunidades. Um engenheiro talentoso em Recife pode trabalhar para uma empresa em São Francisco sem sair de perto da família. Essa é uma mudança profunda, e ainda estamos descobrindo as implicações.
O que eu gostaria de ter sabido antes
Se eu pudesse voltar e dar alguns conselhos para o meu eu de 20 anos — sabendo que ele provavelmente ignoraria a maior parte — é isso que eu diria:
Especialize-se mais cedo. Amplitude é boa. Fico feliz por ter passado por telecom, pesquisa, mídia, consultoria, fintech, ad tech e viagens. Cada domínio me ensinou algo que os outros não ensinariam. Mas é na profundidade que está o valor. No momento em que me especializei em engenharia de dados, minha trajetória de carreira mudou. Passei de "bom generalista" para "a pessoa que você chama quando precisa construir uma plataforma de dados que de fato funciona". Amplitude me deu perspectiva. Profundidade me deu alavancagem. Gostaria de ter encontrado minha profundidade antes.
Escreva mais, mais cedo. Comecei a escrever publicamente muito tarde. Este blog existe porque finalmente percebi que o juro composto das ideias só funciona se você as coloca lá fora. Cada artigo que escrevo clarifica meu pensamento. Cada conceito que explico me força a entendê-lo mais profundamente. Escrever não é uma atividade secundária para engenheiros — é uma habilidade central. Os melhores engenheiros com quem trabalhei eram todos bons escritores. Não é coincidência.
Construa em público mais cedo. Relacionado a escrever, mas mais amplo. Abrir código de ferramentas, compartilhar arquiteturas, escrever sobre fracassos. O efeito de rede de compartilhar seu trabalho é enorme. Pessoas te encontram. Oportunidades aparecem. Colaboradores surgem. Por anos construí coisas em privado, dentro de empresas, atrás de NDAs. Esse trabalho foi valioso, mas invisível. O trabalho que compartilhei publicamente nos últimos dois anos gerou mais oportunidades profissionais do que os dez anos anteriores de trabalho privado combinados.
A melhor jogada de carreira é resolver problemas reais, não perseguir títulos. Perdi tempo no começo da carreira pensando em títulos. Engenheiro sênior. Tech lead. Arquiteto. Diretor. O jogo dos títulos é uma distração. O acelerador de carreira de verdade é ser a pessoa que resolve problemas difíceis. Não a pessoa com o título impressionante, mas a pessoa que as pessoas chamam quando algo está quebrado e precisa funcionar. Resolva problemas difíceis o suficiente e os títulos vêm — e até lá, você já parou de se importar com eles.
Invista em relacionamentos. A coisa mais valiosa desses 28 anos não é nenhuma tecnologia que aprendi. São as pessoas com quem trabalhei. Ex-colegas que viraram co-fundadores. Mentores que abriram portas. Engenheiros que gerenciei e que depois me contrataram como consultor. Sua rede não é uma contagem de conexões no LinkedIn — é o conjunto de pessoas que conhecem seu trabalho e confiam no seu julgamento. Construa isso deliberadamente.
Para onde tudo leva: o stack com que trabalho hoje
Tudo que aprendi em 28 anos converge no trabalho que faço agora. Veja como as peças se encaixam:
A Plataforma de Dados é a fundação — os pipelines, warehouses e orquestração que tornam os dados confiáveis e acessíveis. É aqui que 28 anos construindo sistemas de produção dão retorno mais direto.
A Base de Conhecimento é a memória institucional — um wiki estruturado, mantido por LLM que captura decisões de arquitetura, padrões de falha, conceitos de domínio e topologia de sistemas. Sem isso, os agentes de IA são espertos mas arquiteturalmente ingênuos.
MCP (Model Context Protocol) é a camada de contexto ao vivo — o protocolo que dá aos agentes acesso às suas ferramentas, bancos de dados e serviços com guardrails apropriados. É o complemento em runtime do contexto em "tempo de compilação" da base de conhecimento.
E os Agentes de IA ficam no topo — integrados em fluxos de trabalho de dados, onde podem planejar, gerar, analisar e automatizar. Mas eles só funcionam bem porque as camadas abaixo são sólidas.
Esse stack não é um arcabouço teórico. É o que de fato construo para clientes. E cada camada se apoia em lições de uma parte diferente desses 28 anos. A plataforma de dados se apoia nos anos de mídia em escala e de ad tech. A base de conhecimento se apoia nos anos de consultoria, onde aprendi o quanto conhecimento institucional importa. MCP e a camada de agentes se apoiam no trabalho mais recente. Tudo isso só faz sentido por causa da amplitude de experiência embaixo.
O que vem a seguir
Estou construindo a Mentges.AI. A tese é simples: a maioria dos times precisa de ajuda para integrar IA em seus fluxos de trabalho de dados, e essa ajuda precisa vir de alguém que de fato construiu sistemas de dados em produção — não de alguém que só leu sobre eles.
O trabalho tem três partes:
Consultoria. Ajudar times a projetar e implementar o stack completo — plataformas de dados, bases de conhecimento, fluxos de trabalho agenticos, integrações com MCP. Trabalho hands-on, embutido. Não apresentações de slides e documentos de estratégia. Sistemas reais que vão para produção.
Escrita. Este blog. Pensar em público sobre engenharia de dados, integração com IA e o ofício de construir sistemas que duram. Cada artigo que escrevo se compõe no próximo. O artigo de base de conhecimento informou o artigo de MCP, que informou o artigo de agentes em pipelines, que informou este aqui. Escrever é como eu penso.
Open source. O template de base de conhecimento é a primeira peça. Mais ferramentas e templates estão a caminho — coisas que construo para trabalho de cliente que são gerais o suficiente para compartilhar. Open source é como retribuo à comunidade que me ensinou tudo que sei.
Se você tivesse dito ao trainee de 20 anos daquela empresa de telecom no Rio de Janeiro que em 28 anos ele estaria construindo plataformas de dados aumentadas por IA para empresas ao redor do mundo, de um escritório em casa, escrevendo sobre isso publicamente e abrindo o código das ferramentas — ele não teria acreditado. Não porque soasse ambicioso demais, mas porque a maior parte disso ainda não tinha sido inventada.
Essa é a coisa sobre uma carreira longa em tecnologia. Você não apenas testemunha as mudanças. Você constrói em cima delas. Cada era te dá ferramentas e lições que tornam os desafios da próxima era tratáveis. Os anos de telecom me ensinaram disciplina de produção. Os anos de mídia me ensinaram escala. Os anos de consultoria me ensinaram pessoas. Os anos de engenharia de dados me ensinaram o ofício. E a era da IA está me ensinando que tudo isso foi preparação para algo maior que qualquer peça individual.
Vinte e oito anos depois, estou mais empolgado com engenharia do que nunca. Não porque IA seja chamativa — ela é, mas isso passa. Porque, pela primeira vez, o conhecimento acumulado de uma carreira inteira pode ser estruturado, indexado e tornado útil para máquinas. Cada lição que aprendi do jeito difícil agora pode ser codificada em uma base de conhecimento que torna os agentes de IA mais inteligentes. Cada padrão que reconheci em cinco empresas pode ser documentado em um template que ajuda a próxima pessoa a pular os erros que cometi.
O melhor momento para começar a construir foi 1998. O segundo melhor é agora.
Quer trabalhar comigo?
28 anos construindo sistemas, agora disponíveis para o seu time. Vamos conversar sobre o que você está construindo.