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.
Did you actually manually review the 600k lines of code?
And the reason LLMs tend to produce such insanely large codebases is partially what the comment you're replying to explained, they duplicate everything all over the place.
The codebase is large because its a complex problem and its around 75% tests. Have used various tools to find duplicates and they arent there to any significant extent.
"You are violating the DRY principle with code like <blahblah>. Look through the codebase in depth, and identify possible places to consolidate common logic."
Yeah, there's no substitute for taste, but this is not that big of a deal. I infinitely prefer repeated code to crappy, leaky abstractions. Let the model generate some slop, then tighten it up either by hand or with more prompting.
I just finished an LLM assisted Rust rewrite of a production project after a couple months. It's around 150k LOC, mostly Rust, excluding generated code and tests. Around 200k if I include tests. I'm also now starting to extract / refactor some of it's code into their own reusable crates, so my LOC isn't going to grow and might even shrink a bit. I can't speak to 1M LOC, but I'd imagine that takes a lot of human context to reason about too, and you probably want to break it up into manageable chunks if possible.
LLMs have been a boon. I have a lot of guardrails in place though to keep the LLMs focused and producing correct and ergonomic code. A lot of effort and review has gone into creating these guardrails (choice of language, linting, forced conventions, tests, etc.). A lot of these practices will be useful in future projects. I highly recommend this approach. Don't just copy skills or processes that others publish. Figure it out yourself so the lessons stick. Human in the loop, especially one that has learned through practice and failure, is still immensely valuable IMO. It's a fine line between getting stuff done and yakshaving over your tooling... but that's always been the case, as proven by my vim dotfiles. :)
It's worth noting that the AI industry is filled with tons of snakeoil and BS. You don't need to take someone's course in "21 steps to be productive with AI" or w/e. Just like learning a new programming language, dig right in and try to build something that scratches an itch. Pick a project you have complete autonomy over instead of that "spend all the tokens" crap managers were pushing until recently (this has corrected now right?).
Parent saying "Skill issue" though... What a jackarse.
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.
That's a completely reasonable take. I wouldn't have any issue with a nuanced comment like that. My issue with your above comment is that it's a lot more arrogant than nuanced.
That's fair, I think my point is there's a nuanced theory behind my choice to be rude, which is essentially "you need to experiment more, be more open minded, really work at it, and then you'll see what others are seeing, it isn't impossible." It's like Dark Souls, nobody can beat it for you, or teach you how to use dodge rolls, you've gotta build that skill yourself, and blaming the tools won't help.
I think your attitude is pretty lazy. It's a low-effort answer to say "skill issue" and then walk away feeling superior. Much harder to lean in to the other person, understand them, then help guide them onto the path. When you do this, you cause them to accelerate tremendously.
IMHO as you get more senior in software, after a while the only interesting metric becomes: are you raising the level of the people around you?
EDIT: looking at your Github seems like you are still in university. So I'll say "age and experience issue" on your end ;)
> IMHO as you get more senior in software, after a while the only interesting metric becomes: are you raising the level of the people around you?
Strongly agree, especially given how helping your teammates scales geometrically rather than linearly like improving your own output. If you work on a team team of five people with roughly equal output, and each becomes 20% more productive because of improvements you make, your team's output is increased the same as if you doubled your own productivity without helping anyone else on your team. (The math doesn't work out the same if your teammates aren't as productive as you already, but that's just an another argument for why it's better in the long run to be someone who can enable those around them rather than someone who only helps themself; helping everyone else has compounding returns if you keep doing it!)
I personally just also find it more fulfilling to be someone who makes everyone else around me better rather than just trying to be better than anyone else, but I recognize that not everyone will be motivated by that, so sometimes framing it in terms of raw output can help. The other potentially strong argument for those who are a bit more motivated by their own experiences only is that it's usually a lot more fun to have smart productive coworkers than ones who make you scoff and say "skill issue" to!
> That's fair, I think my point is there's a nuanced theory behind my choice to be rude, which is essentially "you need to experiment more, be more open minded, really work at it, and then you'll see what others are seeing, it isn't impossible."
Why not just say that then, instead of being rude? I pretty firmly disagree with the idea that being rude is ever a useful way to convey information rather than intent. Content and tone are separate axes that you can calibrate independently, so what you're saying is never an excuse for how you say it. Being rude conveys emotion, not information, and you didn't really convey information in your comment other than "look at how amazing the stuff I do is", and that's not a particularly effective mechanism for getting people to see your point of view.
I agree with you and I didn't think your comment was rude. Some people are against using LLMs and they will always find an excuse instead of experimenting with them so it doesn't matter how helpful you try to be they already made their mind.
> Some people are against using LLMs and they will always find an excuse instead of experimenting with them so it doesn't matter how helpful you try to be they already made their mind.
Do you think that I'm "against LLMs" and "finding an excuse instead of experimenting" because I disagree with you and the parent comment? If so, you should consider whether your perceptions are accurate, because I use them extensively.
More generally, if you aren't interested in engaging with the people who disagree with you, and you think that enough of them are arguing in bad faith and will never change their mind that their presence should determine the tone of your comments, why bother engaging in the discussion at all then?
I think "skill issue" is often deployed (including here) as a shortcut for what you said - "the only thing stopping them is that no one has helped them understand".
(I try not to say "skill issue" myself because it comes across as rude.)
I regularly see claims by people that they have produced large, reliable bodies of code using vibe coding. Unfortunately, no vibe coded project I've used comes anywhere close to code reviewed by a human. Admittedly, my sample size is very small: things like claude-code, OpenClaw, and the occasional project I see mentioned here. But compared to the things I used regularly like GNU coreutils, Firefox, Linux, vim, git and the hundreds of other software projects I use daily, vibe coded apps are in a different ballpark. Vibe coded apps of a few 100k lines often glitch several times a day, the traditional ones that have several orders of magnitude more lines often don't fail in several years of use.
AI is now being used to assist in creating and maintaining these traditional bodies of software, of course. It looks like it has enhanced productivity as open source contributions have grown by 20% or so, and we've only just started to learn how to use it. I haven't noticed any degradation in quality. It may be too early to tell, but I suspect the engineers involved wouldn't let that happen.
As you say, it's a skill issue - it takes considerable skill to produce reliable maintainable code. But I suspect that wasn't the skill you are referring to.
Maybe the key difference is that you are so far off the beaten path that there simply are no examples of what you are doing that the models "want" to emulate?
I've also had reasonable success with the models generating fairly idiomatic Objective-Smalltalk, my own language of which there are likely few to no examples in the training data.
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.
Check out the /docs dir in the repos for each plan file and the language specs.
They are my 4th and 5th DSLs and I learned quite a bit along the way, most importantly how to separate a WASM runtime wired up to a Monaco editor “lsp” with the same crate for editor-services that works with the actual system binary LSP.
Feel free to peruse the repos! I follow compression-oriented programming, so there are places where the code is "insufficiently" DRY intentionally, as I feel out the precise use cases, and I explicitly made some other decisions (like a God editor object) for meta design reasons (I want it to be easy to modify the editor state from anywhere, just like in Emacs), so all I ask is that you review these without being excessively punative to prove your point.
I've found this to be more consistently the case than not. People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function. They put together a keyword soup post that sounds good on an AI generated resume but falls apart upon investigation.
> People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function
It's funny because you chose to target the one who is pro-AI, who has since posted their code, and not the GP who is against AI, who also didn't post any code to support his opinion that "it turns out the models don't care about your ideas and want to do what's popular in their training data".
Its hard not to feel insulted here. "Projects using AI like this don't exist, and if they do, they're broken and the people who made them have psychosis." However, although I haven't tested my projects cross machine, or cross platform yet (my editor only works on MacOS because it uses kqueue), I would be happy to take an unedited video demonstration of both, I assure you they both run.
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
things you described are not "highly unusual" in the way gp comment is describing. you are just remixing bunch of stuff. Thats the type of thing ai is really good at.
The GP was just talking about not using common languages like TypeScript and frameworks like React, which is a bar of unusual that seems arguably far lower than mine, especially since I literally defined special custom DSLs with unusual semantics, and used libraries like SDL_gpu with little to no pre-existing training data. So this seems like shifting the goalposts.
"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"
The key is to remove degrees of freedom from the agent. IMHO this is the really hard work of agentic engineering. You need to strongly constrain what the agent can even do in the first place to force it into a certain area.
That runs the danger of putting the model out of distribution, of course, so it takes some experimenting.
I'm working on a Ruby project where - on purpose - I'm disallowing any frameworks other than what's standard Ruby. So no Rails or Sinatra, just the inbuilt Webrick web server. Initially it was hard to keep the model on the rails but as I've learned more it gets easier. That said, it's clear to me that the model pulls very strongly in familiar directions in terms of how it writes code, i.e. a lot of what gets written still ends up looking "Railsy" even though my learning project doesn't use it.
It makes everyone more average and same-y. It’s a good average, better than bad, but I cringe everytime I see someone claiming it’s a force multiplier for their personal expression. Bullshit.
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've been playing around with https://github.com/bytedance/deer-flow and they seem to figure out how to get around context sizing issues and has a more automated prompt system.
Essentially the problem with current hanrsses is they just can't find/evict context and want to ensure KV cache isn't evicted.
If they evict the old prompt and tried to keep all the proper rules, then you get token churn anyway, as what you want is an entirely new chain of events where your rules/guidance sit at the front of the model chain.
What we're getting to is there really isn't an economical way for cloud models to do it; you can do it with a local model, but at comfortable speeds, you need smaller sized.
I think a good harness via Qwen3.6-35B-A3B is possible, as the token gen is only 3B since that's the active parameters.
So it's mostly that to keep rules pinned to the top of the context will either bloat the model or it'll evict the KV cache.
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 of 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?
I have found including this in my AGENTS.md to be quite transformative in this regard:
> Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. For this, you must create stubs of the expected modules and exports in the red phase, so that the test cases actually run and fail on the test case assertions themselves. In some cases, when using this approach, once in a while some of the red phase test cases might "incidentally" pass, and this is ok. Before running red phase tests you should always make predictions about the number of test cases you expect to fail/pass -- this count is not the number of test files or test suites, but rather the number of test cases. By performing these red phase expected counts of passing/failing test cases, it will help you catch errors in your prior reasoning quickly and efficiently.
> Always use a proof-driven, scientific method-based approach to validate hypotheses, assumptions, and conclusions: define the smallest falsifiable hypothesis, create or identify a reproducible failing case, gather direct evidence, make the smallest targeted change, and then re-run the same proof to confirm the issue is fixed. Avoid speculative fixes, broad rewrites, or changing multiple variables at once. When possible, preserve the reproduction as a regression test before implementing the fix. Consider that when gathering evidence, additional logging and durable files can be very helpful.
> The strict TDD and proof-driven approaches described above could be described as "proof-driven development". Try to internalize and generalize these concepts, as they are broadly applicable.
> It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run.
Is this for llm purposes? In many forms of TDD a compile error is key to the red phase. And you are going from red to green before asserts even exist is part of the process.
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...
The LLM will often miss the most obvious simplifications. And if I ask it to present me with six approaches how we could solve a problem, chances are we will settle on number seven or eight, both my ideas after rejecting all the other six. But those first six were still valuable for coming up with the version we actually settle on. Making the rubber-duck talk is genuinely useful.
And the rubber duck is actually pretty good at the localized grunt work, so you can spend more time talking with it about big-picture stuff
But the CPU is not executing the textual description of your architecture. It executes code.
Honestly, I've found that the architecture described to and by LLMs is always a more rosy picture than what is actually generated, no matter how many times you do an adversarial review. It's less visceral than in image generation, but the pattern is the same -- the broad strokes seem fine but the details are awful.
> 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.
How much of the source code of the compiler you use did you read? How much of the source code of the standard library of your chosen language did you read? What about the dependencies?
How much of the source code of a huge codebase does the average developer read? I don't think any human alive has read the majority of code in huge codebases like Word, Windows, Linux, etc.
For almost every developer, the majority of the code you use every day, whether in software you use or actual code you're shipping, is not code you've ever read. And no one seems to have a problem with it, because we've built lots of processes around this. It's only when the code is written by an AI and not a coworker or random library author that people seem to have a problem.
And I get it! AI wasn't very good at writing code two years ago. Maybe even a year ago. I think it's good now, but maybe you don't - ok, that's fine, maybe it'll only live up to your standards in a year or two or ten. But that doesn't seem to be what people are arguing, it's not "AI isn't good enough", it's "how can we possibly ship code we never read", and my point is that we've all been doing this for our entire careers.
The code we've shipped throughout our careers certainly wasn't reviewed only by us. It was reviewed by programmers with more expertise in the relevant area. That's a healthy and efficient division of labor, expertise, and responsibility.
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.
> 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.
This doesn't strike me as wrong, but where the rubber meets the road. Let me give you an example.
My superior with close to zero programming skills, sat down with Claude and "wrote" a Django backend with SPA React frontend that enables user directory sync from one source to another and then exposes an API for other services to consume. It supports RBAC, 2FA, extensions for directory sources, dashboard with stats and what not. Everything packed into docker containers ready to deploy on the cloud. Again, the person is very skilled as a consultant, but lacks programming skills whatsoever. I did a code review, prepped a list of things to fix and he did fix them with Claude again. Later on, he used Claude to rewrite the Python backend to Go. I did no code review on that part. Fable was used in several iterations to test for security issues before each release.
Long story short, this service is now running in the cloud and the customer uses it to solve their problem. We got a couple of other customers on the line as well.
> Fable was used in several iterations to test for security issues before each release.
How? The point of Fable (vs. Mythos) is that it has extreme guardrails against doing e. g. security work, even mentioning "security" or "vulnerability" in the prompt will shut it down.
That if you polish it a bit, you can probably write a short story. /s
The thing is, making claims like that doesn’t prove anything. You have to either show the result or prove that is reproducible. Otherwise, it may as well be something you dream up this morning.
Execution is not the code, but how do you decide to do every part. "Idea does not matter, execution does" always meant: "big generic ideas don't matter, it is how you organize it in the myriad of details it is composed of (in a given incarnation of the general idea) that matters."
But why aren't lower level "ideas about execution" more clearly expressed in code? Or at least pseudocode?
Many of us would struggle with our reading comprehension of an English description of an algorithm. But the pseudo / actual code? Much easier to reason about.
I'm not saying you should review even 90% of code. But it feels like an arbitrary line to say "never look at code". It's like never taking a wrench to a car to look at what's built to see whether you trust the car factory.
I think "idea" is getting overloaded here. The article isn't talking about new feature/product/tool ideas, but about what concepts to use to build those features. e.g. what data structures and algorithms to use.
So your last line agrees with the article, I think. They are saying that it's still important to curate ideas, and no longer important to read the code; the time you would have spent reading the code should be spent curating ideas.
Curating ideas requires experience and taste. Can you really develop that without looking at code? Compare Steve Jobs vs Joni Ive curating as a prime example of how taste without practical experience and context can lead things astray. And the worst of it is that it can take a while for the problem to be easily noticeable.
I highly respect Antirez, and as an Italian fellow programmer, for me, he's like a legend!
Although reading this article makes me quite sad; I consider myself an average, mediocre programmer, but I enjoy writing code since it's a way to build the mental model of a problem and to solve it iteratively.
I obviously use agents and all the new fancy tools, but if a great programmer like Antirez says that it's over, I think I'm not so faithful about my future as an engineer.
All AI stocks are plummeting right now. Go your own way and don't listen to tech predictions, no matter how much you revere a person. Often they are all wrong.
>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 :) )
We're all project-managers now. The trust required of the LLM is no different than that that required when a PM trusts a dev-team to implement correctly. As a PM, you need to understand testability and write that into the requirements.
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)
You can have almost 100% tests coverage and green tests and still have a plane crash and LLMs shilling with you that everything is ok. To me it seems we havent learned yet tests coverage means nothing without solid code
The people who I see who are "getting along just fine" in this current mess are either True Believer™ types, or are semi or fully retired and don't need to care particularly strongly which way any of this goes from an employment perspective (meaning: I know people in this group who refuse to use LLMs and people who have attitudes like the author of this article, with similar levels of experience).
I think on one level you can look at these folks and say "well, they may be able to see more clearly because they aren't so wrapped up in it all" but I've done a lot of self-reflection and I simply don't think this is true.
Never thought I'd find myself questioning Antirez, but I have many questions about this post and overall attitude. For example:
> 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.
Why is the attitude here about keeping the floor up rather than raising the bar?
Why can't we have better code with AIs? Its not impossible to do!
When I implement things by basically pairing with the AI, I end up with better designs/architectures/code than I could have written by myself.
It sounds like some people think of the AI code paradigm as one where there will be fewer but better devs producing code/designs of lower quality than they could individually produce, but that is higher quality than the average dev could produce.
Is that really better than a world where AI raises the average across the board at the expense of a bit of speed? At the very least, it seems like a far less risky and less disruptive way to still capture significant benefits from AI.
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.
> 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
This is somewhat of a nitpicking point, but AIUI speculative decoding is worthwhile if (1) you have viable unexploited parallelism that can speed up the "verify" step compared to plain decode, and (2) it's profitable for you to load complete model layers into memory in bulk, not just a tiny fraction of active parameters. (2) tends to be true for large hosters, but not only, e.g. if you're running inference on a large dense model (think Mistral Medium) with SSD streaming and a single session (no concurrent batching), speculative decoding can be quite great.
It's also a spectrum, e.g. some MoE models are not very sparse and comparatively few concurrent requests might already span most of the experts, such that loading a complete set of layer parameters and doing speculative decoding to increase compute intensity actually becomes worthwhile.
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 don't want to sound overly dismissive, but for quite a few practical cases pipeline parallelism with micro-batches will be a likely win over tensor parallelism. Of course this inherently comes with a requirement to take batched inference seriously for local use, at least in special cases where this doesn't put too much of a requirement on memory capacity. By comparison, tensor parallelism is probably good wrt. making memory- and KV-cache hungry models like GLM 5.2 and perhaps Kimi genuinely viable in a non-trivial local inference scenario.
Oh that’s great - I’m generally more interested in single machine use cases but the RDMA stuff is super interesting.
I do wonder if you are planning to eventually delegate some of the merging responsibilities? I see some other projects follow a similar pattern when they grow to a certain size.
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?
> How are you supposed to review 5k lines of code every day?
Maybe there’s grey areas of reviewing 10% of the code, ensuring tests actual are meaningful, the big ideas are correct etc. I personally find that more efficient to do by looking at some code than a proxied description of the code.
> “how is exactly the design of that part? How does it work?”
Isn’t code and syntax often, but not always, a more precise way to see that? Won’t it depend on what you mean by “how does it work”? I’d prefer pseudo code in some cases and actual code in other cases. There are times line by line details matter. There are times when bigger ideas matter.
It’s all like saying you run a car factory and should only ever give out the big ideas, never take a wrench to a car and figure out of if the factory builds cars to your expectations.
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 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 think it's related that we as humans see when something becomes hard to reason about, and decide to refactor it. I'm not sure whether an LLM with full ownership of a codebase could do that, for its own benefit.
I do see a world where models could be trained on it, but I imagine it will be more expensive, because it requires including future rewards about the models' own later efficiency.
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. Which doesn't mean that you can just prompt at a very high level, but that iterating with the LLM over decisions, designs and tests, will essentially allow you to not write a single line of code by hand. 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.
"coding is largely solved" and "self-driving is largely solved" smell exactly the same to me.
ETA: I bristle deeply at your idea that anyone who doesn't agree with you is letting their emotions get the better of them. Perhaps the world is not as black and white as you're painting it?
What does it mean for coding to be solved, and software engineering to not have been solved? If it implies there's now a set protocol that can be followed to reach good results, how has that not been the case before? If it means that we can reach better results than before, then how do we know that can't be improved further? Or does that mean we should know how English language, instead of computer code, maps to computer instructions?
Actually, this paper shows that the LLMs create a lot more slop and degradation of the code after the first prompt. https://arxiv.org/html/2603.24755v1.
So iterating with the LLM will simply make it to produce worse and worse code.
I still read the code; but I work to make a trustworthy agent, so I can skim read at review.
For a year+ I've been gaining leverage by codifying guardrails. Insanely intricate (and fun to create) lint scripts that catch things like python imports inside functions instead of the top of the file, or dumb use of dict return where the return should be a pydantic model, or the agent dumbly using the ugly default Tailwind color classes instead of my design system colors.
It's fun codifying "how we work around here" and it's been great for keeping dumb AI mistakes off my radar.
Last week I busted out my text editor and typed (typed!) a section into CLAUDE.md on my philosophy - my why. "We do test driven development because we have a computer that can instantly validate your code." "We don't modify code until we have created and witnessed some other thing that durably proves the need for our change." Etc. etc.
Well the agent leveled up suddenly and dramatically. It was a real mind opener. One of those banger realizations. I'd been leaving tons of power on the table.
When backfilling tests, it suddenly started mutating production code and rerunning to witness tests go red - something it calls "teeth". It doesn't just assume tests work and move on! I didn't ask for that, it was latent in the model. I no longer have to remind it to run new eslint rules first to prove they're correct. Sometimes it even proposes new lint rules and checks to tighten its guardrails.
What I learned that maps to what @antirez is saying:
With everything about agents, stop operating at a level of "what". The what is the agent's job.
Stop operating at a level of "how" too!
Just focus on not hoarding your "why". Tell your agent where your ideas come from, why they matter. Do not just think the why in your head. Write it down! Put it in CLAUDE.md. Offload it into the system!
Your tools will level up.
Even if it's not about the harness. Building product features? Tell it what you think the users will do. And why. It might codify the UX closer to how you'd have. Tell it what other UIs you've seen and like - it probably knows about them and can just code that - less detail needed.
And it'll bring the code closer to what you'd have written. And bring you closer to that holy grail, LGTM skim-review.
> looking at the code itself is suboptimal and often pointless
yeah I was having a convo with AI about this recently
I was like, I recognize AI tools are useful, but I don't end up using them as much as I'd like to
and the conversation kind of went towards acknowledging how dramatic the shift has been from using search engines to get ideas about how to manually code, to just sharing ideas for other people to maybe implement in their own way using AI
So, there were all kinds of buzz phrases that popped up like about "prompts as source code" and "spec driven development" and "context engineering" which just kind of confirmed for me that I think some of my "slowdown" with coding with AI has been due to a shift from this manual coding with search engine assistance to sharing ideas and letting AI do the actual coding
Manual review akin to skimming while reading and then reading in depth specific passages that need "deeper focus" is probably something to consider keeping doing
... I believe many programmers at this point have less impact they could have because they look at the code.
I think my strength is now more in my ability as a mathematician and a writer than as a programmer. Being able to write detailed specs and doing QA by testing is far more productive than looking at code.
Right don't do that then when you have a floating point problem or an integer overflow let's see if your ability as a mathematician helps or if you need to know the machine and the code
That is the part Claude can handle and actually does. In fact, recently claude automaticaly converted some spline generating code to double precision and did some other refactoring as well after it realized poor results thru tests it generated on its own! I was gobsmacked!
Humans are fallible, so we review the code. They "hallucinate" and produce mistakes and go in the wrong direction. We evolved an entire discipline around processes, tools, reviews etc. to help remedy (not solve!) this.
For some reason, the moment those humans are being replaced by fallible, stochastic machines, we decide to just throw the baby out with the bathwater entirely and no longer leverage critical parts of this pipeline? Because it's inefficient and we're bottlenecking the process? The magic of LLMs has quite literally bought us more cycles to do this stuff, not less!
I use the things every day to an extreme degree and still I don't think I will ever quite understand the leaps in logic required to arrive at this position.
Problem is that in our job we are conflating several things that are different:
- Coding: Writing instructions in a programming language. Example: writing a function that calculates the total price of an order.
- Programming: Designing a solution, writing the code, testing it, and fixing problems. Example: building a small application that manages orders and payments.
- Software engineering: Creating and maintaining reliable software systems using structured processes, architecture, testing, documentation, and teamwork. Example: designing an online store that can support millions of users and be maintained for many years.
It seems like in the future coding will all be done by machines and we can use our brain for the other 2 things.
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.
Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome.
That’s why we read code. Because only there the correct and incorrect cases are clearly separated.
But that's just more data. Create the error conditions in your test harness and exercise them. The machine will tell you what happened. Then correct the machine.
I.e. if by its structure we can conclude that our test cases are sufficient. Because if we don't know its structure then we don't know there aren't undisclosed sub-partitions of (combinatorially exploded) test space where it breaks.
How do we know its structure? By specifying it. How do we do that in enough detail? Code. Or we use static analysis I guess. Which is harder.
I can't even fathom how someone can say this with a straight face. Judging by the absolute garbage (architecture-wise) that the frontier models put out, I pity anyone taken in by this sort of thinking. They regularly tie themselves in knots and dig deeper holes for themselves without my intervention.
Software is exact; its maths. We would not tolerate a machine that operates on the basis proving/applying theorems right like 60% of the time. How we think this is suddenly acceptable in software engineering baffles me. CVEs can kill people, bad software can cause severe harms
But maybe I should not be on here arguing about this. I should be out there working on how to profit off such fundamental misunderstandings.
the model does not make the architecture decisions, you make the architecture decisions. you define what success is, including performance characteristics. fuzzing and property based testing ensure correctness. what does it matter what the code looks like if it the machine you've created fulfills the criteria you define?
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.
> Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations are broken (do more work than they should, for instance), and so forth.
I agree 100% that AI helps a lot with that. But I feel like there's something missing between "AI helps a lot with that" and "I believe reading code is mostly pointless". I genuinely wonder how the above can be accomplished without reading any code.
> I genuinely wonder how the above can be accomplished without reading any code.
We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way.
That's not usually going to be the most efficient way to understand code, but I've found that it's pretty useful to be one of the few empiricists in an organization full of rationalists (software engineers are typically rationalists in my experience). I wouldn't propose that we dispense with rationalism altogether, but it does seem that the we'll benefit by achieving a better balance than we've traditionally had.
> 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?
I also got a hint from this that he worries the community would reject features in Redis (and Redis itself) if they expected that the code has not been human-reviewed.
I'm facing this with some of my own open source projects: I feel a responsibility to manually review the code because I don't want to damage the reputation of those projects by shopping code I haven't looked at myself, even where I'm confident that it works and is well structured already.
I really don't understand why we feel the need to drop the review aspect. Programming with LLMs is a very non-linear process, there's no prompt-to-code mapping where editing a part of the prompt would produce an identical code construct with just a small part of it changed. LLMs are incapable of ensuring the thing works as expected, and the prompt itself is lossy too. Without review, we have no tangible way to interact with the system being constructed.
For "ideas", substitute "code in a higher level language". At least if we actually want to control the ideas. Right now, with those ideas expressed only in English, our control is limited.
What LLM coding does is generate lots of code from a fairly small English (natural language) prompt.
If you look closely, I think you'll see that this is two processes:
1. Translate from fuzzy English to precise machine-executable language
2. Translate from high-level description to lots of low-level code.
Although these two are still pretty great when they are mashed-together, I think they'd be even better, lots better, if we could separate them.
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 think this blog post could use a disclaimer that Redis has AI offerings and would like to expand in the vector database market.
The fact that the author addresses the young makes me feel uncomfortable. Gen-Z knows that currently almost all blog posts have an ulterior motive and are worded in a way that claims to be in their best interests.
Do not listen to well-known programmers who use their non-AI earned fame to steer you into the unknown future.
The AI stock market is already collapsing as we speak and these recommendations aren't worth much.
Totally agree. But I have the feeling damage has already been done, like full oop back then. To be precise I don't think oop was a total mistake, rather being maximalists about it was a mistake like with AI. I am so pessimist that I believe sooner or later we will testify the first death because of ai unreviewed code. I hope I'll be wrong
You're right. It's disappointing to see an established name, which I used to respect as a voice of an experienced programmer, pivoted to a different field and purpose. There's no substance or personality there anymore, only a kind of indirect marketing for how to drive an overhyped code-generation service provided by a corporation.
From out of the ruins other voices of reason, talent and expertise will surely emerge, but it will be difficult to find and listen amidst the public pollution and industrial megaphone drowning them out. The mainstream culture has been enshittified, and healthy creative subcultures have yet to grow into their stride.
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?
No its fine. The problem is trying to read all the code. Reading some is fine. I tend to focus on public APIs, and key areas. But not the thousands of lines which arre tests or will be refactored.
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?
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/
> "Apple" is a generic name, that does not actually really express anything particularly specific.
...
> "apple" as an idea doesn't really express anything concrete without lots more context.
I understand where you're coming from and appreciate the nuance, but can't help to feel that you've moved the goalposts from the earlier:
> There are no "ideas" independent of expression.
I never meant to claim that ideas have to be concrete or specific, if anything, the best thing about an idea is that it is not any of those.
And it's clear to me that you did perfectly understand what I meant by:
> "apple", "manzana", "pomme", "mela", "maçã"
as you then said "isn't even a fruit", so I was able to effectively communicate to you the abstract idea of a particular type of fruit. Communication of ideas does work to promote coordination of actions (in this case a comment thread on "the same topic"), and while flawed and fuzzy, I don't see how it could function if there were no ideas independent of expression.
Do I have to look at the text of the article (words, letters, punctuation) to get to the ideas in it? Do ideas exist outside of the code where they are embedded? If the ideas live outside the code how confident can I be confident the code as written embodies the ideas? These are the things I keep thinking about.
Exactly. And I don't want to encourage him to have the AI write the whole text, just to let it proofread what he wrote. It's a natural language processing tool. Let's use it for that.
And if you had to email someone in Italian, would you really do it with poor grammar? Or would you write it in English and translate it, or use a tool to ensure it's correct?
I'm not telling him to stop writing on his own and instead just let AI write for him, but there's no shame in letting an NLP tool do what it's made for and correct the mistakes you made writing in a language you aren't native to.
Very egocentric piece. Almost reads as “I’m so cool, I did so many cool things, and most things other people did is way worse than even the slop that my LLM prompting skills are capable to produce”.
Also “ You have to understand how things work, what is the best design, how to reach a certain level of performance.” - how does OP propose to understand how things work or what is the best design if you don’t actually go and build things or read the code? I hope the answer is not “reading mythical man month” or “watching YouTube video tutorials”.
This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think."
I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data structures and ideas; less and less in lines of code.
And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide.
The idea is the hard part, and it's the right place to focus your effort.
I bet you had to solve math equations and prove math stuff to get your degree, am I right? Now imagine I tell you that you could have just prompted LLMs with “please solve the is and make no mistakes”, would you think you’d be able to get your math degree?
The point I’m trying to make is that it’s very easy to tell everyone “don’t read the code, just focus on architecture” when you have decades of experience behind your shoulders, where you HAD to read the code, iterate, learn from your mistakes, read code written by others, and actually writing and making stuff yourself to gain that experience and understand architecture.
How do you expect people to learn all this stuff that you know if don’t want them to actually do the work but instead “control the idea”, whatever this means? It’s just baffles me that people don’t see this.
You made my evening a bit better by your message, kind stranger. It is lonely in there, but I suspect you know, just like me, that we can't chose a different path.
> In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe will happen, so I feel like I can say this without sounding egocentric
Not egocentric but surely full of himself
> This is why yesterday, on X, I said that I believe many programmers at this point have less impact they could have because they look at the code. I truly believe into that.
I have great impact because I own the code and I read it when I generate it not the contrary
> How are you supposed to review 5k lines of code every day?
I have the feeling we will just lose the battle and start to randomly die inside crushing planes or sinking ships thanks to unreviewed code. Or lose money, or whatever you can think of many examples.
> The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job, that is, asking yourself: what I’m doing with this software? What are the new directions I want to take? And also, think at new ideas, features, optimizations tricks. And doing a lot of QA.
Guess what when we hand coded we did all these points every day, now we can't because we need to go 100x faster, understand nothing that came out from the slot machine and, cherry on top, we should focus on QA instead of pushing high quality code first.
I'm really worried by the direction the industry is taking and how dangerous these "influencers" are, especially in Italy where I see he has a big follow up.
We lied on a mountain of slop before LLMs sure but at least some systems were still reliable, today you can already see nothing is reliable not even the simplest service like Spotify, programmers are already not verifying the output.
What I'm curious about is how a young programmer in, say, Sicily or Finland or somewhere who is a student or doesn't have a lot of spare cash, is going to deal with a world where everything is predicated on access to expensive tokens controlled by megacorporations, or where even 'open source' models require fairly expensive hardware to run.
I think about that too. Had I grown up thinking that I need to pay a subscription to build software, I wouldn't have tried to get into engineering at all. As a teen I wanted to learn electronics and robotics, but I couldn't afford the parts to build anything so I taught myself programming and CS instead, and that's the only thing that helped me slog through academic education.
I can't imagine making the same choice again today. Nowadays I worry that software engineering is about to become short-lived right after I've entered the workforce, in which case I'll regret the time I spent to get to this point based on a false hope.
I think this is a possible future, but we are nowhere close with the current tech. It makes too many mistakes currently. I could envision a future where the hallucination and error rate is brought down to a very small number, but trusting your codebase completely to an LLM at this point has a 100% chance of eventually becoming a problem.
This will be true because LLMs will increasingly generate better code faster and will outpace your patience to read the code while being entice to move forward faster because of partial trust. Like an engineer that you direct to do things, you as a technical manager can only review so much. It will drift till we are just asking it to review and give you a overview for you to review.
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/)
Genuine question, is redis actually used by competent engineers?
The idea of a separate networked process to store and retrieve variables from memory sounds like something a first year engineer would do when they learn about a hot tech netflix uses before they learn about fundamentals like what a heap and a stack are.
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.
At 600k lines of Rust, not finding those issues yet. You can search for different versions of same concepts, I mean you need to refactor a lot anyway.
Did you actually manually review the 600k lines of code?
And the reason LLMs tend to produce such insanely large codebases is partially what the comment you're replying to explained, they duplicate everything all over the place.
The codebase is large because its a complex problem and its around 75% tests. Have used various tools to find duplicates and they arent there to any significant extent.
"You are violating the DRY principle with code like <blahblah>. Look through the codebase in depth, and identify possible places to consolidate common logic."
Yeah, there's no substitute for taste, but this is not that big of a deal. I infinitely prefer repeated code to crappy, leaky abstractions. Let the model generate some slop, then tighten it up either by hand or with more prompting.
I just finished an LLM assisted Rust rewrite of a production project after a couple months. It's around 150k LOC, mostly Rust, excluding generated code and tests. Around 200k if I include tests. I'm also now starting to extract / refactor some of it's code into their own reusable crates, so my LOC isn't going to grow and might even shrink a bit. I can't speak to 1M LOC, but I'd imagine that takes a lot of human context to reason about too, and you probably want to break it up into manageable chunks if possible.
LLMs have been a boon. I have a lot of guardrails in place though to keep the LLMs focused and producing correct and ergonomic code. A lot of effort and review has gone into creating these guardrails (choice of language, linting, forced conventions, tests, etc.). A lot of these practices will be useful in future projects. I highly recommend this approach. Don't just copy skills or processes that others publish. Figure it out yourself so the lessons stick. Human in the loop, especially one that has learned through practice and failure, is still immensely valuable IMO. It's a fine line between getting stuff done and yakshaving over your tooling... but that's always been the case, as proven by my vim dotfiles. :)
It's worth noting that the AI industry is filled with tons of snakeoil and BS. You don't need to take someone's course in "21 steps to be productive with AI" or w/e. Just like learning a new programming language, dig right in and try to build something that scratches an itch. Pick a project you have complete autonomy over instead of that "spend all the tokens" crap managers were pushing until recently (this has corrected now right?).
Parent saying "Skill issue" though... What a jackarse.
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.
That's a completely reasonable take. I wouldn't have any issue with a nuanced comment like that. My issue with your above comment is that it's a lot more arrogant than nuanced.
That's fair, I think my point is there's a nuanced theory behind my choice to be rude, which is essentially "you need to experiment more, be more open minded, really work at it, and then you'll see what others are seeing, it isn't impossible." It's like Dark Souls, nobody can beat it for you, or teach you how to use dodge rolls, you've gotta build that skill yourself, and blaming the tools won't help.
I think your attitude is pretty lazy. It's a low-effort answer to say "skill issue" and then walk away feeling superior. Much harder to lean in to the other person, understand them, then help guide them onto the path. When you do this, you cause them to accelerate tremendously.
IMHO as you get more senior in software, after a while the only interesting metric becomes: are you raising the level of the people around you?
EDIT: looking at your Github seems like you are still in university. So I'll say "age and experience issue" on your end ;)
> IMHO as you get more senior in software, after a while the only interesting metric becomes: are you raising the level of the people around you?
Strongly agree, especially given how helping your teammates scales geometrically rather than linearly like improving your own output. If you work on a team team of five people with roughly equal output, and each becomes 20% more productive because of improvements you make, your team's output is increased the same as if you doubled your own productivity without helping anyone else on your team. (The math doesn't work out the same if your teammates aren't as productive as you already, but that's just an another argument for why it's better in the long run to be someone who can enable those around them rather than someone who only helps themself; helping everyone else has compounding returns if you keep doing it!)
I personally just also find it more fulfilling to be someone who makes everyone else around me better rather than just trying to be better than anyone else, but I recognize that not everyone will be motivated by that, so sometimes framing it in terms of raw output can help. The other potentially strong argument for those who are a bit more motivated by their own experiences only is that it's usually a lot more fun to have smart productive coworkers than ones who make you scoff and say "skill issue" to!
> That's fair, I think my point is there's a nuanced theory behind my choice to be rude, which is essentially "you need to experiment more, be more open minded, really work at it, and then you'll see what others are seeing, it isn't impossible."
Why not just say that then, instead of being rude? I pretty firmly disagree with the idea that being rude is ever a useful way to convey information rather than intent. Content and tone are separate axes that you can calibrate independently, so what you're saying is never an excuse for how you say it. Being rude conveys emotion, not information, and you didn't really convey information in your comment other than "look at how amazing the stuff I do is", and that's not a particularly effective mechanism for getting people to see your point of view.
I agree with you and I didn't think your comment was rude. Some people are against using LLMs and they will always find an excuse instead of experimenting with them so it doesn't matter how helpful you try to be they already made their mind.
> Some people are against using LLMs and they will always find an excuse instead of experimenting with them so it doesn't matter how helpful you try to be they already made their mind.
Do you think that I'm "against LLMs" and "finding an excuse instead of experimenting" because I disagree with you and the parent comment? If so, you should consider whether your perceptions are accurate, because I use them extensively.
More generally, if you aren't interested in engaging with the people who disagree with you, and you think that enough of them are arguing in bad faith and will never change their mind that their presence should determine the tone of your comments, why bother engaging in the discussion at all then?
I think "skill issue" is often deployed (including here) as a shortcut for what you said - "the only thing stopping them is that no one has helped them understand".
(I try not to say "skill issue" myself because it comes across as rude.)
Yes, but with the context that the person saying it is almost always the one who does understand, and is choosing to be snarky instead of helpful.
> All I can say is skill issue.
I regularly see claims by people that they have produced large, reliable bodies of code using vibe coding. Unfortunately, no vibe coded project I've used comes anywhere close to code reviewed by a human. Admittedly, my sample size is very small: things like claude-code, OpenClaw, and the occasional project I see mentioned here. But compared to the things I used regularly like GNU coreutils, Firefox, Linux, vim, git and the hundreds of other software projects I use daily, vibe coded apps are in a different ballpark. Vibe coded apps of a few 100k lines often glitch several times a day, the traditional ones that have several orders of magnitude more lines often don't fail in several years of use.
AI is now being used to assist in creating and maintaining these traditional bodies of software, of course. It looks like it has enhanced productivity as open source contributions have grown by 20% or so, and we've only just started to learn how to use it. I haven't noticed any degradation in quality. It may be too early to tell, but I suspect the engineers involved wouldn't let that happen.
As you say, it's a skill issue - it takes considerable skill to produce reliable maintainable code. But I suspect that wasn't the skill you are referring to.
Maybe the key difference is that you are so far off the beaten path that there simply are no examples of what you are doing that the models "want" to emulate?
I've also had reasonable success with the models generating fairly idiomatic Objective-Smalltalk, my own language of which there are likely few to no examples in the training data.
I do steer them towards my own sample programs.
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.
https://williamcotton.github.io/datafarm-studio/
https://williamcotton.github.io/algraf
https://williamcotton.github.io/pdl
https://github.com/williamcotton/algraf
https://github.com/williamcotton/pdl
Check out the /docs dir in the repos for each plan file and the language specs.
They are my 4th and 5th DSLs and I learned quite a bit along the way, most importantly how to separate a WASM runtime wired up to a Monaco editor “lsp” with the same crate for editor-services that works with the actual system binary LSP.
Feel free to peruse the repos! I follow compression-oriented programming, so there are places where the code is "insufficiently" DRY intentionally, as I feel out the precise use cases, and I explicitly made some other decisions (like a God editor object) for meta design reasons (I want it to be easy to modify the editor state from anywhere, just like in Emacs), so all I ask is that you review these without being excessively punative to prove your point.
https://github.com/alexispurslane/cursed/
https://github.com/alexispurslane/industrialworld/
Feel free to look at my past projects, prior to me starting to use AI (which started with gemini-ocr) to assess my baseline skill level.
I've found this to be more consistently the case than not. People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function. They put together a keyword soup post that sounds good on an AI generated resume but falls apart upon investigation.
> People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function
It's funny because you chose to target the one who is pro-AI, who has since posted their code, and not the GP who is against AI, who also didn't post any code to support his opinion that "it turns out the models don't care about your ideas and want to do what's popular in their training data".
Do you see the irony?
No, they don't. They're more interested in pathologizing and talking down to and about me.
Its hard not to feel insulted here. "Projects using AI like this don't exist, and if they do, they're broken and the people who made them have psychosis." However, although I haven't tested my projects cross machine, or cross platform yet (my editor only works on MacOS because it uses kqueue), I would be happy to take an unedited video demonstration of both, I assure you they both run.
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
things you described are not "highly unusual" in the way gp comment is describing. you are just remixing bunch of stuff. Thats the type of thing ai is really good at.
The GP was just talking about not using common languages like TypeScript and frameworks like React, which is a bar of unusual that seems arguably far lower than mine, especially since I literally defined special custom DSLs with unusual semantics, and used libraries like SDL_gpu with little to no pre-existing training data. So this seems like shifting the goalposts.
Also, what would be highly unusual to you?
> The GP was just talking about not using common languages like TypeScript and frameworks like React
i dont see anything like that in that comment.
"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"
The most esoteric I've seen from an LLM was this light rendering fix in a TempleOS game engine: https://gitgud.io/CrunkLord420/cyberchud/-/commit/c49879751c...
Though it's still cheating with a compatibility layer, I don't think claude touched any HolyC.
The key is to remove degrees of freedom from the agent. IMHO this is the really hard work of agentic engineering. You need to strongly constrain what the agent can even do in the first place to force it into a certain area.
That runs the danger of putting the model out of distribution, of course, so it takes some experimenting.
I'm working on a Ruby project where - on purpose - I'm disallowing any frameworks other than what's standard Ruby. So no Rails or Sinatra, just the inbuilt Webrick web server. Initially it was hard to keep the model on the rails but as I've learned more it gets easier. That said, it's clear to me that the model pulls very strongly in familiar directions in terms of how it writes code, i.e. a lot of what gets written still ends up looking "Railsy" even though my learning project doesn't use it.
It makes everyone more average and same-y. It’s a good average, better than bad, but I cringe everytime I see someone claiming it’s a force multiplier for their personal expression. Bullshit.
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've been playing around with https://github.com/bytedance/deer-flow and they seem to figure out how to get around context sizing issues and has a more automated prompt system.
Essentially the problem with current hanrsses is they just can't find/evict context and want to ensure KV cache isn't evicted.
If they evict the old prompt and tried to keep all the proper rules, then you get token churn anyway, as what you want is an entirely new chain of events where your rules/guidance sit at the front of the model chain.
What we're getting to is there really isn't an economical way for cloud models to do it; you can do it with a local model, but at comfortable speeds, you need smaller sized.
I think a good harness via Qwen3.6-35B-A3B is possible, as the token gen is only 3B since that's the active parameters.
So it's mostly that to keep rules pinned to the top of the context will either bloat the model or it'll evict the KV cache.
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 of 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?
> cascading from an assumption that was incorrect
I have found including this in my AGENTS.md to be quite transformative in this regard:
> Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. For this, you must create stubs of the expected modules and exports in the red phase, so that the test cases actually run and fail on the test case assertions themselves. In some cases, when using this approach, once in a while some of the red phase test cases might "incidentally" pass, and this is ok. Before running red phase tests you should always make predictions about the number of test cases you expect to fail/pass -- this count is not the number of test files or test suites, but rather the number of test cases. By performing these red phase expected counts of passing/failing test cases, it will help you catch errors in your prior reasoning quickly and efficiently.
> Always use a proof-driven, scientific method-based approach to validate hypotheses, assumptions, and conclusions: define the smallest falsifiable hypothesis, create or identify a reproducible failing case, gather direct evidence, make the smallest targeted change, and then re-run the same proof to confirm the issue is fixed. Avoid speculative fixes, broad rewrites, or changing multiple variables at once. When possible, preserve the reproduction as a regression test before implementing the fix. Consider that when gathering evidence, additional logging and durable files can be very helpful.
> The strict TDD and proof-driven approaches described above could be described as "proof-driven development". Try to internalize and generalize these concepts, as they are broadly applicable.
> It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run.
Is this for llm purposes? In many forms of TDD a compile error is key to the red phase. And you are going from red to green before asserts even exist is part of the process.
For the TypeScript projects that I work in, if there is value in a compile error phase I am not smart enough to know what it is, heh.
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...
Yes, a better rubber duck is a decent description
The LLM will often miss the most obvious simplifications. And if I ask it to present me with six approaches how we could solve a problem, chances are we will settle on number seven or eight, both my ideas after rejecting all the other six. But those first six were still valuable for coming up with the version we actually settle on. Making the rubber-duck talk is genuinely useful.
And the rubber duck is actually pretty good at the localized grunt work, so you can spend more time talking with it about big-picture stuff
But the CPU is not executing the textual description of your architecture. It executes code.
Honestly, I've found that the architecture described to and by LLMs is always a more rosy picture than what is actually generated, no matter how many times you do an adversarial review. It's less visceral than in image generation, but the pattern is the same -- the broad strokes seem fine but the details are awful.
> 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 don't get this perspective.
How much of the source code of the compiler you use did you read? How much of the source code of the standard library of your chosen language did you read? What about the dependencies?
How much of the source code of a huge codebase does the average developer read? I don't think any human alive has read the majority of code in huge codebases like Word, Windows, Linux, etc.
For almost every developer, the majority of the code you use every day, whether in software you use or actual code you're shipping, is not code you've ever read. And no one seems to have a problem with it, because we've built lots of processes around this. It's only when the code is written by an AI and not a coworker or random library author that people seem to have a problem.
And I get it! AI wasn't very good at writing code two years ago. Maybe even a year ago. I think it's good now, but maybe you don't - ok, that's fine, maybe it'll only live up to your standards in a year or two or ten. But that doesn't seem to be what people are arguing, it's not "AI isn't good enough", it's "how can we possibly ship code we never read", and my point is that we've all been doing this for our entire careers.
The code we've shipped throughout our careers certainly wasn't reviewed only by us. It was reviewed by programmers with more expertise in the relevant area. That's a healthy and efficient division of labor, expertise, and responsibility.
You do not need to understand an entire program to get the benefit of reading a chunk of source code that is part of that program.
People who do this are no longer engineers in any real sense. They’ve switched careers to technical management.
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.
> 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.
This doesn't strike me as wrong, but where the rubber meets the road. Let me give you an example.
My superior with close to zero programming skills, sat down with Claude and "wrote" a Django backend with SPA React frontend that enables user directory sync from one source to another and then exposes an API for other services to consume. It supports RBAC, 2FA, extensions for directory sources, dashboard with stats and what not. Everything packed into docker containers ready to deploy on the cloud. Again, the person is very skilled as a consultant, but lacks programming skills whatsoever. I did a code review, prepped a list of things to fix and he did fix them with Claude again. Later on, he used Claude to rewrite the Python backend to Go. I did no code review on that part. Fable was used in several iterations to test for security issues before each release.
Long story short, this service is now running in the cloud and the customer uses it to solve their problem. We got a couple of other customers on the line as well.
You tell me what to do with that.
> Fable was used in several iterations to test for security issues before each release.
How? The point of Fable (vs. Mythos) is that it has extreme guardrails against doing e. g. security work, even mentioning "security" or "vulnerability" in the prompt will shut it down.
Just opened Claude Code and I don't see any such restrictions. Asked Fable to do security/vulnerability review on the code base and it gladly agreed.
I can't speak for the above-mentioned project though, because I wasn't part of that release.
> You tell me what to do with that.
That if you polish it a bit, you can probably write a short story. /s
The thing is, making claims like that doesn’t prove anything. You have to either show the result or prove that is reproducible. Otherwise, it may as well be something you dream up this morning.
Execution is not the code, but how do you decide to do every part. "Idea does not matter, execution does" always meant: "big generic ideas don't matter, it is how you organize it in the myriad of details it is composed of (in a given incarnation of the general idea) that matters."
But why aren't lower level "ideas about execution" more clearly expressed in code? Or at least pseudocode?
Many of us would struggle with our reading comprehension of an English description of an algorithm. But the pseudo / actual code? Much easier to reason about.
I'm not saying you should review even 90% of code. But it feels like an arbitrary line to say "never look at code". It's like never taking a wrench to a car to look at what's built to see whether you trust the car factory.
I think "idea" is getting overloaded here. The article isn't talking about new feature/product/tool ideas, but about what concepts to use to build those features. e.g. what data structures and algorithms to use.
So your last line agrees with the article, I think. They are saying that it's still important to curate ideas, and no longer important to read the code; the time you would have spent reading the code should be spent curating ideas.
I completely agree with this you. The article is NOT about product ideas. Your parent has misunderstood the article.
Curating ideas requires experience and taste. Can you really develop that without looking at code? Compare Steve Jobs vs Joni Ive curating as a prime example of how taste without practical experience and context can lead things astray. And the worst of it is that it can take a while for the problem to be easily noticeable.
I highly respect Antirez, and as an Italian fellow programmer, for me, he's like a legend!
Although reading this article makes me quite sad; I consider myself an average, mediocre programmer, but I enjoy writing code since it's a way to build the mental model of a problem and to solve it iteratively.
I obviously use agents and all the new fancy tools, but if a great programmer like Antirez says that it's over, I think I'm not so faithful about my future as an engineer.
From another Italian fellow: stop following people and do your own thing, it will be worth it no matter what influencers says
All AI stocks are plummeting right now. Go your own way and don't listen to tech predictions, no matter how much you revere a person. Often they are all wrong.
>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 :) )
We're all project-managers now. The trust required of the LLM is no different than that that required when a PM trusts a dev-team to implement correctly. As a PM, you need to understand testability and write that into the requirements.
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)
You can have almost 100% tests coverage and green tests and still have a plane crash and LLMs shilling with you that everything is ok. To me it seems we havent learned yet tests coverage means nothing without solid code
"Testing shows the presence, not the absence of bugs"
- Dijkstra
The people who I see who are "getting along just fine" in this current mess are either True Believer™ types, or are semi or fully retired and don't need to care particularly strongly which way any of this goes from an employment perspective (meaning: I know people in this group who refuse to use LLMs and people who have attitudes like the author of this article, with similar levels of experience).
I think on one level you can look at these folks and say "well, they may be able to see more clearly because they aren't so wrapped up in it all" but I've done a lot of self-reflection and I simply don't think this is true.
Never thought I'd find myself questioning Antirez, but I have many questions about this post and overall attitude. For example:
> 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.
Why is the attitude here about keeping the floor up rather than raising the bar?
Why can't we have better code with AIs? Its not impossible to do!
When I implement things by basically pairing with the AI, I end up with better designs/architectures/code than I could have written by myself.
It sounds like some people think of the AI code paradigm as one where there will be fewer but better devs producing code/designs of lower quality than they could individually produce, but that is higher quality than the average dev could produce.
Is that really better than a world where AI raises the average across the board at the expense of a bit of speed? At the very least, it seems like a far less risky and less disruptive way to still capture significant benefits from AI.
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
> 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
This is somewhat of a nitpicking point, but AIUI speculative decoding is worthwhile if (1) you have viable unexploited parallelism that can speed up the "verify" step compared to plain decode, and (2) it's profitable for you to load complete model layers into memory in bulk, not just a tiny fraction of active parameters. (2) tends to be true for large hosters, but not only, e.g. if you're running inference on a large dense model (think Mistral Medium) with SSD streaming and a single session (no concurrent batching), speculative decoding can be quite great.
It's also a spectrum, e.g. some MoE models are not very sparse and comparatively few concurrent requests might already span most of the experts, such that loading a complete set of layer parameters and doing speculative decoding to increase compute intensity actually becomes worthwhile.
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 don't want to sound overly dismissive, but for quite a few practical cases pipeline parallelism with micro-batches will be a likely win over tensor parallelism. Of course this inherently comes with a requirement to take batched inference seriously for local use, at least in special cases where this doesn't put too much of a requirement on memory capacity. By comparison, tensor parallelism is probably good wrt. making memory- and KV-cache hungry models like GLM 5.2 and perhaps Kimi genuinely viable in a non-trivial local inference scenario.
Oh that’s great - I’m generally more interested in single machine use cases but the RDMA stuff is super interesting.
I do wonder if you are planning to eventually delegate some of the merging responsibilities? I see some other projects follow a similar pattern when they grow to a certain size.
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?
This article feels too black and white
> How are you supposed to review 5k lines of code every day?
Maybe there’s grey areas of reviewing 10% of the code, ensuring tests actual are meaningful, the big ideas are correct etc. I personally find that more efficient to do by looking at some code than a proxied description of the code.
> “how is exactly the design of that part? How does it work?”
Isn’t code and syntax often, but not always, a more precise way to see that? Won’t it depend on what you mean by “how does it work”? I’d prefer pseudo code in some cases and actual code in other cases. There are times line by line details matter. There are times when bigger ideas matter.
It’s all like saying you run a car factory and should only ever give out the big ideas, never take a wrench to a car and figure out of if the factory builds cars to your expectations.
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 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 think it's related that we as humans see when something becomes hard to reason about, and decide to refactor it. I'm not sure whether an LLM with full ownership of a codebase could do that, for its own benefit.
I do see a world where models could be trained on it, but I imagine it will be more expensive, because it requires including future rewards about the models' own later efficiency.
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. Which doesn't mean that you can just prompt at a very high level, but that iterating with the LLM over decisions, designs and tests, will essentially allow you to not write a single line of code by hand. 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.
"coding is largely solved" and "self-driving is largely solved" smell exactly the same to me.
ETA: I bristle deeply at your idea that anyone who doesn't agree with you is letting their emotions get the better of them. Perhaps the world is not as black and white as you're painting it?
What does it mean for coding to be solved, and software engineering to not have been solved? If it implies there's now a set protocol that can be followed to reach good results, how has that not been the case before? If it means that we can reach better results than before, then how do we know that can't be improved further? Or does that mean we should know how English language, instead of computer code, maps to computer instructions?
Actually, this paper shows that the LLMs create a lot more slop and degradation of the code after the first prompt. https://arxiv.org/html/2603.24755v1.
So iterating with the LLM will simply make it to produce worse and worse code.
Strong agree, but in a subtly different way..
I still read the code; but I work to make a trustworthy agent, so I can skim read at review.
For a year+ I've been gaining leverage by codifying guardrails. Insanely intricate (and fun to create) lint scripts that catch things like python imports inside functions instead of the top of the file, or dumb use of dict return where the return should be a pydantic model, or the agent dumbly using the ugly default Tailwind color classes instead of my design system colors.
It's fun codifying "how we work around here" and it's been great for keeping dumb AI mistakes off my radar.
Last week I busted out my text editor and typed (typed!) a section into CLAUDE.md on my philosophy - my why. "We do test driven development because we have a computer that can instantly validate your code." "We don't modify code until we have created and witnessed some other thing that durably proves the need for our change." Etc. etc.
Well the agent leveled up suddenly and dramatically. It was a real mind opener. One of those banger realizations. I'd been leaving tons of power on the table.
When backfilling tests, it suddenly started mutating production code and rerunning to witness tests go red - something it calls "teeth". It doesn't just assume tests work and move on! I didn't ask for that, it was latent in the model. I no longer have to remind it to run new eslint rules first to prove they're correct. Sometimes it even proposes new lint rules and checks to tighten its guardrails.
What I learned that maps to what @antirez is saying:
With everything about agents, stop operating at a level of "what". The what is the agent's job.
Stop operating at a level of "how" too!
Just focus on not hoarding your "why". Tell your agent where your ideas come from, why they matter. Do not just think the why in your head. Write it down! Put it in CLAUDE.md. Offload it into the system!
Your tools will level up.
Even if it's not about the harness. Building product features? Tell it what you think the users will do. And why. It might codify the UX closer to how you'd have. Tell it what other UIs you've seen and like - it probably knows about them and can just code that - less detail needed.
And it'll bring the code closer to what you'd have written. And bring you closer to that holy grail, LGTM skim-review.
> looking at the code itself is suboptimal and often pointless
yeah I was having a convo with AI about this recently
I was like, I recognize AI tools are useful, but I don't end up using them as much as I'd like to
and the conversation kind of went towards acknowledging how dramatic the shift has been from using search engines to get ideas about how to manually code, to just sharing ideas for other people to maybe implement in their own way using AI
So, there were all kinds of buzz phrases that popped up like about "prompts as source code" and "spec driven development" and "context engineering" which just kind of confirmed for me that I think some of my "slowdown" with coding with AI has been due to a shift from this manual coding with search engine assistance to sharing ideas and letting AI do the actual coding
Manual review akin to skimming while reading and then reading in depth specific passages that need "deeper focus" is probably something to consider keeping doing
Right don't do that then when you have a floating point problem or an integer overflow let's see if your ability as a mathematician helps or if you need to know the machine and the code
That is the part Claude can handle and actually does. In fact, recently claude automaticaly converted some spline generating code to double precision and did some other refactoring as well after it realized poor results thru tests it generated on its own! I was gobsmacked!
Unimpressive slot machine, it will betray you sooner than later and pay a real price
Humans are fallible, so we review the code. They "hallucinate" and produce mistakes and go in the wrong direction. We evolved an entire discipline around processes, tools, reviews etc. to help remedy (not solve!) this.
For some reason, the moment those humans are being replaced by fallible, stochastic machines, we decide to just throw the baby out with the bathwater entirely and no longer leverage critical parts of this pipeline? Because it's inefficient and we're bottlenecking the process? The magic of LLMs has quite literally bought us more cycles to do this stuff, not less!
I use the things every day to an extreme degree and still I don't think I will ever quite understand the leaps in logic required to arrive at this position.
Problem is that in our job we are conflating several things that are different:
- Coding: Writing instructions in a programming language. Example: writing a function that calculates the total price of an order.
- Programming: Designing a solution, writing the code, testing it, and fixing problems. Example: building a small application that manages orders and payments.
- Software engineering: Creating and maintaining reliable software systems using structured processes, architecture, testing, documentation, and teamwork. Example: designing an online store that can support millions of users and be maintained for many years.
It seems like in the future coding will all be done by machines and we can use our brain for the other 2 things.
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.
Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome.
That’s why we read code. Because only there the correct and incorrect cases are clearly separated.
But that's just more data. Create the error conditions in your test harness and exercise them. The machine will tell you what happened. Then correct the machine.
You make it sound so easy. Have you ever worked in QA?
> if we build it to be measurable
I.e. if by its structure we can conclude that our test cases are sufficient. Because if we don't know its structure then we don't know there aren't undisclosed sub-partitions of (combinatorially exploded) test space where it breaks.
How do we know its structure? By specifying it. How do we do that in enough detail? Code. Or we use static analysis I guess. Which is harder.
I could not disagree more.
I can't even fathom how someone can say this with a straight face. Judging by the absolute garbage (architecture-wise) that the frontier models put out, I pity anyone taken in by this sort of thinking. They regularly tie themselves in knots and dig deeper holes for themselves without my intervention.
Software is exact; its maths. We would not tolerate a machine that operates on the basis proving/applying theorems right like 60% of the time. How we think this is suddenly acceptable in software engineering baffles me. CVEs can kill people, bad software can cause severe harms
But maybe I should not be on here arguing about this. I should be out there working on how to profit off such fundamental misunderstandings.
the model does not make the architecture decisions, you make the architecture decisions. you define what success is, including performance characteristics. fuzzing and property based testing ensure correctness. what does it matter what the code looks like if it the machine you've created fulfills the criteria you define?
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.
> Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations are broken (do more work than they should, for instance), and so forth.
I agree 100% that AI helps a lot with that. But I feel like there's something missing between "AI helps a lot with that" and "I believe reading code is mostly pointless". I genuinely wonder how the above can be accomplished without reading any code.
> I genuinely wonder how the above can be accomplished without reading any code.
We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way.
That's not usually going to be the most efficient way to understand code, but I've found that it's pretty useful to be one of the few empiricists in an organization full of rationalists (software engineers are typically rationalists in my experience). I wouldn't propose that we dispense with rationalism altogether, but it does seem that the we'll benefit by achieving a better balance than we've traditionally had.
> We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way.
Interesting perspective. Haven't really thought through that lens
I write 2% of code. And read 5-10%.
I feel like everyone is being too black and white. And everyone has different ways of staying in flow with a software task.
Yeah, totally
Having looked at his code, I doubt this.
he said he read it though, and check the last line
> 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?
I also got a hint from this that he worries the community would reject features in Redis (and Redis itself) if they expected that the code has not been human-reviewed.
I'm facing this with some of my own open source projects: I feel a responsibility to manually review the code because I don't want to damage the reputation of those projects by shopping code I haven't looked at myself, even where I'm confident that it works and is well structured already.
I really don't understand why we feel the need to drop the review aspect. Programming with LLMs is a very non-linear process, there's no prompt-to-code mapping where editing a part of the prompt would produce an identical code construct with just a small part of it changed. LLMs are incapable of ensuring the thing works as expected, and the prompt itself is lossy too. Without review, we have no tangible way to interact with the system being constructed.
He is the creator of redis.
For "code", substitute "object code".
For "ideas", substitute "code in a higher level language". At least if we actually want to control the ideas. Right now, with those ideas expressed only in English, our control is limited.
What LLM coding does is generate lots of code from a fairly small English (natural language) prompt.
If you look closely, I think you'll see that this is two processes:
1. Translate from fuzzy English to precise machine-executable language
2. Translate from high-level description to lots of low-level code.
Although these two are still pretty great when they are mashed-together, I think they'd be even better, lots better, if we could separate them.
But today we cannot.
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 think this blog post could use a disclaimer that Redis has AI offerings and would like to expand in the vector database market.
The fact that the author addresses the young makes me feel uncomfortable. Gen-Z knows that currently almost all blog posts have an ulterior motive and are worded in a way that claims to be in their best interests.
Do not listen to well-known programmers who use their non-AI earned fame to steer you into the unknown future.
The AI stock market is already collapsing as we speak and these recommendations aren't worth much.
Totally agree. But I have the feeling damage has already been done, like full oop back then. To be precise I don't think oop was a total mistake, rather being maximalists about it was a mistake like with AI. I am so pessimist that I believe sooner or later we will testify the first death because of ai unreviewed code. I hope I'll be wrong
You're right. It's disappointing to see an established name, which I used to respect as a voice of an experienced programmer, pivoted to a different field and purpose. There's no substance or personality there anymore, only a kind of indirect marketing for how to drive an overhyped code-generation service provided by a corporation.
From out of the ruins other voices of reason, talent and expertise will surely emerge, but it will be difficult to find and listen amidst the public pollution and industrial megaphone drowning them out. The mainstream culture has been enshittified, and healthy creative subcultures have yet to grow into their stride.
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?
No its fine. The problem is trying to read all the code. Reading some is fine. I tend to focus on public APIs, and key areas. But not the thousands of lines which arre tests or will be refactored.
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?
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
> "Apple" is a generic name, that does not actually really express anything particularly specific.
...
> "apple" as an idea doesn't really express anything concrete without lots more context.
I understand where you're coming from and appreciate the nuance, but can't help to feel that you've moved the goalposts from the earlier:
> There are no "ideas" independent of expression.
I never meant to claim that ideas have to be concrete or specific, if anything, the best thing about an idea is that it is not any of those.
And it's clear to me that you did perfectly understand what I meant by:
> "apple", "manzana", "pomme", "mela", "maçã"
as you then said "isn't even a fruit", so I was able to effectively communicate to you the abstract idea of a particular type of fruit. Communication of ideas does work to promote coordination of actions (in this case a comment thread on "the same topic"), and while flawed and fuzzy, I don't see how it could function if there were no ideas independent of expression.
Do I have to look at the text of the article (words, letters, punctuation) to get to the ideas in it? Do ideas exist outside of the code where they are embedded? If the ideas live outside the code how confident can I be confident the code as written embodies the ideas? These are the things I keep thinking about.
Actions speak louder than words.
> "didn’t you say that you check all the AI generated code for Redis?"... Yes, I do
For important code (Redis) he is still reading the diffs.
> but: try it yourself, you will discover you can’t just say “implement XYZ” and see it working.
Yes, good software still requires engineering today.
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
Exactly. And I don't want to encourage him to have the AI write the whole text, just to let it proofread what he wrote. It's a natural language processing tool. Let's use it for that.
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.
And if you had to email someone in Italian, would you really do it with poor grammar? Or would you write it in English and translate it, or use a tool to ensure it's correct?
I'm not telling him to stop writing on his own and instead just let AI write for him, but there's no shame in letting an NLP tool do what it's made for and correct the mistakes you made writing in a language you aren't native to.
There's a difference between criticizing and saying, "I'm sorry, I don't understand what you are trying to say."
>What’s the point of scanning function by function, line by line?
Because a critical bug could be anywhere, even in a simple function. Particularly when it is written by an LLM.
Who knows when it chooses to have a bad hallucination?
Follow the vibes
Very egocentric piece. Almost reads as “I’m so cool, I did so many cool things, and most things other people did is way worse than even the slop that my LLM prompting skills are capable to produce”.
Also “ You have to understand how things work, what is the best design, how to reach a certain level of performance.” - how does OP propose to understand how things work or what is the best design if you don’t actually go and build things or read the code? I hope the answer is not “reading mythical man month” or “watching YouTube video tutorials”.
This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think."
I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data structures and ideas; less and less in lines of code.
And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide.
The idea is the hard part, and it's the right place to focus your effort.
I bet you had to solve math equations and prove math stuff to get your degree, am I right? Now imagine I tell you that you could have just prompted LLMs with “please solve the is and make no mistakes”, would you think you’d be able to get your math degree?
The point I’m trying to make is that it’s very easy to tell everyone “don’t read the code, just focus on architecture” when you have decades of experience behind your shoulders, where you HAD to read the code, iterate, learn from your mistakes, read code written by others, and actually writing and making stuff yourself to gain that experience and understand architecture.
How do you expect people to learn all this stuff that you know if don’t want them to actually do the work but instead “control the idea”, whatever this means? It’s just baffles me that people don’t see this.
I see it. I'm with you. It does feel lonely though, doesn't it?
You made my evening a bit better by your message, kind stranger. It is lonely in there, but I suspect you know, just like me, that we can't chose a different path.
> In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe will happen, so I feel like I can say this without sounding egocentric
Not egocentric but surely full of himself
> This is why yesterday, on X, I said that I believe many programmers at this point have less impact they could have because they look at the code. I truly believe into that.
I have great impact because I own the code and I read it when I generate it not the contrary
> How are you supposed to review 5k lines of code every day?
I have the feeling we will just lose the battle and start to randomly die inside crushing planes or sinking ships thanks to unreviewed code. Or lose money, or whatever you can think of many examples.
> The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job, that is, asking yourself: what I’m doing with this software? What are the new directions I want to take? And also, think at new ideas, features, optimizations tricks. And doing a lot of QA.
Guess what when we hand coded we did all these points every day, now we can't because we need to go 100x faster, understand nothing that came out from the slot machine and, cherry on top, we should focus on QA instead of pushing high quality code first.
I'm really worried by the direction the industry is taking and how dangerous these "influencers" are, especially in Italy where I see he has a big follow up.
We lied on a mountain of slop before LLMs sure but at least some systems were still reliable, today you can already see nothing is reliable not even the simplest service like Spotify, programmers are already not verifying the output.
What I'm curious about is how a young programmer in, say, Sicily or Finland or somewhere who is a student or doesn't have a lot of spare cash, is going to deal with a world where everything is predicated on access to expensive tokens controlled by megacorporations, or where even 'open source' models require fairly expensive hardware to run.
I think about that too. Had I grown up thinking that I need to pay a subscription to build software, I wouldn't have tried to get into engineering at all. As a teen I wanted to learn electronics and robotics, but I couldn't afford the parts to build anything so I taught myself programming and CS instead, and that's the only thing that helped me slog through academic education.
I can't imagine making the same choice again today. Nowadays I worry that software engineering is about to become short-lived right after I've entered the workforce, in which case I'll regret the time I spent to get to this point based on a false hope.
I think this is a possible future, but we are nowhere close with the current tech. It makes too many mistakes currently. I could envision a future where the hallucination and error rate is brought down to a very small number, but trusting your codebase completely to an LLM at this point has a 100% chance of eventually becoming a problem.
This will be true because LLMs will increasingly generate better code faster and will outpace your patience to read the code while being entice to move forward faster because of partial trust. Like an engineer that you direct to do things, you as a technical manager can only review so much. It will drift till we are just asking it to review and give you a overview for you to review.
Everyone's a prophet now
i use it daily and it's what is trending towards
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/)
Author is redis dev. Seems deep in vibecode mode
Genuine question, is redis actually used by competent engineers?
The idea of a separate networked process to store and retrieve variables from memory sounds like something a first year engineer would do when they learn about a hot tech netflix uses before they learn about fundamentals like what a heap and a stack are.
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.