软件工程师:说正经的,你们真的从LLMs中有所收获吗?
摘要
一位软件工程师对使用本地LLM进行智能编码感到沮丧,指出诸如技术债务、忽略指令和过度生成代码等问题,质疑其有用性。
六个月来,我一直尝试用 Pi 和一些 30-120B 的模型(Qwens、Nemotrons、Leguna 等)进行智能编码。我并不贪心,只使用合理的量化,从不量化 KV 缓存,并将会话长度控制在 90k 以内。但结果总是令人失望。无论我如何约束模型,或者用整页的 Markdown 指令轰炸它,智能体带来的技术债务总是多于其价值。最终我花在清理烂摊子上的时间,比一开始全部手动完成还要多。我的意思是,这些模型简直不知羞耻:它们会糟糕地重复自己;如果它们对另一种方法论更顺手,就会完全放弃你指定的方法论(例如函数式编程 vs 面向对象);在上下文超过 50k 深度时公然忽略指令;写出很容易通过的浅显测试,只是为了自我安慰;几乎从不花一点时间去思考在堆积代码之前是否可以先重构混乱的代码。它们总是倾向于写出大量代码,以至于我常常在心脏病发作前按下 Ctrl+C!一个有真材实料的初级工程师也不会这么混乱。到头来,人们在架构设计和引导上能做的有限,否则就会变成微管理的地狱。那么,对于那些因智能编码而看到生产力提升的高级工程师(正如我经常听到的那样),你们究竟是怎么做到的?谢谢!
编辑:抱歉。我指的是本地模型。我以为这是 LocalLLaMA 子版块。
相似文章
LLMs正在侵蚀我的软件工程职业生涯,我不知如何是好
一位在金融和支付系统领域拥有10年经验的软件工程师反思了像ChatGPT和Claude这样的LLMs如何侵蚀他领域特定知识的价值,因为AI如今能够处理之前需要多年专业知识的复杂设计任务。
LLM编码时代的软件工程最佳实践
一篇讨论软件工程最佳实践如何随着LLM编码工具的整合而发展的文章,为开发者提供指导。
@msimoni: 到目前为止,我还未能让LLM在编程的困难部分显著帮助我——设计代码……
作者发现,LLM在编程的困难部分(设计简单、通用、清晰的代码)并没有显著帮助,但在其他部分却非常有用,以至于他们将其评为10倍的生产力提升。
为什么我仍然是一个怀疑论者
作者对LLMs在软件开发中的有效性表示怀疑,指出缺乏关于生产力提升的独立研究以及AI生成代码的质量问题。
LLM的有效用例
本文分享了LLM在软件工程中的实际应用案例,包括通过RAG搜索客户对话、从日志中排查API故障以及内容精简。重点强调了效率提升和减少手动筛选工作。