研究发现AI工具使资深程序员效率降低19%，但这并非最有趣的发现……
这篇报告研究了2025年初AI工具对经验丰富的开源开发者的生产力影响，通过随机对照试验（RCT）得出了一些出人意料的结论。以下是主要发现和总结：
主要发现
- AI工具并未提高生产力，反而降低了效率
- 开发者预期AI工具能将任务完成时间缩短24%，但实际使用后，任务完成时间增加了19%。
- 这一结果与经济学和机器学习专家的预测（分别预期缩短39%和38%）形成鲜明对比。
- 研究设计与方法
- 参与者：16名经验丰富的开源开发者，平均在目标项目中有5年经验。
- 任务：246个真实开源项目任务，平均耗时2小时。
- 工具：主要使用Cursor Pro（代码编辑器）和Claude 3.5/3.7 Sonnet（AI模型）。
- 数据收集：通过屏幕录制、开发者自我报告时间和专家预测等多渠道分析。
- 时间分配变化
- 使用AI时，开发者花更少时间主动编码和阅读代码，更多时间用于提示AI、等待AI生成输出以及审查AI生成的代码。
- 影响因素分析
- 直接生产力损失：开发者高估AI的实用性，导致过度依赖AI工具。
- 开发者熟悉度：高熟悉度的开发者在熟悉任务中AI的帮助有限。
- 项目复杂性：大型复杂代码库中AI表现较差。
- AI可靠性：开发者仅接受44%的AI生成代码，且需花费大量时间审查和修改。
- 隐性知识：AI缺乏开发者对代码库的隐性知识，限制了其有效性。
- 其他潜在因素
- 实验设计可能影响结果，但分析表明这些因素并非主要驱动力。
- 开发者可能在AI辅助下扩大任务范围，但数据显示这种影响不显著。
讨论与启示
- 现实与预期的差距：尽管AI在基准测试中表现优异，但在实际复杂任务中可能不如预期高效。
- 适用场景：结果可能不适用于小型或新项目，或开发者不熟悉代码库的情况。
- 未来改进：提升AI的可靠性、减少延迟、优化提示策略或针对特定代码库微调可能改善效果。
结论
研究表明，当前AI工具在经验丰富的开发者处理复杂任务时可能降低效率，这与广泛预期相反。这一发现强调了在实际环境中验证AI工具效果的重要性，而非仅依赖实验室测试或专家预测。未来的研究可以探索如何优化AI工具以更好地支持高技能开发者。
我在微软工作(直到第二年)。推动使用人工智能的举措简直荒谬。我不得不使用人工智能来总结设计师制作的文档，因为他们使用人工智能来制作这些文档，结果文档内容冗长且缺乏重点。此外，尝试使用人工智能进行编码感觉是在浪费时间。总之，依我之见，人工智能只能作为一个需要不断验证的垃圾搜索引擎。
啊，是的，将大语言模型(LLMs)作为反向自编码器使用，这是一个经典做法。
这就是未来：大语言模型(LLM)作为人与机器、机器与机器、机器与人的交流协议。
例如，你使用大语言模型(LLM)来帮助填写许可证申请，描述你打算对你的房产进行的新增建设。市政府官员没有时间阅读它，所以他使用另一个专门用于此任务的大语言模型(LLM)来总结它。
我们只是在交换无人阅读的冗长文字。
不用了，我拒绝。
让我想起《真实天才》中的教室蒙太奇场景(https://www.youtube.com/watch?v=wB1X4o-MV6o)。
我不知道这是否是一种新的社会工程攻击手段。如果你知道你的重要文件将被<流行的 AI 工具> 摘要，你会撰写一些与文本字面意思不同的摘要吗？“我给你发送了 X，你批准了它” “大语言模型(LLM) 告诉我你说过 Y” 这样的法庭案件可能会很有意思。
与人际沟通相比，这太过低效且不经济。到那时，它显然会与实际商业利益相悖，最终会被淘汰。
真是浪费电
“我重新混音了一个混音，结果又恢复了正常。”
米奇·赫德伯格(Mitch Hedberg)确实超前于时代。
哈哈，没错
狗永远处于俯卧撑姿势。
我在一家大型公司工作，我们本财年的目标就是尽可能多地使用人工智能，我敢肯定这也是他们拒绝增加人手的原因之一。
这似乎是如今所有科技公司的惯用手法。
我工作的地方也是这样。
看到微软如此缺乏领导力，真是令人悲哀，他们不应该被视为美国政府托付的软件开发良好管理者。
自吮冰淇淋锥到底
没错，换句话说，phind.org或许能帮你节省几秒钟，但实际上，如果你拥有一个功能强大的网页浏览器、uBlock Origin插件和基本的判断力，你最好直接使用谷歌、Startpage或DDG。
除非你直接从有针对性的广告和/或出售这些服务中通过激进的遥测获得用户数据中获利，否则所有这些人工智能大语言模型(LLM)的东西都是无用的(而且对消费者，包括软件工程师来说是有害的——自我破坏)。
这是 25 年后的 oliverbot，只是更赚钱罢了。
是的，大语言模型(LLMs)更像是一种玩具，而不是工具。你可以用它们做一些有趣的把戏，但它们对经验丰富的专业人士的实际应用总是有限的。
我发现“这个代码库中有这个功能吗”这样的查询非常有用。
是的，基本上是一个特定的搜索引擎。
Copilot的公开版本似乎还远不及某些产品。它不会编写测试、构建并修复它们，也不会持续迭代。它不会调用文档或包含规划阶段等功能。
这可能是问题的一部分。此外，如果Copilot仍在使用OpenAI技术，那要么速度较慢，要么使用了较差的模型。
OpenAI 仍在使用 Nvidia 作为其技术栈，因此速度大约是某些我使用过的实现方案的 10 倍慢。
不知道，我也在业余时间使用 Sonnet 帮助编码、ChatGPT 等。它们都存在相同的问题，如果需要具体功能而非“我不知道如何做这个基本操作”时，它们都是垃圾。
你试过Warp吗？我认为它更接近我们内部使用的工具，尽管我们也有一个完整的IDE。AI需要能够理解代码、编写测试、构建并运行测试，以便迭代解决问题。
此外，它还需要能够启动代理、创建任务。与源代码控制系统配合，找出问题所在并合并代码。
我发现开发过程中最耗时的部分是所有这些独立的步骤。例如，如果我自己进行一些代码更改，我可以直接告诉AI构建并测试示例，这样它就能进行修复。不久后它应该也能访问调试器，但有时查看日志文件以查找问题也可能有所帮助。
目前我可以粘贴调用堆栈并解释问题，它通常能自行解决……可能需要一些关于大致查找方向的指导。让它自动编译并在调试器中运行，这样当我回来喝杯咖啡后，它就准备好进行更多手动测试了。
[已删除]
2% 的时间，它 100% 有用
普通人甚至无法分辨 AI(即大语言模型(LLMs))没有感知能力。
因此，这可以理解。普通开发人员(我指的是普通开发人员)在工作中使用人工智能可能会蒙受净损失。
使用大语言模型(LLMs)来针对特定问题(即模板、获取/设置函数、转换函数、自动测试编写/模糊测试)是非常好的，但一切都需要人工操作，这可能是时间损失的原因。
另一方面，开发者可能是在学习而非提升效率，因为AI有时会输出大量上下文(需要阅读以确保正确性)，这也没关系。
我认为AI实际上阻碍了学习，因为它隐藏了大量上下文。例如，如果我想使用一个库/框架，借助AI我可以让它生成代码而无需完全理解该库/框架。而没有AI的话，我必须阅读文档，这能提供更多上下文和理解。
这真的取决于库的文档质量。我曾让Copilot使用了一个未文档化的函数参数，因为该参数在库的单元测试中被使用，而Copilot当然可以访问该库的GitHub。
但起初我并不知道那个单元测试，所以我误导Copilot认为该参数不存在。它照做了，但随后无法提供解决方案。几天后我偶然发现了那个测试，才意识到 Copilot 从头到尾都是对的……
我觉得你已经完美地解释了这个问题。
有时候这样就完美了。
例如：我敢肯定有人每天都在编写和调试 shell 脚本。我不是。
我可以坦率地说，AI确实帮我节省了时间，但它仍然需要调试实际的shell脚本，因为AI仍然会搞砸一些语法。但我也会这样做。
在不熟悉的语言中做某事？用你熟悉的代表性语言编写，然后请求转换。
许多技巧都有效，但我发现对于更复杂的问题，我不会试图让AI来解决，而是将其作为高级版的Stack Overflow使用，并确保查阅文档。
解决问题的时间并不总是显著缩短，甚至可能稍慢，但我的做法是，我更经常考虑多种解决方案，而过去往往只是采用能奏效的方案。
请谨慎对待此观点，我们仍然在尝试让AI完成本应简单的事情时浪费时间，而AI往往会失败。
个人而言，我希望AI在编写代码时能自动生成测试用例。编写框架以便我解决问题，并在修复未被测试充分覆盖的代码或引入更多复杂性时(从而增加测试需求)进行检测。
我浪费在人工智能上的最多时间，是当我让它编写测试时，它引用了错误的测试库，我的节点环境给我显示了无用的错误信息，而人工智能在收到这些错误信息后，决定让我去追查一个毫无头绪的问题。
这一切都蕴含着学习的价值。
我可以百分之百肯定，AI并未让我整体效率提升，但确实让我更快地解决了某些问题，许多问题也处理得稍好一些。当然，也有一些问题处理得更差。
就像任何新技术(或工具)一样，我们需要找出如何以最佳且最高效的方式使用它。
今天的AI就像90年代初的电池驱动电动工具。如果你还记得那些……当时根本无法想象我们今天会达到这样的水平(就电动工具而言)。
AI的潜力显而易见，只是实际应用还令人失望。
这是胡说八道，你应该阅读它给你的代码并从中学习。仅仅因为你选择不从它提供的内容中学习更多，并不意味着它阻碍了学习。你选择忽略它提供的完整解决方案，而是盲目应用它，而不是阅读、理解并参考文档。如果你同时从AI示例和文档中学习，往往可以在更短时间内学到更多，而不是仅仅阅读文档。
谢谢你，我从来不会盲目地添加大语言模型(LLMs)建议的库。这就像说麦当劳的存在会阻碍你学习烹饪一样。这当然可能是事实，但没有人用枪指着你的头。
自动扶梯阻碍了我走楼梯
是的，但这也涉及到“好行为者(开发者)”与“坏行为者”的讨论。好行为者会点击AI用于生成内容的来源链接以深入了解。如果你将AI作为搜索工具使用，那么在整合大量信息方面，它比当前的搜索引擎稍好一些。但你确实需要核查并实际查看源材料。幻觉现象非常常见。
因此，它是一个很好的搜索成本降低器，但并不是一辆自动驾驶汽车。
如果你的衡量标准是“生成的代码行数”，那么大语言模型(LLMs) 可能会非常令人印象深刻…
但如果你的衡量标准是“解决的问题数量”，或许效果并不理想？
如果你的衡量标准是“解决的问题是否符合企业主需求？”或者更糟糕的是“解决的问题是否符合企业主需求，且没有安全漏洞和 bug？”
那就不再那么好了！
但企业主需求的一部分(很大一部分)是减少员工成本并减少员工数量。
那么他们应该停止要求如此安全、无漏洞的软件，直接解雇所有开发人员。需求 = 满足。
我的意思是，如果不是为了提高利润率和裁员或不招聘员工，这种推动根本不会实现。我认为他们甚至会牺牲代码质量以换取更大的工资节省。但我同意你的暗示。这种平衡远没有他们希望的那么美好。
你的错误在于认为企业主能够判断代码质量。就我而言，在过去30年的职业生涯中，我从未遇到过任何一位企业主或高管能够以任何方式判断代码质量。连一家11人的初创公司也不例外。
假设而言，我的意思是说。即使高级开发人员告诉他们代码质量会受到一定程度的影响，他们仍然会接受这种权衡。至少在一定程度上。他们不需要能够判断它。
但说实话，我甚至不确定自己是如何走到这一步的，而且有点失去思路了。
这是一个很好的观点。
是的。我一直在使用大语言模型(LLMs)来开发一些我以前不熟悉的技术。能够简单地设计一个架构，然后让它运行，修复错误，并很快得到一些可用的东西，这非常有用。
问题出现在让它处理重要任务时，比如对某个服务器技术进行身份验证……然后你审查代码，发现天啊，尽管身份验证代码冗长繁琐，但只要有有效的用户名，任何密码都能通过验证。而且它还会公开有效的用户名。真是太棒了。
但撇开这类问题不谈，它确实是一个有用的学习工具，也是在无人协助或搭档缺乏相关技术知识(口头表达能力)时进行配对编程的手段。
对于那些只要能正常工作就行的细节，它非常实用。
对我来说，今天它是一个语法助手、日志消息生成器和注释生成器。在最初的几个月里，我发现自己进展缓慢，直到有一天我有了顿悟。我花了3个小时和Chat GPT争论一些我本可以在20分钟内用谷歌解决的问题。从那天起，它成为了一个很棒的辅助工具。但它写的代码简直一团糟，绝不能把它当作比框架种子工具更重要的东西。该死，管理层对它着迷了。他们坚信它几乎是AGI，而它离AGI有多远真是可笑。
需要引用来源
已经有足够多的非AI工具来处理模板代码，我信任它们能准确完成我期望的任务
将学习视为非高效工作是奇怪的。
我的意思是说，高效工作指的是编写代码、提交代码或提交足够多的PR。
糟糕的管理者的定义绝对不包括学习，而且这项研究可能也没有考虑到这一点。
我讨厌每次都阅读小抄，我很高兴大语言模型(LLMs)能为我做正则表达式，但大语言模型在某些多线程方面表现很糟糕，只会给你一些乍一看看起来不错但实际上很糟糕的建议。
我使用副驾驶进行编码的经验时好时坏。但我使用副驾驶作为拉取请求的额外审查者时，体验还是不错的。
即使它具有感知能力，你们仍然会这么说。
你们都是谁？
我明白我们正在取得进展。(只需看看/r/SubSimulatorGPT2)
我们到那里再谈这个吧。
我的经验是，它可以在几分钟内完成80%的工作，但去除重复代码、修复不良或不存在的系统设计以及解决 bug 需要很长时间。之后我才能专注于完成剩余的20%以实现该功能。在大多数情况下，没有 AI 我确实更快。
我尝试用AI解决这些问题，但耗时太久。有时它会修复某个问题，但在处理下一个请求时，却随机撤销了之前的修复……真是令人沮丧。如果我编写一份详尽的规格说明书，包含大量细节，确实能获得更好的结果，但这需要大量时间，而且最终我还是得手动修复很多问题。目前最佳应用场景是原型设计或小型任务/bug修复，例如添加图标、增大按钮尺寸等，本质上是一到三行的修改……这类需求/bug通常因优先级低而被搁置数月，但借助AI至少可以将这些任务外包出去。
我最喜欢的是当它提供解决方案时，我对它的通用性感到不满，然后要求更新，它就像“哦，是的，我们可以做Y”，而我一直在想“为什么你一开始不直接做Y呢？”
据我理解，对提示进行高度具体化可以帮助弥合这一差距，但最终你只是间接编程而已。考虑到大语言模型(LLMs)在处理大型项目方面表现欠佳，它还无法改变游戏规则。
我知道这只是单一研究，目前我只读了摘要和引言的第一部分(但一定会读完)，但看起来思路很清晰。
我对研究结果非常喜欢。我拥有计算机科学硕士学位，专业方向是人工智能，特别是机器学习。我热爱这个领域并认为它极具趣味性。但长期以来，我对人工智能作为开发工具持怀疑态度。我当然使用过人工智能，也能看到其表面价值，但它似乎带来了一种“脑力退化”的感觉。它似乎剥夺了学习和进化的过程。只需向人工智能提出需求，完全跳过真正让我们学习的困难部分，直接对每个建议点击“确定”就行了。
而且我们都知道，大型代码提交往往比小型提交获得的评论更少。人工智能的建议也常常让人觉得太容易接受那些包含 bug 和错误的更改。我猜这反过来会导致开发时间增加。
哦，还有，对于复杂任务，我经常在试图向该死的人工智能解释我想解决的问题时失去耐心。感觉我直接手动完成会更快，而不是花时间写一篇长篇大论。
我热爱编程，但不擅长写作，也不希望写作成为解决问题的首要方式(但我确实希望自己的写作能力能比现在更好)
更不用说系统层面的下游瓶颈了。除非你同时加快了需求、用户访谈和洞察、代码审查、合并、质量保证等流程，否则对加快代码生成并没有多大帮助。最后，我们生产的东西质量是否仍然足够？谁知道呢？让大语言模型(LLM)生成所有内容，将人类从方程式中剔除，就无所谓了。人类用户很烦人，让我们只使用大语言模型(LLM)用户吧。
这不仅仅是一项研究。它与2024年DORA报告的发现非常吻合：https://blog.nordcraft.com/does-ai-really-make-you-more-productive
2024年在人工智能技术领域已是遥远的过去。
“石器时代的工具无效，新闻播报11点！”
这让我想起那些不厌其烦地列举“AI无法做到的事情”的无尽文章，结果发现所谓的“研究人员”或“记者”使用的其实是免费版本的GPT-3，而非付费版本的GPT-4。你看，每月花费$15用于一个研究项目实在太过奢侈！
每次他们说做不到的事情，GPT 4 都能做到。
我的想法是，我正在培养一种宝贵的技能，即了解大语言模型(LLM)可能解决哪些问题，以及它不可能提供良好解决方案的问题，还有一种良好的提示技能。因此，当AI无法解决我的问题时，我不会认为这是浪费时间，即使我的开发进程因该问题而放缓。
我确实越来越擅长识别出AI开始出现幻觉并陷入循环时，这标志着是时候跳出循环尝试其他方法了
我发现情况恰恰相反。我猜这可能是因为我花了十年时间在Stack Overflow上解码答案，但我需要在将AI生成的内容放入代码之前，完全理解它所输出的每一件事。AI要么能引导我解决问题，要么生成一些我认为太过繁琐而不想手动输入的内容。
GT?
我发现这项随机对照试验(RCT)中最有趣的细节之一是，他们录制了所有操作的屏幕录像，并通过标记大量录像来详细记录AI任务与非AI任务在时间分配上的差异。
我注意到，实际使用AI编写代码所花费的时间确实显著减少(从图表粗略估算约为20-30%)。但这一减少被用于“额外”AI任务(如编写提示词或审查AI输出)所花费的时间所抵消。
我怀疑这可能是感知改进与现实之间存在脱节的原因：AI确实使编写代码的过程更快。我推测大多数开发者在估算任务所需时间时，主要依据的是编写代码所花费的时间。因此，由于这一步骤的加速，整体过程可能会“感觉”更快。
编写代码本身并非时间消耗大户。真正耗时的是代码设计、重构、确保命名规范、添加注释、遵循原则分离、优化以及现代化改造等工作，这些才是编写优质代码所需投入时间的环节。
大语言模型(LLM)代码往往是随机的。例如，它使用了不太流行的Python库，但我当时有条件搜索更好的库并使用它。因此，是的，它对于启动项目很有用，但不能替代实际的工程设计。
* 参与者都是经验丰富的开发人员，平均拥有 10 年以上的经验。
* 他们从事的是自己非常熟悉的项目。
* 他们正在解决实际问题
这描述了我过去一周的工作，我一直在使用ChatGPT Plus来帮助开发一个长期项目，该项目需要添加约10,000行代码(数字来自代码差异)。我认为“AI”并未让开发过程更快，但不得不承认，有一个能定期互动的工具，它能追踪代码变更并掌握整体架构，确实大幅缩短了我完成开发所需的时间。
我认为它完全无法帮助更快地编写代码，但它确实有助于检查代码的合理性，并提供比我完全自己做更快的有效解决方案。
当前的“人工智能”解决方案，如大语言模型(LLMs)，是绝佳的橡皮鸭。
我从中得到的主要启示并不是人工智能不好，或者它会让你变得更慢。我认为我们无法得出这个结论。
但它确实表明，我们不能依赖自己的直觉来判断AI工具对生产力的影响。
除了CEO。我们绝对应该相信他们在这些问题上的直觉。
/s
是的，我同意。我只是分享自己的亲身经历，试图传达的是，很难判断它是否有助于提高生产速度或提升产出质量。
我认为速度和质量都得到了提升，但这种提升并不像人们想象的那样容易量化。
我同意这一点。AI在学习新事物方面很棒，尤其是在深入研究一种语言、框架或技术时，能帮助降低学习曲线。
然而，如果你已经知道该怎么做，你的专业知识会超过AI，它可能会提出一些你已经知道的低效解决方案。
它是个通才但不是专才。这是一个很好的衡量标准，让你知道自己在该领域的专业程度。
我喜欢它，因为它让我思考自己的词汇量。我可以随时与它交流。
不过它确实挺笨的，哈哈
我确实花了一些时间来修复AI生成的那些最初看起来还不错的垃圾代码。
个人经历：作为高级程序员，我让AI完成了一个相对常规的任务。
它给我生成了100行代码，看起来很不错。
但完全无法编译，而且其中充满了函数调用，而这些函数中并不存在相应的参数。哈哈。
我试图将AI作为一个“非常好的助手”来节省时间，只需阅读文档即可了解函数的功能，但它并没有真正帮助到我。
只有当你想要做的事情有非常详细的文档记录，而且版本尚未达到大语言模型(LLM)的截止点时，它才能发挥作用。最前沿和晦涩难懂的东西就不在考虑之列了。
那么，对于那些可以轻松找到人类编写的示例代码的问题，它也能发挥很好的作用吗？哦，天哪！
是的，但不可否认的是，在某些情况下，大语言模型(LLM)会更快，并产生足够好的代码。
是的，真正的诀窍是将你正在使用的任何 SDK 的文档作为上下文的一部分输入到人工智能中。
这样它就无需依赖高度压缩的内存。
没错，如果可能的话，启用搜索功能。但这仍然无法达到预期效果。
这与我的经历一致。我曾尝试让Copilot将一个简单的(约100行)Python脚本转换为Node.js，但仍然需要修复大量错误。
这就像有一个笨拙但勤奋的实习生在帮你工作。
我的经历通常相反，代码通常能编译通过，且问题非常轻微 (通常可由AI自身修复)
如果任务需要多步操作，那就糟糕了。
代码虽然能编译，但执行步骤时常出错
试试Claude Code或类似工具。它能编写代码、编译、运行测试、读取错误信息、查阅文档、分析库代码、添加调试语句，并循环迭代直至认为完成。
谢谢！
对我个人而言，在不熟悉的框架和技术栈中快速解决问题时，AI工具堪称救星。我是一名顾问，因此必须按时交付成果。最近一个项目预计需要120小时。借助ChatGPT Pro和Gemini，我仅用30小时就完成了任务，这意味着我可以利用剩余时间超越原定任务范围，为客户提供更多价值。总体而言，这是令人惊叹的成功，从今往后我将在工作各方面都使用这些工具。
我假设你是把它当作“辅助工具”使用的，让它帮你查找所需的文档和示例。
对于这个用途，它确实有效，不过效果一般。
这就是我使用它的方式。仅仅了解一个库就能节省大量时间。
“超出原定任务范围”
让我猜猜，当老师忘记有考试时，你举手了
我之前也曾不得不修改过他们的代码。就连他的注释里都有省略号。
是的，我基本上只用它来查找如何完成之前从未做过的事情。
在专业问题解决的精英领域——尤其是当你被派往一个陌生的框架或神秘的技术栈的迷宫时——当代生成式智能已然成为不可或缺的工具。作为一名顾问，我靠计费小时数谋生，而及时的智慧正是我职业的货币。
请想象这样一个案例：最近一个项目被估算为需要120小时。通过巧妙运用ChatGPT Pro和Gemini，我将该项目压缩至仅需30小时——释放出大量时间，让我得以超越项目范围，为客户提供超出预期的工作成果。
结果如何？坦白说，这是一场歌剧般的胜利。从今往后，这些算法共谋者将渗透我职业生涯的每一个角落。
看起来像是AI评论，而且竟然与上面的评论一模一样，连细节都一模一样。Hmmmmmmmm…
我敢肯定，如果你看看另一个回复，那里有两个AI在互相聊天。
现在情况是这样的——当你身处新的框架、新的技术栈时，你没有时间像1985年那样坐下来阅读手册。你必须行动，必须快速解决问题。这就是这些AI工具发挥作用的地方——它们是游戏规则的改变者。我说的就是ChatGPT Pro、Gemini——整个工具包。
我接了一个咨询项目，对吧？他们说：“这个项目需要120小时。”我说：“好，开始干活。”30小时后——咔嚓——搞定了！这就像在第一节就踢进四个达阵。而我节省下来的时间？我可不是闲着没事干——我继续前进，增加了额外价值，真的让客户印象深刻。
归根结底？这些工具不仅有用——它们现在是团队的一员。从现在起，它们将出现在我调用的每一个方案中。
(令人惊讶的是，它将段落大致分为两部分，我参考的是OOP的评论，不是你的。)
嘿，看看这个——
我走进代码就像“时间在流逝，让我们开始吧”，
新的栈，新的框架——我不在乎潮流。
AI在仪表盘上，我的秘密武器在行动，
ChatGPT Pro和Gemini为我指明方向。
他们说“一百二十小时”，兄弟，那时间表就是个笑话——
我把它缩短到三十小时，让截止日期灰飞烟灭。
顾问在忙碌，计费分钟全开，
提前完成，将剩余时间转化为快速超额交付。
客户瞪大眼睛，结果看起来很棒——
从优秀到传奇，是的，我以优雅的方式展现实力。
现在AI已就位，迎接我领域中的下一项挑战，
因为有了这些工具，我永远都是香槟般的存在。
性能和 bug 数量比代码行数更重要的指标。
我拥有超过15年的经验，最近参与了一个使用AI的项目。我可以肯定地说，最初我可能因为过于依赖AI而浪费了时间，但经过几个月的开发，我现在已经建立了一个更高效的工作流程，其中AI在多个步骤中被广泛应用，这无疑整体提升了效率。
我唯一使用AI的时候，是当我有侧项目时，我基本上已经知道该做什么，但懒得去做。其他任何事情都感觉更像是审查代码而不是编写代码，而我讨厌审查代码
但这并不是AI支持者一直告诉我的。这些开发者一定做错了。
C.2.3让我觉得范围蔓延(scope-creep)作为一个因素需要更深入的调查。
我并不怀疑人们在估算时不可靠，但这是几乎普遍存在的真理，我们在做的一切事情中都已得到证明。如果你寻找不可靠(和/或有偏见的)报告或估算，我估计(哈哈)你总会找到。
这项研究专门针对高技能开发者。(仅16人，顺便说一句。)听起来完全合理：你越优秀，AI就越帮不上忙。但我认为这不是主要问题。作为一个职业，当每个人都能成为糟糕的开发者，而糟糕的开发者又能提升到平庸水平时，顶尖开发者会面临什么情况？
实际上，我认为我们反而会变得更有价值，因为这为高技能开发者筑起了一道护城河。一个配备AI的糟糕开发者永远无法超越一个普通开发者。
但我认为这项研究并不能作为“AI对开发者无用”的证据。
我对AI的体验目前是喜忧参半。我发现对于非常简单且可重复的任务，且易于验证时，使用AI往往效果不错。但一旦任务复杂度提升，AI几乎总是失败，尽管我尝试过引导它。
总体而言，我希望完全理解AI生成的内容，因为我尚未完全信任它。未来AI工具或许会改进，但目前还未达到那个水平。
让我猜猜下一个四维棋局中的下一步是什么：解雇所有经验丰富(即成本高昂)的工程师，因为他们被强制使用人工智能后变得效率低下，转而雇佣廉价的外包人员(他们缺乏经验)，并强制他们使用人工智能，然后财务部门突然看起来是净正面的。
根据我在编辑器中使用代码补全功能的经验，它在三方面非常有用：1) 模板代码 2) 文档/注释/操作字符串 3) 在修改第一个实例后，对并行代码进行小规模可预测的修改。
可能还有4) 为你勾勒出一个新函数作为模板，供你填充和完成。但4) 其实是1) 的高级版本。
这与我的经验一致。几乎所有情况下，自己手动完成会更快。例外情况，如其他人所说，是模板代码。
当我需要进行多次复制粘贴并重命名类时，使用 AI 更安全，因为它不会出错。但对于实际任务，它往往耗时更长
我发现它是一个绝佳的替代方案，用于替代Stack Overflow。当我需要快速查阅公共API的语法文档，或进行编译/运行时错误分析时，它表现出色。以这种方式使用时，我实在难以想象它会让我变慢。我曾经浪费整整一天时间在不完整或过时的文档中摸索。也许你可以尝试让它帮你编写代码？
他们是否有过代理编程的经验？
这只是暂时的。人工智能很快会让所有程序员的效率提升10倍
有经验的程序员可能更慢，因为他们知道AS会产生幻觉并输出🐂💩。缺乏经验的人不够熟练，因此与其浪费时间，AS会更快地生成“某种东西”，即使它可能不正确，而缺乏经验的人又不够熟悉来检查和纠正它。
对我来说，AS吐出的绝大多数内容都是🐂💩。没有它我能编码得快得多，而AS会产生大量幻觉，很少能提出最优或合适的解决方案。
它让经验不足的开发人员“更快”的错觉，并没有考虑到其他人需要花费时间来清理和修复快速产生的所有🐂💩。这是将活动与成就混为一谈。
大语言模型(LLM)似乎确实有助于明确的大规模移植任务。例如，AirBnB 迁移单元测试框架的案例。或者 Spine Runtimes 的维护？这些博客文章展示了大语言模型(LLMs)在约束条件明确且可验证的大规模任务中的应用。
我有一个类似的用例，尝试让克劳德代码迭代最后 20% 的工作，但我并不信任它，而是手动验证了所有内容。
如果你一直盯着代理程序，你会变得更慢。给代理程序一些标准模板，让你有好的示例可以提供。然后专注于应用程序的其他部分。
当代理程序完成后，审查它并重复这个过程。否则，你只是在等待一个初级水平的程序员慢慢让你失望。
这就是为什么这些工具在演示和影响者中看起来很好……
因为它们总是处理新的项目设置和新的绿地仓库。
但一旦事情变得棘手、定义不明确且复杂，情况就会变得艰难。
作为一名专业开发者，也就是那些实际上被付钱来做这件事的人，我只是没有遇到足够多的模板代码，以至于它能节省大量时间！
样本量为16且任务时长为2小时的测试结果并非最佳基准，但由于每位程序员都喜欢批评AI，他们会对这些结果感到兴奋。
是的，AI被过度炒作，但让我们看看在大型任务的绿地项目中会发生什么。
我认为绿地项目并不现实：你不会每天都遇到这样的项目。这相当罕见。
我职业生涯的大部分时间都在迭代一个由许多人在我之前和之后编写的大型代码库。绿地项目根本不是软件工程的挑战！
我在职业生涯中遇到过许多此类项目，而我并不在科技中心工作。
即使是大型系统的一部分或与其他系统交互的组件，也需要从零开始编写。
任何人都可以写出垃圾代码，然后转到另一个项目，做好才是难点。
这条帖子在我动态中显示为“品牌合作”，与通常的“推广”广告不同。这是Reddit推送广告的另一种方式，还是其他什么？
这与文章内容无关，只是想弄清楚最近在Reddit上看到的内容。
我发现虽然使用AI完成任务可能需要更长时间，但结果会更准确，当然我也会进行审核。
当我独自编码时，常常忘记更新文档或为了赶工而走捷径。
使用AI时，我更敢于进行更复杂的改动。
我不确定他们是如何测量的，但软件开发涉及很多因素。
这是否意味着他们更高效或更准确？因为这可能抵消速度的下降。
没关系，但如果AI让程序员变慢，我认为问题出在开发者身上。
AI只是工具，你必须把它当作工具使用，它应该能提高你的产出，即使只是微小的提升。
对我来说，我通常比预估的时间少花15-17%的时间在功能开发上。虽然这不算多，但我特别喜欢它在那些最繁琐、最机械化的部分表现出色，这些部分几乎不涉及真正的编程。
所以任何工具都应该提高“产出”——无论产出指的是什么？
这是一个过于笼统的论断！许多工具虽然能提高安全性，但会降低效率。单元测试就是典型的例子，它会直接拖慢开发速度。使用单元测试编辑代码库绝不会比不使用时更快。
我认为关键在于“每个人都认为自己高于平均水平”——换句话说，自我评估是我们首先欺骗自己的谎言！
作为一名经验丰富的应用程序开发者，我可以证明这是彻头彻尾的胡说八道。使用AI来提高编程效率有正确和错误的方式。如果相信这份“研究”，听起来大多数人都在错误地使用AI。
哈哈。是的，总是开发者的错，因为他们没有“正确”使用AI。
在这种时候，我读到这样的内容，真庆幸自己专攻2D编程。1D编程对我来说从未合乎逻辑，但由于大脑的特殊性，我选择了恰好是AI无法胜任的编程风格。
他们使用AI工具的经验和技能如何？使用的是哪种AI工具？
这是我脑海中立即浮现的问题。
为什么不读论文呢？
因为我暂时没有时间读论文
大多数人都有100多个小时
谢谢
他们选择的工具，大多数使用Cursor或Claude Codes
我对其他指标也感兴趣，比如每行代码的缺陷数量。
如果最终产生的缺陷更少，那么20%的性能下降并不是世界末日。
如果我有两个开发人员，其中一个能在5天内完成一个“完整且无 bug 的功能”，而另一个则需要4天完成该功能，再加上“跨多个时间段”的调试和修复 bug 工作，我当然会选择前者。
这是一项针对16人的研究，其中只有一人对Cursor有丰富的经验。事实上，那位有Cursor经验的人，是少数几个显示出显著生产力提升的人之一。
因此，这项研究最多只能证明，学习新工具可能会暂时降低你的生产力，直到你熟悉该工具。
我在TFT游戏间隙编码时，生产力提升了200%
优秀的程序员可能不擅长提供足够详细的提示。如果追求特定的实现方式，仅凭一段或两段文字加代码往往不够。AI在拥有完整上下文时效果最佳。例如，我正在开发一个API，我告诉ChatGPT我想要一个无控制器架构的.NET项目。我提供相关表的模式、存储过程名称、每个客户端的API密钥存储方式、我希望的缓存策略、建议的速率限制，然后要求生成2到3个端点以及我希望以JSON格式获取的数据。它做得相当不错，通常需要2到3次迭代才能达到我想要的效果，这样我就可以继续开发。但原本需要半天或更长时间的工作，现在只需30分钟的提示和代码审查。
我还发现它非常适合解释第三方API的工作原理，例如Stripe、Salesforce、Xero，以及我需要使用哪些方法来实现我的目标。
不能说它让我变慢了。
胡说八道
你的理由是什么？你对研究的方法、结果或结论有任何意见吗？