人工智能编程助手:是负累还是解脱?

人工智能编程助手:是负累还是解脱?

一个AI编程助手在艰难地应对错综复杂的代码,象征着技术债务。

引言: 随着人工智能不断地变革各行各业,在软件开发的实践一线,一个发人深省的现实正逐渐浮现。正如一位资深工程师的坦诚讲述所揭示的,备受吹捧的LLM“副驾驶”与其说是一个有助的领航员,不如说是一个指手画脚的“后座司机”,正在把我们引向无法预见的技术债务和深深的幻灭。

核心提炼

  • “大型语言模型作为助手,人类作为架构师”的范式不仅仅是一种偏好,更是一种关键的必要,这凸显了人工智能目前无力理解架构复杂性或自主维护代码质量。
  • 对于复杂且功能完备的开发或基础设施重建项目,大语言模型非但不能提高效率,反而会显著降低生产力,并引入大量技术债务,将那些看似“捷径”的做法,变成代价高昂的弯路。
  • 大语言模型最初的“惊艳感”,往往掩盖了其在准确性、连贯性方面更深层、持续存在的问题,以及引入的细微、难以排查的错误,从而导致了纠正AI生成修正的循环。

深度解读

阿尔贝托·福尔廷(Alberto Fortin)的经历,虽然是个人体会,却与越来越多的资深开发者产生了共鸣,他们正面临着人工智能炒作与复杂工程环境中实际应用之间的巨大鸿沟。他最初对大型语言模型(LLM)的接受,受行业内盛行的关于生产力变革性提升的论调所驱动,很快就被一个严酷的现实所取代:对于涉及Go和ClickHouse的严肃基础设施工作而言,这些工具弊大于利。正如福尔廷所阐述的,核心问题不仅仅是功能性错误,而是一种更深层的弊病:代码质量差、架构不连贯,以及一个持续存在的“总差两周就能修复”的循环——LLM生成的解决方案引入了新的、通常是隐蔽的问题。

这不仅仅是对特定模型的批判;它对生成式AI能否在高度受限、琐碎的任务之外成为可靠伙伴的观念提出了根本性挑战。对于一个需要多年维护健壮、可扩展代码库的工程师来说,代码的“整洁性”和逻辑一致性至关重要。LLM尽管在语言上很流畅,但在这方面却明显力不从心,常常生成语法上看似合理但架构上幼稚或存在根本性缺陷的解决方案,这类似于一个口才流利但缺乏专业知识的演说家。

福尔廷的关键见解——“我是软件工程师,资深软件工程师,我是架构师。LLM是助手。助手回应我;我来制定计划”——概括了所需的关键思维转变。将大量的认知负荷或创造性问题解决任务卸载给AI的幻想,至少目前来看,仍然只是一个幻想。相反,工程师们发现自己正在扮演一个耗尽精力的新角色:一个高度警惕的AI质量保证专家,不仅要不断调试自己的代码,还要调试AI的建议,而且常常要调试这些建议所产生的连锁效应。这种额外开销抵消了任何预期的效率提升,导致信任丧失,迫使开发者回归久经考验的方法:亲自理解代码库。福尔廷发现,通过手动调试获得的“百分之百的理解”并非更慢的替代方案,而是通往稳定解决方案的最快途径。

对比观点

LLM驱动开发的支持者可能会争辩说,Fortin的经历是一个特例,可能源于提示工程不足、使用场景过于激进或未能适应新范式。他们会指出无数的例子,其中大型语言模型成功生成样板代码、重构小型代码片段或协助调试错误信息。争论往往转向“这取决于你怎么使用它”或“你要求它做得太多、太快了”。此外,人工智能发展的速度是不可否认的;模型正在迅速改进,也许下一个迭代版本将克服这些障碍。他们可能会辩称,即使大型语言模型只处理10-20%的日常编码任务,这仍然代表着一个大型工程团队整体生产力的显著提升,从而让高级开发人员腾出时间从事更具战略性的工作。

前景探讨

未来1-2年内,LLM在复杂软件工程领域的现实展望表明,它们将继续演变为强大的助手,但不会成为自主的,甚至半自主的工程师。业界可能会形成一种更细致的理解,即LLM擅长于特定、狭窄的任务:生成单元测试、样板代码、编写文档,或提供有针对性的重构建议。真正的架构推理、长期维护代码质量以及理解大型系统错综复杂的依赖关系,仍牢牢地属于人类领域。最大的障碍不仅仅是模型准确性,还在于建立真正的信任、确保确定性和可解释的输出,以及在考虑验证的认知开销和潜在技术债务成本时,证明其能带来净正向的投资回报。这场“革命”将是渐进式的,侧重于增强人类能力而非取而代之。


原文参考: I’m dialing back my LLM usage (Hacker News (AI Search))

Read English Version (阅读英文版)

Comments are closed.