Piglei 用「框架 vs 库」的区分来审视 AI 编程：框架掌握程序的整体结构，以极低的表面认知成本换取便利，而当下 AI 编程工具正被普遍当作这样的框架使用。文章以 Django REST Framework 为例——继承 ModelViewSet 只需一个 class 加三个属性就能生成整套 CRUD API，但要定制 create 的响应体、或给 list 加过滤条件，就得重写 get_queryset 等多个方法并堆上 if/else 补丁；改用不含魔法的 ViewSet 后代码变长，被藏起来的认知债务却浮出水面。作者认为框架的两个固有问题在 AI 编程上同样成立：抽象泄露（自然语言提示词失灵时，只能撕开抽象、精确到变量名去定位根因）与控制权丧失（Vibe Coding 把结构决策全交给 Agent）。他的建议是把 AI 当库用：寻找提示词的甜蜜区而非追求绝对最少的提示词，作为总设计师关注程序结构并把约束写进 AGENTS.md，并审查 AI 生成的代码。适合正在把 AI 引入日常开发的工程师。
Laravel 在 Socialite、Scout 等包仓库关闭了 issue 创建入口，改为引导贡献者直接提 pull request，主框架仓库暂未受影响。作者以开源维护者身份逐条列出顾虑：强制提 PR 确实能省下维护者的 triage 时间，但在 AI 辅助下提 PR 的成本已接近提 issue，而 LLM 生成的补丁需要更多审查精力；同一个 bug 引发的重复 PR 还会让 GitHub Actions 反复触发，这一点 issue 不存在。更关键的是，要求 PR 是把贡献门槛抬高而非降低，会用不起 AI 工具、或还没积累足够经验的开发者排除在外——而作者自己当年正是从给 Laravel 提 issue 起步的。全文没有硬结论，只把 trade-off 摆出来，适合关注开源维护、issue/PR 流程与 AI 编码影响的一线工程师阅读。
Martin Fowler 反驳了一个常见取舍：花时间打磨软件质量，还是尽快交付功能？他把软件质量拆成用户可感知的 external quality（界面、缺陷）和用户看不见的 internal quality（架构、命名、模块划分）。用户愿意为前者多付钱，却无法判断后者，于是内部质量常被当成可以砍掉的开销。Fowler 的论点是：internal quality 的作用是降低未来每次改动的成本，其成本实为负值。他用累积功能量对时间的伪曲线说明，低内部质量的项目初期推进快，随后 cruft 迅速堆积，改动越来越慢；他访谈的资深开发者表示，劣质代码数周内就会显著拖慢进度。文章也承认顶尖团队同样会产生 cruft，差别在于他们用自动化测试、频繁 refactor 和 continuous integration 把它压住。作者坦承软件产出无法测量，因此结论依赖经验判断而非数据。适合需要向管理层解释重构价值的工程师。
2006 年，作者在纽约杂志数字团队用 MySQL 4 加 Perl 给时装周做分面搜索：秀场图按「2006」「bag」「red」等标签分类，用户可下钻筛选，每个属性还要带精确计数。当时 Solr facets 尚不存在，Autonomy 的计数不对，Endeca 刚出隐身期，三个人的团队只能自己啃 SQL，靠 EXPLAIN、GROUP BY 和反复调 MySQL 服务器参数把延迟压下去。 二十年后作者看到的却是相反趋势：工程师给普通规模的问题上 DynamoDB 这类「行星级」数据库，却对自己正在用的关系库缺乏基本掌握。文中复述一次电商事故——商品列表页要 10 秒以上，且无流量时一样慢，同一页面同时踩了缺索引、ORM 循环逐条查询（单页 200–500 条 SQL）、SELECT 全部列三个坑。作者的主张是：现代 RDBMS 在被证明有罪之前都是清白的，举证责任几乎全在工程师身上；文末给出排障顺序（慢查询日志 → 高频查询 → EXPLAIN → 只取必要列 → 必要时写原生 SQL）与三类反模式。适合后端与数据工程师。
作者把技术债分成三类：审美债（只犯强迫症，不影响用户和交付速度，交给自动化代码分析就行）、可延期债（范围可控，需要在 sprint 里逐步销账）、毒性债（半成品变成 workaround 磁铁，新功能一层层叠在上面，越拖越大）。毒性债的两个典型来源是缺测试和缺文档：没有集成测试兜底，就不敢对代码动大锤；没有 README 和 runbook，每次复现 bug 都要重新逆向一遍系统，这是有实际美元成本的时间损耗。作者还主张 TODO 注释基本等于永不做，应该把它变成看板上的正式卡片，并给债务故事打标签，让团队能看清新功能与债务的比例。债务列永远不会空，但也不能失控增长。适合一线工程师和技术负责人。
作者把「产品意识」拆成可观察的行为：这类工程师不满足于拿到 spec 就开写，而是先追问 why，主动挑战需求，并同时评估产品与工程两侧的取舍。文中给出 9 个特质，包括主动接触业务与用户数据、与非工程角色建立关系、用「最小可爱产品」标准处理 edge case、上线后持续追用户行为指标直到得出结论。作者认为产品直觉来自反复的项目循环——提问、给方案、快速验证、复盘落差、再提问——循环越多，建议越准，最终成为 PM 在立项前就会来问的人。面向做用户侧功能、与 PM 协作的工程师，末尾附了 6 条可执行的练法。
Ted Neward 逐条拆解微服务的卖点：文中引用的六条好处，两条来自微服务文献，两条来自二十年前的 EJB 宣传，两条来自四十多年前的 Oracle Tuxedo 文档。剥掉包装后剩下的是 1971 年 Parnas 论文里的“模块”——独立构建、版本化、部署、可复用的代码单元；CLR 的 assembly、JVM 的 JAR、操作系统的动态库都是它，Unix 的 pipes-and-filters 早在 70 年代就在讲同一件事。作者认为企业真正买到的是组织清晰度：小团队自己掌握分析、测试、数据、部署等依赖，不再被 DBA、QA、基础设施团队阻塞，代价是团队必须具备全套技能并承担 on-call。技术代价则是把进程内模块调用换成跨网络调用，延迟增加五到七个数量级，并且撞上分布式计算的谬误——加节点只会让它更糟。结论：模块或独立进程加统一 API 约定即可，组织依赖要在组织层面解决。适合架构师与技术负责人。
Simple Thread 联合创始人回顾 20 年工程生涯，先交代自己的经验边界：前半段在小公司和创业团队，之后做咨询接触大企业，再把公司从 2 人带到 25 人，因此这些判断都带有『人少、要交付、还要维护老系统』的前提。文中 20 条多半反直觉：最难的是做对的东西而非写好代码；最好的代码是不用写的代码；系统终将变烂，该追求可持续改进而非完美；10x 程序员是神话，真正该做的是别让 0.1x 程序员进团队；数据比代码库活得更久；面试几乎无法预测一个人是否是好的队友；技术选型要看存活多年的『鲨鱼』而非新潮工具。适合希望校准自己工程判断的一线开发者，也可当团队讨论素材。
antirez 以 Redis unstable 分支（32e0d237）源码为例，把代码注释拆成九类：function、design、why、teacher、checklist、guide 六类有益，trivial、debt、backup 三类可疑。他反驳“代码够好就不需要注释”的常见观点，理由有两条：注释不是在复述代码做了什么，而是补上单读局部代码拿不到的信息（为什么这样做、为什么不选看起来更自然的写法）；注释也是降低读者认知负荷的工具，scripting.c 里逐行标注 Lua 栈布局即是例证。文中逐类给出判定标准与取舍：design 注释让简化方案显得出于考量而非偷懒；teacher 注释扩大能读懂这段代码的人群；checklist 注释源于 4 bit type 这类无法中心化的设计；debt 注释（TODO/FIXME）应尽量挪到文件顶部或当场修掉；backup 注释在 Git 时代没有存在理由。适合长期维护大型系统代码库的工程师。
作者主张把代码行数视为“花掉的行数”而非“产出的行数”：每行代码都要持续支付维护成本，而为提高复用率构建的抽象会把调用方绑死在实现的显式与隐式行为上，让后续变更代价更高。因此目标应是可删除（disposable），而非可复用、可扩展。文中给出递进策略：能不写就不写；先复制粘贴几次再提取函数；把无状态、与应用无关的代码放进 util 并一工具一文件；接受 boilerplate 换来的灵活性；像 requests 包住 urllib3 那样把 policy 与 protocol 分层；允许业务逻辑先做成一坨泥巴；按“不与谁共享”而非功能拆分模块；用统一接口、HTTP 缓存与 CDN、feature flag 制造可替换点；错误处理放在端到端的最外层，如同 Erlang 监督树用 fail-fast 重启替代就地恢复。适合维护长期演进代码库的工程师与设计者。
Julia Evans 认为提问是一项可以练出来的工程技能，并把方法拆成可操作的几步：先陈述自己对主题的现有理解，再问『这样对吗』；把『SQL join 怎么工作』这类宽泛问题改写成答案明确的事实问题（例如 join N 与 M 两张表的时间复杂度是 O(NM) 还是 O(NlogN)+O(MlogM)，MySQL 是否先排序 join 列）。她给出的实例包括：在 rkt-dev mailing list 上先写清 rkt 与 Docker 在磁盘上存容器镜像的差异，再问为什么这样设计；入职数据团队时给 Hadoop、Scalding、Hive、Impala、HDFS 等术语建了一份词典。文中还讨论了如何选人提问（对方答一题 5 分钟、能省自己 2 小时才划算；不必事事找最资深的人）以及提问者与回答者共同承担的责任。作者明确表示问『笨问题』无妨，也批评 ESR《提问的智慧》把全部成本压给提问者。适合正在 ramp-up 的一线工程师与需要跨团队取信息的人。
Joel Spolsky 从 TCP 讲起：TCP 承诺可靠、有序、不损坏的传输，底层却是会丢包、乱序、损坏的 IP，靠重传和重排把不可靠伪装成可靠——这就是抽象。文章的核心论断是：所有非平凡的抽象都会泄漏。二维数组按行还是按列遍历，缺页次数可能差出几个数量级；逻辑等价的 SQL 多加一句 a=c 可能快上千倍；C++ string 类再努力也写不出 "foo" + "bar"，因为字面量永远是 char*；NFS 挂载的 home 目录在服务器宕机时会让 .forward 邮件直接丢失；ASP.NET 用一段 onclick JavaScript 假装超链接能提交表单，用户禁用 JS 就全线失效。结论对工程师有实际后果：抽象省下写代码的时间，不省学习的时间；工具层次越高，出问题时越需要往下钻。适合做系统、工具链和框架的一线工程师。
作者列出自己构建软件时遵循的一组原则，主线是让系统更简单：让非法状态无法表示、保证数据一致性、先设计数据再写代码、测量之后再优化。文中用一个数据库例子说明不一致的代价——必须保持 x=y 的两个布尔变量一旦拆到不同库、无法原子更新，数据就多出两种状态，toggle 函数在这些状态下没有正确答案。作者认为一致性是当下最被低估的工程原则，多数问题本质上都是数据不符合预期；他同时主张代码一致性优先于局部「正确」，学习应聚焦 concepts（关系模型、代数数据类型、borrow checker、Curry-Howard 同构）而非 React、Kubernetes 的表层细节。适合做后端与数据系统设计、正在权衡微服务拆分和 schema 取舍的工程师。
一位创业公司 CTO 复盘自己推行“文档优先”的整套做法：用一页纸代替半小时站会、把文档工时显式写进排期、给每个 feature 合并时附一段“为什么选 X 不选 Y”。他也承认过度文档会反噬（过时页面比没有更糟），因此只记录能活过一个季度的 80% 内容，并用一条轻量 CI 检查强制新埋点必须配 wiki 条目。文中给出 ADR、incident post-mortem、Diátaxis、docs gardener 等具体机制，适合正在搭建工程规范的中小团队负责人与一线工程师参考。
Michael Lynch 指出，多数代码评审文章只关心「找 Bug」，几乎不谈如何把问题讲清楚，结果把评审变成对作者的人身评判。本文把评审同时当作技术过程与社交过程，给出一组可直接落地的做法：把空白格式、构建、测试、lint 等机械检查交给 CI 和 formatter；用 style guide 终结风格争论；收到 changelist 后立即开始评审，单轮返工上限一个工作日；单轮批注控制在 20-50 条以内，先给高层设计意见再抠细节；用可运行的代码示例代替口头说明；批注里避免出现 "you"，改用 "we"、省略主语或改写为问句；把命令改成请求；把每条意见挂到具体原则上并附上风格指南或文档链接。适合正在设计团队评审流程、或想改善评审沟通方式的工程师。
本文由 2026 年 Bun 从 Zig 迁移至 Rust、以及 Andrew Kelley 与 Jarred Sumner 的公开争执切入，追问软件生产究竟是手艺（craft）还是工业。作者串联 tabs vs spaces 争论、自动格式化兴起、Go 语言设计背后的“去技能化+劳动强化”、Clojure 式手工理想，以及木工职业者与爱好者的分工，并以美国安全带强制立法历史比喻类型系统和 Rust 借用检查。他认为 slop 本质是主观判断，并预言 coding agent 会加速软件工业化：语言锁定消退、手写代码被自动重写、质量被量化并自动化。文章证据以史料和引文为主，非实操指南，适合关心 AI 编程浪潮下工程文化变迁的工程师阅读。
作者结合多年外包经验论证：软件开发的最大成本不是写出代码，而是把系统装进脑袋——即建立心智模型（mental model）。理解 getUserPreferences(userId) 这样的函数，往往要沿着数据库 schema、API 定义、缓存层、错误处理和调用点反复跳转；新代码和 AI 生成的代码都不免这一步。LLM 把生成成本压到极低，也把阅读负担推到更大的规模，甚至出现律师提交 ChatGPT 虚构判例这类事故——不是不愿读，是读太贵。文章因此建议：把 AI 用在解释既有代码、加快建模，而不是产生更多代码；团队效率也不该按生成行数衡量，而应按建立准确心智模型的速度衡量。适合以 AI 辅助编程却怀疑“产出量”指标的工程读者。
随着 Zapier、Nubank、Goldman Sachs 等公司把编码任务大规模交给 AI 代理，行业内出现了一种“代码工厂”：生成速度提高 10 倍，但测试和 QA 验证并没有跟上。文章指出，AI 生成的代码被默认当作生产就绪，验证成了被跳过或浅覆盖的环节，并引用了“变更失败率上升 30%、每 PR 事故上升 23.5%”等未经注明的数据。作者认为行覆盖率不能代表真实用户流程，测试必须成为自主流水线：可扩展、测真实流程、独立于编码代理并自我维护，否则只会用虚假测试放大盲点。后半部分是 QA Wolf 的平台功能介绍。适合关注 AI 编码质量和测试策略的工程团队阅读，但需注意内容带有厂商推广立场。
Jujutsu（jj）是一个用 Rust 实现的开源版本控制系统，目标是在兼容 Git 生态的同时，把常见版本控制操作变得简单直接。它以“工作副本即提交”为核心设计：文件一旦改动，系统就会自动生成提交快照，配合操作日志可以对任意操作进行撤销/重做。合并冲突也被建模成一级对象，不再只是文本标记，从而让冲突解决与历史改写更可控。项目可直接在现有 Git 仓库中使用，也支持独立运行。适合想了解新一代 VCS 设计、Git 替代方案与 Rust 工具链的工程师阅读。
文章以两条业务环路解释资深工程师的核心工作：市场/业务端靠快速试错来降低不确定性，服务端则靠稳定、可理解、可调试的代码来控制复杂度。两者在公司里并行运转，导致工程师反复追问'为什么又要加功能'，而业务方困惑'为什么就是不做'。作者认为高级工程师真正擅长的是拒绝不必要的构建、复用已有能力，并把这种能力包装成一个问句——'Can we try something quicker?'——来同时回应业务对速度的渴求与自己对复杂度的警惕。他还进一步提出为速度与稳定各建一套系统（Speed 版与 Scale 版）的解耦思路，并指出 AI 在加速市场反馈环路的同时，正在破坏系统的可理解性且不承担任何责任。适合关注组织沟通、系统演进与 AI 时代工程职责的工程师阅读。
工厂工人直言不信任软件工程师：图纸和模型可以在纸面完美，但传感器积尘、零件批次差异、冷启动阀门卡滞，这些现场条件才决定系统安全。好工程恰恰同意这一点——NASA、航空、核工业不依赖“找到优秀工程师并信任他”，而是围绕“工程师可能出错”设计流程：风险分析、需求追溯、独立验证、运行证据。AI让写代码变得廉价，也暴露了普通软件工程的反向结构：需求是一行Jira ticket，设计理由住在某人脑子里，代码被当成唯一真实，验证只是绿色CI。文章主张把工程从写代码移回“让意图显式，给义务配证据”，区分验证与确认，按风险调用冗余度。最后引向作者所在产品 ReqProof，但其核心观点可独立存在。
这是一篇个人随笔，作者从冒充者综合征谈起，反思智能体编程热潮中被忽略的软件工程基本功。作者认为 agent harnesses 已经跨过“能不能做到”的门槛，但要写出可调试、可维护、分层且可组合的软件，仍然需要大量细致的人类判断。LLM 并不真正推理，只是在预测压缩后的人类知识，因此关键是给它简洁、及时的数据，并用带有自然语言反馈的确定性验证工具来纠错。文中引用了 The Illusion of Thinking 论文、JEPA 模型与 Yann LeCun 的研究，也提到 Simon Willison 提出的 lethal trifecta，说明模型无法区分好建议与坏建议、难以抵御提示注入。作者强调，无论是否有智能体辅助，评审、规划并修补软件接缝都是核心技能，当下更需要关注这些基本功。适合关注 AI 编程工具与软件工程质量的一线工程师阅读。
Andrew Ng 团队基于 1 万多条招聘信息、数十次专家访谈与问卷调查，发布 AI 工程技能图谱，将开发者应掌握的能力归纳为四项：构建与部署 AI 应用、软件工程基础、高效使用编码 agent、以及参与定义需求（shaping the build）。文章指出，AI 应用输出不可预测，因此需要借助统计方法与系统化的 eval 和错误分析来加以约束；软件工程知识决定了你能否用好编码 agent，而 agent 能力增强后，工程师的价值正从实现转向定义 spec 与做出成本、扩展性、安全之间的权衡。适用于想规划学习路径的开发者，以及希望以更准确标准招聘 AI 工程师的团队。
本文是一篇 AI 工程师的角色入门导读，基于 Latent Space 的《The Rise of the AI Engineer》展开。核心论点是用 API 边界区分 AI 工程师与 ML 工程师：前者调用模型构建应用，后者构建模型服务本身。文章明确 AI 工程师不需要线性代数或从零训练模型，但需要扎实的软件工程基础、评测体系与反馈回路设计；它同时澄清 AI 工程师与使用 Copilot/Cursor 的 AI 辅助开发者的区别，并认为 Web 开发者的交付导向习惯可直接迁移。文中还插入了 AI Hero 技能包的推广块，内容整体偏定义介绍而非实操细节。
Cloudflare 认为 AI 让软件开发中最慢最贵的“实现”环节变得又快又便宜，瓶颈因此转移到 SDLC 的其余阶段：开源维护者被 PR 淹没，生产工程师疲于应对更快的交付节奏。他们的答案是让 Agent 接管更多环节，并发布了一组配套工具：@cloudflare/ci、本地开发环境的 OpenTelemetry traces、Agent Traces，以及借 Workflows 编排 CI/CD 的完整方案。文章用代码示例展示了如何在 Workflow 中并行执行 lint/test/typecheck/build，并指出 CI/CD pipeline 只是 Workflow 的一种特例——Workflow 还能派生容器、Agent 和浏览器，并持久化状态数小时到数周。针对软件工厂，文章提出平台必须满足的七项要求：程序化、可横向扩展、可复现、实时推送、原子、可升级权限、自改进。适合在 Cloudflare 上构建 Agent 基础设施或探索自主交付管线的工程师。
本文编译自UC Berkeley RDI研究者的立场论文，提出软件自主性的三级框架：代码自主、流程自主、需求自主，并引入规约细节度、时间自主性、监督模式三个正交维度。作者用16个并行Claude代理以不到2万美元构建C编译器的案例说明当前能力边界：独立任务可行，但持续演化基准下仍难保持架构一致性。文章主张按等级设准入门槛，警惕跨级落地；当编码不再稀缺，需求规范、智能体验证与治理责任将成为新核心。适合关注AI工程化、智能体治理与软件工程演进的工程师。
本文作者以在芯片公司Centaur的测试经验为背景，探讨了LLM驱动的智能体（agent）在软件工程中的测试与编码实践。核心观点包括：Centaur的无代码审查、模糊测试为主的工作流在AI时代依然高效，每年仅出现<1个重大用户可见bug；LLM直接生成的测试质量较差，但通过定向提示进行模糊测试可在数分钟内发现真实漏洞；LLM方差极大，同一模型在不同任务上表现迥异，使得公共基准测试的单一排名缺乏实际指导意义；作者还分享了在构建超人类棋盘游戏AI时的系统性方法——基于数据和分析而非盲目提示。文章适用于对AI辅助软件工程、测试自动化及高效agent工作流感兴趣的工程师。
本文作者提出，代码库的结构远比提示词或AGENTS.md文件更能影响AI代理的输出质量。核心观点是采用《软件设计哲学》中的“深模块”原则：每个模块通过简单接口暴露大量实现逻辑，AI代理只需理解接口，无需深入内部。作者进一步提出“灰盒模块”概念——开发者定义并锁定接口行为（通过测试），AI负责实现内部细节。这种方式能改善AI的反馈循环（测试即反馈）、导航效率（文件系统直接映射心智模型）并降低认知负担（开发者只需关注7-8个模块边界）。文章也指出TypeScript中强制边界不易，推荐使用Effect库。适合正在优化AI编码工作流的工程师阅读。