Cockroach Labs CTO Peter Mattis 谈分布式数据库与 AI 编程
Cockroach Labs CTO Peter Mattis 分享从 GIMP、Google Gmail/Colossus 到分布式数据库的工程经验,指出 AI 助其重回代码编写并提升专家影响力。他回顾 Gmail 早期使用 B-tree 存储线程,以及 Colossus 通过 Reed–Solomon 纠删码将存储开销降低 33% 同时增强冗余的技术细节。
Cockroach Labs CTO Peter Mattis 分享从 GIMP、Google Gmail/Colossus 到分布式数据库的工程经验,指出 AI 助其重回代码编写并提升专家影响力。他回顾 Gmail 早期使用 B-tree 存储线程,以及 Colossus 通过 Reed–Solomon 纠删码将存储开销降低 33% 同时增强冗余的技术细节。
Simon Willison 指出,随着与编程智能体合作时间的增加,他愈发确信这些工具反而让软件工程变得更加困难。尽管智能体能实现惊人的功能,但要释放其全部潜力需要非凡的纪律性和专业知识。
GitHub Copilot 官方博客文章指出,虽然聊天是目前与大语言模型交互的主要方式,但在许多场景下它并非合适的用户界面。文章介绍了 GitHub Copilot app 中的 canvas 功能,这是一种运行在应用内部的全栈小应用程序,允许智能体与服务器双向通信并执行本地代码。
GitHub Next 设计工程师 Maggie Appleton 分享其利用“Jigs”交互式原型控制 AI Agent、以手绘笔记替代工具启动项目,并强调在 AI 生成设计中保留人类判断与熟悉交互原语的重要性。
Simon Willison 指出,尽管拥有完全互联网访问权限的终端智能体(如 Claude Code、Codex)可直接调用 API,但 MCP 在需要严格控制外部服务访问、安全处理认证及审计日志的场景中仍具核心价值。他认为仅因编码智能体不需要就判定 MCP 过时,忽略了构建其他类型应用时的实际需求。
Gergely Orosz 通过实地访谈揭示 OpenAI 内部已全面转向以 Codex 为核心的“智能体软件工厂”,非工程团队使用率从 0% 飙升至 90%,IDE 使用量显著下降。文章详细描述了从上下文收集、智能体代码审查到自动部署的闭环流程,指出 PR 数量激增导致 CI/CD 负载增加约 10 倍,并探讨了原生移动端发布瓶颈及未来工程角色向产品判断力转变的趋势。
推荐理由:作者实地探访 OpenAI,揭示了 Codex 如何取代 IDE 成为核心工具,以及智能体在代码审查、部署和监控中的自动化实践。
宝玉在腾讯学堂分享 AI 原生思维,提出做 AI 产品需盯着模型能力边界找需求,并通过高保真原型快速验证、围绕 Agent 重设工作流。他以自研字幕翻译 App BaoCut 为例,展示了从模拟人类字幕组到让 Agent 自主执行验收的迭代过程,强调人的角色应转向定义问题与结果验收。
Casey Muratori 指出软件性能常被行业忽视,主张在架构设计阶段即考虑性能,而非依赖后期 Profiler 优化。他建议开发者学习阅读汇编以理解 CPU 机制,并批评“过早优化是万恶之源”的观点导致架构缺陷难以修复。
金融科技平台 Ramp 开发了名为 Inspect 的内部背景编码智能体,目前其合并的 PR 中有 75% 由该工具发起。Inspect 基于 OpenCode 构建,运行在云端沙箱中,支持无限并发会话、内部数据源集成以及前后端变更验证。团队认为本地机器限制、前端工具需求及远程开发环境是促使他们放弃第三方产品并自研的关键原因。
宝玉分享其使用 Claude Code 和 Fable 5 为 BaoCut App 添加远程转录功能的完整复盘,提出 AI 原生开发本质是传统流程但执行主体变为 Agent。
Addy Osmani 分享从构建 Chrome DevTools 到 AI 开发的职业路径,指出 AI 辅助编程的最大风险是“认知投降”,即开发者对问题理解的退化。他提倡通过“循环工程”实现人与智能体的相互增强,并强调软件工程师因具备问责能力而不可替代。
The Pragmatic Engineer 指出当前大量 CTO 和 VP of Engineering 等高层正选择离职或休整,主要源于对 AI 转型压力的应对失败及初创公司股权价值缩水。
Honeycomb CTO Charity Majors 认为 Opus 4.5 与 Claude Code 促使 AI 成为软件工程的代际变革,类比云计算对基础设施的影响。她指出代码生成经济已变,人类应聚焦验证系统而非代码审查,并主张工程需构建能安全发布未读代码的体系。
作者拒绝依赖 LLM 进行“凭感觉编程”,认为其无法解决软件开发的本质复杂性,且缺乏对抽象局限性的元认知。LLM 消除的仅是偶然复杂性,而摩擦是理解代码架构与发现设计缺陷的关键线索。盲目追求速度可能导致逻辑谬误,如 DOGE 团队因照单全收数据字面意思而得出错误结论。
Anthropic Claude Code 和 Cowork 产品线工程与产品负责人 Fiona Fung 在 Code with Claude 2026 大会上分享了 AI 时代管理工程团队的经验。
资深开发者因身处“管理复杂性”循环,常以维护成本为由拒绝需求,导致与追求“消除不确定性”的业务团队沟通失效。文章指出其核心价值在于利用现有资源快速验证假设,建议将“减少代码”转化为“更快获得确定性”的解决方案,从而弥合认知分歧。
Andrej Karpathy 在 Sequoia Capital 的 AI Ascent 访谈中提出,2025 年 12 月是其个人编程体验的转折点,AI 生成代码从“需修补”变为“直接可用”。
推荐理由:Karpathy 区分了 Vibe Coding 抬高下限与 Agentic Engineering 保住上限,并指出 LLM 能力呈锯齿状分布,为理解 AI 编程现状提供了清晰框架。
宝玉分享《Why Your “AI-First” Strategy Is Probably Wrong》一文,认为 AI First 的本质是软件工程 First,人需从代码编写转向关键节点判断。
文章提出了智能体工程(Agentic Engineering)的八个等级,涵盖从 Tab 补全、上下文工程、复合工程、MCP 与技能、Harness Engineering、后台智能体到自主智能体团队的演进路径。