---
source: 'https://howaiworks.ai/blog/antirez-control-the-ideas-not-the-code'
section: blog
title: 'Antirez: Control the Ideas, Not the Code'
description: >-
  Redis creator antirez says reading AI-generated code line by line wastes a
  programmer's day. What he proposes instead, and where the argument holds.
date: '2026-07-13'
author: HowAIWorks Team
tags:
  - antirez
  - Redis
  - AI Coding
  - Code Review
  - Agentic Coding
  - Software Development
  - Developer Tools
readingTime: 7 minutes
isReviewed: false
---

# Antirez: Control the Ideas, Not the Code

> Redis creator antirez says reading AI-generated code line by line wastes a programmer's day. What he proposes instead, and where the argument holds.

## 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](https://howaiworks.ai/blog/harper-reed-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](https://howaiworks.ai/glossary/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](https://howaiworks.ai/glossary/context-window) 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](https://howaiworks.ai/use-cases/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](https://antirez.com/news/169)
- [antirez, January 2024](https://antirez.com/news/140) — the earlier post on programming with AI
  that he points back to

## Frequently Asked Questions

### What is antirez's argument in 'Control the Ideas, Not the Code'?

Salvatore Sanfilippo (antirez), the creator of Redis, argues that when a programmer controls the design of a system, reading the generated implementation line by line is 'suboptimal and often pointless.' He proposes spending that time on architecture, testing and documented design decisions instead.

### Is he saying code review is dead?

He calls his own review of AI-generated Redis code 'something I need to do but that I believe to be mostly pointless,' continued out of respect for users rather than conviction. He also expects frontier models such as Fable and GPT 5.6 to catch more errors and race conditions in his current sorted-set work than his own review will.

### What is a DESIGN.md file?

A document written in human language that records each data structure, the ideas it contains, the implementation tricks and the design decisions. Antirez's idea: a maintainer opens it, owns the ideas, then points an agent at the code with the right mental model — instead of reading the implementation line by line.

### Does this advice apply to junior developers?

Antirez says this is the one point he is unsure about. He believes juniors should still learn to write programs by hand — 'a small interpreter, a small database, an hash table' — but doubts that reviewing an LLM's output on a customer's JavaScript teaches them anything.

### Is this the same as vibe coding?

No, and antirez says so directly: 'this does not mean to vibe code something just asking for the final product.' His own local-inference work is the counter-example — you cannot say 'implement XYZ' and watch it work; you have to understand the design, the performance target and the correctness bar. The design is what you control, not the prompt.

### What is the main risk in following this advice?

Design control only substitutes for code reading if you can actually verify the result. Without strong tests, benchmarks and observability, 'controlling the ideas' collapses into trusting the model, and subtle correctness bugs surface in production instead of in review.

---

Source: https://howaiworks.ai/blog/antirez-control-the-ideas-not-the-code — HowAIWorks.ai