I believe issues will arive with AI in the near future in terms of their performance. Disagreeing with the author, I think code quality pre-AI, in certain languages, were golden. They all contained bugs but they were written in a way that bug sources would be more or less obvious and most but not all top open source software had linting guidelines, code styles & friends to help make it ingestible. Perhaps these helped said project's maintainers a great lot, but it absolutely SAVED AI when it came to training data. These top-quality repositories with thousands of lines of great code combined with hundred thousand lines of mixed quality code was the perfect formula for the big data churner™. Now what? All those repos, inflated with stars are generated by one of the 5 LLMs out there. There has been extended discussions about deterministic behaviour in LLMs, and I'm no ML engineer but to me this drop in entropy will surely cause backtracking in code quality. Of course there a vast array of improvements that can be made outside of training data, but the whole psychology attached to LLM marketing, in my opinion, obstructs those improvements. You could train a better suited way of input for LLMs, set cutoffs and posttraining in just the right places and everything but you gotta think it through. How many of those who ask their favourite LLM everything think anymore? How much of our current knowledge is safe from AI hallucinations or subtle nudges? AI has changed the world of coding, but the current state in Anthropic HQ will determine if it will just be mid-quality codegen or accelerationist fever dream.
I tried really hard to do this, but it turns out the models don't care about your ideas and want to do what's popular in their training data, so they will happily ignore anything you try to force down their throats, especially as context length grows or if you hit compaction.
So to make best use of the models steer them down familiar paths, mention common pattern and frameworks, use popular packages and languages that have the high median quality online.
I started my project with a few simple interface definitions and a short design / architecture doc that I include in the AGENTS.md file, but no matter how hard I try all of the models just end up ignoring it and sprinkled new seeds of variants of the same stuff all over my code base, that with each new session grow new branches.
I do highly unusual, off the beaten path projects with AI.
For instance, a game engine written entirely in LuaJIT, but allocating almost all data structures using CFFI, a very unusual, custom object-orientation DSL I designed myself, and that uses SDL3's SDL_gpu library to do all rendering, a ton of GLSL 4.6 compute shaders cross compiled to SPIR-V and Metal (which constraints what GLSL can be written), and is a hybrid tile-oriented and 3D engine.
Another example is my Emacs-like live-modifiable image-based editor, again in LuaJIT+CFFI, with a kqueue+atomic lock-free ring buffer+pthread based actor model, each running a separate LuaJIT interpreter, with a custom advicing system, event bus, async/await implementation riding on the event bus, a custom process management and IO library, and testing via Tmux.
Even DeepSeek V4 Flash mostly does fine with this, once it's built a few memories in the memory system. Let alone something like DSv4-Pro or GLM 5.2. All I can say is skill issue.
It's not an issue of usual vs unusual, I'm saying the models are way better at writing and maintaining django or react code bases than your own hand rolled architecture that you define in some docs that it has to learn and keep in context. All of the models do an amazing job making local edits and working in small greenfield projects but once you get to full production systems with close to a million lines things start to rot. The code still works and the models are able to make progress but all of a sudden you have 3-4 different versions of your concepts sprinkled in random corners of your code base.
My second point is that the models are way better at things like Rust or Lua than Python or JS, because the average person producing code in those languages has way more programming experience, so the code quality of training data online in those languages is higher than the programming 101 medium blogspam type content you see in more popular intro languages.
I haven't hit nearly a million lines, that's true, these projects are "only" 20k and 45k lines of code or so, respectively; however, I do have directed acyclic graphs of worker agents, managed asynchronously by the agent I chat directly with, do huge architectural refactors (the most recent, was to update everything in the codebase that used the sychronous Lua standard library `io` functions to use the asynchronous, multithreaded IO system I created for the editor — at least, everything that could use the new library, which I kept deliberately simple in a few ways, and everything that wasn't already temporary, but you know) and that's turned out quite well, and at least for me, 45k sloc is nothing to sneeze at, especially since with a green field project there's less examples to keep them on track. I do regularly check in to make sure it's using my design to the fullest, as well.
I don't necessarily disagree with the overall point you're making, but I think calling it a "skill issue" is a bit reductive. These are relatively new tools that are changing quickly, and the amount of flexibility in how you can use them is a lot higher than pretty much anything else we've built up patterns for in the industry in recent years. Rather than dismissing people who express having trouble producing the results you can, I feel like we should be giving lifting others up by providing insights into how we're able to do those things when we know that they're possible. Otherwise, how do we know it's truly a "skill" issue and not a "knowledge" issue, and the only thing stopping them is that no one has helped them understand?
right, the model will listen to you for ~32k context; half of that is just getting them into the "downhill" path for being a coding assistant. You can throw in whatever your heart's desire and if it's a single fix, it might listen to you; but treating it like a smart-IDE basically means it'll follow whatever dominant pattern is in the training data.
If we had smart capitalism (the SAME PROBLEM) we'd realize what we want are per-framework or per-OS models that simply are 80% how to english and 20% the tools we need for a given project.
> Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I need to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste.
I wonder why he HAS TO ("I need to...") review the code even if he thinks it is pointless? Is that because his employer, Redis, requires it?
Very uncomfortable to read. The proposed idea of not reading the code you ostensibly wrote, doesn’t just challenge the traditional workflow or methodology, it challenges the identity of a programmer itself. For experienced, respected programmers like antirez perhaps reading and writing code truly has just gotten in the way of the ideas, but I cannot identify with that perspective. The devil is in the details, reading other peoples code (and code the LLM writes) evolves the idea itself, and changes my understanding of it. My view on this is so biased by the direct relation of code I read and write to feeding myself and my family (the vast majority of my programming is for a paycheck) that suggestions of removing myself from the process feel grim, not exciting.
For complex code changes or bigger features I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, etc. It's not that you spend less time refining ideas, you just do it at another level of abstraction
But that does come with tradeoffs, and it's not the right thing for every project. But when it does work it does increase the amount of work you get out in the same time
Ideas are a dime a dozen. All of us have half a dozen of what appear to be good ideas every. Execution matters, testing and sanity checking matters, actual engagement with users and iteration matters.
Sure, we're reducing the cost of idea -> prototype to near zero (well, as long as tokens are free or nearly free), but that just means we now have mountains of throw away code, within which there may a gem or two.
Nothing yet has replaced the curating of ideas that good teams do as a matter of course.
I think the gist of what the aurhthor is saying is, AI is not good enough to just give one vague prompt to and let it go, but it's good enough for you to give it a "design" and then not worry about the actual code it writes. But you need to do a lot of QA still. And you still need to learn to code and write some code, I guess so you can give the LLM good instructions? But if giving good enough instructions requires some level of coding skill, how are you going to gain that skill if you don't do much programming or reading code?
It all sorta feels like an old guy (he says hes's old in TFA) who forgot how he got to where he is today trying to give advice. Be careful what you believe, young programmers.
For some background on me to set the context for the following opinion:
- been a SRE/DevOps at banks/hedge funds for almost 20 years
- now work in L1 crypto
- have been coding since I was 12 and have also been using frontier models for the past year (including running multiple agents at the same time etc).
My thoughts:
The models are indeed amazing. They can read large codebases, find bugs, infer the root cause of an issue from partial logs etc etc.
They do still hallucinate. WAY less than they used to but it's still non-zero. In a way that's worse b/c the model will spit out a complex piece of software and say "Yep, no mistakes. I even wrote tests and they all pass!" You might think "Phew, that's great!" but in the same way we've all found bugs in production code written by smart people, there will be bugs here too.
I say this not to imply that you have to read all of the code. I say if only to underline that for big complex systems, the "let's write unit tests for the parts that ABSOLUTELY HAVE TO BE CORRECT" is still just as important as it ever was. I'm thinking of examples like:
- the order and execution handler of a trading system
- avionics flight controls
- healthcare related medical devices
- etc
As an example: I was working on a complex system. I wasn't sure if the LLM code was actually correct so I wrote up a quick script that I checked, line by line, to be 100% sure it was working as I expected. I then used that script to double check the LLM. I didn't read all of the code the LLM created. The sense of "ok, now this works" was astounding.
I'll add, a lot of the developers I work with are going this "hybrid" route too where they will have the LLM write code and tests but then go back in and double check.
In closing, a lot of these big rewrites with LLMs are possible only b/c the devs KNOW, FOR A FACT, that the unit/integration tests are correct. I'm still not convinced that you can have LLMs write all of the code and all of the unit tests and be 100% sure that it's all correct. (I will admit that this has always been difficult and even the pre-LLM days were not a guarantee that all of the code wa s correct)
This position assumes that purely LLM-written codebases are able to scale infinitely.
IMO there isn’t enough evidence for me to feel comfortable in that judgement.
Anecdotally, I find that pretty often LLMs (even bleeding-edge models) write unidiomatic/unscalable/poorly-abstraced code when working in large codebases.
Some of the most exciting engineering work is happening in the DS4 repo - and I'm watching it almost like a sports game.
When the DSpark paper came out[1] the next day we had folks attempting to implement, working together, validating their failures. Eventually their work being synthesized into a PR[1] that admits performance is not ideal. Something antirez alluded to in one of his videos (speculative decoding is a great boon, but mostly for large labs hosting and serving many requests at once, and maybe not so effective for local inference).
There's recent work into "directional steering"[3] that has made it's way into per-session directional steering overrides thanks to audreyt[4].
There's support for the new Hy3[5] model also thanks to audreyt[6].
There's Pre-M5 optimizations[7] in the queue thanks to ivanfioravanti who also helped with some of the initial M5 optimizations.
I haven't watched a repo like this since llama.cpp and whisper.cpp in the early days (though llama.cpp is pretty exciting right now with the SYCL improvements that are flowing in for the new Intel GPUs).
The DS4 repo is a really interesting place to watch folks who heavily code with agents collaborate together in a way that seems pretty effective. I've been really enjoying it.
Thanks! And sorry for not yet merging many of those. The problem is, I'm dealing with tensor parallelism for the CUDA and Metal-RDMA fork right now, so was not albe to care about PR / issues for a lot of time.
I am not sure I'm buying this. The raison d'être for our existing software engineering methods is that humans make mistakes and we needed to contain the effects of these mistakes; and without an appropriate methodology to do that, software defects will just accumulate over time. Worse, once they show up, nobody understands the code well enough to do anything about them, or at least not without considerable time investment.
This does not change with agents doing the coding. Coding agents make mistakes also. Not very often nowadays, but neither do competent human programmers. And without a methodology to keep problems in check your agentic code will also accumulate software defects over time and result in code that becomes less and less maintainable, because you have no mental model of the software.
Antirez is correct in pointing out that slop existed before we started to use LLMs for programming; I've worked with my share of really ugly legacy code myself. But the problems do not magically disappear in the LLM age, no matter how good your model is. They remain, as every model is ultimately a heuristic (albeit a very powerful one), and no heuristic is 100% accurate.
This does not mean that coding agents are useless; used correctly, they can be enormously powerful accelerators for the software development (and validation!) process, because combining your strengths with those of a modern LLM is generally a substantial net gain. But that must still happen as a part of an approach that results in maintainable software with minimal defects.
Personally, I primarily use agents as virtual pair programmers these days, which I find very useful. This is an iterative process with relatively small and contained changes, where "looking at the code" is just part and parcel of following along and building a mental model of the resulting piece of software.
What do you mean? Are you arguing that it's impossible to fully translate things? Would you argue that "apple", "manzana", "pomme", "mela", "maçã" etc. all refer to different ideas?
Do you have any evidence for Valkey "widely replacing" Redis, instead of just rapidly gaining adoption as well? Additionally, it's important to clarify that the replacement was 100% over licensing issues — iirc predating the vibe coding entirely — not the use of AI to code, and that furthermore, no one has to my knowledge pointed to any flaws in the Redis codebase even correlated with AI use. So this is a disingenuous framing.
100% of the employers I worked for (one employee) never did that switch. The license did not affect us; we had nothing to do with AWS and the like, so we just continued using Redis like before. We already had our RPM builds, so whatever course distros took, we did not even care to look.
To be honest until today I thought Kafka was the popular go-to Redis replacement, as almost none of my employers used Redis for its original, intended purpose, namely being an in-memory key-value store. What they really wanted was RabbitMQ.
Sure, it costs less, and AWS is in a dominant position. Users here are playing the side of the bully since they don't care about what is right and wrong with the hyperscalers. "BSD is better than AGPL!" And give money to the wrong side of the history. Nor that I expected anything better, the single person has a given sensibility, the mass, as a whole, do whatever is in a given moment convenient or believed to be more pure (license wise). However thanks to that, you will see how little progresses we will have (and we are having) in the space of open source system software with very open licenses. Developers of software mostly are not happy to bring OSS to the success to see them used by hyperscalers to capture all the value. However I did it again, with DwarfStart, to release code under the BSD license: even in the current situation, I think it is better to give back than to have a personal gain, but this is a position that very little folks can afford to take.
However: this conversation is completely out of topic but people instead of talking about AI and code, which is a tabu, will move the conversation to personal attacks and shit like that.
I wish you'd chosen a "non free" fair source or open core license from the start.
Amazon has stolen enormous wealth from you and your collaborators.
People cheer for the hyperscalers even though AWS and GCP are not at all open source themselves, charge absurd margin, and do everything in their power to lock you in.
It's really unfortunate.
Thank you for Redis.
Hopefully AI gives them extra competition. There doesn't seem to be a moat for them yet apart from distribution. Hopefully that holds. The world needs competition and less concentration of power.
In order to really leverage a nonfree (proprietary) or more-free (AGPL/SSPL) license you have to have a substantial thing to protect. If you try to protect something trivial, your competition will just implement it themselves, unless your price is low enough to make that not worth it. Redis is relatively trivial, it is a REmote DIctionary Service. Amazon could have written their own Redis quite easily.
They didn't, because the idea is sufficiently non-obvious, but ideas are protected by patents, not copyright.
Even RMS recommended using LGPL in some cases to maximize overall freedom by not making your competitors copy it. In the case of Redis, GPL probably would've maximised freedom (but not revenue) as Amazon still could've used it and released any changes they made.
Valkey has diverged from Redis, gaining features like vector search and multithreading.
Thanks, I believe that as a whole choosing the BSD created a more positive effect, so I'm happy with that. It is just that it is really unfair to read a comment where people use ValKey to accuse you of AI slop :D It means that our community, and this site itself, is at this point really low quality. This will in turn discourage the many great folks that are here. A replacement is needed. But TLDR, I would release Redis again with the BSD license if I could go back in time.
Do you understand Redis and ValKey have mostly overlapping code bases? And of that intersection, a big part of the code was written by myself by hand. So no, that's not the case. Also as I wrote in the blog post, Redis is currently not using AI if not as AI-assisted coding. Of course I'm not writing this reply for you, since I believe if you write a comment like that, you are part of that HN slice that makes this site at this point a slop place (no need for AI for very low quality), but for others that may find this information useful.
I don't find this argument compelling because you're selectively applying logic.
Okay, so you don't like AWS or Google. Fine. What about the thousands of other hosting companies that use Linux, Apache, Nginx, PHP, Ruby, Python, and Perl for their offerings? Are Yunohost and Dreamhost evil for using Postgres and not open-sourcing their orchestration layer?
The precise reason I build my sites on top of Linux and Apache and Postgres is because I can switch hosts at any time. But what you're advocating for is being completely locked in to the hosting service that is controlled by the company that happened to have authored the database. I would never use a product from a company that had that attitude because I would be completely beholden to them.
I get your frustration that AWS and Google make it hard for database vendors to release their work under a truly open source license. But what you're advocating for would destroy a huge amount of the value of self-hosting and open-source.
This isn't true, I don't think. For example, Instagram was built on Django, but I don't believe the Django founders magically got money because their totally free to use OSS was used in the way it was licenced.
If you don't want people to use your software and make money, then don't release it with a licence that explicitly says you may make money from this software.
There used to be a social contract that you got free code if you behaved nicely with it. Then companies realised social contracts were worthless (not just in open source) and stopped following them and only followed legal contracts.
Amazon and Google are pouring resources into reducing the fitness of the Redis project, pilfering insane revenues, yet not once has either offered to open source their own core platforms.
They're attacking another company that is powerless to defend itself.
And the community cheers it on.
How kind of them to ensure valkey remains "open" so you can continue to purchase it through their hyperscaler product. They'll get their margins through your other usage and they won't pass that along to the Redis project. They'll be keeping that for themselves.
Sucking the oxygen out of the room while they metastasize into every area of the economy they can grow into. Dumping on healthy markets like an invasive species. Then they buy up the shells of once healthy companies, lay off the workers, outsource the labor.
I believe issues will arive with AI in the near future in terms of their performance. Disagreeing with the author, I think code quality pre-AI, in certain languages, were golden. They all contained bugs but they were written in a way that bug sources would be more or less obvious and most but not all top open source software had linting guidelines, code styles & friends to help make it ingestible. Perhaps these helped said project's maintainers a great lot, but it absolutely SAVED AI when it came to training data. These top-quality repositories with thousands of lines of great code combined with hundred thousand lines of mixed quality code was the perfect formula for the big data churner™. Now what? All those repos, inflated with stars are generated by one of the 5 LLMs out there. There has been extended discussions about deterministic behaviour in LLMs, and I'm no ML engineer but to me this drop in entropy will surely cause backtracking in code quality. Of course there a vast array of improvements that can be made outside of training data, but the whole psychology attached to LLM marketing, in my opinion, obstructs those improvements. You could train a better suited way of input for LLMs, set cutoffs and posttraining in just the right places and everything but you gotta think it through. How many of those who ask their favourite LLM everything think anymore? How much of our current knowledge is safe from AI hallucinations or subtle nudges? AI has changed the world of coding, but the current state in Anthropic HQ will determine if it will just be mid-quality codegen or accelerationist fever dream.
I tried really hard to do this, but it turns out the models don't care about your ideas and want to do what's popular in their training data, so they will happily ignore anything you try to force down their throats, especially as context length grows or if you hit compaction.
So to make best use of the models steer them down familiar paths, mention common pattern and frameworks, use popular packages and languages that have the high median quality online.
I started my project with a few simple interface definitions and a short design / architecture doc that I include in the AGENTS.md file, but no matter how hard I try all of the models just end up ignoring it and sprinkled new seeds of variants of the same stuff all over my code base, that with each new session grow new branches.
I do highly unusual, off the beaten path projects with AI.
For instance, a game engine written entirely in LuaJIT, but allocating almost all data structures using CFFI, a very unusual, custom object-orientation DSL I designed myself, and that uses SDL3's SDL_gpu library to do all rendering, a ton of GLSL 4.6 compute shaders cross compiled to SPIR-V and Metal (which constraints what GLSL can be written), and is a hybrid tile-oriented and 3D engine.
Another example is my Emacs-like live-modifiable image-based editor, again in LuaJIT+CFFI, with a kqueue+atomic lock-free ring buffer+pthread based actor model, each running a separate LuaJIT interpreter, with a custom advicing system, event bus, async/await implementation riding on the event bus, a custom process management and IO library, and testing via Tmux.
Even DeepSeek V4 Flash mostly does fine with this, once it's built a few memories in the memory system. Let alone something like DSv4-Pro or GLM 5.2. All I can say is skill issue.
It's not an issue of usual vs unusual, I'm saying the models are way better at writing and maintaining django or react code bases than your own hand rolled architecture that you define in some docs that it has to learn and keep in context. All of the models do an amazing job making local edits and working in small greenfield projects but once you get to full production systems with close to a million lines things start to rot. The code still works and the models are able to make progress but all of a sudden you have 3-4 different versions of your concepts sprinkled in random corners of your code base.
My second point is that the models are way better at things like Rust or Lua than Python or JS, because the average person producing code in those languages has way more programming experience, so the code quality of training data online in those languages is higher than the programming 101 medium blogspam type content you see in more popular intro languages.
I haven't hit nearly a million lines, that's true, these projects are "only" 20k and 45k lines of code or so, respectively; however, I do have directed acyclic graphs of worker agents, managed asynchronously by the agent I chat directly with, do huge architectural refactors (the most recent, was to update everything in the codebase that used the sychronous Lua standard library `io` functions to use the asynchronous, multithreaded IO system I created for the editor — at least, everything that could use the new library, which I kept deliberately simple in a few ways, and everything that wasn't already temporary, but you know) and that's turned out quite well, and at least for me, 45k sloc is nothing to sneeze at, especially since with a green field project there's less examples to keep them on track. I do regularly check in to make sure it's using my design to the fullest, as well.
> All I can say is skill issue.
I don't necessarily disagree with the overall point you're making, but I think calling it a "skill issue" is a bit reductive. These are relatively new tools that are changing quickly, and the amount of flexibility in how you can use them is a lot higher than pretty much anything else we've built up patterns for in the industry in recent years. Rather than dismissing people who express having trouble producing the results you can, I feel like we should be giving lifting others up by providing insights into how we're able to do those things when we know that they're possible. Otherwise, how do we know it's truly a "skill" issue and not a "knowledge" issue, and the only thing stopping them is that no one has helped them understand?
[delayed]
[delayed]
right, the model will listen to you for ~32k context; half of that is just getting them into the "downhill" path for being a coding assistant. You can throw in whatever your heart's desire and if it's a single fix, it might listen to you; but treating it like a smart-IDE basically means it'll follow whatever dominant pattern is in the training data.
If we had smart capitalism (the SAME PROBLEM) we'd realize what we want are per-framework or per-OS models that simply are 80% how to english and 20% the tools we need for a given project.
But that's no where the money is.
> Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I need to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste.
I wonder why he HAS TO ("I need to...") review the code even if he thinks it is pointless? Is that because his employer, Redis, requires it?
Very uncomfortable to read. The proposed idea of not reading the code you ostensibly wrote, doesn’t just challenge the traditional workflow or methodology, it challenges the identity of a programmer itself. For experienced, respected programmers like antirez perhaps reading and writing code truly has just gotten in the way of the ideas, but I cannot identify with that perspective. The devil is in the details, reading other peoples code (and code the LLM writes) evolves the idea itself, and changes my understanding of it. My view on this is so biased by the direct relation of code I read and write to feeding myself and my family (the vast majority of my programming is for a paycheck) that suggestions of removing myself from the process feel grim, not exciting.
For complex code changes or bigger features I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, etc. It's not that you spend less time refining ideas, you just do it at another level of abstraction
But that does come with tradeoffs, and it's not the right thing for every project. But when it does work it does increase the amount of work you get out in the same time
Ideas are a dime a dozen. All of us have half a dozen of what appear to be good ideas every. Execution matters, testing and sanity checking matters, actual engagement with users and iteration matters.
Sure, we're reducing the cost of idea -> prototype to near zero (well, as long as tokens are free or nearly free), but that just means we now have mountains of throw away code, within which there may a gem or two.
Nothing yet has replaced the curating of ideas that good teams do as a matter of course.
I think the gist of what the aurhthor is saying is, AI is not good enough to just give one vague prompt to and let it go, but it's good enough for you to give it a "design" and then not worry about the actual code it writes. But you need to do a lot of QA still. And you still need to learn to code and write some code, I guess so you can give the LLM good instructions? But if giving good enough instructions requires some level of coding skill, how are you going to gain that skill if you don't do much programming or reading code?
It all sorta feels like an old guy (he says hes's old in TFA) who forgot how he got to where he is today trying to give advice. Be careful what you believe, young programmers.
Never comment till you read the whole post, since your question is exactly addressed at the end.
For some background on me to set the context for the following opinion:
- been a SRE/DevOps at banks/hedge funds for almost 20 years
- now work in L1 crypto
- have been coding since I was 12 and have also been using frontier models for the past year (including running multiple agents at the same time etc).
My thoughts:
The models are indeed amazing. They can read large codebases, find bugs, infer the root cause of an issue from partial logs etc etc.
They do still hallucinate. WAY less than they used to but it's still non-zero. In a way that's worse b/c the model will spit out a complex piece of software and say "Yep, no mistakes. I even wrote tests and they all pass!" You might think "Phew, that's great!" but in the same way we've all found bugs in production code written by smart people, there will be bugs here too.
I say this not to imply that you have to read all of the code. I say if only to underline that for big complex systems, the "let's write unit tests for the parts that ABSOLUTELY HAVE TO BE CORRECT" is still just as important as it ever was. I'm thinking of examples like:
- the order and execution handler of a trading system
- avionics flight controls
- healthcare related medical devices
- etc
As an example: I was working on a complex system. I wasn't sure if the LLM code was actually correct so I wrote up a quick script that I checked, line by line, to be 100% sure it was working as I expected. I then used that script to double check the LLM. I didn't read all of the code the LLM created. The sense of "ok, now this works" was astounding.
I'll add, a lot of the developers I work with are going this "hybrid" route too where they will have the LLM write code and tests but then go back in and double check.
In closing, a lot of these big rewrites with LLMs are possible only b/c the devs KNOW, FOR A FACT, that the unit/integration tests are correct. I'm still not convinced that you can have LLMs write all of the code and all of the unit tests and be 100% sure that it's all correct. (I will admit that this has always been difficult and even the pre-LLM days were not a guarantee that all of the code wa s correct)
This position assumes that purely LLM-written codebases are able to scale infinitely.
IMO there isn’t enough evidence for me to feel comfortable in that judgement.
Anecdotally, I find that pretty often LLMs (even bleeding-edge models) write unidiomatic/unscalable/poorly-abstraced code when working in large codebases.
Some of the most exciting engineering work is happening in the DS4 repo - and I'm watching it almost like a sports game.
When the DSpark paper came out[1] the next day we had folks attempting to implement, working together, validating their failures. Eventually their work being synthesized into a PR[1] that admits performance is not ideal. Something antirez alluded to in one of his videos (speculative decoding is a great boon, but mostly for large labs hosting and serving many requests at once, and maybe not so effective for local inference).
There's recent work into "directional steering"[3] that has made it's way into per-session directional steering overrides thanks to audreyt[4].
There's support for the new Hy3[5] model also thanks to audreyt[6].
There's Pre-M5 optimizations[7] in the queue thanks to ivanfioravanti who also helped with some of the initial M5 optimizations.
I haven't watched a repo like this since llama.cpp and whisper.cpp in the early days (though llama.cpp is pretty exciting right now with the SYCL improvements that are flowing in for the new Intel GPUs).
The DS4 repo is a really interesting place to watch folks who heavily code with agents collaborate together in a way that seems pretty effective. I've been really enjoying it.
[1]: https://arxiv.org/abs/2607.05147
[2]: https://github.com/antirez/ds4/pull/502
[3]: https://arxiv.org/html/2406.00045v2
[4]: https://github.com/antirez/ds4/pull/148
[5]: https://hy.tencent.com/research/hy3
[6]: https://github.com/antirez/ds4/pull/523
[7]: https://github.com/antirez/ds4/pull/555
Thanks! And sorry for not yet merging many of those. The problem is, I'm dealing with tensor parallelism for the CUDA and Metal-RDMA fork right now, so was not albe to care about PR / issues for a lot of time.
I am not sure I'm buying this. The raison d'être for our existing software engineering methods is that humans make mistakes and we needed to contain the effects of these mistakes; and without an appropriate methodology to do that, software defects will just accumulate over time. Worse, once they show up, nobody understands the code well enough to do anything about them, or at least not without considerable time investment.
This does not change with agents doing the coding. Coding agents make mistakes also. Not very often nowadays, but neither do competent human programmers. And without a methodology to keep problems in check your agentic code will also accumulate software defects over time and result in code that becomes less and less maintainable, because you have no mental model of the software.
Antirez is correct in pointing out that slop existed before we started to use LLMs for programming; I've worked with my share of really ugly legacy code myself. But the problems do not magically disappear in the LLM age, no matter how good your model is. They remain, as every model is ultimately a heuristic (albeit a very powerful one), and no heuristic is 100% accurate.
This does not mean that coding agents are useless; used correctly, they can be enormously powerful accelerators for the software development (and validation!) process, because combining your strengths with those of a modern LLM is generally a substantial net gain. But that must still happen as a part of an approach that results in maintainable software with minimal defects.
Personally, I primarily use agents as virtual pair programmers these days, which I find very useful. This is an iterative process with relatively small and contained changes, where "looking at the code" is just part and parcel of following along and building a mental model of the resulting piece of software.
There are no "ideas" independent of expression.
What do you mean? Are you arguing that it's impossible to fully translate things? Would you argue that "apple", "manzana", "pomme", "mela", "maçã" etc. all refer to different ideas?
It's kind of ironic reading a post with such bad grammar written by someone that seems to be so pro-AI
I'm against using AI to write text targeting other humans.
I appreciate the human writing, fwiw
I didn't want to say that out loud, but you are right and it's unfortunately hard to understand some of what he's trying to say
Follow the vibes
As a reminder, Redis was widely replaced by its non-vibe-coded fork Valkey.
I think that's a very unfair characterization. The Valkey fork happened due to licensing changes in Redis in early 2024.
Do you have any evidence for Valkey "widely replacing" Redis, instead of just rapidly gaining adoption as well? Additionally, it's important to clarify that the replacement was 100% over licensing issues — iirc predating the vibe coding entirely — not the use of AI to code, and that furthermore, no one has to my knowledge pointed to any flaws in the Redis codebase even correlated with AI use. So this is a disingenuous framing.
100% of the employers I worked for since the time of Valkey had replaced Redis with Valkey.
100% of the employers I worked for (one employee) never did that switch. The license did not affect us; we had nothing to do with AWS and the like, so we just continued using Redis like before. We already had our RPM builds, so whatever course distros took, we did not even care to look.
To be honest until today I thought Kafka was the popular go-to Redis replacement, as almost none of my employers used Redis for its original, intended purpose, namely being an in-memory key-value store. What they really wanted was RabbitMQ.
Kafka does a completely different thing than Redis.
i am currently working on this exact migration at my company. aws also kind of pushes valkey so ppl seem to choose the default.
Sure, it costs less, and AWS is in a dominant position. Users here are playing the side of the bully since they don't care about what is right and wrong with the hyperscalers. "BSD is better than AGPL!" And give money to the wrong side of the history. Nor that I expected anything better, the single person has a given sensibility, the mass, as a whole, do whatever is in a given moment convenient or believed to be more pure (license wise). However thanks to that, you will see how little progresses we will have (and we are having) in the space of open source system software with very open licenses. Developers of software mostly are not happy to bring OSS to the success to see them used by hyperscalers to capture all the value. However I did it again, with DwarfStart, to release code under the BSD license: even in the current situation, I think it is better to give back than to have a personal gain, but this is a position that very little folks can afford to take.
However: this conversation is completely out of topic but people instead of talking about AI and code, which is a tabu, will move the conversation to personal attacks and shit like that.
I wish you'd chosen a "non free" fair source or open core license from the start.
Amazon has stolen enormous wealth from you and your collaborators.
People cheer for the hyperscalers even though AWS and GCP are not at all open source themselves, charge absurd margin, and do everything in their power to lock you in.
It's really unfortunate.
Thank you for Redis.
Hopefully AI gives them extra competition. There doesn't seem to be a moat for them yet apart from distribution. Hopefully that holds. The world needs competition and less concentration of power.
In order to really leverage a nonfree (proprietary) or more-free (AGPL/SSPL) license you have to have a substantial thing to protect. If you try to protect something trivial, your competition will just implement it themselves, unless your price is low enough to make that not worth it. Redis is relatively trivial, it is a REmote DIctionary Service. Amazon could have written their own Redis quite easily.
They didn't, because the idea is sufficiently non-obvious, but ideas are protected by patents, not copyright.
Even RMS recommended using LGPL in some cases to maximize overall freedom by not making your competitors copy it. In the case of Redis, GPL probably would've maximised freedom (but not revenue) as Amazon still could've used it and released any changes they made.
Valkey has diverged from Redis, gaining features like vector search and multithreading.
Thanks, I believe that as a whole choosing the BSD created a more positive effect, so I'm happy with that. It is just that it is really unfair to read a comment where people use ValKey to accuse you of AI slop :D It means that our community, and this site itself, is at this point really low quality. This will in turn discourage the many great folks that are here. A replacement is needed. But TLDR, I would release Redis again with the BSD license if I could go back in time.
Do you understand Redis and ValKey have mostly overlapping code bases? And of that intersection, a big part of the code was written by myself by hand. So no, that's not the case. Also as I wrote in the blog post, Redis is currently not using AI if not as AI-assisted coding. Of course I'm not writing this reply for you, since I believe if you write a comment like that, you are part of that HN slice that makes this site at this point a slop place (no need for AI for very low quality), but for others that may find this information useful.
As a reminder, Amazon and Google pillaged the Redis project and took all the profits of themselves.
OSI purity is hyperscaler brainwashing. They don't want to pay you. They want to take your labor.
Amazon and Google have made billions of dollars off of Redis while the original authors and the company formed around it have gotten none of that.
The best licenses for new database projects are fair source and open core.
Tell the hyperscalers, "fuck you, pay me".
Fuck valkey. Fuck Amazon. Fuck Google.
They're fucking thieves. And they'll lay you off the second they get the chance.
I don't find this argument compelling because you're selectively applying logic.
Okay, so you don't like AWS or Google. Fine. What about the thousands of other hosting companies that use Linux, Apache, Nginx, PHP, Ruby, Python, and Perl for their offerings? Are Yunohost and Dreamhost evil for using Postgres and not open-sourcing their orchestration layer?
The precise reason I build my sites on top of Linux and Apache and Postgres is because I can switch hosts at any time. But what you're advocating for is being completely locked in to the hosting service that is controlled by the company that happened to have authored the database. I would never use a product from a company that had that attitude because I would be completely beholden to them.
I get your frustration that AWS and Google make it hard for database vendors to release their work under a truly open source license. But what you're advocating for would destroy a huge amount of the value of self-hosting and open-source.
This isn't true, I don't think. For example, Instagram was built on Django, but I don't believe the Django founders magically got money because their totally free to use OSS was used in the way it was licenced.
If you don't want people to use your software and make money, then don't release it with a licence that explicitly says you may make money from this software.
What was stolen?
There used to be a social contract that you got free code if you behaved nicely with it. Then companies realised social contracts were worthless (not just in open source) and stopped following them and only followed legal contracts.
> took all the profits of themselves.
some of those profits are passed on to users too. valkey on aws is cheaper for customers too.
> some of those profits are passed on to users too. valkey on aws is cheaper for customers too.
You must be joking.
Until the whole of AWS and GCP are open source, they're taking absurd margins on your business and locking you in.
not sure i follow, thats the whole cloud hosting model. yeah you can self host to avoid that but thats a whole another tangent.
If you are already locked in then whats the benfit of choosing redis from a pointy haired boss prespective.
Amazon and Google are pouring resources into reducing the fitness of the Redis project, pilfering insane revenues, yet not once has either offered to open source their own core platforms.
They're attacking another company that is powerless to defend itself.
And the community cheers it on.
How kind of them to ensure valkey remains "open" so you can continue to purchase it through their hyperscaler product. They'll get their margins through your other usage and they won't pass that along to the Redis project. They'll be keeping that for themselves.
Sucking the oxygen out of the room while they metastasize into every area of the economy they can grow into. Dumping on healthy markets like an invasive species. Then they buy up the shells of once healthy companies, lay off the workers, outsource the labor.
They're doing exactly the same thing to Valkey that they're doing to Redis, it's just more legal. Somehow Valkey is more successful because of it.