评估 AI 工具的价值具有挑战性，原因在于存在缺陷的指标，如代码行数或开发者调查。历史上，自动化并未消除职业，而是转变了工作角色，这使得预测 AI 对工作的影响变得极为困难。虽然闭源 AI 模型目前引领创新，但开源模型正在迅速追赶，能力差距正在快速缩小。AI 的一个重大问题是幻觉引用，这可能会用虚假信息污染互联网的知识库。尽管人们担心 AI 生成的代码会被用于攻击，但它也被证明在防御软件方面有效，能够预先发现漏洞。当 AI 模型将现有代码作为上下文时，代码库中的技术债务会被放大，导致“生成性债务”累积。互联网中 AI 生成内容日益增多，形成了“僵尸互联网”，使得区分人类互动与 AI 输出变得困难。生成 AI 代理可能感觉像是并行处理，但人类注意力仍然是关键的串行资源，无法被复制。虽然 AI 工具降低了构建解决方案的成本，但组织对齐与协调已成为新的瓶颈。AI 带来的生产力提升往往体现为产出量的增加，而非质量的改善，这侵蚀了进行关键战略思考和指导的时间。

作者分享了其在 GOTO 会议上的经历，探讨了 LLM 增强编程的观察，并指出需要新一代来引领变革。文中特别提及 Ian Johnson 利用 AI 重构代码库的工作，揭示了在测试和架构模式的推动下，角色正从“编写者”向“策展人”转变。作者批评英国政府以安全为由关闭开源仓库的做法是方向错误的。Adam Tornhill 关于代理式编程中认知耐力的见解，强调了决策密度增加所带来的心理成本。作者引用了一些幽默语录，并回应了年轻人对科技寡头制和人工智能的不满情绪。文中引用了《经济学人》的两篇文章，一篇探讨历史技术变革对就业的影响，另一篇聚焦人工智能对毕业生招聘的影响。作者批评美国政府监管人工智能的努力缺乏实质内容且专业不足。同时指出，由于人工智能的快速演进，缺乏监管可能带来危害。最后，作者因其在软件开发领域的专业背景，支持 Beth Anders-Beck 竞选国会。

Birgitta Böckeler 在关于编码代理传感器的文章结尾，探讨了测试套件作为回归传感器的作用，并重点分析了变异测试在其中可发挥的作用。

"Vibe coding"显著加速了软件原型开发，但 AI 代理经常推荐不安全的配置，从而引发安全问题。Gautam Koul、Lucian Moss、Neil Drew-Lopez 和 Daberechi Ruth Edeokoh 分享了他们在为 Thoughtworks 全球营销部门构建应用程序时的经验。他们认识到，要应对这一问题，我们需要编写安全上下文文件以指导 AI，谨慎处理 AI 权限请求，建立每日安全情报馈送，并为开发者提供默认安全的运行环境和模板。

"Vibe coding"是指通过向大语言模型（LLM）发出提示来构建软件，而无需查看生成的代码。这种方法由 Andrej Karpathy 提出，因其依赖自然语言指令，对非程序员而言易于上手。虽然"vibe coding"适用于快速项目，但在代码质量和安全性方面存在严重缺陷。"Vibe coding"的核心原则是“忘记代码甚至存在过”，这既带来了其易用性，也构成了其局限性。这与“代理编程”（Agentic Programming）不同，后者侧重于代码审查与理解。通过"vibe coding"开发的软件可以快速构建，但往往缺乏可维护性，并可能引入重大安全漏洞。安全风险尤为令人担忧，因为大语言模型易受攻击，且可能泄露敏感信息。较差的代码质量使得未来修改软件变得困难，即使借助先进的大语言模型也是如此。大语言模型可能生成错误和不当行为，而这些错误可能未被察觉。"Vibe coding"开发的软件最适合用于范围有限、用户基数较小的临时性项目。复杂或广泛使用的应用程序则更需要关注代码质量和安全性。

Birgitta Böckeler 补充讨论了三种用于静态代码分析的传感器，重点在于检查并强制实施更好的模块化。用于依赖检查的计算型传感器在强制执行规则方面表现良好，但规则本身存在局限。构建用于耦合数据的计算型传感器效果平平。相比之下，通过提示推断型传感器审查模块化更为有效。

在她近期关于为代码代理用户构建 harness 的文章中，Birgitta Böckeler 提出了一种用于扩展代码代理 harness 的思维模型：该系统由指南和传感器组成，旨在提高生成优质代理输出的概率，并在问题到达人类视线之前实现自我修正。Birgitta 现已开始发表文章，阐述她利用传感器保持代码库可维护性的实践经验。本文部分聚焦于基础代码 linting 的静态分析。

最近的一次 retreat 探讨了代理编程（agentic programming）在软件开发未来中的应用。其中一个成功案例是利用大语言模型（LLMs）用 Rust 克隆了一个遗留编译器。与会者讨论了利用 LLMs 通过采访人类专家来验证复杂规范。一个关键收获是，理解组织的变更控制指南是洞察其历史的重要窗口。会议探讨了在 LLMs 背景下“提升并迁移”（lift and shift）迁移的影响，建议这应成为首要步骤。金融行业专业人士讨论了在多个司法管辖区管理软件所面临的挑战，并探索 LLMs 可能提供的帮助。文章强调，结对编程在代理软件开发背景下培养判断力的价值。作者指出，LLMs 在处理繁琐的数据转换编码方面表现出色。一位演讲者提出了对 AI 系统实施“混沌猴子”（Chaos Monkey）测试的必要性。文章还突出了软件开发者从 AI 的选择和模式中学习的潜力，将其视为一种优势。作者的肘部受伤引发其对技术如何影响工作的反思，并思考未来是否可采用语音输入。

文本探讨了利用语言学习模型（LLMs）生成和评估复杂任务的上下文，而非仅依赖人工撰写的文档。这涉及提示 LLM 对人员进行访谈，通过提问收集必要信息并生成上下文报告。作者从 Harper Reed 的博客中汲取灵感，强调 LLM 应一次只提出一个问题。另一种应用是利用质询式 LLM 对专家进行访谈，以评估文档的准确性，从而为人工审查提供替代方案。该方法可分阶段实施：首先用于文档创建，随后用于专家审查。该技术不仅适用于 LLM 场景，还能促进从难以写作的人员中提取知识。它有助于克服从写作困难者处获取信息的挑战，实现一种 AI 驱动的写作，即使其风格具有特定特征。最终，该方法论优先考虑信息的捕获与共享，即便其偏离传统写作偏好。这种方法利用了 LLM 在多样化情境中促进沟通与知识转移的能力。AI 生成的输出被认为优于信息缺失或撰写质量低劣的文档，尤其是在面对写作困难者时。该方法凸显了 LLM 在弥合沟通差距和改善协作工作流方面的潜力。

人类正越来越多地将代码编写工作委托给智能体。未来是否还会有源代码存在？要探讨这个问题，我们必须理解代码的本质。Unmesh Joshi 认为代码具有两个既独立又交织的目的：对机器的指令，以及对问题域的概念模型。他探讨了为何构建与机器对话的词汇表至关重要，编程语言如何作为思维工具，以及这些因素如何影响我们在与大语言模型协作的未来。

Rahul Garg 创建了一个开源框架 Lattice，通过嵌入工程最佳实践并构建上下文层，以提升 AI 辅助编程。Wei Zhang 和 Jessie Jie Xia 应高关注度更新了关于结构化提示驱动开发（SPDD）的文章，并新增了问答部分。Jessica Kerr 探讨了 AI 辅助开发中涉及的双重反馈回路，强调开发者塑造其开发环境的机会。Ashley MacIsaac 因 Google 的 AI 错误地将其识别为罪犯而对其提起诽谤诉讼。Stephen O'Grady 审视了包括 Amazon 和 Microsoft 在内的科技公司对 AI 的重大投资。Willem van den Ende 提出，本地开源 AI 模型对于编码任务可能已“足够好”，从而可能提供更大的控制力和数据安全性。这一策略可能效仿 Apple，后者并未在云端 AI 上投入巨资，或许正押注于本地 AI。随后文本引用了 Fred Brooks 的《人月神话》及软件“泥潭”（tar pit）。Kent Beck 的帖子讨论了使用 AI 进行编码所面临的挑战，以及内部质量可能遭遇的潜在陷阱。最终的问题是：AI 能否克服复杂性的挑战，还是将被其困住。

20 世纪 60 年代，Fred Brooks 领导了 IBM System/360 的开发工作，该项目塑造了他后来的见解。他于 1975 年出版的著作《人月神话》仍是软件开发领域的经典。尽管部分内容已过时，但它提供了至今仍具适用性的永恒启示。一个核心概念是布鲁克斯法则：向进度落后的项目中增加人手，只会使其更加延期。团队规模的扩大呈指数级增加沟通开销，从而阻碍进展。概念完整性（即系统设计的相互关联性）是该书的关键启示之一。布鲁克斯优先保证统一的设计，而非纳入零散的功能，强调简洁与直截了当。他认为，连贯的设计反映了一套统一的底层思想。这一概念显著影响了他的职业生涯与工作方式。该书还强调了周年纪念版的意义，原因在于其中收录了布鲁克斯具有影响力的论文《没有银弹》。

Chris Parsons 的最新指南强调利用人工智能进行编程，重点关注验证工作，以及从人工审查向自动化检查的转变。他倡导“代理工程”（agentic engineering），并突出了 Claude Code 和 Codex CLI 等工具的重要性。该指南将代码生成的速度置于次要地位，优先重视验证，致力于构建稳健的审查流程。程序员的核心理念正转向训练人工智能并塑造开发“驾驭机制”（harness）。文章引用了 Birgitta Böckeler 关于“驾驭工程”的研究，强调了计算传感器的优势。Adam Tornhill 的观点指出，函数长度与代码结构及意图密切相关。Nilay Patel 关于“软件大脑”世界观的见解提供了重要视角。文章还强调了一致的数据定义对于实现有效的人工智能交互至关重要。作者观察到，人工智能领域的专业人士正竞相让自己对 AI 工具变得“可解读”。此外，作者分享了自己使用人工智能的个人体验，并探讨了人工智能对工作产生的影响。

大型语言模型编程助手已展现出显著价值，但主要应用于个人开发者。ThoughtWorks 的内部 IT 组织已将其用于团队协作，并开发出一套名为“结构化提示驱动开发”（Structured Prompt-Driven Development, SPDD）的方法与工作流。Wei Zhang 和 Jessie Jie Xia 在 GitHub 上提供了该工作流的详细示例。该工作流将提示视为一等工件，与代码一同纳入版本控制，并用于使开发工作与业务需求保持一致。他们发现，开发者要高效使用该方法，需掌握三项关键技能：对齐（alignment）、优先抽象（abstraction-first）以及迭代审查（iterative review）。

Thoughtworks 发布了第 34 期技术雷达，对工具、技术、平台和编程语言进行了调研。该雷达强调人工智能（AI），促使人们重新审视基础软件开发实践，如结对编程和整洁代码。同时，它也指出由于智能体（agentic）工具的出现，命令行界面正迎来复兴。雷达还讨论了围绕大语言模型（LLM）的安全问题，特别是“权限饥渴型”智能体需要广泛访问权限，这可能带来提示注入等风险。为此，雷达探讨了“驾驭工程”（harness engineering）方法，以安全地管理这些雄心勃勃的智能体。文章质疑 AI 生成代码的质量，并引用了一个案例：未经人工审查的 AI 辅助代码变得难以维护。作者强调，即使在使用 AI 时，仍需人类监督以确保代码的持久性与可靠性。文中还提出了一个关于 LLM“代笔”的哲学性实验。此外，文章批评了直接申报税（Direct File）税收计划的被拆解，指出政府改革往往以复杂为掩护，具有欺骗性。文章将直接申报税所体现的公共服务精神与 DOGE 表现出的漠不关心形成对比，并强调高效税收体系对国家安全的至关重要性。

作者参加了务实峰会，并与 Kent Beck 和 Gergely Orosz 就人工智能（AI）展开讨论。对话涉及将 AI 与过去的技术变革进行类比、敏捷方法、测试驱动开发（TDD），以及在以 AI 为本的行业中生存所需的条件。作者反思了编程中“懒惰”这一美德，强调其在构建高效抽象中的重要性，并引用了 Bryan Cantrill 关于“懒惰”及其与编码相关性的观点。作者担忧，由于 AI 缺乏这种“懒惰”的美德，加之代码生成变得过于容易，可能导致系统过度复杂化。作者分享了自己重构代码以简化其结构的个人经历，并与使用大型语言模型（LLM）可能产生的结果形成对比。文章还介绍了 Jessica Kerr 将测试驱动开发应用于提示代理的案例。作者进一步探讨了 AI 过度自信及其编造信息的倾向，并引用电影《黑暗之星》（Dark Star）作为例证。作者强调，必须教导 AI 系统对其结论保持怀疑态度，尤其是在高风险或不可逆后果的情境下。作者认为，克制——即能够 refrain from action（ refrain 意为“克制、 refrain from doing something"）——是确保 AI 安全与负责任的自主性的关键能力。

昨晚，我观看了中央广场剧院的优秀剧目《破解密码》。该剧讲述了艾伦·图灵的故事，他对我的专业领域以及自由民主的命运都作出了里程碑式的贡献。如果您本月身处波士顿地区，非常值得一看。

作者一直在收听两档优秀的播客：一档由 Simon Willison 和 Lenny Rachitsky 主持，另一档则由 Gergely Orosz 采访 Uber 前首席技术官 Thuan Pham。Simon Willison 主持的播客对当今世界现状提供了连贯的概述，探讨了编程方式的演变以及该领域的重要模式；而 Gergely Orosz 主持的播客则深入剖析了 Uber 在微服务方面的实践，并提出了“牺牲性架构”的概念——即高增长软件必然需要频繁重构。作者还提到 Axios 近期遭遇了一起供应链攻击：攻击者花费数周时间与主要维护者建立联系，随后植入远程访问木马（RAT）。作者指出自己也曾成为类似攻击的目标，该攻击组织严密且极具迷惑性。此外，作者发现了 Diátaxis 这一技术文档组织框架，它将文档分为四类：教程、操作指南、参考手册和解释性内容。作者特别赞赏其对“教程”与“操作指南”的区分，以及将解释性内容独立成区的理念。作者还提及 Lalit Maganti 利用 AI 代理开发 SQLite 工具的经历，凸显了借助 AI 进行开发的机遇与风险。最后，作者引用 Ryan Avent 的一篇博文，强调以关怀为导向能带来对经济增长的重要视角：增长不应仅为增长而追求，而应着眼于其扩展集体能力、缓解苦难的能力。总体而言，作者的这篇帖子涵盖了从播客、供应链攻击到技术文档和 AI 开发等多个主题，突出了在各个领域中审慎思考与细致权衡的重要性。

作者分享了关于大型语言模型（LLM）和人工智能（AI）的看法，同时为假期做准备并反思行业趋势。关于AI对软件开发影响的调查常常忽略了LLM使用方式的多样性，这可能导致结果偏差。作者对编程的未来感到不确定，并鼓励大家尝试使用LLM并分享经验。他们认为AI热潮是一个泡沫，类似于过去的科技发展，尽管最终会破裂，但仍有可能带来持久的价值。作者将参加GOTO哥本哈根会议，与业内同行重新建立联系。LLM被视为“幻觉引擎”，强调了验证输出和考虑多种提示的重要性。软件工程可能会演变成包含非确定性，类似于其他工程学科。作者指出，LLM可能表现得像不靠谱的初级同事，提供误导性的结果。最后，作者强调了LLM带来的安全风险增加，特别是关于具有自主性的浏览器扩展。

一个常见的企业难题：关键的遗留系统变成了“黑匣子”——对运营至关重要，但难以理解且修改风险很高。Thiyagu Palanisamy 和 Chandirasekar Thiagarajan 与一位客户合作，利用 AI 辅助的逆向工程，从 UI 元素、二进制文件和数据溯源中重建功能规范，以克服分析瘫痪。他们开发了一种有条理的“多视角”方法——从可见的工件开始，逐步丰富，进行逻辑三角测量，并始终保留溯源。人工验证仍然是确保提取的功能准确性和信心的关键。这次合作表明，将系统从黑匣子转化为蓝图，能够为现代化决策提供动力，并加速迁移工作。

Bahmni 开源医院管理系统始于九年多前，前端使用 AngularJS 和 OpenMRS REST API。Rahul Ramesh 希望将其转换为使用 React + TypeScript 前端和 HL7 FHIR API。在探索如何进行现代化改造时，他使用了研究、审查和重建的结构化提示工作流程，并结合了 Cline、Claude 3.5 Sonnet、Atlassian MCP 服务器和文件系统 MCP 服务器。通常情况下，更改一个控件需要 3-6 天的手动工作，但借助这些工具，在不到一小时的时间内完成，成本不到 2 美元。

CLI 编码代理与聊天机器人或自动完成工具有着根本性的不同——它们是能够读取代码、运行测试并更新代码库的代理。Ben O'Mahony 解释说，虽然商业工具令人印象深刻，但它们无法理解我们环境的特定上下文以及我们特定项目的古怪之处。相反，我们可以通过组装开源工具，并针对测试、文档生成、代码推理和文件系统操作使用我们特定的开发标准，来构建自己的编码代理。

几周前，Unmesh Joshi 和我开始讨论他如何在使用 LLM 时构建一套抽象语言。我们认为这个话题可能会引起大家的兴趣，于是将其写成了一篇文章。我们探讨了编程是如何构建和应用抽象的，以及 LLM 在这两种活动中如何以不同的方式帮助我们。

作者开发了一种称为“扩展节点”的技术，以有效地管理演讲时间。这些是预先计划好的可选主题，可以简要或详细地介绍。这使得演讲者可以在不显得仓促或准备不足的情况下调整演示文稿的时长。每个扩展节点通常由一个包含关键短语的幻灯片组成，作为讨论的提示。如果时间紧迫，该主题会被快速总结，通常会声明其超出范围。反之，如果时间充裕，演讲者可以详细阐述可选材料。作者还掌握了在观众不察觉的情况下跳过幻灯片的技巧，这项技能需要控制笔记本电脑。这项技术提供了信心，特别是由于作者并没有广泛排练演讲。扩展节点被证明对于根据不同的时间段调整演讲和管理听众互动非常有价值。这些灵活的片段在演示文稿的结尾最有帮助，因为届时剩余时间最为明确。

OKR 已成为连接大型组织战略与执行的热门方式。但当它们自上而下层层传递时，往往会失去意义。团队接收到的目标并非自己参与制定的，结果是承诺薄弱，实际改变甚微。 Paulo Caroli 描述了高绩效团队可以如何以另一种方式工作。他们定义自己的目标，在一个采用协作流程的组织中，将团队的 OKR 与更广泛的战略对齐。通过这些团队 OKR，他们创建了共同的目标，并成为定期计划、签到和回顾循环的基础。

Sriram Narayan 在其《影响情报》文章的结尾，回应了关于这项活动的五个常见反对意见，包括速度变慢、缺乏敏捷性和协作性，以及创新的不可预测性。

像Cursor这样的AI编辑器可以使用LLM（大型语言模型）以惊人的速度生成代码，处理样板代码，并为各种任务提供功能性代码片段。然而，在构建强大的系统时，功能正确性只是起点。代码还必须是安全的、可预测的、可维护的，并且没有微妙的副作用。Unmesh Joshi通过开发者和LLM之间的对话，演示了如何通过专家的指导，将最初可能不安全的代码片段转化为强大的、系统就绪的组件。

有些人问到了这些社交媒体帖子中的链接被多少人点击了。我在文章中添加了一些内容，部分是为了解释为什么我没有这些信息，部分是为了展示网站流量的整体来源数据。