Introduction
On 13 July 2026, Salvatore Sanfilippo — better known as antirez, the creator of Redis — published a post titled "Control the ideas, not the code." Its central claim: "if you control the ideas of your software, looking at the code itself is suboptimal and often pointless."
He is explicit that this is not a licence to stop caring. "Note that this does not mean to vibe code something just asking for the final product," he writes — the distinction between the two is the whole post. His argument is that the scarce resource in a programmer's day has moved, and that reading machine-written diffs line by line is no longer where a senior engineer's hours buy the most.
He is also explicit about why he keeps saying it. He says he feels "the urge of lowering the impact for people less prepared to the change than me," programmers who sense that their field has changed and feel they are "betraying their own field" by not looking at the code. His message to them: "it's not your weakness, it's not that you are AI-pilled. It is just that our field is evolving."
The three reasons he gives
Volume. Coding agents now emit far more code than a human can absorb. His question is blunt: "How are you supposed to review 5k lines of code every day?" At that rate, review is not a quality gate. It is a formality performed by a tired human who is skimming.
Mismatched strengths. "LLMs are very good at writing locally optimal code, and are worse (but improving) with big ideas." So scanning function by function inspects the thing models are already good at. What he does instead is prompt the design he has in mind and then interrogate it — "how is exactly the design of that part? How does it work?" — and judge whether the model is right. "It is much faster."
Opportunity cost. "The working day is 8 hours." Hours spent reading generated code are hours not spent asking what the software is for, what direction it should take next, what the next optimization is — and doing "a lot of QA."
Underneath the three sits a fourth, and it is the one most likely to provoke. On the sorted-set optimization he is currently working on, he expects that reviews by Fable and GPT 5.6 "are going to spot ways more errors and subtle race conditions that my review is going to uncover." If the machine is the better reviewer, the classic defence of human review — a second pair of eyes catches what you missed — starts pointing the other way.
The phrase in the title is not new, and he says so: "controlling the ideas" comes from The Mythical Man-Month. His aside is that a book from the 1970s "tells us more things about the current software era than many of the things that were said from 2000 to 2020."
What he proposes instead
Not "ship it and hope." The replacement for reading code is writing down the design.
He wants to spend the hours that review currently eats on QA, on the next optimization, and on using
LLMs to produce a DESIGN.md in which each data structure is described in human language — "the
ideas it contains, the implementation tricks, the design." The workflow he imagines for a future
maintainer: "Do you want to modify sorted sets? You open the file, read the design, then you own the
ideas. You can open your agent and ask it what to do with the right mental model."
This is a real inversion. Conventionally the source is the artefact and documentation is a lossy afterthought that rots. Here the documented intent is primary and the implementation is closer to a compilation target — regenerable, replaceable, not the thing you own. It is the instinct behind spec-first agent workflows such as Harper Reed's LLM codegen workflow, pushed one step further: the spec is not scaffolding you discard after the build, it is the asset.
The local-inference example, and what it actually shows
The strongest evidence in the post is his own. With DwarfStar, his local-inference project, he implemented inference for two models — DeepSeek v4 and GLM 5.2 — "in a completely automated way." His first point about it is a warning: "try it yourself, you will discover you can't just say 'implement XYZ' and see it working. You have to understand how things work, what is the best design, how to reach a certain level of performance." That is the line separating his position from vibe coding.
The second point is the sharp one. When he compared his automated implementation against existing systems for correctness, he found that the other implementations "sometimes contained more errors" — and that the local-inference world at large "is full of subtle errors that accumulate and damage the model output," including broken indexed-attention implementations that do more work than they should and degrade performance past a certain context length.
His conclusion is not that AI writes buggy code. It is the reverse: in a domain this fast-moving and this fiddly, "rigorous engineering (in the design side) and testing is far better than writing a GPU kernel by hand (or reading it)." Which lets him ask the question the post is really built around: "are we sure most of that resistance it is not ideological?"
He also refuses to grant the premise that the old way was clean. "The level of slop we touched during recent years, before AI, is unbelievable."
Where he stops short
Two hedges are as informative as the thesis.
The first came from Matteo Collina, who asked him on X: didn't you say you check all the AI-generated code for Redis? He does — and calls it "something I need to do but that I believe to be mostly pointless." He keeps doing it "out of respect for users," because Redis is infrastructure and people will open those files by hand. The changes he makes on review, he concedes, are largely matters of taste rather than defects.
The second is juniors. He is unsure whether programmers without a mental model need to understand code deeply, but he is sure what they should not be doing: reviewing LLM output on a customer's JavaScript. Better, he says, to learn a language and implement "a small interpreter, a small database, an hash table." That leaves the honest gap in the piece — the design-first mode works because he already has thirty years of code in his head, and nobody has yet explained how the next generation acquires that.
The part that has to hold
The load-bearing word is control. Controlling the ideas is not the same as having them. It means you can state what the system must do and then tell whether it does — which requires tests you trust, benchmarks that catch a regression, and enough observability to see the failure you did not predict. Antirez has all three, plus decades of judgment about what a wrong design smells like; the "a lot of QA" in his third reason is not a footnote, it is the thing that makes dropping review survivable.
Strip that out and the advice inverts. Without the verification apparatus, "control the ideas, not the code" becomes vibe coding with better vocabulary, and the errors he found in the inference ecosystem — plausible output, wrong numbers — surface in production rather than in a diff. The middle path most teams will land on is the one his own fourth argument points at: route the mechanical pass to machines — see AI for code review — and spend human attention on the decisions a model cannot make.
Conclusion
The post is about where senior attention should go, not about permission to stop looking. Antirez describes a job whose centre of gravity has moved from writing and reading implementations to specifying, verifying and owning intent — and he is candid that he has not fully made the move himself, that he keeps reviewing Redis out of duty rather than conviction, and that he does not know what any of it does to the people coming after him.
That mix of a strong claim and two honest hedges is what makes it worth arguing with. The uncomfortable question it leaves is not whether models can write the code. It is what a programmer is for once they can.
Sources
- Control the ideas, not the code — antirez, 13 July 2026
- antirez, January 2024 — the earlier post on programming with AI that he points back to