No dia 23 de julho, nos encontramos de novo com a comunidade Ruby em Buenos Aires. Fomos sponsors do Ruby Sur Meetup na La Maquinita Innovation Lab, o mesmo espaço onde já tínhamos estado com a comunidade React algumas semanas antes. Com a comida, as telas e o espaço garantidos, a noite ficou pronta para duas palestras que geraram mais pergunta do que qualquer pessoa esperava.
O custo real de escolher errado a sua primary key
Santiago Merlo, Rails Senior Developer na Rootstrap, abriu a noite com uma palestra que começou numa discussão de corredor: um colega dele estava trabalhando num projeto legado que usava UUID como primary key, e a decisão pareceu estranha pra Santiago. Em vez de ficar só com a dúvida, ele foi fazer o benchmark.
Os números que ele mostrou foram difíceis de contestar. Usar UUID versão quatro como primary key no Postgres, comparado a um BIGINT tradicional, significa perder mais de quarenta por cento de velocidade de escrita e chegar a cinquenta por cento de fragmentação no índice B-tree. A versão sete do UUID melhora bastante esse cenário, mas ainda ocupa o dobro do espaço de um inteiro. A alternativa que mais convenceu Santiago foi uma abordagem híbrida: usar um BIGINT como primary key interna do banco de dados, e expor um UUID pra fora, pra não vazar informação como o volume de registros ou a ordem de criação.
A palestra gerou perguntas técnicas de verdade: o que acontece com colisões de ID num blue-green deployment, se vale a pena ter um microsserviço dedicado só pra gerar UUIDs únicos, e até uma história sobre um sistema de registro de animais de estimação no Reino Unido que usa strings de quatro caracteres pra escrever números romanos, e fica sem combinações antes de chegar nem perto de quarenta.
Quando um cliente prefere pagar tokens em vez de pagar salários
A segunda palestra foi de Patricio Mac Adden, co-fundador da Sinaptia, e começou com uma história que deixou a sala em silêncio: alguns meses atrás, um cliente da empresa dele avisou que ia reduzir a equipe humana porque preferia gastar esse orçamento em tokens de IA em vez de em pessoas. O cliente queria mover o desenvolvimento pra specs e agentes trabalhando sozinhos, sem ninguém acompanhando.
Foi dessa crise que nasceu a palestra. Patricio passou pela evolução do autocomplete do Copilot até os agentes que hoje conseguem planejar, escrever código e até corrigir os próprios erros, e por que isso muda as regras do jogo: gerar código já é barato, mas errar continua custando o mesmo ou mais. Ele falou de vibe coding versus desenvolvimento guiado por especificações, de harness engineering, e testou na prática várias ferramentas (Claude Code, OpenCode, agentes minimalistas como o Pi) até achar a que tirava a fricção sem tirar o controle.
O conselho central dele foi fácil de dizer e difícil de seguir: não terceirize o pensar. Você pode deixar o agente escrever o código, mas o planejamento e o entendimento do porquê de cada decisão têm que continuar sendo seus. Essa mesma lógica apareceu nas perguntas do público: usar skills locais por projeto em vez de skills globais, pra não acabar com os mesmos problemas de inconsistência que já existiam com equipes humanas grandes.
O que a comunidade levou pra casa
A Ruby Sur é uma comunidade com mais de trinta meetups e vários milhares de mates no currículo, e essa edição somou mais uma noite de palestras que valeram a pena, além de comida e networking até tarde. Antes de encerrar, teve sorteio de uma caixa de som JBL entre quem ficou até o final.
No dia seguinte, a própria organização da Ruby Sur agradeceu publicamente o patrocínio da Howdy nas redes deles, e já estão pensando na próxima edição. Nós também. Quando uma palestra sobre primary keys termina com a sala fazendo perguntas de arquitetura de verdade, e uma palestra sobre IA termina com a sala repensando como trabalha todos os dias, a meetup cumpriu seu papel.
