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.