原来，摔断胳膊也是一件幸事......
当事人表示，「我再也不想回到过去了」。
这是为何？
事情是这样的，几个月前，Claude工程师Erik Schluntz骑车上班的路上，意外摔断右手，打上了石膏。
为了生计，他不得已用左手打字。
即便如此，Schluntz依旧在Anthropic旧金山的办公室里，一周狂肝了3000行代码。
为AI编码点赞
谁也不曾想，这背后竟是AI立了大功。
他通过结合语音转文字技术，与Claude AI结队，整整写了2个月的代码。不过，必须承认的是，其中有许多是「样板代码」。
为此，Schluntz还撰写了一篇长文，题为——AI替代了我的右手。
文章中，他表示，「通过这件事，体验到了人类几乎不再需要自己编写代码的未来」。
老实说，我爱上了这种感觉。
另一位Anthropic工程师表示，通过从这件事，我们可以获得软件工程未来几年的关键一瞥。
即使右手不能使，AI是完全可以让你成为一个10倍程序猿。
那么，Erik Schluntz如何在受伤期间，能够让AI为他高效编码呢？
初始设置
首先，文章开篇他最先介绍了，自己如何对AI进行设置，最终决定使用了Claude AI。
Schluntz在摔断手之前，也曾使用类似Copilot等AI代码生成工具，但主要还是「手写」。
2105年哈佛硕士毕业，Cobalt机器人公司创始人、Anthropic AI技术研究员
此外，他也使用过「语音转文字」，但也主要在手机上发短信，并未在电脑中尝试过这一功能。
好在，Mac内置语音控制在NLP处理上非常出色。
唯一不足的是，在听写任何与代码相关的内容时，Siri表现得很糟糕。毕竟，一些符号和词汇，大大超出其识别范围。
就比如：
Schluntz：Eval
Siri：Eval？你想说的是Evil吗？
当然，目前有一些专门针对代码的优秀语音转文字系统，比如Talon。
但由于Schluntz对AI代码生成非常感兴趣，于是决定尝试，用自家AI去完成这项艰巨的任务。
这里没有使用Copilot，是因为其自动补全功能，对作者来说异常慢，需要开发者先写出半行代码，才能实现。
毕竟摔伤了一只手，「动嘴」还是比「动手」快。
这时，只需将大块代码库内容一键复制粘贴到Claude AI中，然后通过语音命令进行转换。
举个栗子，Schluntz会说「重构ABC函数以接受输入XYZ」或「为这些新函数ABC编写单元测试，并查看XYZ的示例测试」。
虽然Claude并不总是能在第一次尝试时成功，但它能很好地接受后续指令和调整——
「我感觉就像是，和AI进行『结对编程』，而由另一个人操作键盘」！
调教Claude
「被迫」这样写代码后，Schluntz很快就弄清楚了，什么样提示会生成有效代码，什么会是无效。
有时候，它非常神奇，但有时候，就连作者本人恨不得把电脑扔出窗外。
他不得不在IDE和Claude之间频繁地复制粘贴，并手动拼接被Claude输出长度限制截断的代码片段。
甚至，有几次他对Claude「提高了嗓门」，只因AI「忘记了」Schluntz之前的指令。
接下来，就看看Schluntz如何调教的Claude。
要具体，并举例说明
如果你只给出一个基本请求，LLM可能会给出一个中规中矩的通用答案，可能并不适用于你的特定代码库。
这时， 就需要给出「非常明确的指令」，来获得更优的结果。
比如，详细说明你期望的输入和输出，使用哪些库等。
Schluntz发现，将指令放在输入的开头和结尾效果最好，可以确保AI不会「遗忘」重要的上下文。
最好是，能够提供代码库示例，供AI参考。特别是，在编写单元测试、处理样板代码时，AI表现特别好。
通过示例，AI还可以学习如何使用代码库中的内部工具函数。
这当中，迁移和重构，是最完美的应用场景。
Schluntz会手动迁移一个实例，然后用它作为示例让Claude转换其余的输入。
通过这种方式，他可以快速重构大约3,000行代码。
让Claude掌舵
大多数人把LLM当作StackOverflow的替代品：他们虽是在询问方向，但仍然自己在驾驶。
Schluntz则反其道而行之。
「如果你能够给Claude正确的基础构建模块，它往往可以一次性完成整个任务」。
在周末的机器人项目中，Schluntz和朋友Survy给Claude提供了一段控制单个电机和读取蓝牙游戏手柄的代码。
通过这些构建模块，Claude能够一气呵成地编写出所有远程控制机器人的代码，节省了大量时间和繁琐的数据处理！
令人惊讶的是，这与常见的建议完全相反，即一次只向LLM提出一个问题。
尤其是，在Schluntz不熟悉的领域，Claude往往在任务分解方面表现得尤为出色。
过于具体的请求也能奏效，但有时会导致失去整体视角，类似于在没有整体背景的情况下，给出狭隘的建议。
RTFM == Read This For Me
电机控制器，有一份100页的说明书，内容繁琐且复杂。
但Schluntz和Survy将其上传到Claude，然后提问，迅速解决了其中一个问题。
在以前，这可能需要一个小时的仔细阅读，并查找相关术语和教程。
机械同理心
「你不需要成为工程师才能成为赛车手，但你必须拥有机械同理心。」
——三届F1世界冠军Jackie Stewart
渐渐地，Schluntz开始建立起一种非常好的直觉，Claude能正确处理哪些事情，以及哪些事情仍需要人类做。
了解这种区别，让他在两个方向上都避免了很多挫败感。
Schluntz学会了哪些地方可以进行简化处理：
- 「我正在使用一个名为pygame的Python库……」 简化为 「在pygame中……」
- 「当我运行你的代码时，我收到了这个错误信息……你认为我现在应该怎么做」 简化为直接复制堆栈追踪（stack trace）。
他甚至还学会了，转换或重构大块代码可以带来显著效果。例如，在每一行之间添加计时器（timing instrumentation）。
另一方面，Schluntz学到如果一个LLM在两次尝试中，无法修复一个错误，那么它永远也不能修复。这时就需要自己动手了。
他还对Claude可能会犯的错误，有了很好的直觉。
有一次，Claude给了一段代码，它循环遍历motor1, motor2, motor2, motor4，遗漏了motor3。
作者的朋友注意到这一点，并说 「这一定是幻觉」！但Schluntz能感觉到，「Claude绝不会犯这种错误」。
果然，当他们检查输入时，发现这个错误确实存在于最初放入Claude的原始代码中。
为自己构建临时工具
当Schluntz带着机器人绕着后院转了一圈后，它输出了一份包含GPS坐标和其他数据的CSV文件。
他想检查这些数据与实际情况的准确性，但并没有很高效的方法，要弄清楚如何查看和分析这些GPS坐标可能需要一个小时。
甚至，他可能会手动在手机上检查GPS坐标，用眼睛死死盯着这些数字，害怕漏掉其中一行。
这次，Schluntz将CSV文件的前两行提供给Claude。
它立即生成了一个网页APP，可以在卫星图像上渲染上传的GPS坐标CSV文件！
拥有恰好符合我需求的完美调试工具，而不用依赖print语句或预先构建的可视化工具，彻底改变了局面。
AI让软件开发变得如此便宜，以至于它可以为特定任务创建一次性工具！
总的来说，这些经验和教训让Schluntz在使用AI写代码时，变得更高效！
没有AI工具，这就像是放弃编译器，改为手写汇编语言一样。
未来会怎样？
在文章的最后，Schluntz将AI编程划分为三个阶段：
过去1-2年
过去的几年里，AI在软件工程中的最大用途是，在IDE中使用Copilot自动补代码，或是通过ChatGPT查询代码知识（以往需要去StackOverflow寻找答案）。
以及，通过一些智能体，在没有人类监督情况下辅助编程，执行多个步骤，但这些并不实用。
今年
2024年，这三个领域都在发生变革。
诸如Zed、Cursor和各种VSCode扩展这样的IDE，深入地整合了大模型，拥有更完美的上下文，还能处理更大块的代码生成。
Claude Artifacts、ChatGPT的Data Analyst取代了Jupyter Notebook。它们已经成为作者的原型开发工具，和一次性代码的首选解决方案。
最后，一批如Cognition、Factory、CodeGen等智能体初创公司，正在端到端地自动化某些工作流程。
未来1-3年
Schluntz认为，未来1-3年，会出现真正的「AI工程师」。
也就是说，这三个领域可能会融合成一个产品——「AI工程师」，一个可以在自主模式和同步模式之间连续工作的系统：
1. 自主模式适用于范围明确的任务
AI将完全独立工作，具备编写和运行代码、使用外部工具、搜索网络信息、访问内部文档以及从过去错误中学习的能力。它会不断迭代任务，直到完成或遇到瓶颈。这将占据80%的工作量。
2. 配对编程模式适用于最难的任务
人类将在高层次上指导AI，而AI负责处理低层次的实现细节。互动将是高度多模态的，人类和AI将在文本描述、视觉图表、口头讨论和直接操作彼此代码之间无缝切换。你可能会共享屏幕，让AI跟随并给出建议和意见，或者AI共享它的屏幕，而你在它操作时给予指导。
除此之外：
- AI工程师将拥有与你作为员工时相同的所有背景信息和知识
AI将连接到公司的知识库，访问你的设计文件和客户访谈记录。无论是自主操作还是与人类配对，AI都能在需要时无缝地提取这些信息以做出决策。
- AI工程师将是主动的而不是阿谀奉承的
如果你提出一个设计建议，AI会提供用户访谈记录，并提出更好的建议。
AI工程师将为其工作中的简单和可预测部分派遣更便宜的子智能体，从而降低计算成本和延迟。就像你可以浏览日志文件而不必逐字阅读一样。
在Schluntz看来，AI工程师在特定方面将比大多数人类工程师更聪明，但有时会缺乏常识或者需要重新集中注意力并接受指导。
实际上，这与今天经理和产品经理与工程师合作的方式并没有太大区别。
我们还需要工程师吗？
正如计算器的发明并没有让会计师失业，而是提升了他们的工作，使他们能够在更高的抽象层次上进行思考。
会计师仍然需要知道如何做数学运算和理解计算，但像计算器和电子表格这样的工具使他们能够创造比以前更多的价值。
类似的，AI也会降低创建软件的门槛，就像任何人都可以使用Excel做个人会计一样。
学生们可以在宿舍里启动完整的应用程序和业务，小型工作室也可以为自己创建量身定制的软件工具。
这时，创造力将会是唯一的瓶颈。
人类工程师不会消失。
我们仍然需要在高层次上进行优先级排序，理解问题的整体架构和范围，并审查AI的工作，尤其是在系统变得更大时。
不同的是，我们将会把更多的时间花在思考构建什么上，而不是重复性地考虑「如何」构建。
如今，Schluntz已经摆脱了石膏的「束缚」，但他依然会将大部分代码交给Claude去写。
软件工程的未来
巧合的是，Cognition AI的总裁Russell Kaplan昨天也发表了长推，预测在AI越来越擅长写代码的时代，软件工程行业将如何发展。
Congnition AI正是第一个AI软件工程师Devin的开发商。
在Kaplan看来，研究实验室将对下一代模型的编码和推理进行更多改进。很快，模型在编程上就会变得非常出色。
为什么呢？
除了通用人工智能的进步外，编程还有一个独特的优势：通过「自我对弈」实现超越人类的数据扩展潜力。
模型可以编写代码，然后运行它；或者编写代码，编写测试，并检查一致性。
这种类型的自动监督在大多数领域是不可能实现的，因为我们在接近人类专业知识极限时，面临着后训练的数据壁垒。而代码不同——它可以通过经验和自动化进行测试。
因此，软件工程在几年内将会发生根本性的变化。
真正的编码智能体将能够完成端到端的任务，并与今天的AI Copilot相辅相成。
在这个新世界中，每个工程师都将成为工程经理，并配有一支由智能体组成的实习生大军。
工程师只需将把基本任务委派给编码智能体，然后就能把更多的时间花在解决更高层次的问题上：理解需求、架构系统以及决定构建什么。
这将引领我们进入一个前所未有的软件繁荣时代。
很快，曾经难以开发且成本高昂的软件将变得更加易于获取（提高10倍），「一次性软件」也将会大量涌现。
未来的软件工程师将比现在多得多，只是工作方式会有很大不同：更多的自然语言，以及更少的样板代码。
当然，对于这种变化，工程师们很快就能够适应，就像他们从汇编语言过渡到Python时一样。
除了直接的生产力提升之外，这还会对初创公司产生实质性的「二阶效应」。
首先，面向开发者的公司也将针对编码智能体进行「营销」。毕竟，你的智能体会决定使用哪个云服务和选择哪个数据库。
曾经作为优先考虑的用户友好CLI，将转变为智能体友好的UI/UX界面。
产品质量的门槛也将提高。在开发者能够更快交付的世界中，半成品或功能不完整的MVP将不再被接受。
随着编码智能体的兴起，测试基础设施将变得更加重要和普及。因为编码智能体会编写更多的测试，同时也会依赖这些测试来检查他们的工作。
随着智能体使代码迁移变得更容易，转换成本将不再是科技公司的护城河。公司甚至将智能迁移助手与产品进行捆绑销售，来简化使用流程。
无论具体情况如何，总体趋势是明确的：现在是成为开发者的最佳和最高效的时代。
