那时，那种方式曾被认为极其低效。如今，我自己又在使用类似的方式。这种熟悉感，让我想重新审视当年的判断。

远程开发的基本思路一直很直接：把开发环境和任务放在另一台机器上，连接过去操作。那台机器可以是云服务器，也可以是家里的一台 Mac mini。

节目里提到的好处也很实在：

• 合上笔记本，远程任务还能继续运行。
• 后台进程移到另一台机器上，笔记本更省电、负担更轻。
• 换一台设备，仍然可以接着查看和操作同一批任务。

我觉得，值得关注的变化是开发者与机器之间的工作节奏。

当开发过程需要人持续操作、即时反馈时，远程连接中的延迟和摩擦会不断打断思路。一次很小的等待，重复几百次，就会成为明显的效率损失。

使用 Codex 这类编程工具后，工作中多了一种节奏：描述任务，让它执行，再回来检查结果、调整方向。对于能够独立运行一段时间的任务，开发环境持续在线、随时可以接入，就更有价值。

当然，长时间构建和后台任务十几年前就存在，今天的开发也仍然需要大量即时交互。AI 并没有让过去的问题自动消失。

同一种架构是否高效，需要放回具体的工作方式里判断。

这次听播客，也让我开始用更完整的尺度看待自己的远程开发体验：从布置任务到检查、修正和验收结果，整个过程究竟节省了多少时间，又增加了多少维护成本？

十几年前的体验值得记住，今天的实践也值得重新衡量。

你经历过早期的远程开发吗？AI 编程工具改变了你的看法吗？

播客原文：https://syntax.fm/1023

#RemoteDevelopment #Codex #DeveloperExperience

这个问题，把 AI 编程带来的效率提升和能力焦虑放在了一起。

在 Syntax #1031 中，Scott Tolinski 和 Wes Bos 的讨论，有几个值得认真思考的观点。

Scott 强调的是：技能需要持续使用。

当我们不再亲自练习，也不再主动理解实现过程，相关能力就会逐渐生疏。他反复提到一个词：active participant——主动参与者。

即使代码由 AI 写，我们也需要参与推理、理解过程，并判断结果。

Wes 则区分了两种容易混淆的“退化”。

一种是忘记语法细节，比如 reduce 回调的参数顺序。

另一种是不再理解程序如何工作：一个请求如何流经应用，API 如何调用，各个模块怎样协作，性能问题可能出在哪里。

前者可以借助工具补足，后者直接影响解决问题的能力。

他尤其担心一种变化：AI 让“不读代码也能推进项目”变得容易，我们可能慢慢失去追问“它为什么这样工作”的习惯。接受第一版输出，也就替代了原本的研究、判断和学习。

注意力的变化，会进一步放大这个问题。

Scott 坦言，等待 AI 回复时，他很容易切换到其他事情，甚至同时打开了 13 个项目。任务看起来都在推进，自己却越来越难深入其中。

Wes 也更难找回过去的编程心流。不过，在研究问题、设计架构、选择技术，以及借助 AI 探索陌生领域时，他仍然能获得那种专注和兴奋。

这段讨论给我的启发是：评价自己有没有成长，需要同时看交付结果和理解程度。

面对 AI 生成的代码，可以给自己留三个检查点：

• 我能解释它为什么这样工作吗？
• 它出问题时，我知道从哪里开始排查吗？
• 我能判断这个方案的取舍，以及它需要怎样验证吗？

代码可以交给 AI 生成，理解和判断仍然需要持续练习。

你在使用 AI 编程时，会刻意保留哪些自己动手或独立思考的环节？

播客原文：https://syntax.fm/1031

#AI编程 #软件工程 #开发者成长

Codex 联合创建者 Tibo Sottiaux 在 The Pragmatic Engineer 的访谈中，提出了一个值得思考的观点：Code Review 同时承担着检查正确性、交换知识和对齐意图的职责。AI 正在改变这些职责的分工。

据他介绍，OpenAI 已将 AI 安全检查纳入 PR 流程，发现安全问题时会阻止合并。模型还能沿着依赖关系深入检查，发现文档描述与实际实现之间的差异——这些问题往往需要人工花很长时间才能定位。

他认为，正确性和安全检查会越来越多地被自动化。而团队仍然需要认真讨论：

• 我们究竟想解决什么问题？
• 这个改动是否值得做？
• 系统应该保证什么，又接受哪些取舍？

这些讨论，最好在写代码之前发生。

过去，PR 经常成为需求和设计讨论的最后一道关口：代码已经写完，大家才开始追问目标是否合理。AI 加快实现速度后，如果团队仍然等到 Review 才对齐意图，返工也可能随之加速。

这给工程团队一个很具体的启发：在加强自动审查的同时，把需求、接口契约和验收标准讨论得更清楚、更早。

代码审查的演进，也需要协作方式一起改变。

#CodeReview #SoftwareEngineering #AI #EngineeringLeadership

来源：The Pragmatic Engineer｜Building Codex with Tibo Sottiaux

这个例子提醒我，生成代码只是交付过程中的一个环节。

自己逐步实现功能时，也在建立对需求、数据流和边界的理解。接收 AI 生成的结果后，这些理解可能需要重新补上。

比如，一个导出功能很快就写好了，但数据范围是否正确、失败时如何处理、是否符合现有接口约定，仍需要有人判断和验证。

再加上不断回答问题、查看进度、在多个 Agent 之间切换，节省下来的实现时间，可能变成了更密集的审查和决策。

团队也会遇到同样的问题：如果待审改动增加的速度持续超过审查完成的速度，积压就会越来越多。

所以，我更关心的是：从提出需求到完成交付，团队总共投入了多少实现、理解、审查和返工的时间。

几个调整值得尝试：

• 让每份改动有明确的目的和验证方式，减少一次接收大量陌生代码的负担。
• 提前约定常规事项的处理方式，把人的注意力留给重要取舍，减少反复确认。
• 按团队的审查能力控制并行任务，给已有工作留出完成的空间。

对于熟悉的小改动，直接动手写也可以是高效选择。AI 参与到什么程度，可以随任务调整。

在你的团队里，哪些调整让 AI 编程更省力？

讨论来源：Syntax #1039，26:19 起 https://syntax.fm/1039

#AICoding #SoftwareEngineering #DeveloperExperience