Redis array: short story of a long development process
Redis’ new array data type and regex capabilities are prompting debate over how far the project should evolve toward “small database” functionality and how best to model use cases like time-series or text-file-like workloads. The feature set was largely built using large language models, which many commenters see as a powerful “automatic programming” aid for experienced developers but not a wholesale replacement for human design, review, and accountability. Participants also weigh in on governance and trust in Redis, contrasting solo high-level stewardship with more community-driven models, and on how AI-heavy workflows affect productivity, code quality, and long-term maintainability.
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.