<antirez>

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. 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).
翻翻这个博客的历史，有不少关于用 AI 编程的文章，其中几篇能追溯到 2024 年 1 月（比如这篇：https://antirez.com/news/140）。毕竟，我在编程界也算小有名气。我无需像那些拼命刷存在感的老头一样，非得赖在圈子里不可。我最近刚重返 Redis，现在又在开发一个用于本地 LLM 推理的开源软件，社区反响还不错。那我为什么还要继续干这种事——说些别人不爱听的话？为什么还要一个劲地宣布未来的编程方式会是什么样？因为我迫切希望能减轻那些比我更没准备好迎接这场变革的人所受的冲击，他们往往比我年轻，而且不像我，没预见到这么多事情要来（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, In 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. For the following reasons:
这就是为什么我昨天在 X 上说，我觉得不少程序员到了这个阶段，本该有更大影响力，却因为死盯着代码反而没发挥出来。我真的这么认为。注意，这可不是说要“凭感觉编程”随便让 AI 出个成品就行。关键点是：如果你掌控着软件的思路，那盯着代码本身往往是低效的，很多时候甚至毫无意义。原因如下：

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?
你现在能够生成大量代码了——哪怕不考虑 LLM 生成代码的冗余（大部分情况下这其实是因为你没把指令说清楚）。每天要你审查 5000 行代码，怎么搞？

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.
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.
工作日就 8 小时。如果你把时间花在读代码上，那是一种权衡。你花在当下工作中最重要部分上的时间就少了——也就是问问自己：我用这个软件在做什么？我想往哪个新方向走？同时还要思考新点子、新功能、优化技巧。以及做大量的 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. 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. 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?
控制想法。还记得《人月神话》里的这句话吗？一本 70 年代的书，比 2000 到 2020 年间无数言论更能揭示当下软件时代的真相。那些如今抗议 AI 的人，怎么过去十年对软件行业的糟糕状态无动于衷？AI 出现前那几年，我们触碰的垃圾程度简直难以置信。再跟你说件事：什么叫垃圾？我用 DwarfStar 完全自动化地实现了两个 LLM（DeepSeek v4 和 GLM 5.2）的推理，但你自己试试就会发现，光说“实现 XYZ”根本跑不起来。你得理解底层原理、最佳设计、如何达到特定性能。然后我把实现和其他系统做正确性对比，发现有些实现甚至错误更多。 我做了更深入的研究，发现本地推理领域到处是各种微妙的错误，它们层层叠加，最终损害模型的输出质量。注意力机制的实现也存在问题——一旦上下文超过某个阈值，性能就会明显下滑，因为索引式注意力实现是有缺陷的（比如做了超出必要的工作）。诸如此类的问题比比皆是。这归根结底是个极其复杂且快速迭代的领域，每天都有推理图略有差异的新模型发布。对开发者而言，这简直是一场不公平的游戏。不过嘛，AI 在这方面帮了大忙。很多领域里，严谨的工程设计加上测试，远比手写（或阅读）GPU 内核要高效得多。那我们真的能确定，大部分阻力不是来自意识形态上的偏见吗？

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. 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. 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 data structure is described in human language, with the ideas it contains, the implementation tricks, the design. That, in the future, is going to be much more useful. 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 lot more useful than reviewing the code.
Matteo Collina 昨天在我的推文下问我：“你不是说你会检查所有 AI 生成的 Redis 代码吗？”这确实是个好问题。没错，我确实在检查，但到了这个阶段，这已经变成了一件我*需要*做、却觉得基本没啥意义的事——尤其在 GPT 5.5 发布后就已经有点这种感觉，而现在有了 Fable 和 GPT 5.6 Sol 更是如此。是的：我能找出那些我不喜欢编码风格的地方，但如果我去翻看其他 Redis 贡献者写的代码，里面有*糟糕得多*的写法——不是因为他们水平不行，纯粹是审美差异。我习惯写非常干净的代码，因为我想让代码可读，所以在实现 Redis Arrays 时我动手做了修改。现在我又在做 Redis 有序集合节省 50%内存的优化，很快会提交 PR。但我觉得这事儿已经没以前那么有用了。今后没人该再去盯着这些代码看了，应该只看代码背后的思想。我之所以还在坚持，是出于对用户的尊重。Redis 现在已经是个常用工具，很多程序员会打开文件手动修改。但如果我能撒手不管，你知道我会怎么做吗？ 把审查占用的所有时间用来做更多 QA，思考下一个优化点子并落地，同时拿 LLMs 写一份 DESIGN.md 文件，用人类语言描述每个数据结构，包括它背后的思路、实现技巧和设计。将来再看，这可比单纯审查代码有用多了。想改 sorted sets？打开文件读一遍设计，你就能掌握核心想法。打开你的 agent，用正确的心智模型问它怎么搞。这比一行行复审代码强太多了。

Fable and GPT 5.6 reviews to the sorted sets memory saving are going to spot ways more errors and subtle race conditions that my review is going to uncover. Yet I’ll do it. But for the majority of software projects, all this does not make sense anymore. Focus on controlling the ideas, instead. Focus on quality, testing, and having an idea of the software you want to ship. The world changed and it is painful, but also full of opportunities to improve a software world that was already completely rotten.
Fable 和 GPT 5.6 对 sorted sets 内存优化方案的审查，能比我本人揪出更多错误和微妙的竞态条件。不过我还是会干。但对于大多数软件项目来说，这一套已经行不通了。不如把精力放在掌控想法上——质量、测试、以及对你想要交付的软件有清晰的认识。世界变了，虽然痛苦，但也充满机遇，让我们去改善那个早已腐朽不堪的软件世界。

I have a doubt only regarding young programmers that don't have enough experience, and can't build a mental model. We don't know, yet, if they will require or not to understand very well how a given piece of code works, but I believe they should learn how to write programs. Yet, I'm not sure checking the LLM output is the right thing they should do. 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. Reviewing some Javascript stuff of some web site for a customer? Hell, no, don't lose time with that shit.
我唯一担心的就是那些经验不足、还没建立起思维模型的年轻程序员。目前还不知道他们是否真的需要彻底搞懂某段代码的所有细节，但我坚信他们应该学会怎么去写代码。不过，我拿不准检查 LLM 的输出是不是他们该做的事。要是他们能学一门编程语言，自己动手写个小解释器、小数据库、哈希表之类的东西，那才叫真有价值。跑去给客户检查网站上的那堆 JavaScript？得了吧，别在这种破事上浪费时间。