Redis array: short story of a long development process

AI-assisted development and “automatic programming”

  • Central theme is how the Redis array feature was developed with heavy LLM assistance over ~4 months.
  • Maintainer says LLMs enabled tackling a higher level of complexity (e.g., 32‑bit support, complex algorithms, extensive tests) in the same time they would previously have spent on a simpler version.
  • Workflow is spec-driven: write a very detailed design/spec, use LLMs to “code inpaint” missing pieces, then perform line‑by‑line human review and iterative refinement.
  • Several commenters use similar workflows: adversarial use of multiple models to critique specs and plans, AI-assisted documentation and tests, and rubber‑ducking ideas.

Debate on productivity gains and limits

  • Some report significant speedups (e.g., 2–4x value, 10x more total output including docs/tests; faster spec work, easier work in unfamiliar codebases).
  • Others argue these gains are modest relative to hype about “10x devs” or fully automated coding, stressing that architecture, precise specs, and reviews remain human‑heavy.
  • Skeptics see LLMs mainly as advanced autocomplete/boilerplate generators that still require senior oversight; reading and understanding generated code can be slower than hand‑writing it.
  • There is pushback against claims that LLMs can replace developers, especially in critical systems; proponents emphasize they are powerful co‑pilots, not autopilots.

Redis arrays feature, scope, and design

  • Discussion on whether Redis is becoming “a small database.” Maintainer reiterates Redis is a data‑structures server; arrays are justified as a fundamental type with focused, self‑contained complexity.
  • Arrays are highlighted as better fits for some use cases previously done with hashes (e.g., sensor data, ring buffers, dense ranges).
  • Some question whether arrays + regex/grep‑like ops should have been built atop existing structures (e.g., sorted sets, Lua) rather than new APIs; maintainer argues specialized implementations give better performance and semantics.

Regex, locales, and technical details

  • New ARGREP/regex capabilities are motivated by text‑file‑like array use cases.
  • Concerns about locale‑dependent behavior are raised; response notes Redis sets locale at startup but certain case‑insensitive matches (e.g., accented characters) won’t behave as users might expect.

Project process, governance, and trust

  • Large PR size (~22k added lines) sparks discussion about review burden. Clarification: core logic is ~5k LOC; rest is tests and vendored regex library.
  • Some argue this resembles solo‑driven design rather than community‑driven development; maintainer defends a strong single‑designer model with selective incorporation of feedback.
  • One commenter questions trusting Redis due to LLM use; others rebut that careful, expert‑supervised use of LLMs is not a reliability concern.