Vercel CEO Guillermo Rauch
Guillermo Rauch 用 WebGL2 和 Web Audio 做了一台虚拟唱机。程序先把音乐转换成唱片沟槽的形状，再让模拟唱针每秒采样 38.4 万次，把运动换成唱头感应电压对应的声音。按他的介绍，爆音、转速波动和内圈音色变化由模拟过程产生。页面也允许用户像 DJ 一样操作唱片。Rauch 说曲目来自公版或采用知识共享许可，并提供了可二次创作的代码入口。
Builder Zara Zhang
Zara Zhang 说，做产品的乐趣来自技术的可预测性与人的不可预测性碰在一起。她也逐渐少用“vibe coding”一词，因为这个叫法容易让人以为作者在成品上没花心思。她观察到，有些人即使用 AI 工具写代码，也会为作品投入大量精力。
OpenAI Codex 产品团队 Nan Yu
Nan Yu 建议从最直白、足以解决问题的架构或交互做起，再通过迭代把它变简洁。太巧的设计也要求用户跟得上设计者的思路。他说，AI 让目标清楚时更容易直达方案，目标模糊时也更容易花钱交付一堆没用的东西。
曾在 Cursor、Notion 和 Stripe 做设计的 Ryo Lu
Ryo Lu 发布了 AI Engineer 上海演讲的完整视频，配有中英文字幕。他在原帖提出一个问题：“当我们什么都能做时，还知道自己想要什么吗？”他还说幻灯片逐页在 Keynote 里手工制作。
Y Combinator CEO Garry Tan
Garry Tan 认为，前沿模型让修改软件的摩擦下降，也让日常缺陷更难忍受。他预计个人按需软件会越来越常见。另一条里，他说自己的 gstack-evals 尝试复现 Jev Engineering 文章里的实验，报告得到了类似结果，且 particle-1 在他的尝试中表现更好。原帖简述的是他自己的复现判断，未列出完整实验条件。
Box CEO Aaron Levie
Aaron Levie 认为，有些数字工作可以拆给多个 Agent 并行做，增加算力可能缩短用时或扩大检查范围。他把代码、安全和科研列为例子，对生产力上限的说法是预测。他建议每隔三到六个月重试原先做不成的任务，观察模型能否借助现成工具完成具体流程。他举的例子包括安全工具和数据源、跨系统迁移及 CAD。
FPV Ventures 合伙人 Nikunj Kothari
Nikunj Kothari 建议，想在旧金山认识同行时，可以先给对方看一件具体的作品，或者写一封有明确来意的短邮件。他举的例子包括已上线的副项目、自己组织的聚会和几行有针对性的私信。他说，即使用 AI 写作变容易了，他仍更愿意和花心思准备的人见面。
Latent Space — [One Million AI Engineer Special] How Stanford Teaches AI-Native Engineering — Mihail Eric, Monaco
核心要点：Mihail Eric 把斯坦福的 AI 编程课推进到真实开源仓库。学生要让维护者看懂并接受变更，也要知道 Agent 的上下文和验证条件从哪里来。
Monaco 的 AI 负责人 Mihail Eric 在斯坦福讲授 CS146S。首轮课里，他发现有些作业可以用一次提示做完。新版因此加入真实的开源贡献，学生接手已有代码，由维护者审阅。入门作业仍让学生自己搭一个约两百行的编程 Agent 执行框架。他还建议查看现有工具发给模型的请求，观察系统提示、工具和上下文是怎样组合的。
遇到陌生的大仓库时，Eric 建议先调研代码和约束，再提出几条方案，由人选定方向，之后写规格、实现和测试。练习可以让不同工具做同一个十分钟的任务，再比较各自如何找上下文和完成验证。把工作交给多个 Agent 之前，他先问仓库是否容易理解、结果能否验证。代码生成变快后，合并队列、环境启动和审阅都可能拖慢交付。
他在 Monaco 的实践里举了两个例子。团队基于 Coder 搭建 Monocoder，让长任务在隔离环境里运行。Slack 里的 Hal 可以协助排查故障、提出 PR，也回答销售人员对产品的疑问。团队试用审阅工具时，会看它在真实 PR 里的提示有多频繁、啰嗦程度如何、是否有用。后来工程师主动要求开通 Devin，团队继续用它做审阅。
在课程后半段，Eric 让学生讨论哪些变更验证充分到可以自动通过，哪些需要人审，并把数据存储、计费和授权视为需要格外认真检查的区域。Monaco 的 PR 描述会说明本次实际改了什么，并指向相关文件。主持人也提出，单个 PR 即便描述准确，仍可能背离跨多个变更的长期意图。Eric 认为，自动化继续加深时，人仍要明确要做什么，并判断交付是否达到了这个目的。