71–80 of 118 posts
Salvatore really wants to popularize the term Automatic Programming/Coding it seems. ( https://antirez.com/news/159 )
Earlier quoted context omitted.
How much faster/slower are you with that process compared to writing code yourself?
Can't speak for GP or OP, but I see about 10x the output and 2-4x the value of what I would be able to get by hand. Within the gap between 2-4x and the 10x is really a lot of design documents, user/dev documentation and testing that I might not have rolled to nearly the extent that I do/get when using AI. I haven't been using multiple AIs adversarially as OP, but might consider giving it a try with Codex and Opus. Th…
I feel strong making "dev" documentation though, since it seems a bit redundant/superfluous. I fully suspect nobody is going to read it at this point.
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…
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-ready code per day. I can productively review a couple of thousand.
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.
>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.
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…
How much faster/slower are you with that process compared to writing code yourself?
* I can work in code I'm not familiar with much easier
* LLMs often identify confusion or uncertainty upfront, so I can address it earlier.
* I'm much less mentally taxed so I can go for longer at my top end.
* Meetings, disruptions, end of day is WAY less critical since I can lean on the LLM to get back into things.
* I can do something else productive while the LLM is running. Bug fixes, documentation, PR reviews, etc.
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…
Reviewing 22,000 lines of code, even from antirez, with this complex of a feature set and minimal PR description sounds like a nightmare. One starts to see why major open-source software like Postgres tends to be developed on a mailing list, with intermediate design decisions discussed by the community, separate patches for different related features, incremental review, and then a spaced release cadence.
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".
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.
Earlier quoted context omitted.
Can't speak for GP or OP, but I see about 10x the output and 2-4x the value of what I would be able to get by hand. Within the gap between 2-4x and the 10x is really a lot of design documents, user/dev documentation and testing that I might not have rolled to nearly the extent that I do/get when using AI. I haven't been using multiple AIs adversarially as OP, but might consider giving it a try with Codex and Opus. Th…
I'm seeing the same, for gains being largely from documentation. I feel strong making "dev" documentation though, since it seems a bit redundant/superfluous. I fully suspect nobody is going to read it at this point.
or maybe the conclusion is that model providers need to clean up their training data!