Control the Ideas, Not the Code

A July 2026 post by Salvatore Sanfilippo, written shortly after he rejoined Redis and started building DwarfStar, a local LLM inference engine. His claim, first made on X and then expanded here: most programmers now get less done than they could because they keep reading the code. If you control the ideas behind a piece of software, scanning it function by function is slow and usually pointless.

He is careful to separate this from vibe coding. Vibe coding asks for a finished product and accepts whatever comes back. What antirez describes is the opposite end — you hold the design in your head, prompt it deliberately, and interrogate the model about how a part works ("how is exactly the design of that part? How does it work?") to check whether the mental model matches. The output you steer is the design, not the lines.

The argument

Three reasons he gives for not reviewing the code:

Volume. You can now generate far more code than you can read, and LLM output tends to be verbose on top of that. Reviewing 5,000 lines a day is not a real workflow.

Where LLMs are strong and weak. They write locally optimal code well and handle big ideas worse (though improving). Reading line by line checks the thing they are already good at while ignoring the thing they are bad at. Better to evaluate the design.

Opportunity cost. The workday is eight hours. Time spent reading code is time not spent on what antirez thinks is now the most important part of the job: deciding what the software should do, finding new directions, thinking up optimizations, and doing a lot of QA.

He anchors this in The Mythical Man-Month — "controlling the ideas" is Brooks' phrasing, and antirez notes a book from the 1970s describes the current era better than most of what was written between 2000 and 2020. This is the same Brooks lineage that no-silver-bullet-llms works through: the essential difficulty is the design and the concepts, not the typing.

Slop predates AI

antirez pushes back on the anti-AI position by asking why the people now protesting were not already horrified by the state of software over the past decade. His view is that the codebase was rotten before the models arrived, so treating AI as the source of slop misreads the history. He suspects a lot of the resistance is ideological.

His DwarfStar work is the evidence he offers. He implemented inference for two models (DeepSeek v4 and GLM 5.2) with heavy automation, but insists you cannot just say "implement XYZ" and watch it work — you have to understand the design, the performance targets, how the pieces fit. Comparing his implementation against other inference systems for correctness, he found the others sometimes had more errors: subtle bugs in attention that accumulate and degrade model output, broken indexed-attention implementations that do more work than they should past a certain context length. His point is that rigorous design plus testing beats hand-writing (or hand-reading) a GPU kernel, and AI helps most exactly in that kind of fast-moving, error-prone domain.

The Redis exception

Matteo Collina asked the obvious question in reply to the original tweet: didn't you say you check all the AI-generated code going into Redis? antirez says yes, he does, but he now thinks it is mostly pointless — more so since GPT 5.5, and even more with Fable and GPT 5.6. He still finds things he dislikes stylistically (he rewrote parts during the Redis Arrays work, and is doing it again for a coming 50% memory-saving optimization to sorted sets), but he frames this as taste, not correctness. Other contributors' files are often "far worse" by his standard without their authors being bad coders.

He keeps reviewing out of respect for users, because Redis is common enough that people will open the files and edit by hand. But if his hands were free he would spend that time on more QA, on the next optimization idea, and on having an LLM write a DESIGN.md for each data structure — the ideas, the implementation tricks, the design in plain language. That, he argues, is what a future contributor actually needs: read the design, own the ideas, then point an agent at the change with the right mental model. He also concedes the model reviews (Fable, GPT 5.6) will catch more real errors and race conditions in the sorted-sets PR than his own review will. Redis is the counterexample he grants; for most projects he thinks review no longer makes sense.

The one hesitation

The exception antirez is unsure about is junior programmers who lack the experience to build a mental model. He does not know whether they will need to understand code deeply, but he doubts that reviewing LLM output is how they should learn. Better, he thinks, to learn a language by writing a small interpreter, a small database, a hash table — build the mental model directly. Reviewing throwaway JavaScript for a client website teaches nothing worth the time.

How it fits

This lands in the same place simonw-vibe-coding-agentic arrived at from the other direction. Simon Willison confessed, with guilt, that he had stopped reviewing every line even for production. antirez makes the same move without the guilt — he argues line-by-line review was never the high-value activity, so dropping it is not drift but correction. The two posts bracket the 2026 consensus shift among experienced engineers: reviewing generated code line by line is on the way out; owning the design is what remains.

It also sits against clean-code-coding-agents, which argues clean structure matters more with agents because messy code wastes context. There is no contradiction — antirez writes very clean code precisely so it stays readable, and his DESIGN.md proposal is the same instinct aimed at the agent rather than the human reader. The disagreement is only about where a human should spend attention: the clean-code post says review structure not correctness, antirez says review neither and write the design doc instead.

The Redis angle connects to redis-cost-of-ambition, written a couple of months earlier about the same sorted-sets and arrays work from the outside — Leifer read the array-type PR as feature bloat, while antirez here treats those same PRs as ordinary maintenance he is doing by hand for taste reasons.

From the discussion

The Hacker News thread (225 points, 189 comments) surfaced the strongest counterargument, which antirez does not address. Several commenters reported that steering by ideas works only up to a point of scale. One noted the models "don't care about your ideas and want to do what's popular in their training data" — they are far better at maintaining a Django or React codebase than a hand-rolled architecture described in a design doc, and past roughly a million lines you end up with three or four versions of the same concept scattered across the codebase. A commenter on a 600k-line Rust project disagreed, saying the duplication isn't there at scale if you refactor continuously and lean on tests (his codebase is ~75% tests). The disagreement is really about whether the design-doc mental model survives compaction and long context, or whether the model quietly reverts to its training-data defaults.

Counterpoint

reviewing-ai-code (Thomas Depierre) starts from the same observation — line-by-line review of LLM output doesn't scale — and draws the opposite conclusion. Where antirez says drop the review and hold the design, Depierre argues that review is the only answer anyone has offered to the "LLMs get things wrong a lot" problem, and that code-review-throughput-limits make it unworkable at scale; dropping it therefore doesn't solve correctness, it abandons it. The two agree the review-everything defense is untenable and disagree on whether anything replaces it.

The nearest ally

claude-is-not-a-compiler (Josh Bleecher Snyder, July 2026) reaches the same place — own the design, don't read the lines — but arrives with a different method and a partial answer to the HN objection above. Rather than interrogating one model about its design to check his mental model, he builds the system several times with concurrent agent loops and diffs the results (differential-spec-analysis), on the grounds that the decisions worth catching are the ones the agent never asked about. The scar-tissue guidance document he accumulates is antirez's DESIGN.md proposal reached empirically rather than written up front. He calls the practice vibe-engineering and insists on the boundary antirez also draws: the engineer keeps the decisions, the agent only makes them cheaper to make.

Quotes worth keeping

If you control the ideas of your software, looking at the code itself is suboptimal and often pointless.

Nobody should anymore look at this code, but only at the ideas the code contains.

It may be a lot more useful if they learn some programming language and implement a small interpreter, a small database, an hash table and so forth.