Código é Lava: O Que um Hackathon de 48 Horas Nos Ensinou Sobre Engenharia AI-Native
TL;DR — Em fevereiro de 2026, a KYP realizou um hackathon interno de três dias com uma premissa deliberadamente provocativa: cinco times, um sistema de produção real para reescrever, dois dias para construí-lo, IA como principal força de engenharia. O tema foi “Código é Lava” — a ideia de que software escrito manualmente envelhece tão rápido que pode muito bem ser derretido, e que a capacidade de regenerar software de alta qualidade com IA é agora a habilidade de engenharia mais importante. O time vencedor usou uma linguagem que nenhum deles jamais tinha escrito. O segundo colocado passou o primeiro dia inteiro planejando com agentes sem escrever uma única linha de código. Ambos os resultados foram surpresas. Nenhum deles deveria ter sido.
Por Que Fizemos Isso
A KYP não está experimentando desenvolvimento assistido por IA. Nós nos comprometemos com ele. O modelo operacional que estamos construindo — fluxos de trabalho orientados por spec, frameworks multi-agente BMAD, contexto organizacional como código — não é um piloto. É a direção.
Mas comprometimento não é o mesmo que capacidade. Você não consegue mudar um modelo mental de engenharia apenas lendo. Você precisa construir algo real, sob pressão, com feedback que seja imediato e inequívoco.
O hackathon foi essa função de força. Não uma vitrine. Não um exercício de team building. Um experimento projetado para responder a uma pergunta específica: como é realmente quando engenheiros tratam a IA como principal força de implementação — e o que separa os times que fazem isso bem dos que têm dificuldades?
Trinta e sete pessoas — engenheiros e líderes de engenharia — formaram cinco times e passaram dois dias construindo a mesma coisa: uma reescrita completa de um sistema interno real com requisitos de performance reais e complexidade arquitetural real. Os times escolheram suas próprias linguagens, suas próprias abordagens arquiteturais e seus próprios fluxos de trabalho com IA. A única restrição era o spec e o prazo.
O Setup: Um Problema Real, Não um Brinquedo
O sistema que escolhemos reescrever foi selecionado precisamente porque não é simples. Ele avalia ativos financeiros orquestrando chamadas a múltiplas fontes de dados externas — cada uma com características de confiabilidade diferentes, perfis de latência diferentes (variando de milissegundos a mais de dez segundos) e modos de falha diferentes. A arquitetura que você escolhe para esse tipo de sistema revela seus instintos sobre design de sistemas distribuídos.
Entregamos a cada time requisitos funcionais e não funcionais documentados, uma API mock que simulava o comportamento real de produção incluindo variância de latência, infraestrutura provisionada e um dataset de teste para validação. Os critérios de julgamento foram explícitos: qualidade de arquitetura, extensibilidade, performance medida e throughput — avaliados objetivamente a partir dos resultados dos testes, não dos slides.
Um critério bônus opcional foi incluído: criticidade de avaliação configurável por tipo de ativo. Era mais difícil de implementar do que os requisitos principais, e os times que entregassem precisariam ter planejado para isso desde o início — não é algo que você adiciona no final.
O Que os Resultados Revelaram
Planejamento não é o oposto da velocidade — é o pré-requisito para ela
O resultado mais contraintuitivo do evento veio do time que passou o primeiro dia inteiro em planejamento estruturado com agentes de IA. PRD completo, épicos, breakdown de sprint — usando o framework multi-agente BMAD antes de escrever uma única linha de código de produção. De fora, parecia que eles estavam ficando para trás.
Eles foram o único time a entregar o critério bônus. Totalmente implementado, corretamente dimensionado, funcionando na demo.
O mecanismo não é misterioso em retrospecto. Uma especificação precisa o suficiente — com critérios de aceite bem definidos, restrições explícitas e limites claros entre componentes — é algo que agentes conseguem executar com alta fidelidade. Um spec vago produz código confiante, bem formatado e errado. O time que investiu em precisão desde o início não perdeu tempo. Eles eliminaram o retrabalho que a imprecisão cria.
Esse é o insight do BMAD tornado concreto: os agentes de planejamento não são overhead no processo de desenvolvimento. Eles são o processo de desenvolvimento. Geração de código é a parte fácil.
Expertise em linguagem não é mais pré-requisito para excelência na linguagem
O time vencedor usou Go. Nenhum deles tinha escrito Go antes do hackathon. Em 48 horas, entregaram a solução tecnicamente mais madura — com roteamento dinâmico de serviços externos, circuit breakers, controles de concorrência e observabilidade de nível de produção — em uma linguagem que aprenderam durante o evento.
Isso merece reflexão. Não estamos dizendo que expertise em linguagem é irrelevante. Conhecimento profundo dos idiomas, ecossistema e características de performance de uma linguagem ainda importa. O que estamos dizendo é que o custo de adquirir fluência suficiente para construir software de qualidade de produção em uma linguagem desconhecida caiu para 48 horas quando a IA está fazendo a implementação.
A implicação para como tomamos decisões técnicas é significativa. Escolher uma linguagem com base no que o time já conhece — em vez do que melhor se encaixa no problema — é um argumento mais fraco do que costumava ser. O que o time vencedor demonstrou é que a restrição não é mais familiaridade. É a qualidade do raciocínio por trás da especificação.
Tratar dependências externas como não confiáveis é um instinto de produção, não uma técnica avançada
A decisão arquitetural que mais claramente separou as melhores soluções das demais foi como os times lidaram com as fontes de dados externas. As fontes têm características de latência altamente variáveis — algumas respondem em milissegundos, uma tem média de mais de dez segundos em produção. Qualquer arquitetura que as chame sequencialmente, ou assuma que se comportarão de forma previsível, falha sob carga real.
O time vencedor construiu roteamento dinâmico com verificação contínua de saúde, domínios de falha isolados e controles de concorrência como primeiros instintos — não como recursos adicionados depois que o núcleo estava funcionando. Eles não precisaram das falhas de produção para aprender isso. Eles raciocinaram do spec para os modos de falha antes de escrever o código.
Times que tiveram dificuldades trataram as fontes externas como serviços internos confiáveis. Quando a fonte lenta degradou as execuções de teste, eles não tinham resposta arquitetural.
A diferença não era conhecimento técnico. Ambos os grupos conheciam circuit breakers. A diferença era o hábito de projetar para falha desde a primeira linha — e esse hábito é o que queremos ver se tornar universal na KYP.
Pensamento de produto surge espontaneamente quando o ambiente o recompensa
Um dos momentos mais comentados nas apresentações finais foi um grafo de fluxo de debugging que o time vencedor havia construído em seu setup de observabilidade — um trace visual de ponta a ponta de como uma requisição de avaliação se movia pelo sistema, quais chamadas de fonte foram disparadas, o que retornaram e onde o tempo foi gasto.
Ninguém pediu isso. Os critérios de julgamento não recompensavam isso. O time construiu durante o hackathon porque queria entender o que estava acontecendo dentro do seu próprio sistema.
É essa a diferença entre engenharia para a demo e engenharia para produção. É também o que queremos dizer quando dizemos que estamos construindo uma organização AI-native — não uma onde a IA gera código mais rápido, mas uma onde os engenheiros que direcionam a IA estão pensando no que significa operar o que estão construindo, não apenas entregá-lo.
O Que Erramos
Compreensão de domínio não pode ser delegada à IA. O time que mais teve dificuldades foi sincero em sua retrospectiva: eles começaram a escrever prompts antes de entender o problema. O resultado foram chamadas sequenciais a fontes externas, uma arquitetura otimizada para cenários de happy path e um sistema que não conseguia suportar a pressão dos requisitos reais. A IA amplifica a qualidade do seu entendimento — ela não o substitui. Construir um spec preciso não é uma tarefa que você pula para chegar ao trabalho “real” mais rápido. Esse é o trabalho real.
Não tornamos teste de carga um critério formal de avaliação. O time com a arquitetura mais limpa — design hexagonal, clara separação de responsabilidades, modelo de domínio bem estruturado — não a validou sob estresse. Eles podem ter tido a arquitetura certa sem saber. Ou podem ter tido um design que teria rachado sob carga. Não descobrimos. Edições futuras incluirão resultados objetivos de teste de carga como critério pontuado, não opcional.
O critério bônus precisava ser enquadrado como sinal desde o dia um. Times que ficaram sabendo sobre a personalização opcional de criticidade tarde no processo a trataram como uma meta secundária. O time que a entregou havia planejado para isso desde o início — não era um add-on, era parte do seu spec. A lição: em futuros hackathons, critérios opcionais serão apresentados como sinais de completude do produto, não como crédito extra, para que os times os considerem no momento da arquitetura.
O Que Isso Diz Sobre Como Trabalhamos
O hackathon não foi uma exceção de como construímos software na KYP. Foi uma versão acelerada e observável dos princípios por trás do nosso modelo de engenharia do dia a dia.
Acreditamos que a habilidade de engenharia mais importante em 2026 não é proficiência em uma linguagem ou framework específico. É a capacidade de raciocinar claramente sobre um problema, decompô-lo em uma especificação precisa o suficiente para agentes executarem, e dirigir essa execução com bom julgamento sobre arquitetura, modos de falha e realidade operacional. Essa habilidade se compõe. Cada sistema bem especificado produz uma base de conhecimento melhor para o próximo. Cada fluxo de trabalho de agente que entrega corretamente aperta o ciclo de feedback que melhora a próxima especificação.
O hackathon também demonstrou algo sobre o tipo de engenheiros que estamos tentando construir e atrair: pessoas que são curiosas sobre o problema antes de serem confiantes na solução, que constroem observabilidade para si mesmas e não para a demo, que dizem “não entendemos o domínio suficientemente bem” em voz alta e tratam isso como ponto de partida para melhoria, não uma falha a esconder.
É assim que a engenharia AI-native parece na prática. Não engenheiros que usam ferramentas de IA. Engenheiros que pensam em como trabalhar com agentes de IA efetivamente — como um artesanato, com rigor, com retrospectivas honestas sobre onde a abordagem quebrou e por quê.
O Que Vem a Seguir
O hackathon produziu cinco implementações funcionais de um sistema que vamos realmente reescrever. Isso não é incidental — as soluções agora são implementações de referência para os tradeoffs arquiteturais que enfrentaremos no projeto real. As melhores decisões entre as cinco informarão o design de produção.
Também estamos levando a metodologia adiante:
- A abordagem planning-first do BMAD se tornará um fluxo de trabalho de referência para times de engenharia além do contexto do hackathon
- Os padrões de roteamento inteligente de serviços externos da solução vencedora serão compartilhados como templates de design reutilizáveis
- Teste de carga será um critério formal e entregável de primeira classe em edições futuras
- Realizaremos uma sessão de Tech On Tap especificamente sobre o que o time planning-first aprendeu com seu fluxo de trabalho BMAD, para tornar essa prática acessível em toda a organização
O objetivo mais amplo não é realizar hackathons melhores. É reduzir a lacuna entre o que demonstramos em 48 horas e como nossa prática padrão de engenharia parece em qualquer terça-feira. Essa lacuna está fechando. A velocidade com que fecha depende de quão seriamente levamos as lições — incluindo as desconfortáveis.
A CERC opera a infraestrutura do mercado financeiro brasileiro para registro de recebíveis. A KYP é um dos nossos principais times de engenharia de produto, construindo o modelo operacional AI-native que torna possível a engenharia na escala do sistema financeiro. Se esse tipo de ambiente — altos padrões, retrospectivas honestas, agentes como participantes de primeira classe na engenharia — soa como onde você quer trabalhar, estamos contratando.
Este post foi escrito por Juliano Pereira — líder de tecnologia na KYP/CERC construindo a infraestrutura para engenharia AI-native.