- El trabajo en el nuevo tipo de dato Array de Redis comenzó a inicios de enero y llegó a un PR unos 4 meses después; durante el primer mes se redactó una especificación con la necesidad, estructuras en C, representación dispersa, ring buffer y la semántica del cursor de arreglo para
ARINSERT - El diseño inicial se refinó junto con Opus y, tras el lanzamiento de GPT 5.3, el diseño y el desarrollo avanzaron con Codex; en el proceso de retroalimentación con la IA se siguieron revisando los compromisos y las partes sobre-diseñadas
- La implementación cambió para que incluso asignaciones en índices grandes como
ARSET myarray 293842948324 foofuncionen sin requerir asignaciones gigantes, y la estructura de datos interna cambia según las condiciones entre super directorio, directorio denso segmentado y slices reales del arreglo - Cada slice contiene por defecto 4096 elementos, y
ARSCANyARPOPpueden recorrer arreglos existentes en un tiempo proporcional al número real de elementos presentes, no al tamaño completo del rango - Un caso de uso de poner archivos Markdown dentro de arreglos de Redis llevó a la implementación de
ARGREP; para el soporte de expresiones regulares se eligió TRE, y los casos de uso están resumidos en Redis PR #15162
Implementación y revisión
- A partir del segundo mes se empezó la implementación con un enfoque de programación automatizada, revisando continuamente el código generado
- Incluso después de que la implementación funcionó, se revisó línea por línea el código, incluyendo
sparsearray.cyt_array.c - Gracias a la IA hubo muchas pruebas, pero que el código pareciera funcionar no significaba que fuera óptimo, así que se encontraron y corrigieron pequeñas ineficiencias y errores de diseño
- Varios módulos se reescribieron de nuevo, tanto manualmente como con asistencia de IA, y en el tercer mes se realizaron pruebas de estrés de distintas formas
- En la programación de sistemas de alta calidad, las personas todavía deben involucrarse por completo, pero con IA se obtiene una red de seguridad para tareas agotadoras como añadir soporte de 32 bits y pruebas, además de detectar bugs evidentes en algoritmos complejos
- La gran especificación inicial fue clave para el trabajo posterior y también resultó importante al revisar cada línea del código y corregir lo que no encajaba
Casos de uso y expresiones regulares
- Mientras se modelaban casos de uso, se empezaron a poner archivos Markdown dentro de arreglos de Redis y se llegó a la conclusión de que los archivos encajaban bien con el tipo de dato Array
- Eso llevó a implementar
ARGREPpara crear una base de conocimiento central basada en archivos Markdown necesaria para el trabajo de agentes - Para el soporte de expresiones regulares se eligió TRE, porque al usar expresiones regulares en Redis no debía haber patrones patológicos en tiempo o espacio
- TRE era muy ineficiente en patrones útiles como
foo|bar|zap, así que con ayuda de GPT se optimizó, se corrigieron algunos posibles problemas de seguridad y también se ampliaron las pruebas - Los casos de uso están documentados en detalle en Redis PR #15162, lo que llevó a la conclusión de que Redis necesita un tipo de dato en el que los índices numéricos formen parte del significado
- Se espera que el PR de Array sea aceptado pronto y que pueda aprovecharse en nuevos casos de uso, por lo que se solicita retroalimentación
1 comentarios
Comentarios en Hacker News
Para dejarlo claro, esto lo hizo el creador original de Redis, o uno de ellos
No es un “desarrollador promedio”, e incluso usando LLM le tomó 4 meses
Así que no debería tomarse como un sello de aprobación para decirles a todos los desarrolladores que se cambien por completo a Claude Code, Codex u otras herramientas de código con IA basándose en esto
En especial, es una parte que los CEO promedio de startups deberían ver
En el original dice: “Incluso antes de los LLM, probablemente podría haber hecho la implementación en unos 4 meses. Lo que cambió fue que pude hacer mucho más en el mismo período”
Es decir, el período inicial ya era de 4 meses, y gracias a los LLM hizo más trabajo dentro de ese mismo tiempo
El trabajo promedio de desarrollo se parece más a plomería y CRUD
Así es como trabajo actualmente
Primero escribo un documento de diseño de alto nivel en Markdown con ayuda de IA. Luego uso el mismo modelo quitándole el contexto, o le pido a otro modelo que lo critique, para encontrar bugs, omisiones y huecos. Más tarde siempre encuentran cosas obvias
Entonces les hago resumir esos hallazgos, los pego en la primera IA y le pregunto su opinión. Se acuerdan cambios, se aplican, y sigo con estas rondas adversariales en round-robin hasta que ningún modelo puede hacer una sugerencia significativa
Después le pido a la IA que haga un plan, y ese plan también pasa por varias IAs en modo adversarial. Al final sale un plan bastante sólido
Luego paso a cosas como el plan de casos de prueba end-to-end. Dependiendo del tamaño del sistema, para el final del primer día, la primera semana o el primer mes ya estoy listo para codificar
Cuando se genera el código, pego ese código, la especificación y el plan en otra IA y le pido que encuentre bugs, omisiones y huecos. La idea es seguir validando con otras IAs a la IA principal encargada de implementar
Claro, igual hay que leer el código uno mismo. He visto que la IA se salta el pulido fino de calidad de cierre
No lo digo con sarcasmo. Mi flujo de trabajo también es esencialmente igual, y tampoco es para burlarse de Google. Más bien, significa que no hay nada realmente nuevo
La IA acelera muchísimo tanto los flujos de trabajo efectivos como los inefectivos. Gracias a eso, qué funciona y qué no se vuelve visible mucho más rápido, casi en tiempo real
También dijo que usa otros agentes, y me pregunto si ha visto buenos resultados en revisiones de código donde otro agente pule las partes menos refinadas. Mis colegas creen mucho en eso, pero personalmente sigo dudando de cuánto valor tiene sin revisores humanos
Esto de “preguntarle a otra IA” quizá encaje mejor con tesis-antítesis-síntesis en ciencias de la computación aplicada: https://en.wikipedia.org/wiki/Dialectic#Criticisms
Aunque lo haya escrito antirez, hacer una revisión de 22,000 líneas de código con este nivel de funcionalidades y una explicación mínima del PR suena como una pesadilla
Se entiende por qué proyectos grandes de código abierto como Postgres se desarrollan en listas de correo. Ahí las decisiones intermedias de diseño se discuten con la comunidad, las funcionalidades relacionadas se dividen en parches separados, se revisan de forma incremental y además se espacian entre releases
El arreglo disperso son 2,000 líneas
El comando
t_arrayy la implementación de capas superiores son 2,000 líneasEl código AOF/RDB son unas 500 líneas
El resto son pruebas, descripciones de comandos JSON y la librería TRE bajo
depsDe hecho, la mayoría de las funcionalidades importantes de Redis han sido trabajo hecho prácticamente por el autor en solitario
Además, los revisores conocen bien este trabajo y reciben una compensación adecuada
Muy parecido a mi experiencia usando la mejor IA actual. Está muy lejos de ser un sustituto de la inteligencia y creatividad humanas, pero como colaborador es extremadamente útil
Pero Redis todavía no. Si algún día eso se vuelve posible en software de servidor, la forma actual de desarrollar se habrá terminado
Las funcionalidades, correcciones y acumulación de experiencia seguirán teniendo valor, así que los proyectos y repositorios seguirán existiendo, pero el rol del programador se parecerá mucho al papel que Linus ha tenido hasta ahora con el kernel
En algunos proyectos como el motor de razonamiento DeepSeek v4 ya se trabaja más o menos así
Me entusiasman array/regex, y también es muy interesante la experiencia de ampliar capacidades con LLM. Hay mucha gente probando cosas parecidas en silencio en varios proyectos
Vibe coding y el rechazo que provoca no alcanzan para describir bien esta forma de trabajar
Pero pronto la gente empezó a usar la frase para casi cualquier tipo de programación asistida por IA, y su significado original se fue perdiendo rápidamente
En resumen, ahora ya no se puede confiar en Redis
¿Quién va a hacer un fork sin LLM?
¿No se podrían resolver algunos de los casos de uso presentados también con ZSET? Entiendo el punto de rendimiento, pero así como el arreglo usa opcionalmente una representación dispersa, parecería posible optimizar opcionalmente la forma de almacenamiento de ZSET para valores densos sin añadir una nueva superficie de API
El componente de regex es interesante, pero como ya se mencionó aquí, parece una funcionalidad ortogonal a la estructura de datos de arreglo. O sea, podría usarse también con otras estructuras. ¿No tendría más sentido hacerlo con scripting en Lua? Si el problema es el rendimiento de Lua, quizá también habría una forma de abstraer la OP para que se pueda combinar sobre cualquier comando que devuelva rangos de valores
Respeto que Antirez sea experto en esta área, pero parte de este nuevo conjunto de funciones se siente como una solución típica del desarrollo guiado por LLM: en vez de mejorar funciones existentes, crear funciones nuevas y hacer la funcionalidad más compleja de la cuenta, cuando podría ser más efectivo combinarlas con otras ya existentes
Además, si la representación interna no es un arreglo, las consultas por rango y los buffers circulares no pueden funcionar con la eficiencia y compacidad necesarias
En teoría se puede hacer cualquier cosa con cualquier cosa, pero hay que separar lo que cada API puede hacer para poder usar los casos de uso y ofrecer la mejor implementación interna posible
Tengo curiosidad para antirez. ¿Probó experimentar con una generación casi de una sola pasada para el código final? Me pregunto si con GEPA se podría llegar hasta ahí, o si hay algo que aprender de las técnicas de guía o prompting para obtener el resultado deseado
O tal vez la conclusión sea que los proveedores de modelos tienen que limpiar sus datos de entrenamiento
Parece que Salvatore quiere popularizar el término Automatic Programming/Coding. (https://antirez.com/news/159)
Claro, los LLM son muy particulares por ser no deterministas y por tener un alcance sorprendentemente amplio, pero eso no significa que el término no aplique
Aun así, quizá ayude acortar el término a auto-code
Siempre es interesante ver cómo los desarrolladores muy experimentados interactúan con la IA hoy en día
@antirez: hacia el final del proyecto, introducir una funcionalidad de regex aparentemente separada se siente un poco extraño. ¿Podrías explicar más el razonamiento detrás de esa decisión?
Así que pensé cuál sería el equivalente en archivos de AROP, y la respuesta fue ARGREP
Después incluí tanto coincidencia exacta rápida como coincidencia por regex para poder usar la mejor herramienta según el caso de uso
Luego descubrí que, para múltiples cadenas unidas con OR, una regex bien optimizada podía ser más rápida, así que especialicé un poco TRE