Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis array: short story of a long development process

antirez.com

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Redis array: short story of a long development process

#61

Post by antirez »

fancy_pantser wrote: post #58
antirez wrote: post #56

Earlier quoted context omitted.

The code is 5000 lines of code in total, comments included: 2000 lines the sparse array. 2000 lines the t_array commands and upper layer implementation. ~500 lines of AOF / RDB code. All the other stuff is tests, JSON command descriptions, TRE library under "deps".

I think the point GP is making is this is a PR that smells like a solo dev working on their own project and not how a community-driven project adds major new functionality, although I'm sure there are docs and descriptions (or at least a discussion of tradeoffs and design decisions if not ADRs) are somewhere , but not linked handily to the PR. There is a lot of explanation in the blog post and PR, but it's unilateral…

Redis was completely built in this way since the start. I believe this is a better way to create software. Compromise in design is, in my opinion, something to avoid: feedbacks are important, but often times a single person that studied a lot the problem and have design taste, can come up with a great solution. Mediating such solution, even among two stellar A and B solutions, will not produce a C soution that is better, since you can't produce such solution by interpolation. It is simpler to damage A and B. And: it is rare that in a big set of people all have stellar ideas, so you have to mediate, often, also with people having poor ideas. Not worth the effort for the way I'm wired. What works better for me is to provide hints about what I'm doing, then I receive feedbacks, and sometimes there are really great ideas in this feedbacks, and I incorporate the part I like.

Re: Redis array: short story of a long development process

#62

Post by epolanski »

antirez wrote: post #59
epolanski wrote: post #26

Got few questions: - the project essentially spans almost 3 different (albeit minor) generations of LLMs. Have you noticed major differences in their personas, behavior, output for that specific use case? - when using AI for feedback, have you ever considered giving it different "personalities"? I have few skills that role play as very different reviewers with their own different (by design conflicting) personalities…

1. The huge jump from from Opus to GPT 5.3. Game changer. GPT 5.4, 5.5, were better but only incrementally better. 2. Nope I don't give much personalities, but I use subtle prompt differences to maximize certain responses I want, to make the model focusing in a given detail or acting in a specific kind of engineering mindset. 3. It never happened that the AI was slowing me down since I always had the full context and…

Thanks a lot for the insights. I like the Machiavelli thing.

> Then I ask GPT 5.5 Pro on the web with extensive reasoning set on. It will take sometimes 30 minutes or more to reply.

Any reason why Codex can't do that?

Re: Redis array: short story of a long development process

#63

Post by fancy_pantser »

antirez wrote: post #61
fancy_pantser wrote: post #58

Earlier quoted context omitted.

I think the point GP is making is this is a PR that smells like a solo dev working on their own project and not how a community-driven project adds major new functionality, although I'm sure there are docs and descriptions (or at least a discussion of tradeoffs and design decisions if not ADRs) are somewhere , but not linked handily to the PR. There is a lot of explanation in the blog post and PR, but it's unilateral…

Redis was completely built in this way since the start. I believe this is a better way to create software. Compromise in design is, in my opinion, something to avoid: feedbacks are important, but often times a single person that studied a lot the problem and have design taste, can come up with a great solution. Mediating such solution, even among two stellar A and B solutions, will not produce a C soution that is bet…

Thanks, I think I'm all caught up now. The timeline is like this if I understand correctly: your successors (Yossi Gottlieb and Oran Agra) explicitly announced a new governance model in 2020, saying the project had "outgrown the BDFL-style of management" and that they wanted to "promote more teamwork and structure". With the relicensing in 2024, however, external contributors with five or more commits to Redis dropped to zero in the first six months (basically, community contribution collapsed). In late 2024, you came back in the role of "Redis evangelist" and a year ago there was an additional licensing change, adding AGPLv3 as an option (8.0's tri-license). So now redis has your steady hand on the wheel again.

I was confused because the last time I checked on things, it was still about fostering community input and advancement but not necessarily consensus. Things have tipped back in the original direction since then. I don't think "Redis was completely built in this way since the start" is completely accurate, but also the community effort under the new governance model never got very deeply entrenched while you were away.

Re: Redis array: short story of a long development process

#64

Post by antirez »

epolanski wrote: post #62
antirez wrote: post #59

Earlier quoted context omitted.

1. The huge jump from from Opus to GPT 5.3. Game changer. GPT 5.4, 5.5, were better but only incrementally better. 2. Nope I don't give much personalities, but I use subtle prompt differences to maximize certain responses I want, to make the model focusing in a given detail or acting in a specific kind of engineering mindset. 3. It never happened that the AI was slowing me down since I always had the full context and…

Thanks a lot for the insights. I like the Machiavelli thing. > Then I ask GPT 5.5 Pro on the web with extensive reasoning set on. It will take sometimes 30 minutes or more to reply. Any reason why Codex can't do that?

If Pro is the same model (hard to tell, I'm not sure) it has a token budget to think (test time scaling) which is huge compared to the Codex endpoint.

Re: Redis array: short story of a long development process

#65

Post by fancy_pantser »

tibbar wrote: post #60
antirez wrote: post #56

Earlier quoted context omitted.

The code is 5000 lines of code in total, comments included: 2000 lines the sparse array. 2000 lines the t_array commands and upper layer implementation. ~500 lines of AOF / RDB code. All the other stuff is tests, JSON command descriptions, TRE library under "deps".

First of all, redis is amazing, and your 4 month development process speaks to the fact that you've already designed and verified correctness super thoroughly. ... just speaking as someone who sometimes has to review very long PRs sometimes, though, I feel like 25% is a roughly normal level of "signal to noise." 5,000 lines of core logic is a LOT, and the tests and dependencies do still need to be read. EDIT: I feel…

I think where we went wrong in understanding this PR is in the assumption that it's designed to invite review because that's how a lot of other team- or community-driven projects work.

Re: Redis array: short story of a long development process

#66

Post by beyti »

thallavajhula wrote: post #49

Salvatore really wants to popularize the term Automatic Programming/Coding it seems. ( https://antirez.com/news/159 )

I keep finding myself to minimize the words to describe the same thing as well, since we are finding ourselves doing "that" operation more and more over time.

maybe shortening the term to "auto-code" would help tho.

Re: Redis array: short story of a long development process

#67

Post by ignoramous »

wood_spirit wrote: post #20

Sharing my current MO: I start with a high level design md doc which an AI helps write. Then I ask another AI - whether the same model without the context, or another model - to critique it and spot bugs, gaps and omissions. It always finds obvious in hindsight stuff. So I ask it to summarize its findings and I paste that into the first AI and ask its opinions. We form an agreed change and make it and carry on this a…

This sort of "spec-driven development" was the USP behind AWS Kiro: https://kiro.dev/docs/specs/

> And of course you have to go read the code because I have found it that AI misses polishes

Since you mentioned using other agents, do you get mileage out of code reviews with another agent polishing the unpolished bits? My colleagues swear by it, though I personally remain skeptical about its value without a human reviewer.

> Then I ask another AI

May be synthesis-antithesis-thesis works better in applied computer science... https://en.wikipedia.org/wiki/Dialectic#Criticisms

Re: Redis array: short story of a long development process

#68

Post by sn9 »

pbowyer wrote: post #57
lovasoa wrote: post #25

Earlier quoted context omitted.

How much faster/slower are you with that process compared to writing code yourself?

Developer of 20+ years here, can't give you an accurate multiplier but I am faster. Because spotting holes in specs has never been one of my strengths. And working without technical colleagues much of the time, it's a boon to be able to "rubber-duck" my ideas with something that is at least more intelligent than plastic. Grabbing multipliers from thin air, the coding bit may only be 2x faster with a poorer-quality ou…

Have you considered incorporating formal modelling?

Like:

[0] https://csci1710.github.io/2026/ and https://forge-fm.github.io/book/2026/

[1] https://elliotswart.github.io/pragmaticformalmodeling/

[2] https://quint.sh/

Re: Redis array: short story of a long development process

#69

Post by derefr »

tibbar wrote: post #60
antirez wrote: post #56

Earlier quoted context omitted.

The code is 5000 lines of code in total, comments included: 2000 lines the sparse array. 2000 lines the t_array commands and upper layer implementation. ~500 lines of AOF / RDB code. All the other stuff is tests, JSON command descriptions, TRE library under "deps".

First of all, redis is amazing, and your 4 month development process speaks to the fact that you've already designed and verified correctness super thoroughly. ... just speaking as someone who sometimes has to review very long PRs sometimes, though, I feel like 25% is a roughly normal level of "signal to noise." 5,000 lines of core logic is a LOT, and the tests and dependencies do still need to be read. EDIT: I feel…

> At that point, there's probably not much major input you can have into the core architecture or strategy

Sure you can? In this concrete case, Redis is very "flat" — there's the data structure implementations, and there's the commands that use them. 1+N. You could have feedback about the data structure (i.e. whether it's optimal for the use-cases); or about any of the commands (i.e. not just their impls, but also whether they're the best core API surface to lock in long-term, or even whether they're worth including at all.)

Any given feedback would necessitate fairly limited rework to address, as you're either modifying the data structure (and its tests) or a command (and its tests and docs.)

Re: Redis array: short story of a long development process

#70

Post by zozbot234 »

simonw wrote: post #22
localhoster wrote: post #13

Let's make it very clear - this is the original creator of redis, or one of them. He is not "your avg dev" and it took him 4 months with llm. This is not a seal of approval for you to go and command all your developers to move to Claude code/codex/any other ai coding tool fully. I'm looking at you - any avg CEO of a startup.

It's a pretty strong endorsement for the idea that coding agents, used skillfully by experienced developers, can further amplify their expertise.

Sure but the OP suggests that these were minor gains, and that this limited scope for gains was necessary in order to preserve the quality standard that's long been expected in that FLOSS community. We aren't talking about either a 10x productivity gain or one-shotting entire new features from scratch.

This is arguably a key quote: "Then, it was time to read all the code, line by line. ... I found many small inefficiencies or design errors ... so I started a process of manual and AI-assisted rewrite of many modules." We should not underestimate that step: reading code line by line might easily require more time than writing it from scratch.

Post reply on HN