Control the ideas, not the code

Control the ideas, not the code 掌控思想，而非代码

Look at the past history of this blog. There are many blog posts about programming with AI, a few of them date back to January 2024 (like this: https://antirez.com/news/140). I’m a relatively well regarded programmer, after all. I don’t have the need to still be in the “loop” as a old man that seeks for relevance, I recently rejoined Redis, and now I also am developing a new open source software for local LLM inference that received a good welcome in the community. 看看这个博客的过往历史。有很多关于 AI 编程的博文，其中一些可以追溯到 2024 年 1 月（比如这篇：https://antirez.com/news/140）。毕竟，我是一位相对受人尊敬的程序员。作为一个寻求存在感的老人，我没必要非得挤进“圈子”里。我最近重新加入了 Redis，现在也在开发一款新的本地大模型推理开源软件，并受到了社区的好评。

Why I keep doing this, of saying what people don’t want to hear? Why I keep announcing how future programming will be by default? Because I feel the urge of lowering the impact for people less prepared to the change than me, often younger than me, and that, unlikely me, didn’t see many of those things coming (In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe will happen, so I feel like I can say this without sounding egocentric). 为什么我还要坚持这样做，去说那些人们不想听的话？为什么我还要不断预告未来的编程模式会是什么样？因为我感到一种紧迫感，想要减轻那些准备不足的人所受到的冲击——他们往往比我年轻，而且不像我那样预见到了许多事情的发生（在 2022 年，也就是 ChatGPT 问世之前，我出版了一本书，预告了许多现在已经发生以及我认为“将会”发生的事情，所以我认为我这样说并不显得自负）。

So mine is a trick. People feel more and more programming is completely modified by AI and don’t know what they should do, if they can really start coding in a completely different way, without looking much at the code as their main output. They feel like they are betraying their own field. So my intention is to arrive and say “look at me, I can write code, you know, I’m not hiding behind AI: yet, things changed, it’s not your weakness, it’s not that you are AI-pilled. It is just that our field is evolving in an incredible and painful (but also joyful) direction”. 所以，我这是在用一个小技巧。人们越来越觉得编程被 AI 彻底改变了，他们不知道该怎么办，不知道是否真的可以开始用一种完全不同的方式编程，而不必把“代码”本身作为主要产出。他们觉得这背叛了自己的领域。所以我的意图是站出来说：“看看我，我也会写代码，我并没有躲在 AI 背后：但事情确实变了，这不是你的软弱，也不是你被 AI 洗脑了。只是我们的领域正在朝着一个不可思议且痛苦（但也充满乐趣）的方向演进。”

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. And note that this does not mean to vibe code something just asking for the final product. The point is: if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. 这就是为什么昨天我在 X 上说，我相信许多程序员现在的影响力远低于他们本可以达到的水平，因为他们太关注代码了。我对此深信不疑。请注意，这并不意味着仅仅通过“凭感觉”去要求 AI 生成最终产品。重点是：如果你掌控了软件的思想，那么盯着代码本身看往往是次优的，甚至毫无意义。

For the following reasons: 1. You can now generate a lot of code, even not accounting for the LLM code verbosity (that is also effect of not being able to instruct them well, for most of the part). How are you supposed to review 5k lines of code every day? 2. LLMs are very good at writing locally optimal code, and are worse (but improving) with big ideas. What’s the point of scanning function by function, line by line? Instead you should prompt the design you have in mind, sometimes ask “how is exactly the design of that part? How does it work?”, and evaluate if it is the right model. It is much faster. 原因如下：1. 你现在可以生成大量的代码，甚至还没算上 LLM 生成代码的冗余（这在很大程度上也是因为你无法很好地引导它们）。你每天怎么可能审阅 5000 行代码？2. LLM 非常擅长编写局部最优的代码，但在处理宏观构思时表现较差（尽管正在改进）。逐个函数、逐行扫描代码有什么意义呢？相反，你应该提示你脑海中的设计，有时问问“那部分的设计究竟是怎样的？它是如何工作的？”，并评估它是否是正确的模型。这要快得多。

3. 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. Controlling the ideas. Do you remember this phrasing from the Mythical Man Month? Well, a book from the 70s tells us more things about the current software era than many of the things that were said from 2000 to 2020.
4. 工作日只有 8 小时。如果你把时间花在读代码上，这就是一种权衡。你做得越少，就越偏离了今天工作中最重要的部分，即问自己：我用这个软件在做什么？我想采取什么新方向？此外，还要思考新的想法、功能、优化技巧，并进行大量的质量保证（QA）。掌控思想。还记得《人月神话》里的这个说法吗？嗯，一本 70 年代的书告诉我们关于当前软件时代的道理，比 2000 年到 2020 年间说的许多话都要深刻。

Why people that now protest against AI were not horrified by the state of software in the last decade? The level of slop we touched during recent years, before AI, is unbelievable. I’ll say you another thing. What is slop? With DwarfStar I implemented an inference for two LLMs (DeepSeek v4 and GLM 5.2) in a completely automated way, but: 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. 为什么现在抗议 AI 的人，在过去十年里没有对软件的现状感到恐惧？在 AI 出现之前，我们近年来接触到的“垃圾代码”（slop）水平简直令人难以置信。我再告诉你一件事。什么是“垃圾代码”？在开发 DwarfStar 时，我以完全自动化的方式实现了两个 LLM（DeepSeek v4 和 GLM 5.2）的推理，但是：你自己试试就会发现，你不能仅仅说“实现 XYZ”就能看到它运行。你必须理解事物是如何运作的，什么是最好的设计，以及如何达到一定的性能水平。

Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations are broken (do more work than they should, for instance), and so forth. This is the result of a domain that is very complicated to handle, fast changing, with models that are slightly different one from the other in the inference graph being released every day. It’s an unfair game for developers. 然后，我将我的实现与其它系统的正确性进行了比较，发现其它实现有时包含更多的错误。我深入研究后发现，本地推理领域充满了细微的错误，这些错误会累积并损害模型输出；例如，注意力机制实现中的问题会导致上下文超过一定限制后性能急剧下降，因为索引注意力实现是有缺陷的（例如，做了不必要的工作），等等。这是一个非常复杂、变化极快且每天都有推理图略有不同的模型发布的领域。这对开发者来说是一场不公平的游戏。

Well: AI helps a lot with that. There are many domains where rigorous engineering (in the design side) and testing is far better than writing a GPU kernel by hand (or reading it). So are we sure most of that resistance it is not ideological? Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. 好吧：AI 在这方面帮了大忙。在许多领域，严谨的工程设计（在设计层面）和测试远比手写（或阅读）GPU 内核要好得多。所以，我们确定大部分的抵制不是出于意识形态吗？Matteo Collina 昨天在回复我的推文时问我：但你不是说你会检查 Redis 的所有 AI 生成代码吗？这确实是一个好问题。

Yes, I do, but this is, at this point, something I need to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. 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. I write very clean code since I want it to be readable, so during the implementation of Redis Arrays I operated changes. I’m doing it again for the 50% memory saving optimization of Redis sorted sets, a PR that I’ll submit soon. 是的，我确实在检查，但这在目前看来是我“不得不做”的事情，但我认为这大部分是毫无意义的。在 GPT 5.5 发布后我就有这种感觉，而现在有了 Fable 和 GPT 5.6 Sol，这种感觉更强烈了。是的：我确实能挑出我不喜欢的代码写法，但如果我打开其他 Redis 贡献者写的其它 Redis 文件，情况要糟糕得多——这并不是因为他们不是优秀的程序员，而是因为这纯属个人品味问题。我写代码非常整洁，因为我希望它具有可读性，所以在实现 Redis Arrays 时我做了修改。我正在为 Redis 有序集合的 50% 内存节省优化再次这样做，这个 PR 我很快就会提交。

But I do not feel this is useful anymore. Nobody should anymore look at this code, but only at the ideas the code contains. I continued to do it out of respect for users. Redis is at this point a commonly useful thing, and many programmers will open files and modify stuff by hand. But if I had my hands free, you know what I would do, instead? Use all the time that the review is taking me to do more QA, to think at the next optimization idea and apply it, and to use LLMs to write a DESIGN.md file where each dat 但我不再觉得这有用了。没有人应该再盯着代码看，而应该只关注代码所包含的思想。我继续这样做是出于对用户的尊重。Redis 目前是一个通用的工具，许多程序员会打开文件并手动修改内容。但如果我能腾出手来，你知道我会做什么吗？我会把审阅代码所花费的所有时间用来做更多的 QA，思考下一个优化点并将其应用，并利用 LLM 编写一份 DESIGN.md 文件，其中每个数据……