Quatro Meses, Um Tipo Array no Redis e o Que Isso Diz Sobre IA em Código de Produção

Salvatore Sanfilippo, o engenheiro mais conhecido como antirez e autor original do Redis, passou quatro meses construindo um novo tipo de dado Array para o banco. Ele documentou a experiência neste mês sob um título que se desculpa pelo próprio tamanho: Redis Array Type: Short Story of a Long Development. O post é curto. O desenvolvimento foi longo. E o valor do post está em descrever, com a precisão de um engenheiro de sistemas em atividade, exatamente como foi a colaboração com IA em uma peça de infraestrutura crítica de produção da qual milhões de serviços dependem.

Já escrevemos sobre o harness como disciplina de longa duração que envolve o colaborador IA, e sobre skills como governança modular que tornam essa colaboração auditável. O relato de antirez é a versão prática desses argumentos. É como o harness se parece quando o engenheiro no teclado é um dos programadores de sistemas mais respeitados ainda em atividade, e o código em questão entra em um banco de dados que tráfego de produção martela em milhões de operações por segundo.

A disciplina que ele descreve não é nova para ele. O que é novo é que agora existe um relato público, nominal e granular de como um engenheiro sério usou IA em código sério sem que o resultado soasse nem a depoimento de marketing nem a relato de advertência.

Os Quatro Meses

A forma do projeto merece leitura pausada. O primeiro mês foi de especificação. Antirez passou esse tempo decidindo o que o tipo Array deveria ser, como suas operações seriam expostas, quais semânticas tinha de preservar e como interagiria com o restante do Redis. O segundo mês foi de implementação. O terceiro foi de revisão de código e otimização. O quarto foi de teste de estresse e expansão de funcionalidades, incluindo um operador de busca por expressão regular chamado ARGREP. A cadência é o inverso da cadência orientada a demo que as ferramentas de IA encorajam. Não há MVP no primeiro dia. Não há “envia o caminho feliz e itera”. Há um mês de pensamento e três meses executando aquele pensamento.

Isso não é engenharia nostálgica. É a cadência que código crítico de produção sempre exigiu. Antirez não abandonou essa cadência porque havia IA no teclado. Ele usou IA para mantê-la.

Onde a IA Foi Essencial

Antirez é direto sobre quais partes do trabalho a IA carregou. A implementação do suporte a 32 bits. O trabalho de verificação que ele descreve como “uma força de trabalho virtual garantindo que não havia bugs óbvios” antes de ele commitar código. A sessão de debug na biblioteca de regex TRE, em que o padrão de alternância foo|bar|zap se comportava de forma errada e o modelo rastreou o problema na máquina de estados interna da TRE mais rápido do que um humano lendo o código C conseguiria. Ele usou Opus primeiro. Migrou para GPT 5.3 e 5.x em partes do trabalho de programação de sistemas em que essa família de modelos estava produzindo C melhor. A escolha do modelo é tratada como seleção de ferramenta, não como teste de lealdade.

O padrão entre esses usos é consistente. A IA assumiu o tédio e a verificação. O suporte a 32 bits é trabalho de tradução mecânica que um humano cuidadoso consegue fazer mas detesta. O passe de verificação é o tipo de trabalho em que um revisor incansável que lê cada linha vale mais do que um brilhante que lê só as partes interessantes. O debug da TRE é busca em código desconhecido, que é exatamente onde modelos treinados no corpus de código aberto se sobressaem.

Onde a IA Não Esteve no Comando

A lista de decisões dirigidas pelo humano é a metade mais interessante. Antirez foi dono da fase de especificação. Foi dono da arquitetura, incluindo a escolha central de uma estrutura de diretórios em múltiplos níveis que evoluiu, ao longo dos quatro meses, para o que ele chama de “super diretório de diretórios densos fatiados”. Essa não é uma frase que um modelo produz. É uma frase que um engenheiro produz depois de semanas cutucando a estrutura de dados até que os trade-offs se acomodem. Foi dono da expansão de funcionalidades, incluindo a decisão de que o tipo Array deveria sair com ARGREP em vez de esperar por uma versão de continuação.

A linha que ele traça no post é a linha que importa. “Para tarefas de programação de sistemas de alta qualidade, você ainda precisa estar plenamente envolvido.” Não parcialmente envolvido. Não direcionalmente envolvido. Plenamente. Ele revisou o código linha por linha. Manteve as decisões arquiteturais na própria cabeça. Tratou a saída da IA como material de rascunho que só ganhou direito de entrar no Redis depois de ser lido como se um engenheiro júnior o tivesse submetido.

Por Que Isso É a Tese do Harness na Prática

Argumentamos que o harness é o lugar em que a colaboração com IA fica segura em escala. O argumento foi teórico: um esforço de engenharia de longa duração exige uma estrutura de contenção que sobrevive entre sessões, mantém a especificação estável, controla qual código entra e torna a colaboração auditável. Sem essa estrutura, a assistência da IA vira uma sequência de sugestões sem responsável que se compõem em uma dívida técnica que o time não consegue explicar.

Antirez construiu esse harness para si mesmo, manualmente, em torno de um único projeto. A linha do tempo de quatro meses é o harness. O mês de especificação é o harness. A revisão linha por linha é o harness. A decisão de usar modelos diferentes para partes diferentes do trabalho é o harness. A autoridade arquitetural permanecendo na cabeça do humano é o harness. Ele não chamou de harness, e não precisava chamar. A disciplina produziu o mesmo artefato que harnesses organizacionais produzem: um pedaço de código em que o papel de cada contribuidor é legível, em que as superfícies de risco são limitadas, e em que o engenheiro responsável consegue responder por cada linha.

Essa é a forma que a disciplina assume quando um engenheiro do calibre de antirez a executa sozinho. Em uma organização de 200 engenheiros, a mesma disciplina não pode ser improvisada. Tem de ser codificada no harness: as skills que controlam quais modelos tocam quais superfícies, a contenção que limita o que a execução de IA consegue alcançar, a cadência de spec-first que sobrevive à rotatividade de time. Os princípios são idênticos. A implementação tem de escalar.

O Que Levar Disso para a Prática de Engenharia do Seu Time

Três coisas valem a pena ser carregadas do relato de antirez para como seu time usa IA em código de produção.

Primeiro, o mês de especificação. Se a colaboração do seu time com IA começa pela geração de código, vocês pularam a parte em que o julgamento humano é insubstituível. Decida o que o sistema deve fazer, por escrito, antes que qualquer modelo escreva uma linha. Antirez gastou 25 por cento do tempo de calendário nessa fase. A maioria dos times gasta zero.

Segundo, a revisão linha por linha. Código gerado com IA que o engenheiro responsável não leu não é código; é material não revisado que agora está no seu repositório. A revisão não é uma etapa de garantia de qualidade que vem depois do merge. É o ato que converte a saída do modelo em compromisso do engenheiro.

Terceiro, a postura de modelo-como-ferramenta. Antirez trocou de modelo quando o trabalho exigiu. Não declarou lealdade a fornecedor. Não tratou a escolha como questão ideológica. Pegou a ferramenta que produzia C melhor para o subproblema de programação de sistemas que estava à frente dele. Essa é a postura de um engenheiro em atividade, e é a postura que seu time deveria sustentar.

O tipo Array do Redis vai entrar em produção quando antirez decidir que entra. O código está no repositório dele, sob o nome dele, e ele consegue responder por ele. Quatro meses de colaboração disciplinada produziram uma peça de infraestrutura em que sistemas de produção podem confiar. É isso que IA como colaboradora se parece quando o humano no teclado não delegou o julgamento junto com a digitação.

O slogan é fácil. A disciplina é o trabalho.

Fontes

Sanfilippo, Salvatore (antirez). “Redis Array Type: Short Story of a Long Development.” Maio de 2026.

A Victorino ajuda organizações de engenharia a transformar “IA como colaboradora” de slogan em disciplina aplicada em código de produção: contato@victorino.com.br | www.victorino.com.br