Live data from Hacker News

Redis array: short story of a long development process

antirez.com

101–110 of 118 posts

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

#101

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…

Simon often says that its LLMs help him "write productive code", but most of the code he shows are python libs doing menial tasks. That's fine for tooling, etc, which is sometimes useful.

It would absolutely NOT work for production-code with critical concurrency / embedded / real-time stuff

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

#102
post #91

Earlier quoted context omitted.

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

Exactly. LLMs are good at "code inpainting": you give them the structures / constraints / specs, and they write the boilerplate.

Then you need a senior to go realize the 100 mistakes it did, fix them, and iterate, which is why you can't replace "natural intelligence"

And there are real mathematical reasons why computers won't be able to break through "mathematical reasoning" on their own (indecidability, etc)

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

#103
post #57

Earlier quoted context omitted.

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?

If you can type code fast and accurately, it sounds a great process to use. You're using LLMs for the bit where they bring great value, and yourself as a higher quality coding agent :)

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

#104
post #68
post #57

Earlier quoted context omitted.

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/

Only at the "hmm that seems an interesting idea" level.

Thanks for the links, going to have a read and see if I can apply any to my work.

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

#105
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…

The author said "You know what was the biggest realization of all that?"

> For high quality system programming tasks you have to still be fully involved, but I ventured to a level of complexity that I would have otherwise skipped. AI provided the safety net for two things: certain massive tasks that are very tiring (like the 32 bit support that was added and tested later), and at the same time the virtual work force required to make sure there are no obvious bugs in complicated algorithms.

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

#106

Earlier quoted context omitted.

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…

Simon often says that its LLMs help him "write productive code", but most of the code he shows are python libs doing menial tasks. That's fine for tooling, etc, which is sometimes useful. It would absolutely NOT work for production-code with critical concurrency / embedded / real-time stuff

Antirez wrote Redis. That is "production-code with critical concurrency"

To quote another of his posts:

> I fixed transient failures in the Redis test. This is very annoying work, timing related issues, TCP deadlock conditions, and so forth. Claude Code iterated for all the time needed to reproduce it, inspected the state of the processes to understand what was happening, and fixed the bugs.

...

> In the past weeks I operated changes to Redis Streams internals. I had a design document for the work I did. I tried to give it to Claude Code and it reproduced my work in, like, 20 minutes or less (mostly because I'm slow at checking and authorizing to run the commands needed).

From "Don't fall into the anti-AI hype" https://antirez.com/news/158

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

#107
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.

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

That makes the title of another of his posts very ironic then:

"Automatic programming"

https://antirez.com/news/159

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

#108
post #107

Earlier quoted context omitted.

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

That makes the title of another of his posts very ironic then: "Automatic programming" https://antirez.com/news/159

Not really:

> I started to refer to the process of writing software using AI assistance (soon to become just "the process of writing software", I believe) with the term "Automatic Programming"

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

#109
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…

> We should not underestimate that step: reading code line by line might easily require more time than writing it from scratch.

Might?

Reading code you did not write is always going to take more time if you do it properly.

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

#110
Redis wants to get in on the vector database market that is popular in AI. That is all there is to it.

That is the reason why the Redis author keeps boosting AI. To the point where he even uses Redis to demonstrate how many bugs AI has found. Not every software is as buggy as Redis.

It is all an advertisement by someone extremely adept at manipulating techies.

Post reply on HN