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

81–90 of 118 posts

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

#81

Post by devilsdata »

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…

I actually use LLMs a lot to rubber duck my problems and help develop plans. Then I manually code, to ensure my skills don't deteriorate. I feel like I'm a lot faster, with few of the downsides. Do you have any thoughts on this process?

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

#82

Post by tibbar »

derefr wrote: post #69
tibbar wrote: post #60

Earlier quoted context omitted.

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 wh…

Fair point that there might be some functional changes you can suggest, but I continue to suspect that by the time this PR hit GitHub, all the most important decisions have already been finalized.

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

#84

Post by slig »

jareklupinski wrote: post #74
slig wrote: post #50

Earlier quoted context omitted.

>He is not "your avg dev" and it took him 4 months with llm. He's not, but his work is obviously not average. Average dev work is plumbing and CRUDs.

it's honest work

It is, and LLMs help me a lot doing honest work.

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

#85

Post by artyom »

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.

Antirez is 100% the creator of Redis. And not only that, it's the kind of mind that you probably only get "a handful each generation".

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

#86

Post by dontdoxxme »

jaunt7 wrote: post #83

In short, Redis can't be trusted any more. Who is going to do an LLM free fork?

Your comment is not constructive, why can't it be trusted?

If every user of an LLM took this much care and attention, many people would have fewer issues with LLM assisted coding. In this case the author has demonstrated they can write plenty of code without an LLM, so why not use it carefully to benefit their productivity?

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

#87

Post by FEELmyAGI »

simonw wrote: post #73
zozbot234 wrote: post #70

Earlier quoted context omitted.

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 ineffici…

Right, and those of us who advocate for a sensible approach to agentic engineering don't talk about 10x productivity gains or one-shotting entire new (production-ready) features from scratch either. I remain unconvinced by the "faster to write it by hand than read it" arguments though. My experience throughout my career is that most people, myself included, top out at a couple of hundred lines of tested, production-r…

"top out at a couple of hundred lines of tested, production-ready code per day" + " productively review a couple of thousand." + LLM agents that write code for you = apparent contradiction with your first paragraph.

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

#88

Post by mlmonkey »

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.

This _is_ the original creator of Redis, and one of the best C coders out there, who writes impeccable C code.

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

#90

Post by zozbot234 »

FEELmyAGI wrote: post #87
simonw wrote: post #73

Earlier quoted context omitted.

Right, and those of us who advocate for a sensible approach to agentic engineering don't talk about 10x productivity gains or one-shotting entire new (production-ready) features from scratch either. I remain unconvinced by the "faster to write it by hand than read it" arguments though. My experience throughout my career is that most people, myself included, top out at a couple of hundred lines of tested, production-r…

"top out at a couple of hundred lines of tested, production-ready code per day" + " productively review a couple of thousand." + LLM agents that write code for you = apparent contradiction with your first paragraph.

Right, I don't think you can "productively review a couple thousand" lines of code per day. That would imply that the review step for this very patch only took a couple days in total (since the core code is described as 5k lines) which is rather implausible to say the least.
Post reply on HN