Control the Ideas, Not the Code
antirez.com
antirez.com
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.
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.
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.
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.
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?
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 ;)
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!
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.
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 try not to say "skill issue" myself because it comes across as rude.)
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.
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?
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.
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.
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.
Also, what would be highly unusual to you?
i dont see anything like that in that comment.
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"
Though it's still cheating with a compatibility layer, I don't think claude touched any HolyC.
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.
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.
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.
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.
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.
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
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
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.
Is that something recent? I’ve been doing this for years, even in high school where we were asked essays on contrast between different viewpoints.
I don’t need LLM to do this. It’s the 101 of any engineering process to not rush with the first thought you have and indeed try to explicitly explore the solution space and base your decisions according to defined tradeoffs.
I'm 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.
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.
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.
AI/Vibecoding breaks this social trust, hence the general aversion to using those codebases or bringing LLM code in. It's not really about the general quality of the agents. It's about the code no longer being reviewed and understood by a human. How can one place trust in that? Unit tests don't replace careful review and considerate design.
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.
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.
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.
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.
I can't speak for the above-mentioned project though, because I wasn't part of that release.
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.
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.
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)
- Dijkstra
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 :) )
> 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.
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
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.
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.
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 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.
> 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.
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.
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?
So iterating with the LLM will simply make it to produce worse and worse code.
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.
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.
This doesn't mean AI-generated code is safe. The key point here (which AR explains well in his latest YT video on his way to the gym :D) is that you still need to master the CS fundamentals. Which means:
- People who master the fundamentals will use AI to move much faster.
- People who don't master the fundamentasl and vibe code will evetually hit a wall,
but most importantly
- People who master the fundamentals but review all the code will move much slower.
Innit?
People who master the fundamentals but review all the code will move much slower. But they'll be more successful in the medium to long run if they're catching things that matter. (If they aren't, of course, they're just wasting time.)
The assumption I believe is: if you are experienced enough you will instruct your agent(s) to address all of these during your iterations.
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.
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.
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.
- 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.
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.
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.
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?
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" 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.
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.
> "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 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.
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?
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.
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”.
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.
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.
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.
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.
Hell, I did that in a previous project.
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.
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.
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?
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.