Coding with LLMs in the summer of 2025

摘要

在2025年夏季，前沿大型语言模型（LLMs），如Gemini 2.5 PRO和Claude Opus 4，已成为程序员能力的重要延伸和放大器。作者Antirez指出，通过清晰的问题描述和接受与LLMs的反复互动，开发者可以取得显著成果，包括：在代码发布前消除引入的bug；通过LLM快速生成一次性代码来验证想法和性能；在人机协同设计中融合人类经验与LLM的博士级知识；根据明确规范加速代码编写；以及利用LLM的知识在不熟悉的领域进行编程。

然而，要充分利用LLMs的能力，人类开发者必须遵循特定的实践。首先，大多数情况下应拒绝“随性编码”（vibe coding），因为LLMs在处理复杂、非琐碎目标时，倾向于生成脆弱、冗余且次优的代码。它们更适合作为人类的放大器，而非独立的“一人乐队”。其次，提供大量上下文至关重要，包括论文、大部分目标代码库、人类对问题的理解（如潜在的坏方案、好的解决方案提示、明确的目标、不变性要求和代码风格），以及特定技术的文档。这能显著提升LLM的性能和专业水平。第三，选择合适的LLM模型，作者推荐Gemini 2.5 PRO（语义能力强，擅长复杂bug和问题推理）和Claude Opus 4（有时擅长编写新代码，用户界面友好），并强调应直接与最强大的模型交互，避免使用代理或RAG（检索增强生成）系统，以确保LLM获得完整上下文并保持人类对过程的控制。

作者总结道，尽管对能独立编码的AI代理兴趣浓厚，但目前最大化软件开发影响力的最佳方式是显式地使用LLMs，并始终保持人类在循环中。这种“人机协作”模式能产出最精炼、高质量的代码，使开发者在学习新知识的同时，保持对代码设计和实现的深刻理解。未来AI可能会独立完成更多编码任务，但目前人类的控制是确保代码质量和避免LLM引入错误的关键。同时，作者也警告不要因意识形态或心理原因拒绝使用LLMs，以免错失发展与LLMs协作所需技能的机会。

内容精简

LLMs对编程能力的增强

在2025年夏季，前沿大型语言模型（LLMs）已经展现出显著的能力，能够极大地扩展和增强程序员的潜力。作者Antirez通过其个人经验，详细阐述了LLMs在编程实践中带来的五大核心优势，这些优势共同构成了LLMs作为强大编程助手的价值所在。

首先，LLMs在消除代码缺陷方面表现出色。作者以Redis的Vector Sets实现为例，指出LLMs（如Gemini和Claude）能够在其代码提交给用户之前，立即识别并帮助修复他自己引入的许多bug。虽然最终他自己也能解决所有bug，但LLMs的即时代码审查能力显著加快了这一过程，将许多潜在问题在早期阶段就予以清除。这意味着开发者可以更自信地推进项目，减少后期调试和用户反馈的压力，从而提升开发效率和代码质量。LLMs通过其对代码逻辑和模式的深刻理解，能够发现人类在编写过程中可能忽略的细微错误或潜在的逻辑漏洞，充当了一个高效且不知疲倦的“数字审查员”。

其次，LLMs能够加速想法的探索和验证。当开发者有一个新的想法或解决方案时，LLMs可以迅速生成一次性（throwaway）代码，用于快速测试和验证。这使得开发者能够立即评估某个解决方案的性能、有效性或是否足够好。例如，如果需要比较两种算法的效率，LLM可以快速编写出测试框架和实现代码，让开发者在几分钟内就能得到初步结果，而无需投入大量时间手动编写这些验证性代码。这种能力极大地降低了实验成本，鼓励开发者更大胆地尝试新思路，从而加速创新和优化过程。它将“试错”的周期缩短到极致，让开发者能够更快地收敛到最佳方案。

第三，LLMs促进了人机协同设计。在这种模式下，人类程序员的直觉、经验和设计品味可以与LLM中编码的博士级知识相结合。LLM有时会提出看似愚蠢的路径，但有时也会提供令人难以置信的、极具启发性的想法。人类的角色是充当“守门员”，避免陷入局部最优解和错误，并充分利用LLM在特定领域（如算法、数据结构、最佳实践等）比任何人类都更广泛、更深入的知识。这种协作模式使得设计过程更加全面和富有创造力，人类可以从LLM的广阔知识库中汲取灵感，而LLM则在人类的指导下避免常见的陷阱。它将人类的批判性思维和LLM的生成能力完美结合，共同推动复杂系统的设计。

第四，LLMs能够根据明确的规范加速代码编写。在人类提供清晰、详细的规格说明后，LLMs可以承担部分代码的编写工作。这使得开发者能够将精力集中在更高层次的设计和架构上，而将具体的实现细节委托给LLM。例如，当需要实现一个遵循特定接口和行为的模块时，开发者可以提供详细的函数签名、输入输出要求和预期行为，LLM便能生成相应的代码骨架或完整实现。这种分工显著提高了开发速度，尤其是在处理重复性或模式化的编码任务时。它解放了开发者的时间，让他们能够投入到更具挑战性和创造性的工作中，从而在相同时间内完成更多或更好的开发任务。

最后，LLMs使得开发者能够在专业领域之外进行工作。LLMs可以作为人类思维特定部分的延伸，弥补开发者在某些知识领域的不足。例如，一个主要从事高级语言开发的程序员，可能需要为Amiga演示编写68000汇编代码。这通常需要专业的汇编知识和对特定硬件架构的理解。在这种情况下，LLM可以提供必要的汇编指令、编程模式和调试建议，帮助开发者在不具备深厚专业知识的情况下，也能完成这类任务。这种能力极大地拓宽了程序员的工作范围，使他们能够探索相邻但非核心的领域，从而实现更广泛的项目目标或满足特定的技术需求。它降低了进入新领域的门槛，促进了跨领域学习和技能拓展。

有效利用LLMs的关键实践

要充分发挥LLMs在编程中的巨大潜力，开发者必须采纳一系列特定的实践和方法。作者强调，LLMs并非万能的独立工作者，而是强大的放大器，其效能高度依赖于人类的正确引导和互动方式。

首先，大多数时候应拒绝“随性编码”（vibe coding）。在当前阶段，LLMs擅长作为人类能力的放大器，但在作为独立的“一人乐队”时表现不佳。虽然对于一些小型的一次性项目，如测试脚本或几百行代码的小工具，让LLM独立编写所有代码是可行的，但当面对非琐碎的复杂目标时，LLMs往往会生成脆弱、冗余、复杂且充满局部最优选择的代码库，并且在许多方面都是次优的。更甚者，当任务复杂性超过一定水平时，它们会完全失败。作者通过日常与LLMs编写代码的经验坚信，最高质量的工作是通过“人类+LLM”的组合方程实现的。这种组合比单纯的人类更具生产力，但这有一个重要的前提：人类必须具备广泛的沟通能力和与LLMs互动的经验。高效的沟通能力是利用LLMs的关键因素，因为你需要清晰地表达问题、需求和期望，并理解LLM的反馈。这意味着开发者不能仅仅将任务抛给LLM，然后期望它能完美地独立完成，而必须积极参与到整个开发循环中，进行监督、指导和修正。

其次，提供大量上下文是与LLMs有效交互的基石。当目标是与LLM就代码实现或修复进行推理时，开发者需要向LLM提供尽可能多的信息。这包括相关的研究论文、目标代码库的大部分内容（如果可能，甚至是整个代码库，除非上下文窗口过大导致LLM性能受损），以及人类对任务的全面理解（即“脑力倾泻”）。这种“脑力倾泻”尤其应包含以下几点：关于可能看起来不错但实际上是次优解决方案的提示，并解释其原因；关于非常有潜力的解决方案的提示，即使人类尚未完全阐述清楚，LLMs也常常能利用这些提示找到正确的路径；以及明确的任务目标、所需的不变性（invariants）和代码应遵循的风格。例如，LLMs倾向于编写包含不必要依赖的Python代码，但通过明确的提示可以帮助减少这个问题；而C语言代码在作者的经验中通常表现更好。此外，当处理不那么普遍或显而易见的技术时，将相关文档添加到上下文窗口通常是一个好主意。作者举例说明，在为Redis的Vector Sets（一种LLMs尚不了解的新数据类型）编写测试时，他会将README文件添加到上下文，通过这种简单的技巧，LLM能够立即以专家级别使用Vector Sets。提供丰富的上下文能够显著提升LLM的理解能力和生成代码的准确性与专业性。

第三，选择合适的LLM模型并正确使用至关重要。作者指出，最著名的LLMs并非总是最佳选择。对于编码活动，他主要推荐使用Gemini 2.5 PRO和Claude Opus 4。根据作者的经验，Gemini 2.5 PRO在语义上更强大，能够发现更复杂的bug，并对更复杂的问题进行推理。Claude Opus有时可能更擅长编写新代码（尽管并非总是如此），其用户界面也更令人愉悦。通常，为了解决复杂问题并拓宽人类对设计空间的理解，至少需要使用两种LLM进行反复的交互。如果只能选择一个，作者推荐Gemini 2.5 PRO。更重要的是，在使用LLM时，应避免使用代理（agents）或集成编码代理的编辑器等工具。开发者应该始终将任务展示给最强大的前沿LLM本身。同时，要避免任何可能只向LLM展示部分代码或上下文的RAG（检索增强生成）系统，因为这会严重损害LLM的性能。开发者必须完全控制LLM在提供回复时所能看到的内容。此外，作者强调要始终保持在循环中，通过手动将代码从终端移动到LLM的网页界面。这种手动操作确保了开发者能够跟踪每一个过程，从而保持自己作为“增强型程序员”的角色，而不是被动地接受AI的输出。

LLMs在编程中的未来与当前定位

尽管当前业界对能够独立编码的AI代理抱有巨大兴趣，但作者Antirez明确指出，在当下，作为一名软件开发者，最大化个人影响力的最佳方式是显式地使用LLMs，并始终保持人类在整个开发循环中。这意味着人类程序员是主导者，LLM是强大的工具和助手。

这种“人机协作”模式在当前阶段能够产出最精炼、最高质量的代码。当需要时，代码可以保持最小化；当需要复杂思想时，LLM也能提供支持。通过这种方式，开发者能够完成那些原本处于其知识或专业边界之外的任务，并且在过程中学到很多新知识。作者强调，从LLMs学习就像从书籍或同事那里学习一样，它是一种新的、有效的教育形式。更重要的是，通过人类的控制，所有产出的代码都将遵循开发者的代码和产品理念，保持高质量，并且不会因为LLM引入的错误和缺陷而随机失败。开发者也将对所有编写的代码及其设计保持深刻的理解和掌控。这种模式确保了代码的可靠性、可维护性和符合项目愿景。

作者承认，未来随着AI技术的不断进步，这种情况将不可避免地发生改变。最终，许多编码任务将由AI独立完成，届时人类的角色将更多地集中在决定“做什么”（what）和“如何做”（how）上，这仍然是至关重要的。然而，他强调“我们尚未达到那个阶段”。在当前这个精确的时间点，保持控制是利用LLMs产出最优质代码的关键。

作者建议，开发者应不时地测试AI代理的能力，但每当感觉它们不如自己做得好时，就应该回到终端，在AI的帮助下进行编码（仅当AI能提升产出时；有时独立工作会更好）。当AI代理真正能够出色地完成工作时，作者表示他将是第一个切换到完全由AI驱动的模式，而自己则只为兴趣而编码。但就目前而言，他呼吁大家跳过炒作，以最佳方式使用AI，即：保留控制权。

最后，作者也提出了一个潜在的风险：由于某种意识形态或心理上的拒绝，避免使用LLMs，从而积累劣势，并未能发展出与LLMs协作所需的一系列难以描述的技能。他认为这可能是一个“中庸之道”（In medio stat virtus）的案例，即在完全依赖AI和完全拒绝AI之间找到一个平衡点。这意味着开发者既不应盲目追随AI的独立代理，也不应固步自封，而是应该积极学习如何有效地与LLMs协作，从而在不断发展的技术环境中保持竞争力。

问答

LLMs目前在编程中主要有哪些应用？ LLMs目前主要用于：消除代码中的bug、加速想法的探索和验证、进行人机协同设计、根据明确规范加速代码编写，以及帮助开发者在不熟悉的领域进行编程。
为什么作者建议大多数时候要拒绝“随性编码”（vibe coding）？ 作者认为，LLMs在处理复杂、非琐碎目标时，倾向于生成脆弱、冗余、复杂且次优的代码，并且在任务复杂性超过一定水平时会完全失败。它们更适合作为人类的放大器，而非独立的“一人乐队”。最高质量的工作是通过“人类+LLM”的组合实现的。
在使用LLMs进行代码开发时，提供上下文的重要性体现在哪里？ 提供大量上下文（如论文、代码库、人类对问题的理解、潜在解决方案提示、明确目标、不变性要求和代码风格，以及特定技术文档）能够显著提升LLM的理解能力和生成代码的准确性与专业性，使其能够以专家级别处理特定任务。
作者推荐哪些LLM模型用于编程，并说明其理由？ 作者主要推荐Gemini 2.5 PRO和Claude Opus 4。Gemini 2.5 PRO在语义上更强大，擅长发现复杂bug和推理复杂问题。Claude Opus有时擅长编写新代码，用户界面更友好。作者建议至少使用两种LLM进行复杂问题的反复交互，如果只能选一个，则推荐Gemini 2.5 PRO。
作者对未来LLMs在编程中的发展持何种看法？ 作者认为未来AI将独立完成更多编码任务，届时人类将更多地决定“做什么”和“如何做”。但他强调目前尚未达到那个阶段，当前阶段人类保持控制是产出高质量代码的关键。
使用LLMs时，人类程序员应如何定位自己的角色？ 人类程序员应定位为“增强型程序员”，始终保持在开发循环中，对LLM进行监督、指导和修正。他们是主导者，LLM是强大的工具和助手，负责提供清晰的规范、大量的上下文，并对手动移动代码以确保控制。
使用LLMs有哪些潜在的风险或需要避免的误区？ 潜在风险包括：过度依赖LLM独立完成复杂任务导致代码质量下降；使用代理或RAG系统导致LLM无法获得完整上下文从而影响性能；以及因意识形态或心理原因拒绝使用LLMs，从而错失发展与LLMs协作所需技能的机会。

原文

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:

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.
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.
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.
Accelerate your work by writing part of the code under your clear specifications.
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.

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.

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.

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:

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.

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.

Use the right LLMs

The most famous LLMs are not the best. Coding activities should be performed mostly with:

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.

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:

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.

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.

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.

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”.

译文

Gemini 2.5 PRO等前沿大型语言模型（LLM），凭借其对众多主题的广泛理解以及在几秒钟内掌握数千行代码的能力，能够扩展和增强程序员的能力。如果你能清晰地描述问题，并且能够接受与LLM协作所需的反复沟通，你就能取得令人难以置信的成果，例如：

在代码触达任何用户之前，消除你引入的错误：我在Redis的Vector Sets实现中体验到了这一点。我最终会消除所有错误，但许多错误在Gemini/Claude的代码审查中就被立即移除了。
更快地探索某个想法的可行性，让LLM编写一次性代码进行快速测试，以便尽快了解某个解决方案是否确实更高效、是否足够好等等。
参与结对设计活动，将你的直觉、经验和设计品味与LLM中编码的博士级知识相结合。在此活动中，LLM有时会提出愚蠢的方案，有时则会提出令人难以置信的绝妙想法：你，作为人类，在那里是为了避免局部最优和错误，并利用你的数字朋友比任何人类都了解更多特定和多样事物的优势。
在你明确的规范下编写部分代码，从而加速你的工作。
利用LLM作为你思维特定部分的延伸，处理你专业领域之外但与你能力相邻的技术（例如：为Amiga演示编写68000汇编代码？），弥补你所缺乏的知识。

一年半前，我写了一篇题为“2024年初的LLM与编程”的博客文章。当时，我发现LLM已经很有用，但在过去的一年半里，它们取得的进步彻底改变了局面。然而，为了充分利用它们的能力，与LLM交互的人类必须具备某些特质并遵循某些实践。让我们来探讨一下。

大多数时候拒绝“凭感觉编程”

在这个历史时刻，LLM是优秀的放大器，但不是好的“单人乐队”工作者。对于一些小型的一次性项目，比如测试、几百行代码的小工具，让LLM编写所有代码仍然是合理的。但是，尽管LLM可以在你的严格监督下成功编写部分代码库（详见后文），并在开发中带来显著的速度提升（或者，在过去相同的时间内开发更多/更好的能力——我就是这样做的），但当它们独自面对非平凡目标时，它们往往会生成脆弱的代码库，这些代码库比实际需要更大、更复杂，充满了局部最优选择，在许多方面都不尽如人意。此外，当手头的任务复杂程度超过一定水平时，它们就会彻底失败。明天这一切都可能改变，但就目前而言，经过与LLM日常编程的经验，我坚信最高质量的工作是通过“人类+LLM”的等式实现的。我相信人类和LLM一起比单独的人类更具生产力，但这需要一个重要的“如果”，即如果这些人类拥有广泛的沟通能力和LLM使用经验：高效沟通是使用LLM的关键因素。

提供大量上下文

当你的目标是与LLM就实现或修复某些代码进行推理时，你需要向LLM提供大量信息：论文、目标代码库的大部分（如果可能的话，是整个代码库，除非这会使上下文窗口过大以至于损害LLM的性能）。以及你对应该做什么的所有理解的“脑力倾泻”。这种“脑力倾泻”必须特别包含以下内容：

关于可能看起来不错但实际上是糟糕解决方案的提示，以及它们为何次优。
关于非常有潜力的优秀解决方案的提示，即使人类尚未完全阐述：LLM通常可以利用它们来找到正确的路径。
关于应该做什么的明确目标、我们所需的不可变条件，甚至代码应有的风格。例如，LLM倾向于编写充满不必要依赖的Python代码，但通过提示可以帮助减少这个问题。根据我的经验，C语言代码往往要好得多。

在处理不那么普遍/显而易见的特定技术时，通常最好也将文档添加到上下文窗口中。例如，在为向量集（一种Redis数据类型，新到LLM尚不了解）编写测试时，我将README文件添加到上下文中：通过这种简单的技巧，LLM可以立即以专家级别使用向量集。

使用正确的LLM

最著名的LLM并非最佳。编程活动应主要使用：

Gemini 2.5 PRO
Claude Opus 4

根据我的经验，Gemini 2.5 PRO在语义上更强大。它能发现更复杂的错误，并对更复杂的问题进行推理。Claude Opus有时可能更擅长编写新代码（有时则不然），其用户界面更令人愉悦，而且通常你需要至少两个LLM来针对复杂问题进行反复沟通，以拓宽你（人类）对设计空间的理解。如果你只能选择一个，请选择Gemini 2.5 PRO。

使用LLM的基本要求是：不要使用代理或集成编码代理的编辑器等工具。你应该：

始终将内容展示给能力最强的模型，即前沿LLM本身。
避免任何只向LLM展示部分代码/上下文的RAG（检索增强生成）。这会损害LLM的性能。在提供回复时，你必须控制LLM能看到什么。
始终通过手动将代码从你的终端移动到LLM网页界面来参与循环：这确保你跟踪每一个过程。你仍然是编码者，但得到了增强。

结论

尽管人们对能够独立编程的代理兴趣浓厚，但目前你可以通过明确地使用LLM并保持在循环中，来最大化你作为软件开发人员的影响力。未来，随着AI的进步，这种情况将不可避免地改变，最终许多编码任务将由AI独立完成：在那个未来，人类将决定“做什么”和“如何做”，这仍然至关重要。但我们尚未达到那个阶段。在当下，掌控权允许我们使用LLM生成最精炼的代码：在需要时极简，在必要时运用复杂思想。

你将能够完成那些原本处于你知识/专业边界之外的事情，同时在此过程中学到很多（是的，你可以从LLM学习，就像你可以从书籍或同事那里学习一样：这是一种可能的教育形式，一种新的形式）。然而，所有生成的内容都将遵循你对代码和产品的理念，并且质量高，不会因为LLM引入的错误和缺陷而随机失败。你还将对所有编写的代码及其设计保持深刻的理解。

时不时地，测试一下代理能做什么是明智的。但每次你觉得它们做得不如你时，就回到你的终端，在AI的帮助下编程（当你觉得它能提升你的产出时；有时你独自工作会更好）。当代理真的能出色完成工作时，我将是第一个切换的人，我将仅仅出于热情而继续自己编程。但就目前而言，让我们跳过炒作，以最佳方式使用AI，即：保持控制。然而，还有另一个风险：出于某种意识形态或心理上的拒绝而避免使用LLM，从而积累劣势（并且未能发展出一套与LLM协作所需的难以描述的大量技能）。也许这确实是一个“中庸之道”的案例。