大语言模型时代的软件开发：还有多少团队仍像  2021 年那样编写代码？

TL;DR

许多工程师继续在没有大语言模型 (LLMs) 的情况下编写代码，特别是在受监管行业、政府部门和利基领域，然而企业压力和 C 层管理人员的指令正在推动大多数软件团队采用 AI。

---

1. 并非所有公司都已采用 LLMs

• 受监管部门抵制变革 – 在美国开发医疗设备的团队报告称没有使用 AI，因为法律审查和合规性减慢了任何新工具的使用。(Comment by cowanon77)
• 政府和公共部门工作仍保持手动 – 州和联邦开发人员提到在采用未经证实的工具之前存在五年的滞后，使他们的工作流程与 2021 年相似。(Comment by bthallplz)
• 嵌入式和安全关键型代码通常禁止 AI – 为政府订购的嵌入式设备工作的承包商因尚未解决的版权和责任问题，在合同上被禁止使用 LLM 生成的代码。(Comment by voakbasda)
• 利基技术领域缺乏模型覆盖 – 调试低层网络或自定义 bit-banging 驱动程序从 LLMs 中获益甚微，因为训练数据很少涵盖这些细节。(Comment by mysterydip 和 dotdi)

2. 企业压力正在增长

• C 层 AI 指令 – 一些公司有明确的高管指令，要求在一年内实现 70-80% 的 AI 生成代码，尽管内部政策每天都在变动，导致开发人员对哪些工具被允许感到不确定。(Comment by timbaboon)
• 试点项目和逐步推广 – 组织正在测试、验证和需求管理方面实验使用 AI，然后再进行全面采用。(Comment by cowanon77)
• Token 限制和许可瓶颈 – 即使在允许使用 LLMs 时，token 额度也迫使开发人员必须具有策略性，且只有一部分员工获得许可 (例如, Codex vs. GitHub Copilot)。(Comment by francisofascii)

3. 保持以人为本的个人策略

• 将编码作为思维训练 – 一些工程师通过解决每日 LeetCode 问题来保持其解决问题的能力，无论是否使用 AI 辅助。(Comment by andreybaskov)
• 仅将 LLMs 用于外围任务 – 开发人员报告使用模型进行文档编写、API 查询、测试脚手架或快速代码片段，同时严格审查输出 (≈80% 正确性)。(Comment by ww520)
• 保持“苏格拉底式”工作流程 – 技能转变是从编写代码到提出正确的问题；这种方法仍然需要深厚的背景知识。(Comment by jolt42)
• 为非核心活动预留 AI – 独立承包商可能会使用 LLMs 进行安全审计、重构或日志分析，但会刻意避免将架构和设计委托给 AI。(Comment by voakbasda)

4. 对代理式编码 (Agentic Coding) 的混合经验

• 短期试验往往令人失望 – 使用自主代理进行重复的四个月实验产生了多 bug 的、难以维护的代码，导致许多团队回归到手动开发。(Comment by QuadmasterXLII)
• 当它奏效时，效果令人印象深刻 – 最近使用 “Fable 5.1” 的试验显示了更好的结果，这表明工具成熟度和提示工程 (prompt engineering) 很重要。(Comment by QuadmasterXLII)
• 代码质量担忧 – 团队报告 AI 生成的代码导致测试套件膨胀、产生大量噪声 diffs，并降低了所有权感，这可能会侵蚀代码库的健康度。(Comment by localhoster)

5. 职位市场格局

• 招聘广告仍有差异 – 一些职位列表明确要求 LLM 经验，而另一些则完全没有提及，这表明招聘环境正处于过渡期。(Comment by mikemarsh)
• 承包商保留了更多自主权 – 自由职业者可以选择是否引入 AI，但客户合同可能会有不同规定。(Comment by voakbasda) )

n. 展望

• 不可避免的扩散 – 即使在高度受监管或保守的领域，一旦版权和责任框架确立，预计 AI 工具将获得法律许可。(Comment by voakbasda) )
• 人类专家知识仍然关键 – 核心架构决策、领域特定驱动程序开发和细微的调试工作仍然重度依赖人类洞察力。(Multiple comments)
• 平衡之道 – 成功的团队可能会将严格的人类审查与选择性的 AI 辅助相结合，而非完全自动化代码生成。

---

此综合报告反映了 Hacker News 上分享的各种经验，强调了传统编码的现状、AI 采用的指标、AI 采用的加速，以及开发人员如何应对这一过渡期。