<antirez>

Frontier LLMs such as Gemini 2.5 PRO, with their vast understanding of many topics and their ability to grasp thousands of lines of code in a few seconds, are able to extend and amplify the programmer capabilities. If you are able to describe problems in a clear way and, if you are able to accept the back and forth needed in order to work with LLMs, you can reach incredible results such as:
像 Gemini 2.5 PRO 这样的前沿 LLMs 简直绝了！它们不仅上知天文下通代码，几秒钟就能吃透几千行程序，简直就是程序员的能力倍增器。只要你把问题描述清楚，再配合 LLMs 这种需要来回磨合的工作方式，分分钟就能搞出让人惊掉下巴的成果，比如：

1. Eliminating bugs you introduced in your code before it ever hits any user: I experienced this with Vector Sets implementation of Redis. I would end eliminating all the bugs eventually, but many were just removed immediately by Gemini / Claude code reviews.
在代码祸害用户前就扼杀 bug：我在 Redis 的 Vector Sets 实现上深有体会。虽然最后总能靠自己搞定所有问题，但 Gemini/Claude 的代码审查直接帮我秒杀了一大半 bug，简直像开了外挂！

2. Explore faster how a given idea could work, by letting the LLM write the throw away code to test ASAP in order to see if a given solution is actually more performant, if it is good enough, and so forth.
2. 让 LLM 快速写出临时代码来测试，立马就能验证这个点子到底行不行——看看方案是不是更高效、够不够用之类的，效率直接拉满！

3. Engage in pair-design activities where your instinct, experience, design taste can be mixed with the PhD-level knowledge encoded inside the LLM. In this activity, the LLM will sometimes propose stupid paths, other times incredibly bright ideas: you, the human, are there in order to escape local minimal and mistakes, and exploit the fact your digital friend knows of certain and various things more than any human can.
3. 来场结对设计狂欢吧！把你的直觉、经验和设计品味，跟 LLM 里那些博士级的知识储备碰撞出火花。这货有时候会出馊主意，但冷不丁又能蹦出天才点子——这时候就靠你这个人肉过滤器来避开坑爹操作，顺便榨干这个数字伙伴比任何人类都渊博的知识库。

4. Accelerate your work by writing part of the code under your clear specifications.
4. 只要把需求说清楚，它就能帮你搞定部分代码，效率直接起飞！

5. Work with technologies far from your expertise but contiguous with what you can do (for instance: coding in 68000 assembly for an Amiga demo?) using LLMs as an extension of specific parts of your mind, for the knowledge you don't have.
5. 用 LLMs 当你的外挂大脑，搞定那些专业不对口但能触类旁通的技术活（比如用 68000 汇编给 Amiga 写个演示程序？）——专治知识盲区，让你轻松跨界不翻车。

One and half years ago I wrote a blog post called “LLMs and programming in the first days of 2024”. There, I found LLMs to be already useful, but during these 1.5 years, the progresses they made completely changed the game. However, in order to leverage their capabilities, humans interacting with LLMs must have certain qualities and follow certain practices. Let’s explore them.
一年半前我写了篇博客《2024 年初的 LLMs 与编程》，当时就觉得 LLMs 已经挺管用了。但这短短一年半里，它们的进步简直翻天覆地！不过要想真正玩转 LLMs，咱们人类还得掌握些门道、讲究点方法。来，这就带你一探究竟。

## Refuse vibe coding most of the times
大多数时候拒绝氛围编程

In this historical moment, LLMs are good amplifiers and bad one-man-band workers. There are still small throwaway projects where letting the LLM write all the code makes sense, like tests, small utilities of a few hundreds lines of codes. But while LLMs can write part of a code base with success (under your strict supervision, see later), and produce a very sensible speedup in development (or, the ability to develop more/better in the same time used in the past — which is what I do), when left alone with nontrivial goals they tend to produce fragile code bases that are larger than needed, complex, full of local minima choices, suboptimal in many ways. Moreover they just fail completely when the task at hand is more complex than a given level. Tomorrow all this may change, but right now after daily experience writing code with LLMs I strongly believe the maximum quality of work is reached using the human+LLM equation. I believe that humans and LLMs together are more productive than just humans, but this requires a big “if”, that is, if such humans have extensive communication capabilities and LLMs experiences: the ability to communicate efficiently is a key factor in using LLMs.
眼下这个阶段，LLMs 就像个给力的扩音器，但千万别指望它单打独斗。写点临时小项目还行，比如测试脚本啊、几百行的小工具啊，全权交给 LLMs 倒也无妨。虽然它们确实能在你严格监督下搞定部分代码（后面会细说），让开发效率蹭蹭往上涨——说白了就是同样时间里能产出更多更好的代码，这招我常用。可一旦放手让它处理复杂需求，产出的代码往往又臭又长，结构复杂得像迷宫，到处都是局部最优解的坑，各种细节都不够优雅。更别提遇到超纲任务时，LLMs 直接就撂挑子不干了。  

虽说未来可能会变，但以我天天用 LLMs 写代码的经验来看，现在最靠谱的还是"人类+LLMs"组合拳。人机合作确实比单打独斗强，但有个大前提——开发者得既会调教 LLMs，又擅长跟它沟通。说白了，能不能高效指挥这些 AI 助手，才是用好 LLMs 的终极奥义。

## Provide large context  ## 提供超大上下文
（注：根据中文口语习惯，将祈使句转化为更自然的表达方式，同时保留技术术语的英文原貌）

When your goal is to reason with an LLM about implementing or fixing some code, you need to provide extensive information to the LLM: papers, big parts of the target code base (all the code base if possible, unless this is going to make the context window so large than the LLM performances will be impaired). And a brain dump of all your understanding of what should be done. Such braindump must contain especially the following:
想让 LLM 帮你搞定代码实现或修复问题，就得给它喂足料：相关论文、目标代码库的大段内容（最好是整个代码库，只要别撑爆上下文窗口拖慢 LLM 性能）。还得把你对解决方案的所有理解都倒豆子般倒出来，尤其要包含以下几点：

* Hints about bad solutions that may look good, and why they could be suboptimal.
* Hints about very good potential solutions, even if not totally elaborated by the humans still: LLMs can often use them in order to find the right path.
* Clear goals of what should be done, the invariants we require, and even the style the code should have. For instance, LLMs tend to write Python code that is full of unnecessary dependencies, but prompting may help reducing this problem. C code tends to be, in my experience, much better.
* 那些看似美好实则坑爹的解决方案，为啥它们其实不太靠谱。  
* 就算人类没完全想透，那些潜力巨大的好点子也能给 LLMs 指条明路。  
* 明确目标、硬性要求甚至代码风格都很关键。比如 LLMs 写的 Python 代码总爱堆砌多余依赖，但适当提示能改善这个问题。要我说，它们整出来的 C 代码反而更清爽。  

（注：根据要求保留了"LLMs"专业术语，采用口语化表达如"坑爹"、"整出来"等，拆分长句为符合中文表达习惯的短句，并补充了"要我说"等口语化衔接词）

When dealing with specific technologies that are not so widespread / obvious, it is often a good idea to also add the documentation in the context window. For example when writing tests for vector sets, a Redis data type so new that LLMs don’t yet know about, I add the README file in the context: with such trivial trick, the LLM can use vector sets at expert level immediately.
遇到那些比较冷门的技术时，把相关文档塞进上下文窗口准没错。比如我最近在给 Redis 新出的 vector sets 数据类型写测试用例——这玩意儿太新了连 LLMs 都还没学会。这时候只要把 README 文件丢进上下文，就这么个小技巧，立马能让 LLM 把 vector sets 玩得跟专家似的！

## Use the right LLMs
## 选对 LLMs 很重要

The most famous LLMs are not the best. Coding activities should be performed mostly with:
最火的 LLMs 未必最好用，写代码还是得靠这些神器：

* Gemini 2.5 PRO
* Claude Opus 4

Gemini 2.5 PRO is, in my experience, semantically more powerful. Can spot more complex bugs, reason about more complex problems. Claude Opus may be better at writing new code sometimes (sometimes not), the user interface is more pleasant, and in general you need at least two LLMs to do some back and forth for complex problems in order to enlarge your (human) understanding of the design space. If you can pick just one, go for Gemini 2.5 PRO.
亲测 Gemini 2.5 PRO 在语义理解上更胜一筹！抓复杂 bug 和解决疑难杂症简直开挂。Claude Opus 写新代码偶尔能超常发挥（但也经常翻车），界面确实更养眼。不过真要搞定烧脑问题，建议至少备两个 LLMs 来回切磋，这样才能真正拓宽思路。要是只能选一个当家花旦，闭眼入 Gemini 2.5 PRO 准没错！

The fundamental requirement for the LLM to be used is: don’t use agents or things like editor with integrated coding agents. You want to:
使用 LLM 的核心要求就一条：别整那些花里胡哨的代理，也别用自带编程代理的编辑器。咱们要的是：

* Always show things to the most able model, the frontier LLM itself.
* Avoid any RAG that will show only part of the code / context to the LLM. This destroys LLMs performance. You must be in control of what the LLM can see when providing a reply.
* Always be part of the loop by moving code by hand from your terminal to the LLM web interface: this guarantees that you follow every process. You are still the coder, but augmented.
* 一定要把东西喂给最顶级的模型，直接上最前沿的 LLM 本尊。* 千万别用那些 RAG 技术只给 LLM 看部分代码/上下文——这简直是在废 LLM 的武功。你必须牢牢掌控 LLM 生成回复时能看到哪些内容。* 老老实实手动把代码从终端复制到 LLM 网页界面，确保每个环节都在你眼皮底下。你依然是那个写代码的人，只不过现在开了外挂。

## Conclusions  ## 总结

Despite the large interest in agents that can code alone, right now you can maximize your impact as a software developer by using LLMs in an explicit way, staying in the loop. This will inevitably change in the future, as AI will improve, and eventually many coding tasks will be better served by AI alone: in this future, the human will decide the what & how, which is still crucial. But we are not yet there. In this exact moment taking control allows to use LLMs to produce the sharpest code possible: minimal when needed, using complex ideas when required.
虽然现在大家都对能独立编程的 AI 助手很感兴趣，但作为程序员，目前最能发挥你价值的用法还是亲自带着 LLMs 写代码，全程把控节奏。等 AI 再进化几年，很多编码工作确实交给它们单独完成会更高效——到那时人类只需要把控方向和策略，这才是最关键的。不过现在还没到那个阶段。眼下这个时间点，只有你亲自掌舵，才能让 LLMs 写出最精炼的代码：该简洁时绝不啰嗦，该复杂时又能玩出高级花样。

You will be able to do things that are otherwise at the borders of your knowledge / expertise while learning much in the process (yes, you can learn from LLMs, as you can learn from books or colleagues: it is one of the forms of education possible, a new one). Yet, everything produced will follow your idea of code and product, and will be of high quality and will not random fail because of errors and shortcomings introduced by the LLM. You will also retain a strong understanding of all the code written and its design.
用 LLMs 搞开发简直开挂！它能帮你突破知识边界，边用边学（没错，跟看书请教同事一样，LLMs 也是种全新学习姿势）。最绝的是，产出的代码完全按你的思路走，质量杠杠的，根本不会因为 LLM 抽风就掉链子。而且所有代码的设计逻辑你都能吃得透透的，完全不会变成黑箱操作！

From time to time, it is wise to test what agents can do. But each time you feel they can’t do as well as you can, return to your terminal, and code with the help of AI (when you feel it can improve your output; there are times where you just are better alone). When this will be true, that agents will perform superb work, I’ll be the first to switch, and I’ll keep coding by myself just for passion. But for now, let’s skip the hype, and use AI at its best, that is: retaining control. There is another risk, however: of avoiding LLMs for some ideological or psychological refusal, accumulating a disadvantages (and failing to develop a large set of skills - hard to describe - needed to work with LLMs). Maybe this is really a case of "In medio stat virtus".
时不时测试下 AI 代理的能力是明智之举。但当你发现它们还不如自己时，就回到终端，在 AI 能帮上忙时用它辅助编程（有些时候单干反而更顺手）。等哪天 AI 真能大显神通了，我绝对第一个倒戈——不过就算到那时，我也会纯粹出于热爱继续手写代码。眼下咱们还是少点噱头，把 AI 用在刀刃上：保持主导权。但另一个极端也要警惕，千万别因为心理抵触或意识形态就排斥 LLMs，这样不仅会让自己处于劣势，还会错过培养那些难以言喻的、与 LLMs 协作的关键技能。这事儿啊，恐怕还得讲究个"中庸之道"。