- O trabalho no novo tipo de dado Array do Redis começou no início de janeiro e virou um PR cerca de quatro meses depois; no primeiro mês, foi escrita a especificação cobrindo a necessidade, structs em C, representação esparsa, buffer circular e a semântica do cursor de array para
ARINSERT - O design inicial foi refinado com o Opus e, após o lançamento do GPT 5.3, o design e o desenvolvimento passaram a ser conduzidos com o Codex; no processo de feedback com a IA, foram revisados continuamente os compromissos e as partes excessivamente projetadas
- A implementação mudou para que a definição de índices grandes, como em
ARSET myarray 293842948324 foo, funcione sem alocações gigantes, e a estrutura de dados interna passa, conforme as condições, para super diretório, diretório denso fatiado e formato de slices reais de array - Cada slice comporta por padrão 4096 elementos, e
ARSCANeARPOPconseguem varrer arrays existentes em tempo proporcional ao número de elementos realmente presentes, não ao tamanho total do intervalo - O caso de uso de colocar arquivos Markdown em arrays do Redis levou à implementação de
ARGREP; para suporte a expressões regulares foi escolhido o TRE, e os casos de uso estão organizados em Redis PR #15162
Implementação e revisão
- A partir do segundo mês, a implementação começou no estilo de programação automática, com revisão contínua do código gerado
- Mesmo depois que a implementação passou a funcionar, o código, incluindo
sparsearray.cet_array.c, foi revisado linha por linha - Graças à IA, havia muitos testes, mas código que aparentemente funciona não significa necessariamente código ideal, então pequenas ineficiências e erros de design foram encontrados e corrigidos
- Vários módulos foram reescritos de forma manual e com auxílio de IA, e no terceiro mês foram realizados testes de estresse de várias maneiras
- Em programação de sistemas de alta qualidade, ainda é necessário envolvimento humano completo, mas a IA funciona como rede de segurança em tarefas cansativas, como adicionar suporte a 32 bits e testes, além de detectar bugs óbvios em algoritmos complexos
- A grande especificação inicial foi o núcleo do trabalho posterior e também foi importante para revisar cada linha do código e corrigir as partes que não se encaixavam
Casos de uso e expressões regulares
- Ao modelar casos de uso, começou-se a colocar arquivos Markdown em arrays do Redis, chegando-se à conclusão de que arquivos se encaixam bem no tipo de dado array
- Isso levou à implementação de
ARGREPpara criar uma base de conhecimento central baseada em arquivos Markdown necessária para o trabalho de agentes - Para suporte a expressões regulares, foi escolhido o TRE, porque ao usar expressões regulares no Redis não deveria haver padrões patológicos em termos de tempo ou espaço
- O TRE era muito ineficiente em correspondência de padrões úteis como
foo|bar|zap, então, com a ajuda do GPT, ele foi otimizado, alguns possíveis problemas de segurança foram corrigidos e os testes também foram ampliados - Os casos de uso estão detalhados em Redis PR #15162, chegando à conclusão de que o Redis precisa de um tipo de dado em que índices numéricos sejam parte do significado
- Há expectativa de que o PR de Array seja aceito em breve, permitindo aproveitar os benefícios de novos casos de uso, e é solicitado feedback
1 comentários
Comentários do Hacker News
Só para deixar claro, isso foi feito pelo criador original do Redis ou por um deles
Ele não é um “desenvolvedor médio” e, mesmo usando LLM, levou 4 meses
Então isso não deve ser interpretado como um selo de aprovação para mandar todo desenvolvedor migrar completamente para Claude Code, Codex ou outras ferramentas de programação com IA
Especialmente CEOs comuns de startup deveriam prestar atenção nessa parte
No original, ele diz: “mesmo antes dos LLMs, a implementação em si provavelmente poderia ter sido feita em 4 meses. O que mudou foi que, no mesmo período, deu para fazer muito mais coisa”
Ou seja, o período inicial já era de 4 meses, e com LLM ele conseguiu fazer mais trabalho dentro desse mesmo tempo
O trabalho médio de desenvolvimento está muito mais próximo de trabalho de encanamento e CRUD
O jeito que uso hoje é assim
Primeiro escrevo um documento de arquitetura de alto nível em Markdown com ajuda de IA. Depois peço para o mesmo modelo, mas sem o contexto, ou para outro modelo, criticar e encontrar bugs, omissões e lacunas. Quando você revisita depois, ele sempre encontra coisas óbvias
Aí peço para resumir essas descobertas, colo isso na primeira IA e peço a opinião dela. Produzo as mudanças acordadas e vou incorporando, continuando esse round-robin adversarial até que nenhum modelo consiga sugerir algo significativo
Depois faço a IA montar um plano, e esse plano também passa de forma adversarial por várias IAs. No fim, sai um plano bem sólido
Depois passo para coisas como o plano de casos de teste end-to-end. Dependendo do tamanho do sistema, perto do fim do primeiro dia, da primeira semana ou do primeiro mês, você já está pronto para codificar
Quando o código é gerado, colo esse código, junto com a especificação e o plano, em outras IAs e peço para encontrarem bugs, omissões e lacunas. A ideia é validar continuamente a IA principal responsável pela implementação com outras IAs
Claro, ainda é preciso ler o código você mesmo. Já vi a IA deixar passar acabamentos de detalhe em qualidade de entrega
Não estou tentando ser sarcástico. Meu fluxo de trabalho é essencialmente o mesmo, e também não é para zombar do Google. Pelo contrário, a ideia é que não há nada de realmente novo aqui
A IA acelera enormemente tanto fluxos de trabalho eficazes quanto ineficazes. Com isso, fica muito mais visível, em muito menos tempo, quase em tempo real, o que é eficaz e o que não é
Como também foi dito que ele usou outros agentes, fico curioso se teve bons resultados com revisão de código em que outros agentes dão polish em partes menos refinadas. Meus colegas acreditam fortemente nisso, mas pessoalmente ainda sou cético quanto ao valor sem revisores humanos
Essa abordagem de “perguntar para outra IA” talvez combine melhor, em ciência da computação aplicada, com tese-antítese-síntese: https://en.wikipedia.org/wiki/Dialectic#Criticisms
Mesmo tendo sido escrito pelo antirez, fazer review de 22 mil linhas de código com esse conjunto de funcionalidades e uma descrição mínima no PR parece um pesadelo
Dá para entender por que grandes projetos open source como o Postgres são desenvolvidos em mailing lists. Assim dá para discutir decisões intermediárias de design com a comunidade, separar funcionalidades relacionadas em patches distintos, revisar de forma incremental e espaçar entre releases
O array esparso tem 2.000 linhas
Os comandos
t_arraye a implementação da camada superior têm 2.000 linhasO código de AOF/RDB tem cerca de 500 linhas
O restante são testes, descrições de comandos JSON e a biblioteca TRE em
depsNa prática, a maioria dos principais recursos do Redis foi trabalho feito sozinho pelo autor
Além disso, os revisores conhecem bem esse trabalho e são pagos adequadamente por isso
Isso é muito parecido com minha experiência usando IA de ponta atualmente. Está longe de ser um substituto para inteligência e criatividade humanas, mas como colaboradora é extremamente útil
Mas Redis ainda não é assim. Quando isso se tornar possível em software de servidor, a forma atual de desenvolver vai acabar
Recursos, correções e acúmulo de experiência ainda continuarão valiosos, então projetos e repositórios continuarão existindo, mas o papel do programador ficará muito mais parecido com o papel que o Linus tem exercido no kernel até hoje
Em alguns projetos, como o mecanismo de raciocínio DeepSeek v4, já estão trabalhando assim
Estou animado com array/regex, e essa experiência de ampliar capacidades com LLM também é muito interessante. Muita gente está fazendo discretamente experimentos parecidos em vários projetos
Só vibe coding e a reação contrária a isso não explicam bem esse modo de trabalhar
Só que logo depois as pessoas começaram a usar essa expressão para quase toda forma de programação assistida por IA, e o significado original se perdeu rapidamente
Resumindo, agora não dá mais para confiar no Redis
Quem vai fazer um fork sem LLM?
Alguns dos casos de uso apresentados não poderiam ser resolvidos com ZSET? Entendo a questão de desempenho, mas, assim como arrays usam opcionalmente representação esparsa, parece que daria para otimizar opcionalmente a forma de armazenamento de ZSET para valores densos sem expor uma nova superfície de API
O componente de regex é interessante, mas, como também foi dito aqui, parece uma funcionalidade ortogonal à estrutura de dados de array. Em outras palavras, poderia ser usado também com outras estruturas. Não faria mais sentido isso ser feito com scripts Lua? Se o problema for o desempenho do Lua, talvez exista alguma forma de abstrair a OP para que ela possa ser composta sobre qualquer comando que retorne intervalos de valores
Respeito o fato de o Antirez ser especialista nessa área, mas parte desse novo conjunto de recursos parece uma solução do tipo que aparece com frequência em desenvolvimento guiado por LLM: criar novos recursos em vez de melhorar os existentes, e acabar complicando demais as funcionalidades quando talvez fosse mais eficaz combiná-las com outras já existentes
Além disso, se a representação interna não for um array, consultas por intervalo e buffers circulares não conseguem operar com a eficiência e a compactação necessárias
Em teoria, dá para fazer qualquer coisa com qualquer coisa, mas é preciso separar o que cada API pode fazer para então aproveitar os casos de uso e oferecer a melhor implementação interna possível
Tenho curiosidade para saber, antirez: você chegou a experimentar algo como uma geração one-shot do código final? Fico me perguntando se seria possível chegar lá com GEPA, e se há algo a aprender com os métodos de orientação ou prompting usados para extrair o resultado desejado
Ou talvez a conclusão seja que os provedores de modelos precisam limpar melhor os dados de treinamento
Parece que o Salvatore quer popularizar o termo Automatic Programming/Coding. (https://antirez.com/news/159)
Claro, os LLMs são muito peculiares por serem não determinísticos e terem um escopo surpreendentemente amplo, mas isso não significa que o termo não se aplique
Mas talvez ajude encurtar o termo para auto-code
É sempre interessante ver como desenvolvedores muito experientes estão interagindo com IA hoje em dia
@antirez: no fim do projeto, parece um pouco estranho ter introduzido a funcionalidade de regex como algo aparentemente separado. Você pode explicar melhor o raciocínio por trás dessa decisão?
Então comecei a pensar qual seria o equivalente, nos arquivos, ao AROP, e a resposta foi ARGREP
Depois disso, incluí tanto correspondência exata rápida quanto correspondência por regex, para que fosse possível usar a melhor ferramenta conforme o caso de uso
Aí descobri que, em várias strings unidas por OR, a regex pode ser mais rápida se for bem otimizada, e especializei um pouco o TRE