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.
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.
I've also had reasonable success with them 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.
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.
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 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?
(I try not to say "skill issue" myself because it comes across as rude.)
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.
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.
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.
main problem is that the harness files get loaded into context early in the session and slowly wash away as new information comes in.
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.
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.
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'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?
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
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.
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
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 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 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 :) )
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.
- 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)
> "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.
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.
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
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.
> 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.
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.
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?
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 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.
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.
Interesting perspective. Haven't really thought through that lens
I feel like everyone is being too black and white. And everyone has different ways of staying in flow with a software task.
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.
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?
That’s why we read code. Because only there the correct and incorrect cases are clearly separated.
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'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?
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?
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.
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.
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.
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
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.
Hell, I did that in a previous project.
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.
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.
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.
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.
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.
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?
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.
If you are already locked in then whats the benfit of choosing redis from a pointy haired boss prespective.
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.