标签
Gergely Orosz 推荐了 Dr Cat Hicks 的新书《Psychology of Software Teams》（《软件团队心理学》），指出企业常常误解开发者的工作方式——而如今 AI 突然涌入职场，更让这一问题雪上加霜。
一条推文感慨如今的软件工程师都变成了「高级智能体管理员」，反映了 AI 编程助手对开发者工作方式的影响。
Grok Bot 团队的 @poteto（Lauren）提出信任 AI Agent 成果的四层“倒金字塔”框架：把精力优先投入代码库改造与静态分析，而非规则文件与人工审查，主张通过工程化环境让 Agent 默认做对。
开发者并未被 AI 取代，但 AI 取代了「理解自己代码」的环节：代码由模型生成后无人真正读过，调试退化为把报错喂回模型。文章引用 Veracode 对 100+ 模型的测试（45% 生成代码存在已知安全问题），质疑这种「用理解换速度」的权衡是否会反噬整个行业。
Zach Lloyd 分享了他在 AI Engineer NYC 的演讲，认为软件工程正在演变为工厂工程，并指出工厂基准测试正在成为工程师需要关注的新兴领域。
Gergely Orosz 引用了工程师 Cindy Sridharan 的观点：Claude 在通过定制的 claude.md 获得恰当的指令和上下文后，现在写出的代码几乎总是比她自己写的更好。
斯坦福HAI的一篇报道指出，AI编程代理在团队协作方面表现不佳，单兵作战尚可但难以在协作式软件开发场景中有效配合。
SVPino 认为，AI 工具提升开发者效率后将出现杰文斯悖论，软件和软件工程师的总需求不降反升。
SlopCodeBench 的 10/2026 更新显示，Opus 5.5 与 Astra 在整体表现中领先，而 xhigh 被认为存在负面影响。该基准通过逐步披露功能检查点、让模型在继承同一代码库的多阶段挑战中工作，更贴近真实软件开发流程。
一篇个人博客文章，作者分享自己宗教研究学位如何在软件工程职业生涯中发挥作用，探讨意识形态与编程如何同时作用于人类与社会，以及内部人/外部人视角在理解复杂信念体系中的价值。
OpenHands 宣布成为 NVIDIA Nemotron 3.5 Super VL 的发布合作伙伴，将这款开放多模态模型引入长期运行的软件工程智能体工作流，使智能体能够理解截图、仪表盘、文档和图表等非文本上下文。
斯科特·阿伦森反思了人工智能在数学领域的飞速进步如何让此前对人工智能取代软件工程师的怀疑显得难以成立。他认为，数学代表着人类智力的巅峰，而如今这一领域正受到人工智能的挑战。
Gergely Orosz 的 Pragmatic Engineer 通讯文章回顾 2025 年软件工程与 LLM 的结合现状，涵盖 Anthropic、Cursor、Google、Amazon 等公司如何使用 Claude Code、Cursor、Windsurf 等 AI 开发工具，以及资深工程师们的观察。
一份关于 C++26 契约特性（P2900）的入门教程，介绍前置条件与后置条件如何取代传统的基于 assert 的检查，并涵盖编译器选项、求值语义及常见陷阱。
一位刚晋升为工程主管的博主反思：如今技术面试普遍要求使用 LLM，但 AI 编码工具的订阅费用却可能把经济拮据的优秀工程师挡在门外，他分享了如何调整招聘流程来降低候选人的成本负担。
一位从业者认为，AI 智能体开发者正在重新发现一些基础软件工程早已解决的问题，例如输入验证、数据建模、进程隔离和访问控制，而氛围编程却忽略了这些贯穿各个环节的共性问题。文章呼吁将成熟的设计与架构原则应用于智能体工作流。
该论文通过系统文献综述与128位从业者评估，提出并验证了AI鲁棒性审计框架的44项元需求（分为16个类别），以帮助组织构建和评估AI鲁棒性审计框架。
一篇深度分析文章探讨为什么给软件项目增加更多 AI 代理并不能缩短交付周期，借弗雷德·布鲁克斯的《人月神话》类比指出瓶颈在于决策、验证与协调，并结合 Google Research、Cursor 和 Anthropic 的实验说明输出规模只有在有良好组织结构时才能真正扩展。
一条带有讽刺意味的推文，感慨“软件已死”，哀叹多年积累的解决难题的技能似乎不再有用，暗指 AI 编程工具对软件开发行业的影响。
trq212 和 fnthawar 讨论了使用 coding agent 时的关键能力——「深入细节」。就像经营一家公司一样，你不可能知晓一切，但对正确的细节（代码、架构、设计、UX）保持极致的关注，才是做出卓越产品的关键。