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

91–100 of 118 posts

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

#91

Post by gfody »

zozbot234 wrote: post #70
simonw wrote: post #22

Earlier quoted context omitted.

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

> Sure but the OP suggests that these were minor gains

When antirez says 'I ventured to a level of complexity that I would have otherwise skipped,' I don't think you can call that a minor gain. The alternative is likely something 'good enough' that leaves the community dissatisfied for months, and then after initial design mistakes become load-bearing the ideal implementation can never be realized.

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

#92

Post by merb »

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…

BTW the last day. I played with Claude to fix the simple things all by himself. Sadly we are on gitlab so I needed to tell him to use glab cli and I needed a little bit more time to setup than GitHub (why do they not support gitlab or other code forges…) However it is definitely a time saver in these 1-3 line changes. My workflow basically was:

Let the LLM cook by doing the issues one by one. In the meantime I could start reviewing them. Checkout, running, reading. It was definitely faster since it also correctly linked everything, etc. of course once the change goes beyond that it probably is not working. However I really thought that a good idea would be to check for that work and implement it according to the issue description and change a Mr once the description changes, at least as long as the Mr is 1-3 lines. And even if it does not work, I can just discard it.

(A lot of these problems are often typos that do not even need a checkout, they come in through bigger Mrs that should not be blocked because of them)

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

#93

Post by zozbot234 »

gfody wrote: post #91
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…

> Sure but the OP suggests that these were minor gains When antirez says 'I ventured to a level of complexity that I would have otherwise skipped,' I don't think you can call that a minor gain. The alternative is likely something 'good enough' that leaves the community dissatisfied for months, and then after initial design mistakes become load-bearing the ideal implementation can never be realized.

He writes that right after saying "For high quality system programming tasks you have to still be fully involved". He's just saying that AI was useful to him for tedious special-case tasks (citing the addition of 32-bit support and fishing out bugs in new low-level implementations), that this required starting from a "huge specification" (not a one-shotted prompt!) and that he still had to go over everything with a fine-toothed comb afterwards. That's the farthest thing from the 10x silver bullet AI is now being sold as.

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

#95

Post by skybrian »

zozbot234 wrote: post #90
FEELmyAGI wrote: post #87

Earlier quoted context omitted.

"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.

Both Simon Willison and Antirez said that using LLMs helped them, so it's kind of perverse to read them and conclude the opposite.

In particular, doing direct comparisons between metrics like that doesn't work. "Lines of code" isn't a good way to measure complexity of the code, and the amount of time it takes to review the code will vary quite a bit based on the use case.

There's a lot of diversity in what kind of code people write and just because it worked for someone else doesn't mean it will work for the kinds of problems you solve. It's anecdotal evidence that someone else found it useful, your mileage may vary.

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

#97

Post by zozbot234 »

skybrian wrote: post #95
zozbot234 wrote: post #90

Earlier quoted context omitted.

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.

Both Simon Willison and Antirez said that using LLMs helped them, so it's kind of perverse to read them and conclude the opposite. In particular, doing direct comparisons between metrics like that doesn't work. "Lines of code" isn't a good way to measure complexity of the code, and the amount of time it takes to review the code will vary quite a bit based on the use case. There's a lot of diversity in what kind of co…

The relevant question is whether it helped them 10x or anywhere close to what AI is now being sold as (supposedly even replacing software developers' jobs altogether and one-shotting complete products from a single prompt), or it's just acting as a kind of glorified autocomplete. So far we're clearly seeing the latter based on what both Simon Willison and Antirez are referencing.

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

#98

Post by [deleted] »

SkyPuncher wrote: post #77
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 might be the outlier, but this PR feels like heaven to review. It's a complete, all encompassing PR that I can work through with the entire context right in front of me. If the initial development bar is relatively high, it's far, far easier to identify flaws and gaps when you have the whole thing in front of you all at once.

[deleted]

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

#99

Post by oulipo2 »

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.

Well that's mostly my point: LLMs are mostly useful now as "code inpainting" / "boilerplate writing" when you have a defined spec

I'm doing my work mostly the same as Antirez is doing, writing detailed spec (which is actually 80% of the hard work, even without LLMs), then where I would have written the "boring stuff" I use the LLM to "autocomplete", and then see all the mistakes (which require being a senior to see / fix), correct, and iterate

It makes the work "feel" easier because we mostly skip writing the boilerplate, but it still doesn't replace coders. And companies that think they will be able to skip training juniors (in order to later replace seniors) and still have seniors onboard are making a huge mistake

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

#100

Post by oulipo2 »

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.

...which is VERY, VERY, FAR from "LLMs can automate coding" that people like to say, which is completely false
Post reply on HN