Audible's Moraes Cuts Software Delivery Time with AI Workflows

Audible 的 Moraes 借助 AI 工作流缩短软件交付时间 转向 AI 驱动的规范开发并自动化繁重琐事，使软件部署速度提升超 100%，同时将遗留系统迁移周期缩减三分之二以上。 Ian Moraes 提出了一个由“探索（Explore）”、“优化（Optimize）”和“重塑（Reimagine）”构成的三部分框架，利用 AI 变革 Audible 的软件交付。虽然编写代码仅占开发人员时间的 30%，但 Audible 利用 AI 来应对其余 70% 的繁杂琐事，包括需求澄清、故障响应和测试基础设施。关键亮点包括 Figma 到代码的工作流、将故障平均修复时间（MTTR）降低超 80%、从传统的冲刺规划转向规范驱动开发，以及将遗留系统迁移周期从 190 周缩减至 50 周以内。最终，AI 的引入发挥了效能倍增器的作用，拓展了交付此前无力实现的客户价值的能力。 编写代码仅占开发人员时间的 30%，其余 70% 则耗费在澄清需求、管理依赖项和解决故障等非编码琐事上。 (0:04) Audible 的 AI 框架立足于三大支柱：探索（文化与最佳实践）、优化（减少开发人员的繁杂琐事）以及重塑（将 AI 定位为软件交付的核心伙伴）。 (0:04) 为克服生态系统快速更迭引发的“AI 疲劳”，Audible 鼓励安全的实验尝试、开展同伴实操交流会，并推行“AI 构建倡导者”（AI Builder Advocates）项目。 (4:06) Audible 采用标准工程运维指标（例如部署量、交付速度、MTTR 和回滚率）来评估 AI 成效，而非流于表面的使用量计分卡。 (6:50) AI Agent 利用 Figma MCP 直接将 UX 设计转化为符合内部 UI 组件和无障碍标准的生产就绪代码。 (6:50)

Ian Moraes, Head of Consumer Domains Tech at Audible, argues that realizing the full value of AI in software development requires targeting the 70% of engineering effort consumed by operational toil, dependencies, and requirements rather than focusing solely on raw code generation. By combining peer-driven adoption with spec-driven development and automated operations, Audible aims to accelerate delivery and unblock backlogged roadmap items while enforcing strict human ownership. Targeting Developer Toil Over Code Generation (0:04) At Audible, software teams operate across a large, federated architecture where baseline engineering standards—such as security, availability, and reliability—remain mandatory regardless of tooling changes. Moraes observes that writing code occupies only roughly 30% of a developer's time. The remaining 70% is dedicated to non-coding friction, including clarifying vague requirements, tracking cross-team dependencies, updating software versions, writing test infrastructure, and addressing production incidents. To address this imbalance, Audible organizes its engineering initiatives around three strategic phases: Explore (fostering experimentation and knowledge exchange), Optimize (directly removing the 70% operational toil), and Reimagine (repositioning AI from a peripheral utility into a core collaborator across the software lifecycle). Countering AI Fatigue Through Peer Learning (4:06) Rapid updates across the developer ecosystem—such as MCP security adjustments and new policy control languages—frequently trigger developer fatigue. Audible counters this burnout by establishing safe spaces for engineers to test approved tools, explicitly accepting that several emerging technologies will either underperform or quickly become obsolete. Rather than tracking vanity adoption statistics, leadership measures success through demonstrated peer outcomes. Moraes notes that hands-on sessions—including a live demonstration where an entry-level developer and a senior engineer paired in front of 80 colleagues to configure agents—proved far more effective than mandate-driven rollouts. This peer education is formally anchored by an internal network of AI Builder Advocates. Automating Operational Workflows and Incident Response (6:50) Audible evaluates engineering optimization through deployment frequency, pipeline stability, and rollback rates rather than raw commit counts. Engineers remain strictly accountable for all merged code, even when agents assist with reviews, integration tests, or dependency resolution. In UX pipelines, designers use a Figma MCP integration to convert designs into code that matches Audible's component library while checking accessibility and internationalization standards. For production operations, autonomous agents aggregate logs, deployment histories, and runbooks during off-hours pager alerts to propose fixes based on historical incidents. Moraes reports that participating teams reduced Mean Time to Resolution (MTTR) by more than 80%. Across the organization, AI-assisted code generation expanded threefold over the past year, while deployment velocity rose between 25% and 30% for certain teams, with others seeing improvements exceeding 100%. Spec-Driven Development Across Federated Teams (12:04) Traditional agile workflows often suffer from sequential, ambiguous requirement gathering that causes missed edge cases and rework. Audible is transitioning to spec-driven development, positioning AI to interrogate product managers and engineers about dial-up strategies, policy requirements, and historical corrections of error before coding starts. These requirements are formalized in real time using the ERS format as a binding contract between product, design, and engineering. According to team reports, roughly 70% of the AI's autonomous architectural recommendations are accurate out of the box. This conversational spec phase also facilitates Audible's 'away team' model, where developers must deliver features directly inside repositories maintained by other groups without prior familiarity with the codebase. Modernization Timelines and Expanded Production Capacity (16:32) Audible attributes several major delivery milestones to its AI workflows, including migrating a legacy service to production in under 50 weeks instead of an original 190-week estimate, and reducing internationalization and campaign setup toil by over 50%. In another instance, an engineer working with a product owner delivered an away-team promotional feature in one month instead of three. To balance rapid delivery with platform safety, Audible applies deterministic validation rules where possible, reserving AI validation specifically for non-deterministic edge cases. Moraes concludes that the most significant return on AI development is expanding organizational capacity, allowing teams to deliver previously unfunded 'below-the-line' roadmap items into production for customers. Audible's experience indicates that the greatest operational leverage from AI comes from automating testing, incident response, and cross-team dependencies rather than pure code synthesis. However, realizing these benefits requires teams to enforce deterministic verification and human accountability to ensure architectural reliability across complex distributed systems.

Audible 消费者领域技术负责人 Ian Moraes 指出，AI 驱动软件工程的核心价值不在于加速仅占开发者 30% 时间的代码编写，而在于通过“探索、优化、重塑”框架解决其余 70% 的沟通、运维与依赖等杂务。通过引入规范驱动开发与自主代理，Audible 在维持系统可靠性底线的同时，实现了端到端交付速度的倍增并盘活了此前积压的业务需求。 识别研发瓶颈与三阶段转型策略 (0:04) Moraes 指出，尽管 AI 自动生成代码备受瞩目，但写代码实际上仅占开发者日常工时的 30%。其余 70% 的时间均被厘清业务需求、排查跨团队依赖、完善测试架构、升级依赖版本、处理生产故障以及实施错误纠正（COE）等繁重事务占据。此外，在 Audible 的分布式联邦工程架构下，各团队因依赖方人力受限，普遍采用“客座团队”（away team）模式跨代码库作业，这进一步加剧了沟通与协作的摩擦。 针对这种工时分布现状，Audible 制定了三阶段的 AI 推进框架：首先是“探索”（Explore），培育持续学习的组织文化并分享最佳实践；其次是“优化”（Optimize），直接攻坚占工时 70% 的无谓消耗（toil），将效能收益扩展至整个工程体系；最后是“重塑”（Reimagine），将 AI 确立为核心协作者以颠覆端到端的交付流程。Moraes 强调，无论采用何种 AI 工具，系统的高可用性、可靠性与安全性始终是不容妥协的工程底线。 化解“AI疲劳”与建设实战学习文化 (4:06) 由于行业技术栈演进过于迅猛——例如 MCP 协议的安全加固以及 AWS Dogwood 策略控制语言的发布，工程团队极易出现“AI 疲劳”。为了缓解这一现象，Audible 鼓励员工在受控且合规的环境下安全试错，并明确接受某些工具有可能被淘汰或自然失效的事实。 为推动经验落地，Audible 组织了实操型的同行交流活动，例如曾安排 80 余名技术人员观摩初级工程师与资深开发者同台安装代理并现场解决实际业务问题。在考核维度上，组织摒弃了单纯的使用率统计，转而表彰可量化的实质影响；同时设立“AI Builder Advocates”布道者机制，在各业务线派驻专家，并与 AWS 就早期工具开发展开密切合作。 优化工程流以消除运维与协作冗余 (6:50) 在优化日常开发流程时，Audible 重点考核发布成功率而非代码提交量等虚荣指标，并明确人类开发者对最终产出承担绝对责任。AI 被广泛应用于补全和修复集成测试、疏通流水线阻塞、防范 MCP 投毒（rug-pull）攻击与提示词注入等安全威胁，并作为值班助手协助响应夜间突发事件。 目前落地的关键举措包括：UX 设计师通过 Figma MCP 将设计稿直接传入 AI 代理，由代理提取上下文并比对内部组件库，在确保符合无障碍与国际化标准的前提下生成生产代码；在凌晨报警时，AI 代理汇总系统日志、运维手册与近期发布记录，根据历史案例推荐修复方案，协助试点团队将平均故障恢复时间（MTTR）缩短超过 80%。此外，团队配合运用共享技能库与支持语音输入的 Kiro CLI 工具。过去一年中，AI 辅助代码生成量增长 3 倍；在六个月内，部分团队部署速度提升 25% 至 30%，另有团队的提升幅度超过 100%。 规范驱动重塑交付流程与商业成效 (12:04) 传统敏捷开发采用线性需求沟通，常因规范模糊、忽略边界情况与外部依赖导致冲刺期内频繁返工。Audible 转向了规范驱动开发（spec-driven development），让 AI 扮演主动质询者，在需求提出阶段主动核实合规要求、灰度策略及过往故障教训。需求以 ERS 格式实时沉淀为各方契约，AI 据此自动生成集成测试、编写代码并为跨团队的代码库草拟改动；工程团队反馈其自主建议的初始准确率达 70%，项目交付周期由数周缩减至数天。 在业务层面，一项预估耗时 190 周的旧系统迁移工程最终在 50 周内完成并投产；AI 自动化使多语言翻译、本地化和营销活动搭建的琐碎工时缩减超 50%；一名从未接触过目标代码库的开发者与产品负责人协作，仅用 1 个月即完成了原定 3 个月的跨库促销功能交付。团队在校验时优先选用确定性验证，仅将非确定性边缘场景交由 AI 评估。Moraes 指出，这些实践最重要的成果是将原本因资源受限而搁置的“线下”路线图需求推向生产，实质性地扩大了业务价值交付能力。 Audible 的探索证明，AI 赋能软件开发的核心突破口在于依托结构化规范重塑研发协作机制，进而消除 70% 的外围琐碎开销。然而，面对日新月异的技术迭代，工程团队仍需持续防范新型安全攻击与认知疲劳，并在追求自动化生成效率的同时坚持严格的确定性校验，确保分布式架构的底层稳固。

## Background 本视频由 YouTube 频道 Ai4 于 2026 年 8 月 18 日发布。内容为 Audible 消费者领域技术负责人 Ian Moraes 的演讲，页面简介指出，他分享了带领工程团队从 AI 早期实验走向 AI 原生软件开发周期的实战经验，并为参会者提供了一套评估工具成熟度与规模化推广 AI 的落地框架。 ## TL;DR Audible 洞察到工程师仅有 30% 的时间在编写代码，其余 70% 都耗费在需求澄清与排障等繁杂事务上，因此提出了“探索、优化、重塑”三支柱转型战略。在优化阶段，团队通过基于 MCP 的 Figma 自动化代码流水线和共享上下文，将线上故障恢复时间（MTTR）降低了 80% 以上并显著提升部署频次。在重塑阶段，团队转向以 AI 主动反向质询为核心的“规范驱动开发”（Spec-Driven Development），利用实时需求契约与跨代码库自动解耦，成功将原本耗时 190 周的复杂老旧系统重构周期大幅缩短至 50 周以内。 ## Atmosphere & style 演讲整体呈现出严谨务实、高度贴合工程一线的技术分享氛围，彻底避开了虚浮的 AI 概念炒作。Ian Moraes 以沉稳清晰的叙事节奏，将生产环境的可用性底线、COE 历史复盘与凌晨排障等真实痛点串联起来，既有清晰的架构演进逻辑，又充满让一线开发者深度共鸣的实践细节。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=4s) Audible 的 AI 战略重点不在于单纯优化 30% 的编码时间，而是致力于消除 70% 的工程内耗与繁杂事务（Builder Toil），同时坚守生产环境的高可靠性与安全底线。 - [04:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=246s) 为化解团队对新工具迭代的“AI 疲劳”，Audible 依托全员动手式同侪学习和倡导者网络，坚持以实质业务影响而非调用量等虚荣指标来衡量价值。 - [06:50](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=410s) 工程度量坚定聚焦于实际部署频次（Deployments）而非代码提交量，交付工件的最终责任归属（Accountability）必须始终由人类工程师承担。 - [06:50](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=410s) 建立统一的技能注册表（Skills Registry）与 MCP 安全护栏，成功打通从 Figma 设计稿到生产就绪前端代码的自动化流水线。 - [06:50](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=410s) 在 On-call 故障排查场景中，AI 秒级聚合报警日志、Runbook 与历史工单给出排查建议，使团队平均恢复时间（MTTR）降低了 80% 以上。 - [11:59](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=719s) 研发模式迈入“规范驱动开发”（Spec-Driven Development），AI 从机械执行指令转变为主动引导对话，结合历史事故 COE 自动反向质询潜在边界条件与回滚策略。 - [14:17](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=857s) 通过 ERS 格式将动态需求沉淀为跨角色契约，AI 自动生成测试用例与代码，并能精准解耦外部依赖，极大赋能了跨团队协作的“客座团队模式”（Away Team Model）。 - [16:32](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=992s) AI 辅助交付带来显著提速：原估算需 190 周的遗留系统重构缩短至不到 50 周完成，出海本地化繁杂工作量削减超 50%，跨库促销功能交付耗时缩短了三分之二。 - [18:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=1086s) 践行“验证先行”原则，在适用场景坚决结合确定性验证（Deterministic Validation），并将低人工干预的“绿色流水线”固化为核心工程习惯。 - [18:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=1086s) 工程效能的成倍跃升盘活了组织资源，让原先排期处于优先级水位线以下（Below the line）的创新业务需求得以成功上线落地。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=4s) Audible 的工程环境与 AI 战略全景 Audible 处于前沿技术与开创性音频内容的交汇点。作为重新定义了媒介品类的公司，故事对 Audible 来说具有变革性的力量。AI 不仅深度融入了 Audible 的客户产品特性中（例如基于 MCP、MCP Apps 和 MCP Gateway 为 Claude 开发的 Audible Connector），也全面贯穿于日常的软件交付生命周期。 Audible 的工程体系支撑着全球化、超大规模的消费级解决方案。面对海量真实用户，工程基础规范（Engineering Fundamentals）是绝对不可妥协的底线： - **生产环境的真实标准不变**：AI 可以提高效率，但生产环境对高可靠性（Reliability）、高可用性（Availability）和安全性（Security）的严苛要求丝毫未变； - **分布式与联邦制工程架构**：各团队高度依赖跨团队服务。当合作团队排期受限、缺乏交付容量时，Audible 采用“客座团队模式”（Away Team Model），即工程师直接进入其他团队的代码仓库开发并交付功能； - **标准化基础设施**：全面依托通用的构建管理、自动化测试与 CI/CD 部署流水线。 很多讨论过度聚焦于 AI 生成的代码行数，但 Audible 对开发者时间分配有着更为全局的洞察：工程师仅有 30% 的时间用于编写和创建代码，其余 70% 的时间都耗费在“繁杂事务”（Builder Toil）上——包括澄清模糊需求、梳理跨系统依赖、改进测试基础设施、跨版本软件升级、响应生产事故以及事故发生后的根本原因复盘（COE, Correction of Errors）。因此，Audible 的 AI 赋能核心策略是“不仅优化那 30% 的编码，更着力消除那 70% 的工程内耗”。 ```mermaid flowchart LR accTitle: Audible AI 转型三大支柱框架 subgraph S1["1. 探索 (Explore)"] E1["培育全员学习文化"] E2["跨团队共享实践"] E3["表彰实际业务影响"] end subgraph S2["2. 优化 (Optimize)"] O1["消除 70% 工程杂务"] O2["赋能共享上下文/SOP"] O3["提升实际部署频次"] end subgraph S3["3. 重塑 (Reimagine)"] R1["AI 转为核心协作者"] R2["Spec 驱动端到端开发"] R3["AI 反向质询与查漏"] end S1 --> S2 --> S3 ``` --- ### [04:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=246s) 探索（Explore）：在日新月异的浪潮中构建持续学习文化 AI 领域瞬息万变，技术迭代速度极快。就在近期，MCP 协议升级了强化认证机制、无状态核心（Stateless Core）以及针对 MCP Apps 和 Tasks 的标准化扩展框架；AWS 也刚发布了用于授权的策略控制语言 Cedar/Dogwood。面对层出不穷的新工具，工程团队普遍面临“AI 疲劳”（AI Fatigue）。Audible 通过建立开放、包容的探索机制来化解这一挑战： - **鼓励在核准工具范围内大胆试错**：明确“实验”就意味着可能失败，工具本身也会被更强能力的工具淘汰更替； - **全员动手式同侪学习（Peer Learning）**：曾组织 80 多人同处一室，由初级工程师与资深开发者登台演示，全员同步安装工具与 Agent，边看边做演练具体用例。“通过教学实现自我提升”（By teaching we learn），极大地缓解了面对新技术时的焦虑与疲惫； - **聚焦业务影响而非单纯的使用率指标**：不片面追求 AI 工具的日活或调用量等虚荣指标，而是衡量其对交付带来的实质性改变； - **建立 AI Builder Advocates 倡导者网络**：在每个工程团队中设立专属 AI 推进先锋（Champions），加速跨团队实践复用；同时与 AWS 等云服务商保持深度早期合作，为前沿工具提供一线反馈并借力加速自身转型。 --- ### [06:50](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=410s) 优化（Optimize）：攻克工程痛点与规模化提效 优化阶段的核心在于解决真实痛点，并把经验沉淀为全团队可复用的机制。在工程度量上，Audible 坚定关注部署频次（Deployments）而非单纯的代码提交量（Commits）。AI 可用于生成代码或执行自动化审查，但**责任归属（Accountability）必须始终落在人类工程师身上**——交付工件的终极负责人永远是人类开发者。 为了支撑规模化协作，Audible 构建了多套标准基础设施： 1. **注入共享工程上下文**：将运行手册（Runbooks）、内部代码仓库全量对齐至 AI 工具； 2. **能力与技能注册表（Skills Registry）**：沉淀统一的 Skills 与 Agents（如 A/B 测试配置与 A/B 分析器），通过 SOP 将企业制度与工作流代码化； 3. **安全准入审查机制**：引入经过严格审计的 MCP 服务，规避 MCP 恶意替换（Rug Pull Attacks）、不安全输出处理（Insecure Output Handling）以及提示词注入（Prompt Injection）等新型安全隐患。 #### Figma 自动生成代码流水线 在前端开发流程中，传统模式是 UX 设计师交付 Figma 设计图，工程师介入评审、反复沟通澄清细节，流程线性且耗时。Audible 利用基于 MCP 的 AI 流程实现了设计稿到生产级代码的端到端转换： ```mermaid flowchart TD accTitle: Figma 到生产级代码的 AI 转换流程 A["Figma 设计稿"] --> B["提取设计上下文 (Figma MCP)"] B --> C["检索 Audible Web 组件库"] C --> D["组合视觉模式并注入安全护栏"] D --> E["集成 a11y 无障碍与国际化 (i18n) 技能"] E --> F["输出生产就绪的前端页面代码"] ``` #### 真实落地成效与业务指标 Audible 没有为 AI 发明虚浮的评估看板，而是继续使用成熟的工程核心指标：部署次数、交付速率、回滚率（Rollback Rate）以及线上故障数。实际成效包括： - **AI 辅助代码量**：过去一年间增长了 3 倍； - **部署频次跃升**：近 6 个月内，部分团队部署频次提升了 25%~30%，更有团队实现了 **100% 以上的翻倍增长**； - **终端开发工具演进**：团队广泛采用 CLI 交互工具，其中支持语音输入指令的 CLI 工具极受欢迎； - **On-call 故障排查与恢复（MTTR）**：针对凌晨两点警报触发的场景，AI 会秒级聚合报警日志、部署记录、Runbook 与历史相似工单，给出排查建议，帮助使用该方案的团队**将平均恢复时间（MTTR）降低了 80% 以上**。 --- ### [11:59](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=719s) 重塑（Reimagine）：从工具应用走向 AI 驱动的规范驱动开发 传统的端到端交付模式高度依赖人工推动：需求梳理易有遗漏或表述模糊，文档流转呈严格的线性结构，导致开发阶段常暴露出未被识别的需求，造成极具成本的设计返工与排期重置；团队按照固定的双周 Sprint 拆解任务并依赖人工卡点。 ```mermaid flowchart TD accTitle: 传统人推模式与 AI 驱动 Spec 模式对比 subgraph 传统开发模式["传统开发模式 (人推流程)"] T1["人类编写模糊需求"] --> T2["工程师澄清 & 线性交接"] T2 --> T3["开发中途发现缺漏 & 返工"] T3 --> T4["人工两周 Sprint 拆解 & 代码审查"] end subgraph 重塑开发模式["重塑模式 (AI 驱动 Spec)"] R1["工程师输入初始功能诉求"] --> R2["AI 反向质询与政策/回滚查漏"] R2 --> R3["结合历史 COE 补齐隐藏边界条件"] R3 --> R4["生成精确 Spec 驱动自动化交付"] end ``` Audible 正在全面颠覆这种模式——从“人给 AI 发指令、AI 机械作答”，转变为**AI 主动引导对话（AI is driving the conversation）**的“规范驱动开发”（Spec-Driven Development）： - 当开发者输入初始功能需求后，AI 会主动发起多维度质询：“你是否遗漏了某项业务规则？”、“是否已考虑对应的合规与策略需求？”、“灰度放量（Dial-up）与回滚策略是什么？”； - AI 深度挂载历史事故根本原因复盘（COE），自动校验并提醒：“结合以往同类系统的故障经验，你是否已将某项异常边界条件纳入考量？”； - 丰富的共享上下文与规范驱动机制，让 AI 从单点辅助的代码补全工具，真正转变为参与软件架构顶层设计的核心协作者。 ### [14:17](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=857s) 实时需求契约与 AI 驱动的自动化研发链路 在全新的研发流程中，团队采用 ERS 格式来沉淀需求文档，并由 AI Agent 实时编写与动态更新需求内容。开发人员（Builder）能够与 UX 设计师、产品开发人员组成紧密协作的小团队，无需漫长等待即可展开实时评审。这种模式催生了高度活跃且深度的协作讨论，生成的文档产物不仅供人类工程师阅读，也能直接被 AI Agent 消费与解析。这些产物进而演变为跨角色的刚性“契约”——既是产品经理与研发人员之间的共识边界，也是 UX 设计师、产品负责人与开发者之间的协作契约。 基于这份标准化的契约模板，AI Agent 能够直接根据需求提取并定义测试用例、生成集成测试逻辑并自动编写业务代码。整个开发节奏从以往以周或迭代周期（Sprints）为单位，大幅提速为以“天”为单位运转。此外，Agent 还能自动解耦系统依赖，精准定位跨代码仓库（Code Repos）的调用关系，并主动在外部仓库中发起代码变更提议。这一能力极大地赋能了跨团队协作的“客队模型”（Away Team Model），并智能标出需要工程师进一步深入探查（Double-click）的关键区域。 ```mermaid flowchart TD accTitle: AI 驱动的敏捷协作与交付流水线 subgraph S1["需求与契约定义"] A["多角色实时协作<br/>(Builder + PM + UX)"] --> B["Agent 实时生成 ERS 需求产物"] B --> C["跨角色协作契约"] end subgraph S2["自动化生成与解耦"] C --> D["自动推导测试用例与集成测试"] C --> E["代码生成与跨 Repo 变更提议"] E --> F["依赖解耦与客队模型支持"] end subgraph S3["交付保障"] D --> G["内置安全护栏 (Guardrails)"] F --> G G --> H["快速部署交付 (以天为单位)"] end ``` - **建议准确率达标**：团队在实际验证中发现，AI 给出的代码及依赖修改建议中有 70% 是完全正确的；剩余 30% 则交由工程师凭借人类专业判断进行把关。 - **全流程防护**：在由 AI 编写测试和生产代码的过程中，系统内置了严格的安全护栏（Built-in Guardrails），确保自动化交付的可靠性。 --- ### [16:32](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=992s) 实战落地案例：重构提速、出海本地化与跨模块交付 作为一家“以故事为本”的公司，Audible 在实际业务场景中沉淀了多项由 AI 驱动交付的生动范例。针对一项极为复杂的遗留服务（Legacy Service）重构升级项目，传统评估预计需要耗时 190 周，但在 AI 辅助交付的赋能下，团队最终在不到 50 周的时间内便顺利将其推向生产环境，交付周期缩短了近四分之三。 在跨国业务扩张与出海落地的过程中，另一个独立团队面临着语言翻译、本地化适配以及营销活动配置等大量繁琐重复的“苦工”（Toil）。通过引入 AI 工具链进行流程自动化改造，该团队成功将此类机械性工作量削减了 50% 以上。 另一个极具代表性的跨域协作案例来自一位独立开发者。该开发者与产品负责人搭档，仅用 1 个月时间便完成了原先预估需要 3 个月的促销活动行动号召（Promotion CTA）功能交付。该开发者坦言自己此前对涉及的“客队”外部代码仓库并不熟悉，而 AI 在理解陌生代码库和加速跨团队代码提交上发挥了决定性作用。 --- ### [18:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=1086s) 工程师范式转变：确定性验证、绿色流水线与业务价值突破 团队在拥抱 AI 的同时，总结出了一套关键的工程实践原则。首先是坚持“验证先行”（Validation First）而非直接盲目编码。团队并不盲目迷信 AI：在确定性验证（Deterministic Validation）适用的场景下，坚决采用确定性的传统验证机制，将 AI 验证与确定性验证合理结合。与此同时，上下文模块化（Modularizing Context）也是保障 AI 高效产出的基石。 团队将保持“绿色流水线”（Green Pipeline）固化为一种工程习惯。从代码提交到最终部署，流水线必须以尽可能少的人工干预自动化运行。这种工程习惯的改变驱动了研发人员角色的演进：工程师们开始主动承担起涉及市场营销等非技术维度的任务，将关注点从单一的功能上线任务拓展到了端到端的工作流与最终的客户价值。 - **工程效能显著提升**：在严格保持交付质量的前提下，团队的部署频率实现了 30% 乃至超过 100% 的成倍增长。 - **盘活底层业务需求**：AI 带来的效能跃升使得那些原先位于优先级水位线以下（Below the line）、无法获得资源支持的路线图规划与创新方案，得以被提升到水位线之上（Above the line）并成功落地。 - **演讲结语**：Ian Moraes 总结道，这场 AI 变革的“故事仍在继续书写，我们依然在持续学习和成长”。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=4s) 生产环境对高可靠性（Reliability）、高可用性（Availability）和安全性（Security）的严苛要求丝毫未变 — Ian Moraes > [00:04](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=4s) 工程师仅有 30% 的时间用于编写和创建代码，其余 70% 的时间都耗费在“繁杂事务”（Builder Toil）上 — Ian Moraes > [00:04](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=4s) 不仅优化那 30% 的编码，更着力消除那 70% 的工程内耗 — Ian Moraes > [04:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=246s) 通过教学实现自我提升（By teaching we learn） — Ian Moraes > [06:50](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=410s) 责任归属（Accountability）必须始终落在人类工程师身上——交付工件的终极负责人永远是人类开发者。 — Ian Moraes > [11:59](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=719s) 从“人给 AI 发指令、AI 机械作答”，转变为 AI 主动引导对话（AI is driving the conversation）的“规范驱动开发”（Spec-Driven Development） — Ian Moraes > [11:59](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=719s) 结合以往同类系统的故障经验，你是否已将某项异常边界条件纳入考量？ — Ian Moraes > [14:17](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=857s) AI 给出的代码及依赖修改建议中有 70% 是完全正确的；剩余 30% 则交由工程师凭借人类专业判断进行把关。 — Ian Moraes > [18:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=1086s) 坚持“验证先行”（Validation First）而非直接盲目编码。 — Ian Moraes > [18:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=1086s) 在确定性验证（Deterministic Validation）适用的场景下，坚决采用确定性的传统验证机制，将 AI 验证与确定性验证合理结合。 — Ian Moraes > [18:06](https://www.youtube.com/watch?v=zxJwAdjnMl8&t=1086s) 故事仍在继续书写，我们依然在持续学习和成长 — Ian Moraes ## Mentioned Ian Moraes, Audible, Ai4, Claude, MCP (Model Context Protocol), MCP Apps, MCP Gateway, Audible Connector, AWS, Cedar/Dogwood, AI Builder Advocates, Figma, Figma MCP, ERS ## Video description Ian Moraes - Head of Consumer Domains Tech, Audible What does it take to move an engineering team from AI experimentation to AI-native development? In this session, Ian Moraes, Head of Consumer Domains at Audible, will share practical lessons from leading his team's AI transformation across the software development lifecycle: from early experimentation with AI tools, to optimizing developer workflows, to reimagining how software gets built end-to-end. Attendees will leave with a framework for evaluating AI tooling maturity and actionable strategies for scaling AI adoption across their own builder teams. [Source](https://www.youtube.com/watch?v=zxJwAdjnMl8)

[0:04] Ian Moraes: 生产环境对高可靠性（Reliability）、高可用性（Availability）和安全性（Security）的严苛要求丝毫未变 [0:04] Ian Moraes: 工程师仅有 30% 的时间用于编写和创建代码，其余 70% 的时间都耗费在“繁杂事务”（Builder Toil）上 [0:04] Ian Moraes: 不仅优化那 30% 的编码，更着力消除那 70% 的工程内耗 [4:06] Ian Moraes: 通过教学实现自我提升（By teaching we learn） [6:50] Ian Moraes: 责任归属（Accountability）必须始终落在人类工程师身上——交付工件的终极负责人永远是人类开发者。 [11:59] Ian Moraes: 从“人给 AI 发指令、AI 机械作答”，转变为 AI 主动引导对话（AI is driving the conversation）的“规范驱动开发”（Spec-Driven Development） [11:59] Ian Moraes: 结合以往同类系统的故障经验，你是否已将某项异常边界条件纳入考量？ [14:17] Ian Moraes: AI 给出的代码及依赖修改建议中有 70% 是完全正确的；剩余 30% 则交由工程师凭借人类专业判断进行把关。 [18:06] Ian Moraes: 坚持“验证先行”（Validation First）而非直接盲目编码。 [18:06] Ian Moraes: 在确定性验证（Deterministic Validation）适用的场景下，坚决采用确定性的传统验证机制，将 AI 验证与确定性验证合理结合。 [18:06] Ian Moraes: 故事仍在继续书写，我们依然在持续学习和成长

[0:04] Ian Moraes: while AI-generated code catches all the headlines, actual writing of code only accounts for 30% of a developer's time. [0:04] Ian Moraes: Explore: Cultivating a continuous learning culture, sharing best practices across teams, and celebrating impact. [0:04] Ian Moraes: Optimize: Directly addressing the 70% developer toil and scaling efficiency gains across engineering teams. [0:04] Ian Moraes: Reimagine: Positioning AI as a central collaborator rather than just a utility to rethink the end-to-end software delivery lifecycle. [6:50] Ian Moraes: Every AI-assisted code change or automated review still requires human accountability, as the builder ultimately owns the artifact. [6:50] Ian Moraes: Over six months, deployment velocity increased between 25% to 30% for some teams, while others saw increases exceeding 100% [12:04] Ian Moraes: Audible is shifting this dynamic by using spec-driven development, turning AI into an active partner that leads the conversation rather than simply answering prompts. [12:04] Ian Moraes: Teams report that 70% of the AI's autonomous recommendations are correct out of the box, shifting project timelines from weeks or sprints down to days. [16:32] Ian Moraes: A legacy service migration initially estimated at 190 weeks was completed and deployed to production in under 50 weeks. [16:32] Ian Moraes: Beyond engineering speed, the greatest achievement is moving previously unfunded "below-the-line" roadmap items into active production for customers

[0:04] Hello, I'm Ian from Audible and uh I look  forward to working for you for the next uh [0:10] 20 minutes sharing practical lessons from  our AIdriven software development journey. [0:19] So our lessons come from a company at the  intersection of leading edge tech and creating [0:26] pioneering audio content. We've reinvented a media  category and for us stories are transformative. We [0:36] use AI both to deliver software and we use AI in  our customer features. You know a recent example [0:45] of this is we developed audible connector for  claude using MCP and MCP apps and an MCP gateway. [1:01] In order to appreciate our lessons learned, it's  helpful to understand our engineering environment. [1:09] We're part of a largecale global consumerf facing  solutions in terms of our delivery. That's what [1:18] we develop. And when you're developing largecale  consumerf facing and global solutions, engineering [1:24] fundamentals are non-negotiable. When you think  about reliability and availability and security, [1:33] AI does not change what production really means.  We're part of a large distributed and federated [1:41] engineering environment which means that we  depend on services and teams to deliver help [1:48] deliver our solutions and when they don't have  the capacity to deliver solutions we operate [1:52] using an away team model where we work in their  code repos to be able to deliver our solutions. [2:01] We leverage common builder tools and  capabilities used across our different [2:05] teams for build management, for um  testing, for pipelines and others. [2:18] So AI and the lines of code generated catches and  grabs all the attention and but we view developers [2:30] more holistically in terms of 30% of the time is  spent on building and creating but the other 70% [2:39] is is spent on clarifying requirements identifying  dependencies um being able to enhance our test [2:48] infrastructure, being able to upgrade from one  version of software to another uh to be able to [2:56] respond to production issues and if we do have a  production issue to pursue a correction of errors. [3:01] So when we look at builder time, we're looking  at optimizing that 70% in addition to the 30%. [3:13] So our AI journey framework comprises  three elements. Explore, optimize, [3:21] and reimagine. When you think about explore,  for us, it's about developing and fostering a [3:29] learning culture. Uh being able to share learnings  across our teams. We're all in it together. We [3:36] help each other learn. And then we celebrate  impact. The second element is optimize where [3:44] we're addressing that builder toil which I talked  about the 70% and the 30% and being able to scale [3:51] the impact across our teams. And then the last  element I'll discuss is reimagining where AI is [3:57] a central collaborator not a tool where we're  using AI to rethink how we deliver software. [4:06] So let's talk about the explore um and building  this learning culture. Fostering a culture of [4:13] continuous learning has been an important enabler  for us in terms of growing and enabling this [4:21] cultural AI transformation and that's so important  given the AI landscape that's so dynamic. when we [4:29] consider where we are even last week MCP upgraded  their protocol with hardened authentication [4:38] uh stateless core a standardized extension  framework for MCP apps and tasks and so and [4:44] then today dogwood was announced by AWS a  policy control language for authorization [4:50] so it's constantly changing and we suffer just  like just like probably you suffer from AI fatigue [5:00] We've encouraged experimentation of our  approved tools. So we've used tools. By the way, [5:05] experiment means that sometimes our tools, our  exploration is not very successful. Tools evolve [5:13] to tools are superseded by other capabilities.  So but we encourage experimentation of our tools [5:18] and different use cases. And so that's  been important for our success. and we [5:24] allocate time for learning and sharing.  I'll always remember a time where we had [5:29] 80 plus people in a room. We had three peers, an  entry-level engineer, a more experienced builder, [5:37] and they shared learnings where we followed along.  We basically followed along, install the tools, [5:43] installed the agents, and we walked through a use  case. So, it wasn't necessarily just watching, [5:48] but we also were doing. And learning  from peers provides validation as well [5:54] as by teaching we learn. And it also in a way  helps address that AI fatigue because we're [6:01] all in in it together and we learn from  each other and we grow from each other. [6:08] We have a lot of forums for sharing these best  practices and learning and scaling them across our [6:13] teams. Um we celebrate and share impact not usage.  I don't we don't look a lot at AI adoption usage. [6:21] It's more about impact. We have an AI builder  advocates program where we have champions in each [6:27] team that help accelerate the AI transformation  and also they help scale these learnings across [6:34] our teams. We've also been engaged with AWS  in terms of early tools that they develop. [6:41] We provide input to them and they also help  us sh help us advance our AI transformation. [6:50] So let's talk about that second  element which is optimize which is [6:55] attacking those developer pain points  sharing the impact across our teams. [7:03] So notice I focus on increasing deployments.  It's not about code commits, right? We use AI [7:09] for generating code, for auto reviewing of  code. It still requires a human reviewer. [7:17] And I think the one point I've attended  a number of sessions yesterday and the [7:20] one thing I didn't hear was accountability.  The accountability for an artifact is on the [7:26] builder. It's on the human. You can use AI, but  ultimately the builder owns the accountability. [7:33] It's about writing and fixing integration tests.  We use AI for unblocking pipelines. And the one [7:38] thing I haven't covered in this presentation  because it's probably a talk onto itself is that [7:44] we've imbued our AI tools with shared context.  So our runbooks, our code repos to help enable [7:52] uh building and deploying. We have scale  registries for being able to share skills [7:58] and agents across our um across our teams and we  use SOPs as well to codify institutional knowledge [8:05] and workflows. We use vetted MCPs for discovering  and sharing um capabilities. And let me give you [8:16] a concrete example. A concrete example is that  we work with web experiences for example as one [8:23] customer surface touch point and we work with UX  designers who share a Figma design that then gets [8:30] shared with a builder the builder reviews it has  questions comes back with clarifications again [8:38] it's sequential it's handoff it takes time and so  we're using AI to take a Figma design and convert [8:46] it to usable web page code, production ready  code. What it does is it extracts the design [8:52] context. It searches for audible web components.  It can be used based on the visual patterns in the [8:57] design. It has built-in guard rails. We combine  the components to create the design. And then we [9:03] use accessibility and internationalization skills  to be able to deliver the solution. Of course, [9:08] integrating with Figma MCP and other MCP  servers. An important point is that we did [9:16] not invent new scorecards to measure the impact  of AI. We use our engineering metrics which are [9:21] number of deployments, delivery velocity as  well as quality in terms of rollback rate, [9:27] number of production issues in in production.  So we try to have that balanced metric and [9:33] it what's important is that we look at the  engineering metrics to determine the AI impact. [9:46] you know using agents and skills and SOP we have  a number of shared skills that we use across our [9:52] teams whether it be for AB tests and AB analyzers  we compose those skills we have a agents that use [10:00] those different skills like I just described and  we basically have code harnesses we use Kirao uh [10:08] CLI claude and others Kira CLI seems to be  the more popular one on our team. Kira CLI [10:15] released a a voice capability where instead of  typing your u your prompts or your requests in, [10:21] you can use your voice. So it's it's pretty  cool. I'll give you some some data for your [10:26] reference. Our AI assisted code has increased  3x in the past year. And for some teams the [10:35] number of deployments in the last six months  has increased by 25 to 30% while others have [10:42] increased 100 plus%. So this is real data in  terms of impact um of the use of AI. You know [10:51] we talked about that 70% in terms of development  toil. We're using AI for upgrading our our our [11:01] languages. I think one thing that I do want  to highlight is automating and autonomously [11:08] identifying security risks. Delivery velocity is  increasing security testing and so we've had to [11:14] we're using AI to help us there. If you think  about MCP rug pull attacks and insecure output [11:20] handling and prompt injection, it's certainly  we're using it for a lot of different use [11:24] cases. It's 2 a.m. in the morning. You get a your  pager goes off. You've got to gather the context, [11:33] understand your deployments, look at your logs,  look at your alarms, look at your runbooks. And [11:38] you can see over here that there's a lot of time  being spent gathering the context. We're using [11:43] AI to help us gather the context and provide a  recommendation based on tickets that are similar [11:49] to previous incidents. For those teams that have  used AI for this, it's reduced MTR by over 80%. [11:59] Let's talk about the last  element which is reimagine, [12:04] right? It's rethinking how  software gets built end to end. [12:11] So our current process is that it's very  human-driven. Humans own and create the [12:18] requirements. They miss requirements. It's  ambiguous. We have documentation which is [12:24] written again by humans. It's very sequential.  The requirements are passed to a builder. You get [12:31] clarifications. It takes time. It goes back to to  requirements. Some requirements are not uncovered. [12:37] So, building begins and then requirements are  uncovered. Very costly because now we've got [12:42] to revisit and and restart the design and  build process. We plan on two week sprints. [12:48] We have humans decompose the tasks under  understand what the dependencies are work [12:54] with away teams and here it's about coding first  we have manual review manual pipeline gates we [13:03] use agile and scaled agile which probably a number  of you in this room do too. What we've started to [13:10] do is switch the conversation. Rather than us  providing input to AI and then AI responding, [13:22] what we're doing here is AI is driving the  conversation. The first time I used it, [13:28] it was is pretty amazing in that you're  providing a description of a feature request [13:32] or a new ask. and what AI and what we're using  spectriven development. We have different flows [13:39] for different use cases and we're developing the  best practices as we go. AI asks questions about [13:45] have you forgotten a requirement? Have you gone  ahead and considered uh a policy requirement? [13:51] Have you considered your dialup strategy? It also  looks at previous correction of errors and said, [13:57] have you accounted for this requirement? So it  brings up asks and requirements that we wouldn't [14:03] have thought of previously. Again, context is so  important. The more better context, the better [14:10] shared context will help inform a better types of  questions and a more um efficient delivery of this [14:17] of this process. We're using the ERS format for  documenting the requirements. The agent actually [14:25] creates and writes the requirements, updates the  requirements as we go through. It's it's in real [14:30] time. Smaller teams working together. A builder  gets to work with a UX designer and a product [14:38] developer. And you're reviewing those requirements  in real time. So it's you don't have to wait. [14:45] It's happens in in in a much shorter period of  time and it's a more active engaged discussion. [14:53] Those artifacts are consumed by both agents and  by humans too. So the artifacts are written in [15:02] a way that we're using those artifacts. It  becomes a contract. It becomes a contract [15:07] between the product manager and the builder.  It becomes a contract between the UX designer [15:14] and our product owner and our builder. So it  becomes it becomes a template where we can use [15:21] it to describe and define the test cases. So we're  defining the test cases from the the requirements. [15:28] It's writing out the the integration tests. It  writes out the code and so we're finding that it [15:37] we're working in more in days than in weeks  or sprints. Uh it decomposes dependencies. [15:46] It identifies the dependencies in terms of code  repos. It actually proposes code changes in those [15:53] repos. So it helps with the away team model that  I talked about earlier and it highlights areas to [16:01] go and doubleclick on. I talked with some of our  team that had um been working on this a few weeks [16:08] ago and they said 70% of the recommendations  were correct as of right now. there's still a [16:12] 30% area where it still needs human judgment, but  70% have been correct. Um, so it's really helping [16:20] us here. We're writing tests, producing code, and  embracing, and we're using built-in guard rails. [16:32] So, we're a company of stories, right?  And here are some stories of how we've [16:38] used AIdriven delivery. We took a a legacy  service that was estimated at 190 weeks and [16:49] we delivered it into production in less than  50 weeks. Another example, separate team by the [16:58] way. We're expanding to new countries and some of  the toil with language translation, localization, [17:07] campaign setup, all of that we've reduced with  AI 50% over 50% of the toil. In another example, [17:19] we had one developer, one builder that was  able to work with a product owner and deliver [17:25] a promotion CTA in one month versus 3 months. And  what was significant is that this builder shared [17:34] that they didn't have a strong understanding of  those away team repos. So to be able to have AI [17:41] help accelerate that effort was significant. So  as you know with audiobooks or any books we have [17:48] reviews right. So this is these are reviews from  the team smaller teams it reduces the planning [17:56] overhead. It helps with away team delivery. The  other point is by the way we we've u invested [18:06] in validation first rather than starting the  coding. We don't have to use AI for validation. [18:14] all the time. In cases where deterministic  validation works, we use deterministic [18:20] validation. I see some nodding heads, right?  You don't have to use AI all the time for [18:25] uh validation. Modularizing context, that's a  topic to itself. That's been crucial. I like this [18:33] one. Green pipeline as a habit. We've learned  to be able to deliver and change how we work, [18:39] change our habits. Because when you think about  a pipeline, from the time code gets in to the [18:43] time code gets deployed, it goes to this pipeline  and you want it done with less and fewer manual [18:49] intervention as possible. It was great to see  builders take on non- tech tasks involved with [18:56] marketing and other efforts to help deliver on  the customer outcome. And what we're focusing [19:03] more we're finding is builders are focusing more  on the overall workflow rather than just the [19:11] uh their task of getting something launched.  You know you can talk about engineering metrics [19:16] and show how we've it's improved 30% increase in  deployments while maintaining quality or over 100% [19:22] increased uh deployments. But ultimately in terms  of customer outcome when we see examples of items [19:32] and roadmap items and capabilities and solutions  that were below the line that were not being [19:37] funded and now are being raised above the line to  be able to deliver for our customers that's very [19:42] rewarding and provides another validation point in  terms of our AI delivery that we've been driving. [19:50] The last thing I'll say and I have 10 seconds  is that the story is still being written. We're [19:57] still learning. We're still growing. And with  that, I thank you for your time. [applause]