# Redis array type: short story of a long development

DevFeed: [Redis array type: short story of a long development](<https://devfeed.tech/articles/redis-array-type-short-story-of-a-long-development-20655.md>)

Original publisher: [Read original article](<http://antirez.com/news/164>)

Published: 2026-05-04T14:21:45Z

Content type: opinion

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Development](<https://devfeed.tech/topics/development.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [codex](<https://devfeed.tech/topics/codex.md>), [Large Language Model](<https://devfeed.tech/topics/llm.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [codex](<https://devfeed.tech/tags/codex.md>), [development](<https://devfeed.tech/tags/development.md>), [llms](<https://devfeed.tech/tags/llms.md>), [programming](<https://devfeed.tech/tags/programming.md>), [redis](<https://devfeed.tech/tags/redis.md>), [time](<https://devfeed.tech/tags/time.md>)

## AI overview

The author describes developing a new Array data type for Redis over four months. The work included writing a detailed specification, using Opus and later GPT 5.3 with Codex for design and development, and implementing the data structure through automatic programming with continuous code review. AI-enabled iteration led to a more elaborate internal representation using sparse and dense directories and array slices.

## Source excerpt

I started working on the new Array data type for Redis in the first days of January. The PR landed the repository only now, so this code was cooked for four months. I worked at the implementation kinda part time (kinda because many weeks were actually full time, sometimes to detach yourself from the keyboard is complicated), and even before LLMs the implementation was likely something I could do in four months. What changed is that in the same time span, I was able to do a lot more. This is the short story of what happened. In the first month I just wrote the specification document. The rationale for the new data type, the C structures, the sparse representation used, the exact semantics of the array cursor for ring buffer and ARINSERT. I started writing for days a long specification by hand, then I paired with Opus initially, then GPT 5.3 was released and I switched all the design and development with Codex. Since then I use only GPT 5.x for system programming tasks. Thanks to AI, the specification evolved a lot, via back and forth of feedback, intellectual challenges about what was the best design, what was the right compromise, what was too engineered and what not. Starting from the second month, I started the implementation using automatic programming (auto coding if you prefer), constantly reviewing the developed code. Then I realized that the level of indirection I picked was wrong. I really wanted people to be able to do ARSET myarray 293842948324 foo and everything to still work without huge allocations. The two levels of directory + slices (sparse and dense) I had were not enough. Because I had AI, I took no compromises, and I decided to go the extra mile. Once certain conditions are reached, the data structure internally changes shape, and becomes a super directory of sliced dense directories, that also point to the actual array slices (4096 elements per slice, by default). This design provided still the internal "is actually an array" representation I wan