原贴链接

我是一名软件工程师，每天都在使用大语言模型。它帮助很大。如果我给出正确的提示/上下文，它就会输出我需要的方法/逻辑。它会生成复杂的SQL查询（如果我需要的话）等等。它会解释我不熟悉的概念。它甚至会把复杂的问题分解成可理解的部分，这样我就能对自己想要做的事情有一个整体的了解。如果我不确定语法/不知道如何编写某些代码，或者甚至完全不知道怎么做，它会给我结果，或者至少是方向。然而，我总是会检查它是否合理。我不会盲目复制它输出的内容。如果不行，我会微调它。所以我不确定为什么这么多人诋毁它？有人说‘你会忘记自己怎么做的！’当然，纯粹的语法/编码技能可能会生疏，但如果你能依靠它，评估它的建议，那又怎样呢？对我来说，这有点像说：‘因为你用打火机，你就会忘记如何用两块石头生火！’如果我知道最终结果应该是什么，我用了打火机并且知道火是做什么的，这有关系吗？还有人说‘人工智能给我的是实习生水平的结果！’在生气之前，你有没有试过给出详细的提示和上下文，而不是一个含糊的5个单词的句子呢？说到底，它只是一个工具，对吧？如果你得到了结果，你是如何得到的又有什么关系呢？

讨论总结

这个讨论围绕着软件工程师（SWEs）对在编码中使用大型语言模型（LLM）的态度展开。一些人认可LLM是有用的工具，能提高编程效率，如在日常工作中帮助解决各种问题；但也有很多人存在抵触情绪，主要原因包括担心失业、LLM自身的局限性、对初级开发者的影响、版权问题等，讨论氛围比较多元，各种观点都有一定的支持者。

主要观点

  1. 👍 认为LLM是优秀的编码工具
    • 支持理由：可以像智能文本编辑器一样根据指令快速给出结果，能帮助提高编码效率，如有人利用它在一周内连续完成4个项目。
    • 反对声音：无
  2. 🔥 很多人对LLM用于编码持负面态度是多种因素导致的
    • 正方观点：包括使用场景不当、提示不正确、缺乏处理幻觉的经验、对初级开发者发展的担忧、糟糕的使用体验、版权或意识形态问题、被过度追捧现象吓退等。
    • 反方观点：无
  3. 💡 过度依赖LLM做编码工作有被取代的风险
    • 解释：自身能力基础很重要，虽然LLM是工具但不能过度依赖，例如如果90%的编码工作依赖LLM，被取代概率就有90%。
  4. 👍 正确使用LLM可成为很好的时间节省和提高生产力的工具
    • 支持理由：很多人在工作中使用LLM节省了大量时间。
    • 反对声音：无
  5. 🔥 不同类型的SWEs对LLM用于编码有不同看法
    • 正方观点：如嵌入式软件工程师面临模型数据不足导致代码质量差，TypeScript或Python开发者觉得AI代码不适用于可扩展应用。
    • 反方观点：无

金句与有趣评论

  1. “😂 我认为AI是编码的优秀工具，每天都使用它。”
    • 亮点：直接表达了对AI在编码中使用的积极态度。
  2. “🤔 我对它对初级开发者开始他们的职业生涯的影响有巨大的担忧。”
    • 亮点：提出了一个在讨论中比较受关注的对初级开发者影响的问题。
  3. “👀 当AI能够生成符合编码标准、满足多个规范文档中的每个要求、可由我们的QA部门测试、允许我们的生产线安装和测试、正确解决我们所有的安全风险、在我们的定制硬件上运行、有易于使用的GUI和API，并能够更新其代码以支持新产品和新特性的代码时，我才会担心被取代。”
    • 亮点：详细阐述了在何种情况下软件工程师才会担心被AI取代。

情感分析

总体情感倾向比较复杂，既有积极支持LLM用于编码的，也有消极抵触的。主要分歧点在于LLM对软件工程师职业发展的影响，如是否会导致失业、对初级开发者的影响等。可能的原因是不同的软件工程师有不同的工作场景、职业发展阶段以及对新技术的接受程度。

趋势与预测

  • 新兴话题：对初级开发者的影响以及如何在使用LLM的同时确保他们的成长可能会成为后续讨论的重点。
  • 潜在影响：如果LLM在编码中的应用越来越广泛，可能会改变软件工程师的技能需求，如对编写提示词的能力要求提高，也可能会影响软件开发的流程和效率，对整个软件行业的人才结构和发展方向产生一定的影响。

详细内容：

《软件工程师对 LLM 用于编码的态度为何两极分化？》

在 Reddit 上，一篇题为“ Why are many SWEs salty about LLM use for coding?”的帖子引发了热烈讨论。该帖的作者表示自己作为一名软件工程师（SWE），日常使用 LLM 感觉帮助极大，但不理解为何许多人对其嗤之以鼻。此帖获得了众多点赞和大量评论。

讨论的焦点主要集中在以下几个方面：

  1. 有人认为 LLM 对某些特定类型的问题不太适用，比如涉及高度模板化的 C++代码库、自定义库或 Solidity 智能合约时，容易频繁出错。
    • 例如，有用户分享道：“如果你的问题是像高度模板化的 C++代码库，LLM 就开始频繁犯愚蠢的错误。”
  2. 认为 80/90%的解决方案可能需要更多时间去理解和调试，有时自己编写代码反而更高效。
    • 有人提到：“写代码比读代码容易。理解和调试一个几乎完整的解决方案可能比自己写更费力。”
  3. 部分人对 LLM 的认知还停留在 GPT 3.5 阶段，没有意识到其快速的发展和提升。
  4. 许多人没有掌握正确使用 LLM 的工具和方法。

不过，也有不少积极的声音：

  1. 有人通过新的框架如 smolagents 成功利用 LLM 加速熟悉新的代码库。
    • 比如：“使用新的 smolagents 框架，效果很棒，大大加快了熟悉新框架的速度。”
  2. 一些人认为 LLM 就像非常智能的文本编辑器，在特定任务上能快速生成代码。
    • 有人表示：“让它重构重复代码块，变成循环，瞬间搞定。”

在这场讨论中，共识在于 LLM 是一种工具，关键在于如何正确使用和有效整合。但争议点在于其适用范围、效率提升程度以及对不同技能水平开发者的影响。

总之，关于 LLM 在编码中的应用，Reddit 上的讨论丰富而多元，既展现了其带来的便利，也揭示了存在的问题和挑战，需要开发者们在实践中不断探索和优化使用方式。