Construímos o salty.poker com IA. Aqui Está a Parte que Ninguém Viu.

Vinte e duas sessões de construção em dez dias.

Cada sessão: um agente Claude Code trabalhando a partir de uma especificação de 100 páginas — lendo o estado atual do código, pegando o módulo de especificação atribuído, escrevendo código, conectando serviços, executando migrações, fazendo commits. Sem reuniões de estimativa. Sem conversas sobre escopo. Sem tickets de Jira debatidos em uma sala de conferências.

O resultado dessas sessões foram 20 microsserviços, um motor de mesa em tempo real, gerenciamento de torneios, um razão de partida dupla, verificação KYC, detecção de fraude e uma mesa de poker renderizada em PixiJS com cartas animadas e pilhas de fichas.

O changelog cobre o que foi entregue. Este post é sobre o que aconteceu depois.

O que Realmente Acontece Depois que o Código é Escrito

Escrever código correto e ter um sistema funcionando são duas coisas diferentes. O código passa em seus testes unitários. Os serviços se comportam corretamente em isolamento. Mas quando você conecta tudo — aplicativo web, motor de mesa, conexões em tempo real, autenticação, banco de dados — a superfície de falha cresce mais rápido do que qualquer suite de testes pode antecipar completamente.

A semana passada foi essa fase. Testes de ponta a ponta. Logins reais, lobby real, mesas reais, jogadores reais sentando.

A visualização da mesa carregou e mostrou uma tela em branco onde deveriam estar os assentos. Sem diálogo de compra. Sem forma de voltar ao lobby. Uma tela em branco onde deveria haver um jogo de poker.

O lobby tinha um cartão de mesa que se esticava para preencher toda a altura da página. Um padrão CSS — é assim que o CSS Grid se comporta quando há apenas um item na linha e você não substituiu o comportamento de esticamento.

Nenhum desses bugs foi escrito por um humano. Uma sessão de IA escreveu a visualização da mesa. Uma sessão de IA escreveu o lobby. Ainda eram bugs. Ainda precisavam ser encontrados, rastreados até sua causa raiz e corrigidos.

Por que Este Ainda é o Melhor Caminho

Antes da história de como-quebrou: o fato de estarmos em testes de ponta a ponta em dez dias é a história.

Duas empresas anteriores me ensinaram quanto tempo isso leva da maneira tradicional. Meses de andaimes antes de você ter algo para testar. Meses a mais antes de você estar testando algo que se parece com o produto final.

Fechamos essa lacuna em dez dias. A fase de testes é a parte difícil. Estamos nela.

O que Vem Nesta Série

Este é o post um de quatro. Ao longo da próxima semana, vamos percorrer o que realmente encontramos durante os testes — um bug de roteamento que era invisível até que o stack completo rodasse, um ambiente de desenvolvimento que ignorava silenciosamente mudanças de código, e um guarda de autenticação que enviava cada tentativa de navegação para um loop de redirecionamento.

Para a metodologia mais profunda, escrevo sobre isso no The Salty Korean.

Stay salty.