Redis array : courte histoire d’un long développement
(antirez.com)- Le travail sur le nouveau type de données Array de Redis a commencé début janvier et a été publié en PR environ quatre mois plus tard ; durant le premier mois, une spécification a été rédigée couvrant la nécessité du projet, les structures
C, la représentation clairsemée, le ring buffer et la sémantique du curseur de tableau pourARINSERT - La conception initiale a été affinée avec Opus, puis après la sortie de GPT 5.3, la conception et le développement ont été menés avec Codex ; tout au long du cycle de feedback avec l’IA, les compromis et les parties trop conçues ont été continuellement réévalués
- L’implémentation a évolué pour que la définition d’un grand index comme
ARSET myarray 293842948324 foofonctionne sans allocation massive, et la structure de données interne bascule selon les conditions entre un super-répertoire, un répertoire dense découpé en slices, et des slices de tableau réelles - Chaque slice contient par défaut 4096 éléments, et
ARSCANainsi queARPOPpeuvent parcourir des tableaux existants en un temps proportionnel au nombre d’éléments réellement présents, et non à la taille totale de la plage - Le cas d’usage consistant à placer des fichiers Markdown dans des tableaux Redis a conduit à l’implémentation de
ARGREP; TRE a été retenu pour la prise en charge des expressions régulières, et les cas d’usage sont récapitulés dans Redis PR #15162
Implémentation et revue
- À partir du deuxième mois, l’implémentation a commencé sous une forme de programmation automatisée, avec une revue continue du code généré
- Même après que l’implémentation a commencé à fonctionner, le code, y compris
sparsearray.cett_array.c, a été relu ligne par ligne - Grâce à l’IA, il y avait beaucoup de tests, mais un code qui fonctionne en apparence n’est pas forcément optimal ; de petites inefficacités et des erreurs de conception ont donc été trouvées puis corrigées
- Plusieurs modules ont été réécrits, à la main comme avec assistance IA, et au troisième mois, des stress tests ont été menés de diverses manières
- Dans la programmation système de haute qualité, l’intervention humaine complète reste indispensable, mais l’IA sert de filet de sécurité pour des tâches fatigantes comme l’ajout du support 32 bits et les tests, ainsi que pour détecter des bugs évidents dans des algorithmes complexes
- La rédaction initiale d’une grande spécification a été au cœur du travail ultérieur, et s’est aussi révélée importante pour revoir chaque ligne de code et corriger ce qui ne collait pas
Cas d’usage et expressions régulières
- En modélisant les cas d’usage, l’auteur a commencé à placer des fichiers Markdown dans des tableaux Redis et en a conclu que les fichiers correspondaient bien au type de données array
- Cela a conduit à l’implémentation de
ARGREPafin de créer une base de connaissances centrale fondée sur des fichiers Markdown, nécessaire au travail des agents - Pour la prise en charge des expressions régulières, TRE a été choisi notamment parce que l’usage d’expressions régulières dans Redis ne devait pas introduire de motifs pathologiques en temps ou en espace
- TRE étant très inefficace pour des correspondances utiles comme
foo|bar|zap, il a été optimisé avec l’aide de GPT ; quelques problèmes de sécurité potentiels ont aussi été corrigés et les tests étendus - Les cas d’usage sont détaillés dans Redis PR #15162 et ont conduit à la conclusion que Redis a besoin d’un type de données où les index numériques font partie du sens
- L’auteur espère que la PR Array sera bientôt acceptée et demande des retours afin de pouvoir tirer parti de ces nouveaux cas d’usage
1 commentaires
Réactions sur Hacker News
Pour être clair, c’est le travail de l’auteur original de Redis, ou de l’un d’eux
Ce n’est pas un « développeur moyen », et même avec des LLM, cela lui a pris 4 mois
Il ne faut donc pas prendre ça comme un tampon d’approbation autorisant à dire à tous les développeurs de migrer complètement vers Claude Code, Codex ou d’autres outils de codage IA
C’est un point que les CEO de startup ordinaires devraient particulièrement voir
Le texte dit plutôt : « Même avant les LLM, j’aurais probablement pu faire l’implémentation elle-même en 4 mois. Ce qui a changé, c’est que j’ai pu faire bien plus de choses sur la même période. »
Autrement dit, la durée initiale était déjà de 4 mois, et les LLM ont permis d’accomplir davantage de travail dans ce même laps de temps
Le travail moyen d’un développeur ressemble davantage à de la plomberie et du CRUD
Voici comment je travaille actuellement
D’abord, j’utilise l’aide de l’IA pour rédiger en Markdown un document d’architecture de haut niveau. Ensuite, je prends le même modèle mais sans le contexte, ou bien un autre modèle, et je lui demande de critiquer le document pour trouver des bugs, des oublis et des trous. Il finit toujours par trouver des choses qui, rétrospectivement, paraissent évidentes
Je lui fais alors résumer ces découvertes, je colle ce résumé dans la première IA et je lui demande son avis. Nous produisons des changements consensuels, nous les appliquons, puis nous continuons ce round-robin adversarial jusqu’à ce qu’aucun modèle n’ait plus de suggestion pertinente à faire
Ensuite, je demande à l’IA de produire un plan, et ce plan est lui aussi soumis de façon adversariale à plusieurs IA. On finit par obtenir un plan assez solide
Puis on passe au plan des cas de test end-to-end, etc. Selon la taille du système, on est prêt à coder à la fin du premier jour, de la première semaine ou du premier mois
Une fois le code produit, je colle ce code, ainsi que la spécification et le plan, dans une autre IA pour qu’elle cherche les bugs, les oublis et les trous. L’idée est de faire en sorte que l’IA principale chargée de l’implémentation soit continuellement vérifiée par d’autres IA
Bien sûr, il faut aussi lire le code soi-même. J’ai vu l’IA passer à côté de finitions de détail au niveau qualité de livraison
Ce n’est pas une pique. Mon propre workflow est fondamentalement le même, et il ne s’agit pas non plus de se moquer de Google. Au contraire, cela veut dire qu’il n’y a rien de vraiment nouveau
L’IA accélère énormément à la fois les workflows efficaces et les workflows inefficaces. Du coup, ce qui fonctionne et ce qui ne fonctionne pas devient visible bien plus vite, presque en temps réel
Il a aussi dit qu’il utilisait d’autres agents ; je me demande s’il a constaté des bénéfices en revue de code quand d’autres agents polissent les parties moins abouties. Mes collègues y croient dur comme fer, mais personnellement je reste sceptique sur la valeur de tout cela sans relecteur humain
Cette approche consistant à « demander à une autre IA » relève peut-être, en informatique appliquée, davantage d’une logique thèse-antithèse-synthèse : https://en.wikipedia.org/wiki/Dialectic#Criticisms
Même si c’était écrit par antirez, faire une revue de 22 000 lignes de code avec un tel ensemble de fonctionnalités et une explication de PR minimale ressemble à un cauchemar
Je comprends mieux pourquoi un grand projet open source comme Postgres se développe via des mailing lists. Les décisions de conception intermédiaires y sont discutées avec la communauté, les fonctionnalités connexes sont découpées en patches séparés, les revues se font progressivement et les sorties sont espacées
Le tableau clairsemé fait 2 000 lignes
La commande
t_arrayet l’implémentation des couches supérieures, 2 000 lignesLe code AOF/RDB fait environ 500 lignes
Le reste, ce sont les tests, la description JSON des commandes et la bibliothèque TRE sous
depsEn pratique, la plupart des grandes fonctionnalités de Redis ont été réalisées en solo par l’auteur du billet
En plus, les relecteurs connaissent très bien ce travail et sont correctement rémunérés
Cela correspond beaucoup à mon expérience avec les meilleures IA actuelles. On est très loin d’un substitut à l’intelligence et à la créativité humaines, mais comme collaborateur c’est extrêmement utile
Mais Redis n’en est pas encore là. Le jour où cela deviendra possible dans les logiciels serveur, notre manière actuelle de développer sera terminée
Les fonctionnalités, les correctifs et l’accumulation d’expérience garderont de la valeur, donc les projets et les dépôts resteront, mais le rôle du programmeur ressemblera beaucoup plus à ce que Linus fait pour le noyau aujourd’hui
Sur certains projets, comme le moteur de raisonnement DeepSeek v4, je travaille déjà de cette façon
J’attends avec intérêt array/regex, et l’expérience d’une capacité augmentée par les LLM est elle aussi très intéressante. Beaucoup de gens tentent discrètement des choses similaires sur plusieurs projets
Le seul concept de vibe coding et la réaction qu’il suscite ne suffisent pas à bien décrire cette manière de travailler
Mais très vite, les gens ont commencé à employer ce terme pour presque toutes les formes de codage assisté par IA, et son sens d’origine s’est rapidement dissous
En résumé, on ne peut plus faire confiance à Redis
Qui va créer un fork sans LLM ?
Certains des cas d’usage présentés ne sont-ils pas aussi possibles avec ZSET ? Je comprends l’argument performance, mais comme le tableau utilise en option une représentation clairsemée, j’ai l’impression qu’on aurait pu optimiser en option le mode de stockage de ZSET pour des valeurs denses, sans créer une nouvelle surface d’API
La composante regex est intéressante, mais comme cela a aussi été mentionné ici, elle semble être une fonctionnalité orthogonale à la structure de données tableau. Autrement dit, elle pourrait être utilisée avec d’autres structures aussi. Ne vaudrait-il pas mieux faire cela avec du scripting Lua ? Si la performance de Lua est le problème, on pourrait aussi imaginer une manière d’abstraire l’OP pour qu’il soit composable au-dessus de toute commande renvoyant une plage de valeurs
Je respecte le fait qu’Antirez soit un expert du domaine, mais une partie de ce nouvel ensemble de fonctionnalités donne l’impression d’une solution qu’on voit souvent avec du développement piloté par LLM : créer une nouvelle fonctionnalité plutôt que d’améliorer l’existant, et surcomplexifier l’ensemble alors qu’une meilleure combinaison avec les autres fonctionnalités pourrait être plus efficace
De plus, si la représentation interne n’est pas un tableau, les requêtes par plage et le ring buffer ne peuvent pas fonctionner avec l’efficacité et la compacité nécessaires
En théorie, on peut tout faire avec n’importe quoi, mais il faut séparer ce que chaque API est censée faire pour pouvoir exploiter les cas d’usage et fournir la meilleure implémentation interne possible
J’aimerais demander à antirez s’il a tenté de faire de la génération one-shot à partir du code final ? Je me demande si GEPA permettrait d’y arriver, ou s’il y aurait quelque chose à apprendre de la manière d’orienter ou de prompter pour obtenir le résultat voulu
Ou alors la conclusion est peut-être simplement que les fournisseurs de modèles doivent nettoyer leurs données d’entraînement
On dirait que Salvatore veut populariser le terme Automatic Programming/Coding. (https://antirez.com/news/159)
Bien sûr, les LLM sont très particuliers du fait de leur caractère non déterministe et de leur portée étonnamment large, mais cela ne veut pas dire que ce terme ne s’applique pas
Cela dit, il pourrait être utile de raccourcir le terme en auto-code
Il est toujours intéressant de voir comment des développeurs très chevronnés interagissent avec l’IA aujourd’hui
@antirez : le fait d’avoir introduit vers la fin du projet une fonctionnalité de regex qui semble à première vue distincte est un peu étrange. Peux-tu expliquer davantage ce qui a motivé cette décision ?
Je me suis donc demandé quel serait l’équivalent d’AROP sur des fichiers, et la réponse était ARGREP
Ensuite, afin de pouvoir utiliser le meilleur outil selon les cas d’usage, j’ai intégré à la fois la recherche rapide par correspondance exacte et la recherche par regex
Puis j’ai découvert que, pour plusieurs chaînes reliées par OR, les regex pouvaient être plus rapides si elles étaient bien optimisées, et j’ai donc un peu spécialisé TRE