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?
In my experience, because as you say, the flexibility of these tools and how you engage with them is so broad, and how much the nuances of thay engagement can often matter, the only way to teach someone how to do what you do with them is to sit down and pair a program with them. Barring that, any instructions you could give would massively under-determined what they actually try as a result of your instructions, and so it ends up being an infinite loop of them just coming back and saying "it doesn't work." So in the end, people really just have to discover how these things work for themselves.
It is easier to get an LLM to tell an unusual story using the most popular phrases than have it tell a common story using off-kilter uncommon phrases.
The big arc is easy to get using an LLM, getting it to do the details correctly, that is the actual hard part. So in my cases I (by other people's account a legendarily patient person) lost my cool trying to get a LLM to write CSS in a way that makes any sense if you have a design background. I ended up rewriting the whole CSS by hand, because it is inconsistent, piecemeal and just doesn't make sense. Yeah let's make everything bold and important. Yeah let's write internal implementation details into a label in the UI.
I decided to use LLMs as an aid to my own thinking, not as a replacement.
I know nothing about you or your code, but till you make your code + workflows public and have all of it reviewed / critiqued (so that other can replicate the performance), it's hard to accept it as a serious case study.
For all we know, this could just as well be a severe case of Dunning-Kruger.
Not specifically about the comment you replied to, but there has been an absolute Cambrian explosion of plausible sounding projects that use really complicated words that are just AI psychosis. Recently there was someone who posted a huge Lean proof on GitHub supposedly of proving P=NP. The problem is AI is really good at deluding people if that person doesn't have domain specific knowledge. AI severely makes dunning Kruger worse
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.
yeah I tried rules, hooks and forbidding things like pip / python3 but it just led to the model failing to do what it wants and a bunch of token churn trying to get around my more rigid constraints.
main problem is that the harness files get loaded into context early in the session and slowly wash away as new information comes in.
I strongly agree with antirez. I believe that an intellectually honest programmer should recognize where their knowledge and experience is mostly beneficial, and at this point (and we've seen clear signs for some time) coding is largely solved. But software engineering is not just coding, and it involves a whole set of other tasks requiring direction and creativity that can greatly influence the quality and impact of the software.
The most common arguments against this view seem to arise either from ideological resistance, which I understand given how painful it can be to see one’s job at risk or an important part of one’s identity taken away, or from generalizing a small number of experiences with LLMs to the technology as a whole. In the latter case, those experiences may also be heavily conditioned by the user’s inexperience in working with LLMs, or by the specific use case in which they were applied. There are still certain tasks that not all models can handle reliably as of now, however some can (usually the most expensive), and they will likely continue to improve over 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.
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.
I'm fully on the agentic coding train and haven't manually typed code in a while so I understand the sentiment around moving beyond this level of analysis. However, how can this advice work practically speaking, day to day? Especially at ones day job?
I'm sitting here working and just caught a handful or really bad decisions by the agent, one right after the other, cascading from an assumption that was incorrect. My ideas and architecture are sound in this codebase! Are those things simply to remain in the code if they work 'good enough', or are there consequences right around the corner?
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
>For complex code changes or bigger features I often spend hours with an LLM refining architecture
The problem here is that the LLM hallucinates, so
* it will tell that something is a bad idea, even when it is not.
* it will miss good ideas.
But here is the thing. Even discussing with a rubber duck can do wonders to your thought process. So may people who are noticing the usefulness of this procedure might be actually just doing a slightly better rubber ducking...
> I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions,
Is that something recent? I’ve been doing this for years, even in high school where we were asked essays on contrast between different viewpoints.
I don’t need LLM to do this. It’s the 101 of any engineering process to not rush with the first thought you have and indeed try to explicitly explore the solution space and base your decisions according to defined tradeoffs.
I'm letting go of reading every single line, especially within well-scoped modules that don't affect anything else. On the other hand I struggle to form the mental model required to "control the ideas", as it were, without reading at least some critical sections of the code and without grasping how the fundamental data structures relate to each other.
Are we saying that opening the editor is basically a mistake?
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)
>if you control the ideas of your software, looking at the code itself is suboptimal and often pointless.
This requires developers to have absolute and unconditional Trust in the LLM. It's not easy to trust it completely to the point of completely ignoring the implementation details of the code.
In one of Salvatore's discussions, he mentioned that he hasn't even opened a single file of DS4. This is a courageous choice.
But the real question is: if the younger generation stops writing code, how are they supposed to develop that "forma mentis" (mindset) that allows them to reason about design and architecture? It's only by *writing* the code that you gradually internalize development and design patterns, specifically by clashing with the "brutality" of bugs and solving implementation problems.
P.S. I read Wohpe. It's fascinating how back in 2022 (I think?) Salvatore already wrote down many insights that have actually come true (including, for instance, the ban on "strong artificial intelligence"...).
So I suppose that the future will touch the very development of humanity (like the Genesi project :) )
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.
The ability to use steering vectors seems really powerful. I know you can build your own, but are there any collections of prebuilt steering vectors? Or even just mentions of what kinds of steering vectors people are building for their own use?
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 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 agree that in the end the most important thing is to have the correct mental model of the code, and there is no need to know every implementation detail if you can ensure with other means that they address your requirements. An issue I can can see with not reviewing the code (especially code someone else wrote) is how do you create the mental model? Can a design.md file replace the process of slowly understanding the data flow by reading?
Code is not literature. It's not poetry. It does not express the human spirit. Code is a machine made of symbols. Engineers do care about the beauty of their machine designs, but in the end what matters is whether the machine performs its function correctly, efficiently, affordably. What's wonderful about software is that the function of software is to take input data and produce output data. Every aspect of it is measurable, if we build it to be measurable, because it's data all the way down. The future of software development is not reading code. It's specifying an outcome, success and failure conditions, and iterating until that outcome is reached. Throw out your software engineering "code quality" manuals, your SOLID and your Clean Code. It doesn't matter now.
This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages
You build your outcome conditions and specifications in code as well. And you iterate on them too. I'm not talking about waterfall development. It's something else. You can spend a day just prototyping, spiking, experimenting, and then use that to refine what the outcome can be, doing more work that way than you could in a week before. I think it's crazy to think that software development processes aren't going to change.
> 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?
Because Redis is not "my project", it is a piece of software many relies upon, so I use, for that software, what the community at large agrees to be ok: AI-assisted coding with human careful reading and evaluation of every line.
One thing I've been thinking about is what a new SDLC ought to look like in the age of agentic engineering, since the "old" workflows are likely suboptimal (e.g. PR reviews). Have you given it some thought?
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.
I think the gist of what the author 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 he'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.
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?
Granny Smith, Honeycrisp, Red Delicious? All apples, wildly different, all common. Even within the more commercially available variants there are significant differences: https://www.jessicagavin.com/types-of-apples/
I agree that not having to read the code is the future but I struggle to get there because the AI, like humans, can make mistakes (not follow instructions). For example, I might ask the AI to render a scene using a physical model, and we might come to an agreement at the plan stage, but then it will go off and cut some corner in implementation. So the question is how to reliably verify compliance. If you merely tell another AI to check it properly implemented the plan it too can miss bugs, so you need to put all your effort in making the acceptance tests foolproof, and this is easier said than done. You need a defense in depth approach, using the type system, unit tests, formal verification (if you can), linting, etc. It is an open question how to optimally allocate your correctness efforts for a given budget but, as models get smarter, it is clear to see that the amount of human diligence needed to achieve likely correctness for a given task (say, in LOC) is going to tend to zero (https://metr.org/time-horizons/)
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 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?
In my experience, because as you say, the flexibility of these tools and how you engage with them is so broad, and how much the nuances of thay engagement can often matter, the only way to teach someone how to do what you do with them is to sit down and pair a program with them. Barring that, any instructions you could give would massively under-determined what they actually try as a result of your instructions, and so it ends up being an infinite loop of them just coming back and saying "it doesn't work." So in the end, people really just have to discover how these things work for themselves.
It is easier to get an LLM to tell an unusual story using the most popular phrases than have it tell a common story using off-kilter uncommon phrases.
The big arc is easy to get using an LLM, getting it to do the details correctly, that is the actual hard part. So in my cases I (by other people's account a legendarily patient person) lost my cool trying to get a LLM to write CSS in a way that makes any sense if you have a design background. I ended up rewriting the whole CSS by hand, because it is inconsistent, piecemeal and just doesn't make sense. Yeah let's make everything bold and important. Yeah let's write internal implementation details into a label in the UI.
I decided to use LLMs as an aid to my own thinking, not as a replacement.
> All I can say is skill issue
I know nothing about you or your code, but till you make your code + workflows public and have all of it reviewed / critiqued (so that other can replicate the performance), it's hard to accept it as a serious case study.
For all we know, this could just as well be a severe case of Dunning-Kruger.
Not specifically about the comment you replied to, but there has been an absolute Cambrian explosion of plausible sounding projects that use really complicated words that are just AI psychosis. Recently there was someone who posted a huge Lean proof on GitHub supposedly of proving P=NP. The problem is AI is really good at deluding people if that person doesn't have domain specific knowledge. AI severely makes dunning Kruger worse
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.
yeah I tried rules, hooks and forbidding things like pip / python3 but it just led to the model failing to do what it wants and a bunch of token churn trying to get around my more rigid constraints.
main problem is that the harness files get loaded into context early in the session and slowly wash away as new information comes in.
I strongly agree with antirez. I believe that an intellectually honest programmer should recognize where their knowledge and experience is mostly beneficial, and at this point (and we've seen clear signs for some time) coding is largely solved. But software engineering is not just coding, and it involves a whole set of other tasks requiring direction and creativity that can greatly influence the quality and impact of the software.
The most common arguments against this view seem to arise either from ideological resistance, which I understand given how painful it can be to see one’s job at risk or an important part of one’s identity taken away, or from generalizing a small number of experiences with LLMs to the technology as a whole. In the latter case, those experiences may also be heavily conditioned by the user’s inexperience in working with LLMs, or by the specific use case in which they were applied. There are still certain tasks that not all models can handle reliably as of now, however some can (usually the most expensive), and they will likely continue to improve over 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.
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.
I'm fully on the agentic coding train and haven't manually typed code in a while so I understand the sentiment around moving beyond this level of analysis. However, how can this advice work practically speaking, day to day? Especially at ones day job?
I'm sitting here working and just caught a handful or really bad decisions by the agent, one right after the other, cascading from an assumption that was incorrect. My ideas and architecture are sound in this codebase! Are those things simply to remain in the code if they work 'good enough', or are there consequences right around the corner?
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
[delayed]
>For complex code changes or bigger features I often spend hours with an LLM refining architecture
The problem here is that the LLM hallucinates, so
* it will tell that something is a bad idea, even when it is not. * it will miss good ideas.
But here is the thing. Even discussing with a rubber duck can do wonders to your thought process. So may people who are noticing the usefulness of this procedure might be actually just doing a slightly better rubber ducking...
> I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions,
Is that something recent? I’ve been doing this for years, even in high school where we were asked essays on contrast between different viewpoints.
I don’t need LLM to do this. It’s the 101 of any engineering process to not rush with the first thought you have and indeed try to explicitly explore the solution space and base your decisions according to defined tradeoffs.
I'll admit I have a bit of a skill issue here.
I'm letting go of reading every single line, especially within well-scoped modules that don't affect anything else. On the other hand I struggle to form the mental model required to "control the ideas", as it were, without reading at least some critical sections of the code and without grasping how the fundamental data structures relate to each other.
Are we saying that opening the editor is basically a mistake?
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)
>if you control the ideas of your software, looking at the code itself is suboptimal and often pointless.
This requires developers to have absolute and unconditional Trust in the LLM. It's not easy to trust it completely to the point of completely ignoring the implementation details of the code.
In one of Salvatore's discussions, he mentioned that he hasn't even opened a single file of DS4. This is a courageous choice.
But the real question is: if the younger generation stops writing code, how are they supposed to develop that "forma mentis" (mindset) that allows them to reason about design and architecture? It's only by *writing* the code that you gradually internalize development and design patterns, specifically by clashing with the "brutality" of bugs and solving implementation problems.
P.S. I read Wohpe. It's fascinating how back in 2022 (I think?) Salvatore already wrote down many insights that have actually come true (including, for instance, the ban on "strong artificial intelligence"...). So I suppose that the future will touch the very development of humanity (like the Genesi project :) )
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
The ability to use steering vectors seems really powerful. I know you can build your own, but are there any collections of prebuilt steering vectors? Or even just mentions of what kinds of steering vectors people are building for their own use?
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 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 agree that in the end the most important thing is to have the correct mental model of the code, and there is no need to know every implementation detail if you can ensure with other means that they address your requirements. An issue I can can see with not reviewing the code (especially code someone else wrote) is how do you create the mental model? Can a design.md file replace the process of slowly understanding the data flow by reading?
Code is not literature. It's not poetry. It does not express the human spirit. Code is a machine made of symbols. Engineers do care about the beauty of their machine designs, but in the end what matters is whether the machine performs its function correctly, efficiently, affordably. What's wonderful about software is that the function of software is to take input data and produce output data. Every aspect of it is measurable, if we build it to be measurable, because it's data all the way down. The future of software development is not reading code. It's specifying an outcome, success and failure conditions, and iterating until that outcome is reached. Throw out your software engineering "code quality" manuals, your SOLID and your Clean Code. It doesn't matter now.
This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages
You build your outcome conditions and specifications in code as well. And you iterate on them too. I'm not talking about waterfall development. It's something else. You can spend a day just prototyping, spiking, experimenting, and then use that to refine what the outcome can be, doing more work that way than you could in a week before. I think it's crazy to think that software development processes aren't going to change.
> 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?
Because Redis is not "my project", it is a piece of software many relies upon, so I use, for that software, what the community at large agrees to be ok: AI-assisted coding with human careful reading and evaluation of every line.
One thing I've been thinking about is what a new SDLC ought to look like in the age of agentic engineering, since the "old" workflows are likely suboptimal (e.g. PR reviews). Have you given it some thought?
He is the creator of redis.
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.
I think the gist of what the author 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 he'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.
The end is where you said people should still learn to program, I wouldn't know that you said that without reading to the end.
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?
"Apple" is a generic name, that does not actually really express anything particularly specific.
Eating apple, cooking apple, cider apple, pig feed?
Granny Smith, Honeycrisp, Red Delicious? All apples, wildly different, all common. Even within the more commercially available variants there are significant differences: https://www.jessicagavin.com/types-of-apples/
Heck, just for cooking apples there are huge number of different varieties: https://en.wikipedia.org/wiki/Cooking_apple
Yea, "apple" as an idea doesn't really express anything concrete without lots more context.
And without more context, Apple may even mean something that isn't even a fruit, but still popular: www.apple.com
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
You realize he's not a native English speaker, right? His English grammar is better than my Italian, so I don't feel the need to criticize.
Follow the vibes
I agree that not having to read the code is the future but I struggle to get there because the AI, like humans, can make mistakes (not follow instructions). For example, I might ask the AI to render a scene using a physical model, and we might come to an agreement at the plan stage, but then it will go off and cut some corner in implementation. So the question is how to reliably verify compliance. If you merely tell another AI to check it properly implemented the plan it too can miss bugs, so you need to put all your effort in making the acceptance tests foolproof, and this is easier said than done. You need a defense in depth approach, using the type system, unit tests, formal verification (if you can), linting, etc. It is an open question how to optimally allocate your correctness efforts for a given budget but, as models get smarter, it is clear to see that the amount of human diligence needed to achieve likely correctness for a given task (say, in LOC) is going to tend to zero (https://metr.org/time-horizons/)
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.
Indeed. Doesn't change the fact that people have been using Redis where they could well have used Kafka.
Hell, I did that in a previous project.
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.