Johnson Controls Sees AI Agents Ending Two-Week Software Sprints

江森自控预计 AI 智能体将终结两周软件冲刺周期 智能体 AI 工作流将交付周期压缩至数小时，消除了对固定两周工程冲刺的需求，使产能提升高达 30% 以清理积压任务，而非削减开发人员编制。 Charles Hudson 阐述了从传统孤立的 SDLC 阶段交接向由 AI 编排的持续工程飞轮的转变，这一转变将交付周期从数周压缩至数小时。他说明了 AI 如何将敏捷冲刺从机械的交付瓶颈转变为战略业务规划节奏，同时从日常繁重事务中释放出开发者 10% 至 30% 的带宽精力。Hudson 描绘了从 AI 副驾驶（copilot）到自主软件工厂的行业演进四阶段，并强调人类工程师不会被取代，而是会被赋能升级为编排者、监督者和业务战略家等具有更高杠杆作用的角色。 软件开发生命周期已迎来拐点，正迅速从早期实验阶段过渡到主流企业的全面采用。 (0:04) 传统 SDLC 正在从依赖人工交接的僵化分段闭环，演变为由 AI 引导的动态持续流，类似于 GPS 的实时动态重新规划路线。 (3:08) 仅对孤立的职能孤岛进行自动化所带来的收益正逐渐递减；真正的竞争优势在于将专业化智能体连接成一个加速运转的持续工程飞轮。 (5:08) 开发范式正从被动的、提示词驱动型 AI 辅助工具，转向能够执行多阶段工作流的自主、目标导向型智能体协调器。 (8:53) 工程执行带宽（而非业务构想的数量）才是主要瓶颈，AI 自动化能够从日常琐务中释放出 10% 到 30% 的工程产能。 (11:57)

Charles Hudson outlines how agentic AI transforms the traditional software development lifecycle into an automated continuous flywheel, recovering engineering capacity and shifting developers from manual coding to system orchestration without reducing overall headcount. From Segmented Handoffs to Continuous Agentic Orchestration (5:08) Hudson compares the traditional software development lifecycle—segmented into sequential stages like requirements, design, build, test, and deploy—to an early automobile GPS following rigid, predetermined waypoints. AI alters this structure into a continuous delivery model that dynamically reroutes in real time. While early adoption typically targets isolated functional tasks such as code reviews or test drafting, Hudson stresses that localized automation delivers diminishing returns unless organizations link these disparate steps into an accelerated continuous engineering flywheel. Achieving this continuous flow requires transitioning from reactive, prompt-driven copilots to autonomous, goal-driven agentic architectures. Multi-agent squads coordinate across requirements, build verification, and deployment under an orchestrator agent functioning like an air traffic controller. In Hudson's assessment, automated testing and quality assurance represent the immediate area of greatest time savings, compressing feature delivery cadences that historically required weeks down to a matter of hours. Capacity Recovery and the Evolution of Sprints (11:57) Hudson notes that engineering organizations are primarily constrained by execution bandwidth rather than a shortage of business ideas. Offloading routine maintenance, legacy code support, regression testing, and technical documentation to AI can yield an estimated 10% to 30% capacity boost, functionally equivalent to adding engineering headcount without increasing payroll. This recovered bandwidth shifts the primary operational bottleneck upstream to continuous backlog prioritization and customer value validation. As delivery cycles compress from weeks to hours, Hudson argues that traditional two-week or three-week sprints are obsolete as engineering delivery constraints. Instead, sprints survive as strategic business planning rhythms for roadmap alignment and feedback synthesis, contrasting on-demand continuous deployment with batched delivery. An exception remains for safety-critical domains such as medical devices and regulated manufacturing, where rigorous validation mandates will preserve structured release cadences. Organizational Culture, Trust, and Meaningful Business Metrics (22:04) Hudson contends that the primary barrier to scaling AI across software organizations is cultural and organizational rather than technical. Developers often express anxiety regarding job obsolescence, while enterprises face valid concerns regarding intellectual property protection, regulatory compliance, and security policy adherence. To build organizational trust, Hudson advises deploying structured internal practices, such as sprint-level hands-on AI jam sessions and cross-functional champion networks, rather than chasing new foundational models in isolation. Furthermore, justifying ongoing enterprise investment requires abandoning vanity metrics like prompt counts or lines of AI-generated code. Hudson recommends evaluating transformation through core software delivery metrics, specifically tracking reductions in lead time for changes, increased deployment frequency, improved change failure rates, and the reallocation of recovered developer capacity toward high-value backlog initiatives. Infrastructure Economics and the Four-Stage Role Evolution (34:52) Because commercial AI pricing structures—spanning per-token charges, seat licenses, and enterprise tiers—remain immature, Hudson observes that many organizations are deploying on-premises hardware to host open-source models like Llama. He describes this hybrid posture as a temporary bridge mirroring the early enterprise transition to the cloud, advising engineering leaders to decouple system architectures to prevent vendor lock-in until commercial pricing and market value normalize. Looking across the broader trajectory, Hudson maps AI integration across four evolutionary stages: AI Copilots, AI Teammates, multi-agent AI Engineering Teams, and Autonomous Software Factories. Across this progression, human engineers do not face layoffs due to perpetual development backlogs. Instead, developer responsibilities systematically elevate from boilerplate coding to agent supervision, system architecture, governance enforcement, and business problem formulation. Hudson concludes that while the industry is advancing toward autonomous software factories, human oversight remains indispensable for governance, security posture, and architectural integrity. However, the precise pace of adoption remains an open variable that could outstrip formal industry forecasts, requiring organizations to cultivate continuous learning cultures.

Johnson Controls 全球工程负责人 Charles Hudson 指出，人工智能正推动软件开发生命周期（SDLC）从离散孤立的人工交接，转向由智能体编排驱动的“连续工程飞轮”；这一变革的关键价值并非生成代码的局部提效，而是释放 10% 至 30% 的工程产能，将工程角色与衡量标准全面导向业务成果。 从分段交付循环到动态连续工程飞轮 (3:08) 过去二十年间，传统 SDLC 遵循需求、设计、构建、测试与部署的固定闭环，各职能孤岛（架构师、开发、测试与技术文档编写人员）以线性交接方式协作，催生了发布评审委员会（CAB）与发布列车等制度。Hudson 将 AI 对 SDLC 的重塑比作车载 GPS 的代际跃迁：早期的 GPS 依赖固定停靠点的静态路线规划，而现代系统则能够根据实时路况实现连续导航与动态重路由。 企业若仅在既有职能孤岛内使用 AI（例如仅加速代码初审、生成单测或起草文档），将错失真正的转型红利。Hudson 强调，真正的突破在于通过类似空中交通管制员（ATC）的协调智能体（Orchestrator Agent），将需求、开发、QA 与运维工具链串联为“连续工程飞轮”。这种端到端协作消除了跨部门工单流转与等待耗时，使原本需要数天或数周的交付周期缩短至数小时内完成。 从副驾驶迈向四阶段自主软件工厂 (8:53) Hudson 分析指出，当前软件工程正从被动响应的“AI Copilot”阶段，跨入具备独立执行能力的“AI Teammate”阶段。提示词工程与提示词库只是过渡形态，目标驱动型智能体已能跨阶段自主推进复杂任务，其中自动化测试与质量保障是智能体落地见效最快、节省工时最显著的切入点。 根据 Hudson 提出的四阶段演进模型，软件开发将沿“AI 助手（专注个体效率）”、“AI 队友（专注交付速度）”、“AI 研发团队（专注系统级优化）”，最终发展至“自主软件工厂（Autonomous Software Factories）”。在终极阶段，人类只需输入业务意图与规则，系统即可端到端完成交付。人类工程师并不会被取代，而是沿着“开发者 → AI 监督者 → AI 编排者 → 业务战略师”的路径向上迁移，持续掌握治理、安全、架构与业务价值的核心裁决权。 敏捷周期的重塑与研发产能释放 (11:57) 随着 AI 将交付周期压缩至数小时，业界开始质疑两周或三周的固定 Sprint 机制是否过时。Hudson 认为，Sprint 已不再是工程交付的物理瓶颈，但它仍将作为业务规划、市场对齐与客户反馈整合的关键节奏而存在；交付模式正在从类似于定时排播的传统电视广播，演变为随需交付的点播流媒体。 对于研发管理层而言，核心瓶颈从来不是缺乏商业创意，而是积压需求（Backlog）受制于有限的开发带宽。工程师日常被旧系统支持、现场缺陷修复、合规审查与样板代码等琐碎事务占据。AI 飞轮有望释放团队 10% 至 30% 的研发产能，这相当于在不扩张编制的前提下直接扩充人力，推动研发部门与业务方的对话从“必须推迟哪些需求”转变为“如何交付新的客户价值”。 组织文化、治理防线与业务衡量指标 (22:04) Hudson 强调，规模化落地 AI 的真正挑战在于组织文化、职业焦虑与合规治理，而非技术本身。企业必须建立健全的信任机制与合规护栏，涵盖知识产权泄露防范、安全策略落地以及对 AI 生成代码和测试用例的审计规范。在落地推进上，组织应推行每双周一次的团队动手研讨会（AI Jams）、建立由内部技术探索者构成的倡导者网络，并争取高管对生产环境引入自主智能体的支持。 同时，评估体系必须淘汰提示词数量、代码库行数等浅层活动指标，转向衡量实质业务影响：包括变更前置时间（Lead Time for Changes）、部署频率（Deployment Frequency）、变更失败率以及客户满意度。在基础设施层面，鉴于商业 Token 计费与授权模式尚未成熟，许多企业正采用本地硬件自建开源模型（如 Llama）作为过渡桥梁。Hudson 建议工程架构保持解耦，避免与单一模型供应商深度绑定，以应对未来市场的成本与价值重构。 Hudson 总结指出，未来的行业竞争力取决于能否构建起持续自驱的“AI 原生工程飞轮”；但他也提醒，受严格监管的行业（如医疗器械与关键安全设备）因严格的验证流程仍将维持结构化发布节奏。此外，当前商业 AI 定价模式仍在演进，多智能体协作与自主交付的落地速度可能超出预期，工程团队需在维持架构灵活性与人类主导治理的前提下持续迭代演进。

## Background 该内容由行业大会组织者 Ai4 于 YouTube 平台发布，主讲人为江森自控（Johnson Controls）消防解决方案软件工程高级总监 Charles Hudson。视频主要探讨了生成式 AI 与智能体（Agentic AI）如何全面重塑软件开发生命周期（SDLC）的各个阶段，并结合工业界实战经验分享了工程组织构建 AI 原生研发飞轮与推动落地转型的具体策略。 ## TL;DR 演讲指出软件工程正在从孤立的人工敏捷交接迈向由中央调度智能体驱动的“连续工程飞轮”，交付节奏从传统的双周 Sprint 转向按需持续交付。AI 的核心价值并非单点代码补全，而是通过自动化测试与文档等琐事为团队“找回 10% 至 30% 的工程产能”，驱动团队以业务成果而非 Prompt 调用量等虚荣指标来衡量效能。在组织演进上，研发模式正经历从 AI 副驾驶、AI 队友、AI 工程团队到自主软件工厂的四大阶段，工程师的角色也全面升华为把控架构、安全与业务价值的 AI 编排者与战略家。 ## Atmosphere & style 整场演讲务实生动且充满前瞻性，Charles 开场以“挡在大家与午餐之间”的幽默自嘲迅速调动了现场气氛，分享中兼具跨国工程大厂的落地严谨与大学导师的求知热情。他毫不避讳行业内的裁员焦虑与转型阵痛，用生动的“动态 GPS 导航”等比喻拆解复杂的飞轮架构，台下互动频繁且共鸣强烈，让听众在感受到技术颠覆紧迫感的同时，获得了清晰清晰且富有信心的实战路线图。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=k10A-wAmng4&t=4s) 软件工程正处于关键技术拐点，行业讨论焦点已从最初的大语言模型单点落地全面转向 Agentic AI 与智能体协同带来的深层组织变革。 - [02:26](https://www.youtube.com/watch?v=k10A-wAmng4&t=146s) 传统 SDLC 流程及冲刺、质量门禁等机制本质上是适应过去缓慢人工生产节拍的管控手段，AI 正在将其重塑为动态自适应的持续交付新范式。 - [04:22](https://www.youtube.com/watch?v=k10A-wAmng4&t=262s) 孤立采纳单点 AI 工具（如辅助代码评审或测试用例编写）价值有限，核心突破在于通过中央调度智能体（AI Orchestrator）构建跨生命周期的“连续工程飞轮”。 - [08:53](https://www.youtube.com/watch?v=k10A-wAmng4&t=533s) 下一代软件工程依赖目标驱动（Goal-Driven）的智能体，人类工程师的定位从被动的 Prompt 编写者与代码执行者，转变为架构师、审查者与 AI 行为治理者。 - [11:57](https://www.youtube.com/watch?v=k10A-wAmng4&t=717s) AI 为企业带来的核心业务红利在于“找回工程产能”（Recovered Engineering Capacity），使团队能从深陷遗留系统与琐事中解脱，主动消化积压需求并创造新业务价值。 - [15:15](https://www.youtube.com/watch?v=k10A-wAmng4&t=915s) AI 没有杀死敏捷，反而回归并强化了敏捷宣言的核心；随着代码编写门槛降低，需求优先级排序（Prioritization）成为了新的竞争瓶颈。 - [16:59](https://www.youtube.com/watch?v=k10A-wAmng4&t=1019s) 传统的双周 Sprint 不再是研发交付的时间盒枷锁，而是演变为业务规划与决策的韵律，工程交付本身全面迈向流媒体式的即时与持续价值交付。 - [21:31](https://www.youtube.com/watch?v=k10A-wAmng4&t=1291s) 规模化推行 AI 的核心阻碍在于组织文化抗性、技能升级瓶颈、信任建立以及合规治理，而非纯技术层面的实现。 - [23:37](https://www.youtube.com/watch?v=k10A-wAmng4&t=1417s) 组织采纳 AI 需通过基层“AI Jam”实战、培育内部 Champions（布道者）圈子以及向企业高管证明实际成果三层推进，避免陷入盲目追逐最新模型的陷阱。 - [27:51](https://www.youtube.com/watch?v=k10A-wAmng4&t=1671s) 工程团队应摒弃统计 Prompt 数量或生成代码行数等虚荣指标，转而以变更前置时间、部署频率、变更失败率及业务创新速度等真实成果向决策层证明投资回报。 - [29:41](https://www.youtube.com/watch?v=k10A-wAmng4&t=1781s) 在 AI 商业化与计费模式尚未成熟的当下，本地部署开源模型等混合架构是合理的过渡形态，架构设计的关键在于保持灵活性以避免供应商模型锁定。 - [32:15](https://www.youtube.com/watch?v=k10A-wAmng4&t=1935s) AI 不会缩减工程师编制或停止初级人才招聘，而是极大缩短学习曲线并释放产能，让人类的顶层架构、系统把关与专业经验变得前所未有的珍贵。 - [34:52](https://www.youtube.com/watch?v=k10A-wAmng4&t=2092s) 软件工程中的 AI 演进划分为四个阶段：从 AI 副驾驶（Co-pilot）、AI 队友（Teammate）、AI 工程团队，最终迈向端到端需求驱动的“自主软件工厂”。 - [34:52](https://www.youtube.com/watch?v=k10A-wAmng4&t=2092s) 伴随自动化程度攀升，人类在自主工厂中不仅不会边缘化，反而将最终跃迁为负责全局治理、安全可维护性与价值创造的“业务战略家”。 - [36:45](https://www.youtube.com/watch?v=k10A-wAmng4&t=2205s) 率先构建 AI 原生工程飞轮的组织将具备指数级团队学习与迭代能力，从而在激烈的市场竞争中确立绝对壁垒与先发优势。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=k10A-wAmng4&t=4s) 站在技术拐点：从去年的探索到今年的智能体跃迁 演讲者 Charles Hudson 一开场便幽默地调侃自己处在一个“令人望而生畏的位置——因为我正挡在大家和午饭之间”，引得台下一阵会心的笑声。他环顾会场，询问台下有多少人参加过上一届的 AI4 大会，结果发现绝大多数听众今年都是新面孔。这种参会者的爆发式增长，恰好呼应了过去一年里人工智能领域的巨大剧变。去年行业还在探讨大语言模型的初步落地，而今年整个大会的核心讨论已经全面转向了 Agent（智能体）与 Agentic AI（智能体人工智能）所带来的深层组织变革。Hudson 指出，软件开发生命周期（SDLC）正在被 AI 彻底重塑，本次分享正是要剖析 AI 改变 SDLC 的深层路径、组织采纳 AI 的演进阶段，以及他在 Johnson Controls 全球工程团队与自身行业网络中沉淀的实战经验。 Hudson 坦言，软件工程的 AI 变革信息量极其庞大，涵盖的需求、架构、测试、安全等五大领域“完全可以写好几本书，或者讲上几天几夜”。然而在当下，技术迭代的速度已经超越了出版的周期——“书页刚刚印上文字，里面的内容可能就已经过时了”。因此，他特别声明本场演讲展示的并非普通的要点幻灯片，而是包含大量信息密度的参考资料库，供大家在会后查阅与持续迭代。作为一名在跨国工程巨头身居高位、同时在乔治亚大学（University of Georgia）任教的技术领袖，他给出了三点免责声明：其一，所有观点均代表个人立场；其二，整个行业正处于时空扭曲般的技术飞跃期，他的演讲 PPT 甚至不得不根据业内最新动态“每周一改”；其三，在这场全新的技术浪潮面前所有人都是求知者，正如他在大学里常对学生说的，“我从你们身上学到的，和我教给你们的同样多”。 - 演讲涵盖 SDLC 重构、智能体集成、采纳策略与落地建议五大核心板块。 - 强调当前 AI 浪潮符合历史技术周期（Tech Waves）的发展规律，传统技术跃迁模式正在 AI 时代再次重演。 --- ### [02:26](https://www.youtube.com/watch?v=k10A-wAmng4&t=146s) 传统 SDLC 的停滞与敏捷的局限：为何二十年不变的闭环需要重塑 软件工程在过去二十年里始终围绕着同一个经典闭环打转：从需求（Requirements）、设计（Design）、构建（Build）、测试（Test）、部署（Deploy）到运维（Operate），随后将反馈引入下一轮循环。虽然整个行业在此基础上不断叠加了自动化构建、安全左移（SSDLC）以及 CI/CD 等各种持续改进与持续交付流程，试图让这个环转得更快，但其本质框架从未改变。环内的每一个节点都被高度细分给各种专业岗位——系统架构师、开发工程师、QA 测试团队、技术文档撰写人员（Tech Pubs）各司其职。 ```mermaid flowchart TD accTitle: 传统 SDLC 线性交接流程 subgraph Traditional["传统瀑布与敏捷交接模式（耗时较长、人工门禁阻滞）"] A["需求分析与设计<br/>(架构师/产品经理)"] --> B["代码编写与构建<br/>(开发团队)"] B --> C["测试与安全验证<br/>(QA团队/安全门禁)"] C --> D["部署与运维监控<br/>(变更委员会 CAB/DevOps)"] D --> A end ``` 随后引入的敏捷（Agile）理念缩短了反馈周期，但开发全生命周期的底层工作机制并未发生质变。Hudson 深刻指出，诸如冲刺（Sprints）、质量门禁（QA Gates）、发布火车（Release Trains）以及变更顾问委员会（CAB）等机制的诞生，并不是因为它们本身有多完美，而是因为“过去的工程任务需要耗费大量时间”，这些流程是人类工程师为了匹配缓慢的人工生产节拍而不得不建立的管控手段。AI 的承诺正是打破这种耗时瓶颈。正如 GPS 导航从最初“设定点到点后按固定途径点行驶”进化到如今能够感知路况、实时自动重选路径的“持续动态重选路线（Continuous Rerouting）”一样，现代软件开发正在从预设固定路径的人工流程，进化为由 AI 实时动态驱动的“持续交付”新范式。 - 传统 SDLC 流程：需求分析 $\rightarrow$ 架构设计 $\rightarrow$ 代码构建 $\rightarrow$ 自动化与人工测试 $\rightarrow$ 部署上线 $\rightarrow$ 生产运维与监控。 - 借用杰弗里·摩尔（Geoffrey Moore）的跨越鸿沟理论，当前 AI 在软件开发中的应用已从早期少数极客探索，进入到了早期采纳者（Early Adopters）与主流追随者迅速扩充的临界拐点（Inflection Point）。 --- ### [04:22](https://www.youtube.com/watch?v=k10A-wAmng4&t=262s) 从“摘低垂果实”到“连续工程飞轮”：GPS 导航比喻与跨环节串联 在组织引入 AI 的初始阶段，几乎所有企业都在“摘低垂的果实（Low-hanging fruit）”。各个原本孤立的专业团队都在各自的工作流中局部尝试 AI：软件研发小组用 AI 辅助执行初步的同行代码审查（Peer Review），QA 团队用其自动编写测试用例，技术文档团队用其整理产品发布说明，甚至产品管理与法务部门也开始使用独立的 AI 辅助工具。然而，Hudson 强调，如果仅仅停留在单点工具提升每个孤立环节的效率，根本无法释放 AI 的真正潜力；真正的革命性价值在于“将各个离散环节串联起来”，把过去笨重的人工交接链条转化为高速自转的“连续工程飞轮（Continuous Engineering Flywheel）”。 ```mermaid flowchart LR accTitle: AI 编排器与智能体协同飞轮 subgraph Flywheel["智能体驱动的连续工程飞轮 (Continuous Engineering Flywheel)"] ATC["协调控制智能体<br/>(ATC / Orchestrator Agent)"] AG1["需求与架构 Agent"] AG2["代码编写与审查 Agent"] AG3["自动化测试与安全 Agent"] AG4["CI/CD 与运维 Agent"] ATC <--> AG1 ATC <--> AG2 ATC <--> AG3 ATC <--> AG4 AG1 --> AG2 --> AG3 --> AG4 --> AG1 end ``` 这种飞轮模式依托于前沿的 AI 编排器（AI Orchestrator）架构——就像空管调度系统（ATC，Air Traffic Control）一样，由一个中央调度智能体统一指挥和协调分布在需求、开发、测试、运维等各个环节的专业子智能体。过去需要团队跨越数天乃至数周的人工协同与沟通成本，在智能体协同飞轮的自适应运作下，可以在几小时内完成“从需求确立到 CI/CD 自动部署上线”的全过程。在这个飞轮运转体系中，工程师的工作重心彻底剥离了机械的任务执行，转向了顶层系统架构、AI 行为治理、安全合规验证与最终的商业业务成果交付。 - 传统模式的核心指标是工作量输出，如“写了多少行代码、封装了多少模块、发布了多少 Web 服务”；飞轮模式的核心是“能多快将创造商业价值的功能送达客户手中”。 - 核心提问的根本转变：从“我们如何把 SDLC 的每一个孤立步骤提速？”转变为“我们如何让整个工程飞轮转得更快？”。 --- ### [08:53](https://www.youtube.com/watch?v=k10A-wAmng4&t=533s) Agentic AI 与协同编排：工程师从代码执行者向架构与治理者的角色蜕变 当前大多数团队所使用的“AI 副驾驶（Co-pilots）”在本质上仍然是被动的：它们完全依赖工程师的提示词工程（Prompt Engineering），呆滞地等待外部指令输入，此时团队的衡量标准往往局限于“今天写了多少条提示词”或“是否建立了团队 Prompt 资产库”。然而，下一代软件工程依赖的是“目标驱动（Goal-Driven）”的 Agentic AI。这些智能体不仅理解特定环节的局部任务，更能在中央协调智能体的指挥下，理解全局项目目标并自主规划跨生命周期的复杂长链路工作流，自主创建工单、追踪依赖、基于代码推送与合并自动编写发布文档并触发后续测试验证。 在现场互动中，Hudson 询问在座有多少团队已经在其 CI/CD 或 SDLC 中实际部署了协调智能体（Coordinator Agents）。当看到台下举起不少手臂时，他称赞这些人是勇敢趟坑的技术先驱（Early Adopters）：“你们可以告诉大家试错的痛苦何在，而我们这些快速跟随者（Fast Followers）则可以从你们的经验教训中获益”。在智能体自动化执行各环节流程的同时，人类工程师的定位发生了根本性迁移——必须保持严格的“人机协同（Human-in-the-loop）”，工程师不再是具体的搬砖工人，而是转型为 AI 输出成果的审查者（Reviewer）、全局流程与系统的架构师（Architect）、AI 行为规范的设计者与导师（Mentor），以及关键路径的最终决策者（Decision Maker）。整个软件工程的精髓，正演进为一门“如何精巧编排人类智慧与人工智能协作”的领导艺术。 - 目标驱动与协同调度的 Agentic AI 彻底颠覆了被动等待指令的 Prompt 交互范式，驱动飞轮实现极致交付速度。 - 自动化测试（Automated Testing）是智能体落地中时间缩减最为显著、投资回报率最为直观的领域，大幅释放了 QA 与开发的交付瓶颈。 ### [11:57](https://www.youtube.com/watch?v=k10A-wAmng4&t=717s) 找回工程产能：AI 带来的真正业务红利 在软件研发流程（SDLC）中，自动化测试历来是一个常常被次要化的环节——很多工程团队为了保证基本质量和按期交付，不得不大量依赖手动测试，如果碰巧能写一些自动化测试固然好，但往往难以做到尽善尽美。这一领域正是 AI 大显身手的理想切入点；此外，持续文档编写和内置安全检查同样能被 AI 深度重塑。然而，技术本身并不直接构成竞争优势，单凭技术无法让企业在市场中立于不败之地，**关键在于技术所催生的业务结果**。 AI 带来的最大机遇实际上在于**“找回工程产能”（Recovered Engineering Capacity）**。工程主管们夜不能寐的最大焦虑不是缺乏点子，而是积压了太多业务需求却无力实现——待办列表（Backlog）日益臃肿，永远不知道何时才能排期。通过让 SDLC 的飞轮加速转动，缩短走完一个完整交付闭环的时间，工程团队能够收回大量时间与算力。这种转变本质上是一场思维方式的革命：团队不再被迫纠结于“哪些待办项目要被延期”，而是能够主动向产品经理和业务负责人探讨“我们还能创造什么新价值”。高管层最看重的投资回报——更快的客户价值交付、更高的软件质量、更低的成本、更严密的安全防护与更强的创新能力——正是由此而生。 - **现有工程产能的流失痛点**：大量团队的精力被消耗在老旧系统支持（Legacy Support）、文档编写、测试与缺陷修复、线上技术支持排错、合规审计以及重复性编码工作上。 - **释放产能的威力**：AI 通过自动化这些日常琐事释放产能；若能为工程团队找回 10%、20% 甚至 30% 的产能，其业务效益相当于直接为团队扩充了编制。 ```mermaid flowchart LR accTitle: 找回工程产能与价值循环 subgraph Bottleneck["传统困境"] A["日常琐碎负担<br/>(遗留支持/测试/文档/修Bug)"] --> B["工程产能受限<br/>(Backlog不断积压)"] end subgraph AI_Flywheel["AI 加速与释放"] C["AI 自动化日常任务"] --> D["SDLC 飞轮加速旋转"] D --> E["找回 10%-30% 产能"] end subgraph Business_Impact["业务价值"] E --> F["从'被迫延期需求'<br/>转向'主动创造新价值'"] end B -.-> C ``` --- ### [15:15](https://www.youtube.com/watch?v=k10A-wAmng4&t=915s) 重构敏捷：AI 时代敏捷宣言的强化与演进 随着 AI 极大地缩短交付周期，业内常常出现一种疑问：“我们使用了 AI，敏捷开发（Agile）是不是该被扔进垃圾桶了？敏捷是否已死？”答案显然是否定的。AI 不仅没有消灭敏捷，反而**强化并回归了敏捷原则的核心**。回顾《敏捷宣言》，其根本宗旨在于“响应变化”、“客户协作”、“频繁交付价值”以及“赋能团队”。AI 挑战的仅仅是敏捷在具体执行层面的机械流程（Mechanics），但在理念上却高度契合。 当日常管理开销减少后，团队能够把更多时间投入到客户沟通、战略思考和产品决策上。随着代码开发本身变得越来越轻量、容易，**需求的优先级排序（Prioritization）成为了新的瓶颈**——如何持续不断地将积压列表中的需求动态排定优先级，并从一线、客户与业务端源源不断地汲取创意，直接决定了企业的竞争壁垒与创新能力。因此，核心议题从来不是“敏捷能否在 AI 时代存活”，而是“敏捷如何自我演进以最大化利用 AI 的红利”。 --- ### [16:59](https://www.youtube.com/watch?v=k10A-wAmng4&t=1019s) 双周 Sprint 已死？从时间盒交付走向连续价值流 传统的敏捷开发通常建立在固定的时间周期之上，团队普遍采用两周或三周的 Sprint 周期。这种时间盒（Time-box）机制的设计初衷，是为团队走完一圈 SDLC 并打包出具有足够价值的 Release 预留时间，并配合演示（Demo）与回顾（Retrospective）等敏捷仪式来优化下一轮迭代。然而，当 AI 将交付周期从“数周”急剧压缩至“数天”甚至“数小时”时，一个具有争议性的问题浮出水面：**“两周 Sprint 真的还有存在的必要吗？”** 有 AI 技术负责人甚至直言，现在团队在几小时内就能把新功能交付上线，两周 Sprint 理应被淘汰。 然而，Sprint 的价值在工程维度之外依然存在。虽然工程研发已经不需要两周的时间限制，但**业务端依然需要这种节奏（Cadence）来进行核心决策与优先级排序**。因此，双周 Sprint 的本质发生了根本转变：它不再是研发交付的枷锁，而是转变为业务规划的韵律。这就像媒体消费模式的演变——过去人们只能在固定时间守在电视机前等待节目播出（如同等待两周 Sprint 结束交付功能），而如今流媒体服务实现了随选随看的即时点播（如同持续交付与按需发布）。 | 维度 | 保留不变的核心机制 (What Stays) | 正在发生的变化 (What Changes) | |:--- |:--- |:--- | | **研发流程** | 规划与战略对齐 (Planning) | 演变为持续工程 (Continuous Engineering) 与小步快跑发布 | | **需求管理** | 优先级排序 (Prioritization) | 动态积压列表 (Dynamic Backlogs，未来或由 AI Agent 自动排序) | | **客户与业务** | 客户反馈闭环与干系人对齐 (Alignment) | 从“时间盒交付”全面转向“持续价值交付” (Continuous Value Delivery) | | **组织管理** | 领导层可见性 (Leadership Visibility) | 行业分化：受监管行业（如医疗、特种设备）仍重度依赖固定节奏确保合规 | --- ### [21:31](https://www.youtube.com/watch?v=k10A-wAmng4&t=1291s) 规模化落地的核心瓶颈：从技术探索转向组织与治理 在企业内部推行 AI 时，采纳那些“低垂的果实”（Low-hanging fruit）非常容易。例如，将 AI 配置为代码提交时的第一道代码审查员（First Code Reviewer），在不浪费其他工程师精力的情况下快速拦截低级错误。但在尝试大规模推广时，阻碍采纳的**从来不是技术问题，而是组织变革、人与流程的挑战**。 技术团队能够快速掌握如何编写 Agent、串联 Agent 以及设定防护栏，但组织层面的阻力往往更为棘手。首先是文化抗性与变革管理，工程师在面对新技术时天然存在抵触；其次是技能升级困难，由于 AI 技术日新月异，传统的培训课程往往还没学完就已经过时。此外，与法务、安全团队的沟通以及建立对 AI 生成代码的信任，都是规模化推进的必经之路。 - **组织与文化阻力**：需要克服对变革的本能抗拒，探索超越传统培训课程的高效技能提升方式，并在各团队间沉淀与共享最佳实践。 - **信任与知识产权**：建立对 AI 生成代码与测试用例的验证机制，打消法务和安全部门对于知识产权泄露与代码安全隐患的顾虑。 - **治理与合规框架（Governance & Guardrails）**：明确企业合规政策，评估并引入经过审批的 AI 平台，制定严密的安全防护栏以满足行业监管标准。 ### [23:37](https://www.youtube.com/watch?v=k10A-wAmng4&t=1417s) 推动组织级 AI 采纳：构建文化、治理与信任体系 组织在面对 AI 技术浪潮时，必须在治理、文化与信任层面迎头赶上。Charles 提到，当前许多软件工程师都充斥着焦虑情绪，常常会问：“我会不会失业？如果 AI 接管了一切，软件工程还有未来吗？”他在会前甚至还和现场的音响视听（AV）工作人员就这个话题展开了交流。然而，要真正让 AI 发挥价值，首先要解决的就是组织层面的采纳（Adoption）与信任建立。如果缺乏信任基础，AI 根本不可能在企业中顺利落地。Charles 分享了一套实战打法（Playbook），这是他与人脉圈中的同行们在踩过无数坑后总结出的成功经验。 最成功的公司往往不是那些一味使用“更好 AI”的公司，而是那些为 AI 采纳创造了更好环境的公司。太多企业容易掉进追逐“最新、最亮眼模型”（chasing the shiny object）的陷阱，但仅仅升级模型并不能带来真正的改进；决定成败的关键，在于企业如何将 AI 深度融入到日常流程与 SDLC 当中。AI 的采纳绝不能局限于单独的软件工程团队，而必须贯穿整个企业，上至管理层，下至基层执行，所有领域都需要协同推进。 ```mermaid flowchart TD accTitle: AI 组织采纳的三层推进框架 subgraph SPRINT["基层 Sprint 团队"] A["双周 AI Jam 实践"] --> B["攻克痛点：文档/评审/拆分"] end subgraph CHAMP["骨干 Champions 圈子"] C["汇聚极客与自研爱好者"] --> D["构建知识库与培训项目"] end subgraph ENTERPRISE["企业高管与治理层"] E["关注业务产出与价值指标"] --> F["批准 Agent 准入与全面支持"] end SPRINT --> CHAMP CHAMP --> ENTERPRISE ``` - **Sprint 团队的 AI Jam 实战**：每个 Sprint 组织一次 AI Jam 交流会，公司提供午餐。团队挑选一个具体课题让 AI 尝试解决，比如将用户故事（User Story）拆解为子组件、自动生成工程师不爱撰写的技术文档、辅助代码审查（Code Review）等，采用类似黑客马拉松的形式探索，并在 1 小时后集中分享成果。 - **构建内部 Champions（布道者）团队**：以往的教训是，各团队探索出的经验往往成为彼此孤立的“智慧珍珠”。通过将那些下班后在个人电脑上跑 LLaMA、极度热爱大模型的员工拉进专属的 Teams 或 Slack 频道，放手让他们去探索，他们会自主搭建内部培训体系并在团队间快速传递实践经验。 - **获取企业层（Enterprise）高层支持**：如果无法赢得高管信任，引入 Agent 等新兴技术的尝试就会沦为艰难的逆水行舟；而赢得支持的最佳方式，就是用小步快跑的实际成果证明价值。 --- ### [27:51](https://www.youtube.com/watch?v=k10A-wAmng4&t=1671s) 告别虚荣指标：以业务成果驱动高管信任 在推进 AI 落地的过程中，许多工程管理者容易在考核指标上走入误区。Charles 坦承自己以前也踩过坑，比如去统计“这个 Sprint 团队写了多少条 Prompt”、“知识库里积累了多少 Prompt 模板”、“AI 生成代码与人类编写代码的比例是多少”等。尽管通过 Git 提交记录和推送统计很容易拿到这些数字，但对出资支持这些项目的企业高管而言，这些纯活动型指标没有任何实质意义。 工程团队应当转向关注真正驱动业务价值的核心成果（Business Outcomes）。通过持续追踪并展示引入 AI 工具前后指标的改善快照，才能让决策层看到实实在在的投资回报，进而形成长期的信任与资金支持。 | 评估维度 | 传统虚荣指标（避免采用） | 业务与工程成果指标（核心推荐） | |:--- |:--- |:--- | | **度量焦点** | 团队活动频率与工具使用量 | 交付效率、质量与业务价值 | | **典型指标** | <ul><li>每个 Sprint 的 Prompt 调用次数</li><li>知识库中的 Prompt 模版数量</li><li>AI 编写的代码行数占比（Git Stats）</li></ul> | <ul><li>变更前置时间（Lead Time for Changes）</li><li>需求在 Backlog 中的滞留时长</li><li>部署频率（Deployment Frequency）</li><li>变更失败率与自动化测试表现</li><li>客户满意度、工程吞吐量与创新速度</li></ul> | --- ### [29:41](https://www.youtube.com/watch?v=k10A-wAmng4&t=1781s) 混合架构是过渡形态：保持 AI 架构的灵活性 展望未来，Charles 指出当前面临的一大挑战是 AI 的商业模式与收入模型（Revenue Model）尚未成熟。市面上充斥着 Token 计费、按席位授权、企业级授权，甚至是成果分成（Outcome Sharing）与收入分成等各种探索方案，许多模式令人望而生畏。由于商业模式不成熟，许多企业开始走向“混合架构”（Hybrid Model）——自行采购硬件，在内网本地部署 LLaMA 等开源模型。 这种现象与当年企业从“本地自建（On-Premise）”向“公有云”迁移的历史演进如出一辙。这本质上是一个买方与卖方博弈的市场，当外部供应商提供的价值无法匹配其高昂成本时，买方自然会寻找自建替代方案。Charles 预测混合架构只是一种过渡阶段的桥梁，随着市场价值与成本逐渐回归正常化，企业最终仍会全面拥抱云端成熟方案。 - **避免模型锁定（Model Lock-in）**：工程团队现阶段最核心的原则是保持 AI 架构的灵活性（Flexibility），既可以探索本地部署 LLaMA 并评估其成本收益，也要保证未来能随时平滑切换到价值更优的云端供应商。 - **遵循技术演进规律**：每一轮重大技术变革中，商业模式与价值链的定型都需要一定周期，架构设计的首要任务是适应变化而非死守单一模型。 --- ### [32:15](https://www.youtube.com/watch?v=k10A-wAmng4&t=1935s) 组织演进与工程师角色的升华：放大价值而非取代人力 针对业界最关心的裁员与岗位缩减问题，Charles 明确表示，引入 AI 并不会导致软件工程团队的 Headcount（编制人数）减少。AI 带来的研发飞轮加速实质上释放了更大的“工程产能”（Capacity），而几乎所有软件团队的 Backlog 都堆积如山，即使产能翻倍也有海量需求亟待实现。同时，企业也不会缩减应届毕业生和初级实习生的招聘，因为这群年轻人正是未来的“AI 架构师”，维护人才梯队的健康运转至关重要。 ```mermaid flowchart LR accTitle: 工程师日常重心的演变方向 subgraph PAST["传统耗时工作"] P1["通读庞大老旧仓库"] P2["编写常规业务模版代码"] P3["手动编写技术文档"] end subgraph FUTURE["AI 赋能后的核心聚焦"] F1["攻克核心业务难题"] F2["架构设计与系统规划"] F3["AI 生成方案的校验与把关"] F4["指导/训练 AI Agent"] end PAST -->|AI 工具加速赋能| FUTURE ``` AI 工具将极大加速初级工程师的学习曲线，帮助他们快速理解庞大而复杂的老旧代码库（Legacy Repositories），大幅缩短从入职到产生生产力的时间。管理层的重心也将从监控具体活动彻底转向衡量业务成果、创新步伐与实际价值。Charles 强调，"AI 不会取代工程师，它放大的是工程师的影响力，并让人类的专业经验变得前所未有的珍贵"。岗位的演化与职衔的更迭已经在发生，例如传统的网络安全专家正迅速转向“AI 架构师”，软件工程正在迈入全新的进化阶段。 ### [34:52](https://www.youtube.com/watch?v=k10A-wAmng4&t=2092s) AI 演进的四个阶段：从副驾驶到自主软件工厂 在综合了行业分析师洞察、广泛同行交流以及对过往数字化转型和技术浪潮的深度反思后，软件工程中 AI 的演进路径可以清晰地划分为四个发展阶段。目前整个行业正处于前两个阶段的过渡期。第一阶段是大家已经非常熟悉的 **AI 副驾驶（AI Co-pilot）** 模式，开发者通过 Prompt Engineering（提示词工程）与 AI 协同工作；第二阶段正在迈向 **AI 队友（AI Teammate）** 模式，由具备特定技能的 Agent（智能体）作为团队成员与人类并肩编写和交付代码。 随着技术进一步成熟，演进将进入第三阶段 **AI 工程团队（AI Engineering Teams）**，最终迈向第四阶段令人惊叹的 **自主软件工厂（Autonomous Software Factories）**。在自主软件工厂的终极愿景下，人类只需给出所需功能或完整产品的顶层规格与指导原则，由 AI 构成的软件工厂便能全盘接管并端到端自主完成构建。 ```mermaid flowchart LR accTitle: AI 在软件工程中的四个演进阶段及人类角色转变 subgraph S1["第一阶段: AI 副驾驶"] A1["协作模式: Prompt Engineering"] A2["人类角色: Developer 开发者"] A3["核心目标: 提升生产力"] end subgraph S2["第二阶段: AI 队友"] B1["协作模式: Agent 并肩协作编码"] B2["人类角色: AI Supervisor 监督者"] B3["核心目标: 提升交付速度"] end subgraph S3["第三阶段: AI 工程团队"] C1["协作模式: 多 Agent 自主协作开发"] C2["人类角色: AI Orchestrator 编排者"] C3["核心目标: 系统与流程优化"] end subgraph S4["第四阶段: 自主软件工厂"] D1["协作模式: 需求驱动端到端自主交付"] D2["人类角色: Business Strategist 业务战略家"] D3["核心目标: 驱动业务成果"] end S1 --> S2 --> S3 --> S4 ``` 尽管 AI 的自动化程度不断攀升，但人类在软件生命周期中 "绝对不会消失"。相反，人类的角色定位与核心价值正在经历深远的重塑与升级： - **人类兜底职责**：人类始终需要负责全局把关，包括治理体系（Governance）、系统安全（Security）、顶层架构（Architecture）以及方案的长期可维护性（Maintainability）。 - **角色梯次演进**：人类工程师的角色正从传统的「代码开发者（Developer）」转变为「AI 监督者（AI Supervisor）」，再升级为「AI 编排者（AI Orchestrator）」，最终进阶为聚焦价值创造的「业务战略家（Business Strategist）」。 - **价值重心迁移**：研发效能的衡量标准正从初期的「个体生产力（Productivity）」转向「交付速度（Speed）」，再到「系统级优化（Optimization）」，最终完全聚焦于「实际业务成果（Business Outcomes）」。 --- ### [36:45](https://www.youtube.com/watch?v=k10A-wAmng4&t=2205s) 打造 AI 原生工程飞轮与重塑未来工程师 AI 技术的演进速度极其迅猛，当前的阶段时间线预测随时可能被打破——也许明年重聚时，行业就已经跨越到了第三阶段的多智能体协同。面对这种技术奇点，未来的主导权必然属于那些率先构建起 **AI 原生工程飞轮（AI-Native Engineering Flywheel）** 的组织。 ```mermaid flowchart TD accTitle: AI 原生工程飞轮运作机制 A["构建 AI 原生工程飞轮"] --> B["释放工程产能与研发资源"] B --> C["加速产品创新与前沿探索"] C --> D["团队学习迭代速度大幅提升"] D --> E["每次发布交付更高业务价值"] E --> F["工程师获赋能解决更高阶复杂难题"] F --> A ``` 通过建立 AI 原生工程飞轮，组织能够释放出大量原本消耗在日常编码中的工程产能，并将其重新投入到产品创新与前瞻性探索中，从而在激烈的市场竞争中确立绝对优势。在这样的飞轮驱动下，每一个团队的学习与迭代速度都会呈指数级提升，每一次软件发布都能交付更高密度的业务价值，而每一位工程师也将被赋予前所未有的能力去攻克更高维度的复杂难题。 演讲最后，Charles Hudson 表达了对现场众多参会者的由衷感谢，并分享了自己的联系方式。他谦逊地表示自己是一个“终身学习者”（Perpetual Student），期待与行业同行持续交流碰撞，共同学习并探索 AI 原生时代的软件工程新范式。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=k10A-wAmng4&t=4s) 令人望而生畏的位置——因为我正挡在大家和午饭之间 — Charles Hudson > [00:04](https://www.youtube.com/watch?v=k10A-wAmng4&t=4s) 书页刚刚印上文字，里面的内容可能就已经过时了 — Charles Hudson > [00:04](https://www.youtube.com/watch?v=k10A-wAmng4&t=4s) 我从你们身上学到的，和我教给你们的同样多 — Charles Hudson > [02:26](https://www.youtube.com/watch?v=k10A-wAmng4&t=146s) 过去的工程任务需要耗费大量时间 — Charles Hudson > [04:22](https://www.youtube.com/watch?v=k10A-wAmng4&t=262s) 将各个离散环节串联起来 — Charles Hudson > [04:22](https://www.youtube.com/watch?v=k10A-wAmng4&t=262s) 我们如何让整个工程飞轮转得更快？ — Charles Hudson > [08:53](https://www.youtube.com/watch?v=k10A-wAmng4&t=533s) 你们可以告诉大家试错的痛苦何在，而我们这些快速跟随者（Fast Followers）则可以从你们的经验教训中获益 — Charles Hudson > [16:59](https://www.youtube.com/watch?v=k10A-wAmng4&t=1019s) 两周 Sprint 真的还有存在的必要吗？ — Charles Hudson > [23:37](https://www.youtube.com/watch?v=k10A-wAmng4&t=1417s) 我会不会失业？如果 AI 接管了一切，软件工程还有未来吗？ — Charles Hudson > [32:15](https://www.youtube.com/watch?v=k10A-wAmng4&t=1935s) AI 不会取代工程师，它放大的是工程师的影响力，并让人类的专业经验变得前所未有的珍贵 — Charles Hudson ## Mentioned Charles Hudson, Johnson Controls (江森自控), Ai4, University of Georgia (乔治亚大学), Geoffrey Moore (杰弗里·摩尔), LLaMA, Microsoft Teams, Slack, Git, SDLC (软件开发生命周期), Agentic AI, CI/CD ## Video description Charles Hudson - Senior Director Software Engineering, Johnson Control Fire Solutions The software development lifecycle is being transformed faster than at any point in its history—and AI is at the center of that change. This talk explores how AI is reshaping every phase of the SDLC, from requirements and architecture through testing, security, deployment, and operations, while introducing new concepts such as Agentic AI, continuous engineering, and AI-native development. Attendees will learn how engineering organizations, Agile practices, AI adoption strategies, and business models are evolving, along with practical recommendations for leading this transformation. Whether you're an engineering leader, architect, or software professional, you'll leave with actionable insights to help your organization build software faster, smarter, and with greater business impact. [Source](https://www.youtube.com/watch?v=k10A-wAmng4)

[0:04] Charles Hudson: 令人望而生畏的位置——因为我正挡在大家和午饭之间 [0:04] Charles Hudson: 书页刚刚印上文字，里面的内容可能就已经过时了 [0:04] Charles Hudson: 我从你们身上学到的，和我教给你们的同样多 [2:26] Charles Hudson: 过去的工程任务需要耗费大量时间 [4:22] Charles Hudson: 将各个离散环节串联起来 [4:22] Charles Hudson: 我们如何让整个工程飞轮转得更快？ [8:53] Charles Hudson: 你们可以告诉大家试错的痛苦何在，而我们这些快速跟随者（Fast Followers）则可以从你们的经验教训中获益 [16:59] Charles Hudson: 两周 Sprint 真的还有存在的必要吗？ [23:37] Charles Hudson: 我会不会失业？如果 AI 接管了一切，软件工程还有未来吗？ [32:15] Charles Hudson: AI 不会取代工程师，它放大的是工程师的影响力，并让人类的专业经验变得前所未有的珍贵

[0:04] Charles Hudson: ominous position of keeping everybody from lunch [0:04] Charles Hudson: are going to be out of date [0:04] Charles Hudson: time warp [5:08] Charles Hudson: continuous engineering flywheel [5:08] Charles Hudson: how do we accelerate the entire flywheel? [11:57] Charles Hudson: which projects do we have to delay? [11:57] Charles Hudson: what new customer value can we create? [16:59] Audience Member: They should be. [23:37] Charles Hudson: shiny object [23:37] Charles Hudson: pearls of wisdom [36:58] Charles Hudson: perpetual student

[0:04] Okay. So, I have the uh ominous uh [0:07] position of keeping everybody from [0:09] lunch. So, I'll try to go through this [0:12] as quick as possible. Uh we have a [0:15] tremendous amount to go through and it's [0:17] amazing to see the difference in the [0:19] past year. Uh I was here last year. How [0:22] many people were here last year for AI4? [0:24] So, everyone else is new this year. It's [0:27] incredible to see what we're talking [0:29] about in terms of transformation with [0:31] agents from the past talks. So that's [0:32] what we're going to delve into here is [0:35] for the software development life cycle. [0:37] How is AI changing it? Where do we think [0:40] it's going to go? How are organizations [0:42] adopting AI? Along with some tips and [0:45] tricks that I've found along the way [0:47] through my own network, myself, my [0:50] organization. So let's dig right into [0:53] it. Okay. [0:56] So, we're going to cover five areas. [0:59] Okay, we're going to be discussing many [1:00] of the questions around SDLC. Uh, we do [1:03] have a lot of material. We could [1:04] literally be here for hours and days. [1:06] There are books being written about this [1:08] right now, but however, as soon as those [1:10] first words go on pages, they're going [1:12] to be out of date, right? We're moving [1:14] that fast in this. So, I do apologize up [1:17] front. These are not going to be normal [1:19] bullet slides. These are going to be [1:20] reference slides, reference material, [1:22] okay? So please use them for that in the [1:24] future hopefully and if you find updates [1:27] let me know. Okay. Uh so here's my [1:31] disclaimer. My disclaimer is these are [1:34] my opinions even though I'm tied to a [1:36] large organiz organization uh global [1:39] engineering uh tied to a university. [1:41] These are all my own opinions. Uh second [1:44] we're in the middle of a time warp. [1:45] Okay. I've had to update this [1:47] presentation literally by the week [1:49] because of different events happening. [1:51] Okay. But that's part of the exciting [1:53] piece that we're going through right [1:54] now, the exciting era. And then lastly, [1:59] uh we're all learners in this, right? [2:01] We're all students. Uh one of the things [2:03] I I tell my students that I teach at [2:05] University of Georgia is that I'm [2:06] learning as much from them as they're [2:08] hopefully learning from me, right? We [2:09] all bring this to the table. So I [2:11] welcome discussions after the fact. Uh [2:14] this is a passion of mine is the digital [2:16] transformation, the tech waves that we [2:17] go through. And this is yet another tech [2:19] wave that we see with the same patterns [2:21] as past tech waves. And we'll touch on [2:23] some of that uh going on. So we're at an [2:26] inflection point right now with AI, [2:29] especially with software development. [2:31] Okay, that inflection point means that [2:34] the curve is changing. We're reaching a [2:36] point where we have adoption, right? [2:40] Compared to last year, this time we have [2:42] significant adoption. We have mature [2:44] maturity happening agents, agentic AI. [2:47] Okay, we have some leaders, right? Some [2:52] early adopters, as Jeffrey uh Moore [2:55] would say, some early adopters. We have [2:57] some lagards, some followers. Uh but [3:00] it's becoming mainstream. Look at the [3:02] sheer number of people that are here [3:04] now. Okay. So, with the SDLC, this is [3:08] the the loop that we're familiar with [3:10] from many many years. those that have [3:12] been in software development for for you [3:15] know last 20 years uh this loop has not [3:19] changed we've overlaid things onto this [3:21] loop like security CI/CD process [3:24] continuous improvement continuous [3:26] delivery processes right to try to speed [3:28] up this loop as much as possible [3:30] [snorts] [3:31] but it's the same loop it's requirements [3:34] design build test deploy operate and [3:37] repeat right take that feedback feed it [3:39] back into the cycle we have different [3:42] specialists at each phase in this. We [3:45] have architects, we have testers, we [3:47] have tech pubs, all of these different [3:50] specialized positions. Okay? And agile [3:54] has shortened this feedback loop, right? [3:56] We've adopted agile into this process, [3:59] but the life cycle remains pretty much [4:00] the same. Okay? [4:03] We have sprints, QA gates, release [4:05] trains, cabs. They've all evolved [4:08] because engineering work has taken time. [4:11] Okay, this is the promise of AI is [4:13] shortening that time and we'll get into [4:14] this. These weren't bad processes, but [4:17] they were what fit our slower world in [4:21] this case. [4:22] Okay, so AI is enabling the SDLC to [4:26] evolve uh just like a lot of our prior [4:30] technologies. Think about GPS [4:32] navigation. If you were taking a trip [4:34] years ago when GPS first came out and [4:37] you may have had uh these navigators, [4:39] you would say, "I want to go from X to [4:42] Y, but I need to go through certain [4:44] steps along the way." Now, we've [4:47] progressed to continuous GPS or [4:50] continuous rerouting, right? That's the [4:53] same way we can think about AI. We've [4:55] had a path before. We've had to follow [4:57] that path. But now we have the idea of a [5:00] continuous path and AI creating that [5:03] continuous delivery uh real time. [5:06] Okay. [5:08] So we're going to look at the delays in [5:11] this SDLC and see how AI has improved [5:14] it. Each of these steps that are in that [5:17] and we've added security here for the [5:19] SSDLC. [5:20] Okay. uh for all those that practice [5:23] SSDLC [5:24] each of these you can think of we've [5:27] taken the lowhanging fruit in AI right [5:32] every every group that is assigned to [5:35] each of those steps in SDLC has said [5:37] okay I can use AI in certain ways [5:40] whether that be peer reviews the first [5:42] peer review that happens in a software [5:44] development team I can have it write uh [5:47] tests for my QA team I can have it write [5:50] document mentation in tech pubs, right? [5:54] And we've had some growth there. We've [5:55] grown typically from the software team [5:58] out into other teams. It could be [6:00] product management, QA, tech pubs, legal [6:04] even. And that's what we've seen. But [6:07] the real value here I would I would [6:09] propose is not the efficiency that we're [6:12] gaining in each step of the SDLC, but [6:16] much more being able to chain the steps [6:18] together. And this is where that agentic [6:20] AI comes in. We'll get into that in a [6:22] minute. But being able to actually turn [6:25] this from a slow driven [6:31] handoff type of wheel where one team [6:34] hands off to another into more of a [6:39] flywheel. And that's what we're seeing [6:41] on the right hand side is we're trying [6:43] to take each of these steps now and make [6:49] them much more efficient. Right? So just [6:51] was as was being said by the prior [6:53] speaker about him creating a AI [6:56] orchestrator, right? Where you have an [6:59] ATC controlling or a co coordinator [7:02] controlling m multiple AI agents, right? [7:06] that AI agent could control the [7:08] different AI agents in each one of these [7:10] steps. [7:12] Okay, so it's continuous engineering [7:14] flywheel development to improve the [7:17] overall time. So work as we know that [7:20] took days and weeks now with AI helping [7:24] as co-pilots are really speeding up this [7:27] flywheel. Okay, we're able to get it out [7:29] in hours potentially, right? where a [7:32] feature is developed based on a [7:34] requirement and actually through CI/CD [7:37] and agents and AI technology is being [7:39] deployed out to the customer. [7:42] Okay. So engineers in these steps are [7:45] shifting from executing tasks [7:48] to architecture to governance security [7:53] validation and most importantly business [7:56] outcome right they're thinking how do I [7:59] actually get this feature out to the [8:01] customer that creates value okay instead [8:04] of how many lines of code have I written [8:08] right instead of how many modules did I [8:11] create instead of how many web services [8:14] did I uh post out there, right? And [8:17] we'll talk about measurements and KPIs [8:20] uh in a little bit. Okay, so the key [8:24] question [8:26] changes from how fast can we make each [8:29] step, right? because that's the [8:31] lowhanging fruit I would propose you [8:33] know from these AI tools whether it [8:36] doesn't matter what tool you're using [8:38] but in each of these steps there's [8:39] lowhanging fruit that you can grab for [8:42] expediting that step but more to how do [8:45] we accelerate the flywheel [8:48] how do we turn this faster so this is [8:51] that inflection point [8:53] so with the agentic AI [8:56] if AI can assist with every step what [8:59] happens when and it becomes coordinating [9:01] those steps on its own. As we mentioned, [9:03] that's where the agentic AI can be very [9:05] powerful, right? Because it agents [9:08] inside those individual steps of the [9:10] SDLC [9:12] are really responding to what we tell [9:14] those agents to do. Okay? They're not [9:17] executing on really an overall plan from [9:20] beginning to end. Okay? It might be uh [9:24] creating a ticket. It might be uh [9:27] creating a set of release notes based on [9:30] check-ins, right? Or pushes. [9:33] Okay, so AI co-pilots, you know what are [9:37] what most people are using right now? [9:39] They wait for prompts, right? That's our [9:42] prompt engineering. Okay, that's where [9:44] now the measurement is how many prompts [9:46] have you created today? Right? Do you [9:48] have a prompt library? Right? Instead, [9:52] we want to get to agents that are goal [9:54] driven. [9:56] And those goals might be for the [9:59] specific steps, but when they talk to a [10:02] coordinator agent, now you're talking [10:05] about the entire flow around. So the [10:09] engineers's role in all this shifts from [10:13] execution [10:14] to it might be reviewer of the AI [10:17] results, right? Still has human in the [10:19] loop. architect. How do I architect that [10:22] entire flow with agents? Okay, designer, [10:25] mentor, decision maker, how should the [10:28] agents behave? [10:30] Okay, so engineering becomes that the [10:34] real leadership of orchestrating humans [10:36] and AI together. [10:41] In fact, we're already seeing this. [10:43] Major AI vendors are investing heavily [10:46] in agent-based workflows and [10:48] development. Uh, some of you may be [10:51] doing this in your own organizations. [10:53] How many actually have coordinator [10:55] agents in their CI/CD or SDLC right now? [11:00] So, quite a few. So, these are the early [11:03] adopters, right? You can tell us what [11:05] the pain is like and then we all learn [11:07] from you as the fast followers, right? [11:10] going back to uh product life cycles. [11:13] Okay, so Agentic AI amplifies the impact [11:18] by automating execution across the steps [11:21] while humans still provide the judgment [11:24] and accountability in this. So the [11:28] obvious benefit to a aentic AI is what [11:32] then? It's speed, right? That's what we [11:35] we've been saying is it's speed. It's [11:37] getting this flywheel to go faster and [11:39] faster that we can deliver customer [11:42] value faster and faster. [11:45] And with that, it's faster features, [11:49] it's automated testing, right? Automated [11:52] testing is probably one of the biggest [11:54] impacted areas for time savings I would [11:57] propose inside the SDLC. If you take [11:59] each one of those steps, automated [12:01] testing, if you're like my organizations [12:04] that I've been involved in, it's one of [12:06] those that has been secondary, right? [12:08] You you want to get out quality, you [12:11] focus on manual testing, you get it out [12:12] there. If you get some automated [12:14] testing, great. Okay, this is an area [12:17] ripe for AI. But you have continuous [12:20] documentation, built-in security in this [12:23] process. But technology alone doesn't [12:25] comp doesn't create competitive [12:28] advantage and that's really what's going [12:30] to make the business survive. Okay, is [12:32] that competitive advantage. [12:35] So the business outcomes that it creates [12:39] does. So the bigger opportunity here is [12:42] what I propose is the recovered [12:44] capacity, the recovered engineering [12:47] capacity. How many people here uh you [12:51] know I talk to friends in my network [12:53] engineering leaders and what keeps them [12:55] up at night is the uh number of ideas [12:58] that they have that they can't implement [13:00] for business right how big is your [13:02] backlog right how many when are you [13:04] going to get to those items on the [13:06] backlog right that's that's what keeps [13:08] me up at night as well is that capacity [13:11] and that's what I would say is the real [13:13] benefit here is the capacity the more [13:14] that we can get that flywheel spinning [13:17] the greater capacity [13:19] we have. Okay. So, it's fundamentally a [13:23] mind shift. [13:25] It's changing how we look at the work [13:28] we're doing. Instead of being able [13:30] having to say which projects do we delay [13:33] in the backlog, right? And to our [13:35] product managers and the business [13:36] owners, we're saying okay, what new [13:40] value can we create? Because now we're [13:42] recovering capacity. [13:45] This is also where executives are going [13:48] to want to invest, right? Faster [13:51] customer value, higher quality, lower [13:54] costs, better security, greater [13:56] innovation. [13:57] Okay, so again, I would say the benefit [14:01] here is not how fast that flywheel is [14:04] spinning, but what do we gain back from [14:08] the capacity by it taking less time for [14:11] us to get around that circle, around [14:14] that loop? [14:15] You know the biggest constraint isn't [14:17] ideas. It's the engineering capacity. Uh [14:20] today too much capacity if you're uh [14:23] like a lot of the organizations I speak [14:25] with is spent on legacy system support [14:30] documentation testing and bug fixes tech [14:33] support issues in the field compliance [14:37] repetitive coding. [14:39] Okay. AI reclaims engineering capacity [14:42] by automating routine work. Think what [14:44] you could address in your backlogs if [14:47] you had 10 20 30% more capacity, right? [14:51] That's like adding adding headcount to [14:53] your teams. [14:55] That's the key here. [14:57] However, if AI can now move the SDLC [15:00] flow dramatically faster, it does raise [15:03] some interesting questions about the [15:05] processes and the techniques that we've [15:07] been using for years in software [15:09] development, [15:11] right? And that's what we're going to [15:12] get into next here. It's rethinking [15:15] agile. [15:17] So I talked to a lot of people and and [15:19] they say, "Okay, [15:21] uh I'm using AI. Does that mean agile [15:24] goes out the window?" Okay, does it mean [15:27] agile is dead if I have AI? And my my [15:32] clear answer is no. I think in fact it [15:34] reinforces AI uh reinforces agile with [15:39] the AI. Okay. [15:41] It doesn't replace it. It actually [15:43] strengthens the agile principles. If you [15:46] go back to the agile manifesto, right? [15:49] It's its priorities are response to [15:52] change, collaborate with customers, [15:55] deliver value frequently, and empower [15:57] teams. So even though the AI may [16:00] challenge our mechanics of agile, right, [16:03] how we implement agile, it's actually [16:06] supporting the manifesto and the [16:08] principles of agile. So with less [16:11] administration, more time for customers, [16:14] strategy and product decisions. So as [16:16] development gets easier, prioritization [16:19] becomes the bottleneck, right? Taking [16:22] that backlog and keeping it prioritized [16:24] in a continuous fashion. [16:27] Uh and those product decisions, right? [16:30] What is of true value to the customer? [16:33] getting that funnel fed with the ideas [16:35] from the field, from customers, from [16:37] business to keep the business [16:39] competitive and to differentiate the [16:41] business and be innovative. [16:43] So again, I don't believe the question [16:46] is whether agile survives AI. It's much [16:49] more how will agile evolve to take [16:51] advantage of it. Okay, we may have to [16:54] change the mechanics that we use with [16:56] agile. [16:59] Okay. Traditional agile was built around [17:03] how many week sprints? Who's doing two [17:05] week sprints here? Yeah, three week [17:08] sprints. Do I hear three? Okay. Okay. We [17:12] based it around time cycles and that was [17:14] a time that we felt it was enough to get [17:18] around that loop of the SDLC to be able [17:22] to get out enough value in a release. [17:25] Right? That's the goal. We have our [17:27] ceremonies around agile. We have our [17:30] demos, our retrospectives. We feed that [17:33] back in and hopefully we can deliver [17:35] more value in the next sprint, right? [17:37] And improve our efficiency and and how [17:39] fast we uh go through those sprints. [17:43] Uh as we know though, AI compresses now [17:45] this delivery, right? If we're changing [17:48] it from weeks to days, [17:51] the question becomes, [17:54] what's the value of a two-eek sprint? [17:56] Right? This is where I really want to [17:59] pose a question to everyone. And this is [18:02] probably going to be the most [18:03] controversial slide that I have. What [18:06] are two week sprints dead? [18:09] They should be. I got a comment down [18:11] here. Uh it's interesting. I was talking [18:13] to a friend of mine, a past student who [18:16] is heading up AI for a company in [18:18] Georgia and he said there's no reason we [18:22] need twoe sprints now. I can have [18:23] features delivered out uh into our [18:26] application in hours right with his [18:28] team. [18:30] So does it serve a purpose two week [18:33] sprints? I would propose yes, it still [18:36] does for a lot of companies. Not for [18:39] engineering per se, right? Because we [18:41] can actually now accelerate this [18:44] flywheel, but I would propose that for [18:47] the business to be able to make those [18:50] primary decisions of what's valuable for [18:53] customers and to prioritize those items [18:56] for development. They need that cadence, [18:59] right, to use an agile term. So even [19:02] though it you know the sprint I don't [19:04] think it disappears it may evolve how we [19:07] run those sprints what ceremonies are [19:09] involved in there and what priorities [19:11] those ceremonies take okay so what stays [19:15] we still need planning we still need [19:16] prioritization customer feedback [19:19] stakeholder alignment and leadership [19:21] visibility those are all key pieces that [19:24] are associated with this what changes [19:26] we're now into continuous engineering [19:29] dynamic backlogs [19:31] Okay, I'll be very interested to see if [19:33] someone creates an agent that is able to [19:35] prioritize a backlog. Okay, very [19:39] interesting challenge. [19:41] Smaller releases and continuous [19:43] deployment things we've been trying to [19:45] overlay onto the SDLC for years, right, [19:48] with our CI/CD processes and various [19:51] tools that we brought in. So, another [19:54] way I like to think about this is think [19:56] about streaming media now, right? Before [19:59] streaming media, we had scheduled TV [20:02] programs. Okay? You could only watch a [20:05] certain program unless you had a DVR or [20:07] some other fancy technology which was [20:09] developed to solve a purpose, a problem. [20:13] Uh by tuning in at that time, right? [20:16] That's very much like our two week [20:18] sprints, okay? Or three-week sprints. [20:21] You know, the expectation is I'm going [20:22] to have that functionality at the end of [20:24] the sprint. Right now we have streaming [20:27] services on demand. You know, watch it [20:29] on the plane, download it, watch it [20:32] anywhere. Okay, that's very much what we [20:34] have now. Continuous delivery, quicker [20:37] releases of features. Okay, and the [20:40] business is going to have to adjust to [20:41] that. So, as an outcome, the sprint [20:44] becomes a planning rhythm. I believe [20:46] this is that cadence for the business, [20:49] not a delivery constraint. And that's [20:52] key. It's a planning rhythm for the [20:54] business, not a delivery constraint for [20:57] the engineering. So AI transforms agile [21:00] from time box delivery to continuous [21:04] value delivery. [21:06] Some organizations, especially regulated [21:08] industries, are still going to have [21:11] challenges with this though and they'll [21:12] still benefit from that structured [21:14] cadence uh quite a bit. Okay? And [21:17] there's several different regulated [21:18] businesses out there. If you're in [21:20] medical for example or any uh regulatory [21:24] business, appliances as an example, uh [21:28] you're going to be constrained by this [21:29] heavily. [21:31] Okay. So, how do we scale this? And this [21:34] has been one of my challenges in [21:36] different organizations and in talking [21:37] with a lot of uh larger groups is [21:41] adopting AI. It's very easy to adopt it [21:45] with that lowhanging fruit. You know, [21:48] for example, making it the first code [21:51] reviewer in your process when you are [21:53] ready to check in code, right? That's a [21:56] very easy way to gain some benefit. [21:58] You're not wasting time of other [21:59] engineers. You can have it review and [22:02] catch the simple mistakes, right? This [22:05] is the lowhanging fruit. What I've seen [22:08] is it's not a technical challenge. Once [22:10] a business actually dives in and says [22:13] we're going to implement and allow AI [22:15] tools, it's not a technical challenge [22:18] then that's preventing the adoption. [22:20] It's much more a organizational [22:22] challenge. It's people in process change [22:25] management cultural resistance, right? [22:28] People are adverse to change by default [22:31] a lot of the times. Okay, it's [22:34] upskilling engineers to use AI [22:36] effectively. You know, it's changing [22:38] daily. So, you can't just typically sign [22:41] people up for AI courses because by the [22:44] time they take the course, the course is [22:45] already outdated, right? That's what I [22:47] found at least. [22:49] Uh, building trust in AI generated code, [22:53] right? How many people have had uh [22:54] conversations with their legal group [22:56] about AI code, right? And security about [22:59] it, right? So building that trust, [23:02] consistent adoption across teams, [23:05] sharing knowledge and best practices, [23:07] and then technology and governance, [23:09] governance, protecting uh intellectual [23:11] property, meeting security, regulatory [23:14] compliance, validating AI generated [23:16] software and tests, and establishing AI [23:19] policies, guard rails, and approved [23:20] platforms. Right? This is what [23:24] organizations really need to focus on. I [23:26] think on an engineering side AI becomes [23:29] another tool right we can understand how [23:32] to write agents how to link agents [23:34] together how to put guard rails in place [23:37] the organization needs to catch up and [23:40] be there with the governance the culture [23:42] and the trust right how many people have [23:45] heard the whole thing I'm going to lose [23:47] my job I'm a software engineer right [23:50] there's no future in it for me if AI [23:51] takes everything over I was just having [23:53] this conversation over with the AV guys, [23:56] right? Uh that you know, will it get to [23:59] that point? We'll talk about that. But [24:03] first is adoption, okay? And building [24:05] that trust. So if there's not that [24:08] trust, [24:09] you're not going to get the AI adopted [24:12] into the organization. And this is a [24:14] quick playbook I put together, just some [24:17] of the things that have worked for [24:18] myself and my network of friends. We've [24:21] made lots of mistakes along the way, [24:24] right, of things not what to do. These [24:26] are the things that we found actually [24:28] worked very well. And I'll just touch on [24:30] upon uh a couple of these, but the most [24:33] successful companies aren't necessarily [24:35] those using better AI, [24:38] right? They're creating better [24:39] environments for AI adoption. So, I hear [24:42] too many companies that I talk to [24:45] falling for the trap of chasing the [24:47] shiny object, chasing the latest model, [24:50] right? [24:51] It's not the model that will improve it. [24:54] It's how well is your company actually [24:56] adopting it into the processes and [24:58] that's key for that SDLC. [25:01] So an adoption can't happen in just one [25:03] team. You know it can't just be the [25:05] software engineering team that adopts [25:06] it. This has to be the entire [25:08] organization. And this is what I'm [25:10] proposing here is that you have [25:12] different activities in every area of [25:15] the enterprise including executives that [25:18] have to happen for adoption to be catal [25:21] a catapulted into full [25:25] trust support for the organization. So [25:28] some of the quick things I run AI jam [25:32] sessions once every sprint. Bring in [25:34] lunch. Each team picks one topic that [25:37] they want to approach to try to have AI [25:41] solve. That could be everything from uh [25:44] taking a user story and breaking it down [25:47] in components. uh some software [25:51] engineering challenge that software [25:54] engineers by default are either not [25:56] excited about doing could be writing uh [26:00] writing documentation, right? It's not [26:02] high up on the list for software [26:04] engineers typically. Okay? It could be [26:07] doing code reviews better. It could be [26:09] breaking down stories better. Uh any of [26:12] these and it's a free-for-all. It's a [26:15] hackathon to use the tools and then they [26:17] come back together in that hour and [26:18] share that. Okay, that works well for [26:21] individual sprint teams. Okay, that's [26:23] that first section. But you got to get [26:27] that up above as well. This is one of [26:29] the problems I've had in years past is [26:32] then you have these pockets of all these [26:34] little pearls of wisdom but not being [26:37] sure to cross. So, one of the things [26:40] that I've learned through my network is [26:42] you create a team of champions. And [26:45] these are the folks that go home on the [26:47] weekends, go home at night, have their [26:49] personal projects, they're exploring, [26:52] you know, the latest LLMs, they're [26:55] they're building llama on their own [26:56] systems. Uh they're really passionate [26:59] about this. They become your champions [27:02] inside. Pull them onto Teams, pull them [27:04] onto a Slack channel, and let them [27:06] loose, right? and they will build your [27:09] education programs. [27:11] They'll look at new technologies. [27:13] They'll share these pearls of wisdom [27:15] across the teams and that's been [27:18] extremely uh beneficial for multiple [27:22] enterprises. [27:24] Okay. And then the last I would mention [27:26] here is the last column on the end there [27:30] enterprise. If you don't have buyin from [27:33] the enterprise, [27:35] it's going to be a very tough uphill [27:37] battle, right? If you can't get agents [27:39] into your landscape uh because that's [27:41] not trusted yet, that's not a trusted [27:44] technology, these are the folks that you [27:46] need to get on board. So, we'll talk [27:48] about how how you get those on board. [27:51] How you get those on board is by showing [27:53] success. [27:55] Little steps along the way of success. [27:59] And too many times I've heard and I've [28:02] made this mistake myself of creating [28:04] KPIs around how many prompts did we do [28:08] this sprint, right? Do we have a prompt [28:11] library in our knowledge base that we [28:12] can share across, right? How many lines [28:15] of code were written by AI versus human, [28:19] right? And you look at the check-ins or [28:21] the git pushes, you know, all that and [28:24] you can get those stats, right? But [28:27] those I would say are not going to be [28:29] important to the enterprise to the [28:32] executives who are supporting these [28:34] endeavors who are investing in these [28:36] endeavors. Okay. Instead we want to look [28:39] at the business outcomes. So engineering [28:43] needs to focus more on things like lead [28:45] time for changes. Can we shorten that? [28:47] How long is it sitting in the backlog? [28:49] Deployment frequency. How often is that [28:52] flywheel spinning around and we're [28:54] getting to the operation state where [28:56] we've been deployed and we're actually [28:57] analyzing what's out there. Okay. [29:00] Changing changing the failure rate. How [29:03] well are we doing with automated test [29:05] customer satisfaction engineering [29:07] capacity innovation velocity? And I've [29:09] given a couple hypothetical uh amounts [29:12] up here. But being able to take [29:14] snapshots and show based on the tools [29:17] that you're using and the endeavors [29:19] you've already been able to do in small [29:20] steps how these are improving. That's [29:23] what's going to make a difference for [29:24] the enterprise and the executives who [29:26] are making the investment. Okay. So [29:29] let's talk about the future then. Right? [29:32] That's kind of where we're at the [29:33] inflection point. We're moving into this [29:36] new stage of this era. What about the [29:39] future? [29:41] So, one of the biggest challenges I've [29:43] seen and I'd be interested if this is [29:45] the case for everyone else is that we [29:48] know the business model around AI, the [29:50] revenue model is not mature. It's still [29:52] very young, right? We have uh different [29:55] revenue models of tokens, seat licenses, [29:59] enterprise licenses. There's even been [30:01] talk about outcome sharing, revenue [30:04] sharing, right? [30:05] uh which is a scary topic for I know for [30:07] a lot of people [30:09] but [30:11] what we're seeing is this is causing a [30:15] new direction inside teams and that is [30:18] this hybrid model inside companies right [30:22] where you're actually bringing it could [30:24] be llama inside right you're buying the [30:28] hardware okay does this remind anybody [30:30] of of a past trend we went through cloud [30:35] right on-site, right? And then we move [30:38] to cloud. Same type of maturity that [30:41] needs to happen here, right? It's a [30:43] marketplace. We have buyers and we have [30:45] sellers. If the value for the buyers is [30:49] not high enough, then we're going to [30:51] look at other options. And that's what [30:53] we're seeing. So, I don't think the [30:55] hybrid is going to stick around. That's [30:57] my personal prediction. I think it's a [30:58] bridge until the value and the cost [31:03] normalizes in that marketplace. Right? [31:06] So the key for us is yes, we can look at [31:09] llama. Okay, I know several groups doing [31:11] so. Uh we can try to see what the the [31:14] benefits of that are, what the cost uh [31:18] valuation is for each solution and [31:20] compare them. [31:22] But for engineering teams, the more [31:25] important aspect is going to be that we [31:26] can adjust, right? That we're not [31:29] locking into a specific model. That if [31:31] we decide, hey, we want to go to the [31:33] cloud later because that's more [31:35] beneficial for us that we can actually [31:38] go and then sign up with these vendors [31:40] wholly, if there's enough value there [31:42] and the cost is low enough for us based [31:44] on what we're getting out of that [31:47] relationship. So we've seen this before [31:50] and this repeats itself with every [31:52] maturing technology wave, every [31:54] transformation that happens. Uh it takes [31:56] a while for that revenue model, that [31:58] business model to mature over time. [32:02] Okay. So in the end to be successful, we [32:05] should be flexible in our AI [32:07] architecture. Okay. And ready for these [32:09] models to change. I fully expect we'll [32:12] be seeing a lot of changes coming on. [32:15] So we get back to the engineering [32:17] organization. [32:18] I got six minutes here. So get back to [32:20] the engineering organization. How's it [32:22] how's it changing? So it's changing in [32:26] several different ways. But first off, I [32:29] don't think the head the number of [32:30] headcount changes whatsoever, right? [32:32] Because again, if we focus on what the [32:35] flywheel going faster gives us, which is [32:38] more capacity. [32:40] Again, if you're like me, my backlog is [32:43] quite long. I have enough work to take [32:46] off that backlog for a long time even [32:48] with that added capacity. Right? So I [32:53] don't see it and I I would love to talk [32:55] to people more about this about what [32:56] you're seeing. I don't see it shrinking [32:58] the headcount. Right? In addition, I [33:02] don't see at least in the people I talk [33:05] with about it shrinking the hiring of [33:10] new engineers out of college interns, [33:14] those those younger career engineers [33:18] because they're going to be the future [33:20] AI architects, right? We need to keep [33:23] that system going. Okay? [33:27] So you know engineers going to spend [33:29] more time on business problems, [33:31] architecture and system design, [33:33] validating AI generated solutions, [33:36] mentoring AI agents and high impact [33:38] technical decisions. So what we will see [33:41] with those new engineers is we'll see [33:43] much quicker learning curves, right? [33:46] Because they have the AI tools to help [33:48] them with the repos, the old repos, [33:50] understanding the code bases that are [33:51] there. They're going to scale that hill [33:54] much faster, right? they're going to [33:57] have the tools coming out of [33:58] universities uh that will help them get [34:01] up to speed more quickly. [34:04] So AI accelerates that learning, [34:06] shortens the time to productivity for [34:08] new engineers. Uh leadership shifts from [34:11] measuring activity to measuring [34:13] engineering outcomes, right? That goes [34:15] back to the KPIs, innovation and [34:17] business value. So in the end, I don't [34:20] see AI replacing engineers. It amplifies [34:23] their impact and makes human expertise [34:25] even more valuable. Okay. So the role is [34:28] going to change. Just this morning I was [34:30] talking with someone over breakfast and [34:32] just in the last two months his title [34:33] changed from cyber security to AI [34:36] architect. Right? So the roles are going [34:38] to change the titles are going to [34:40] change. Right? We're going to evolve in [34:42] the software engineering. [34:44] Okay? But I don't think we'll see a [34:46] replacement. [34:48] Okay. And then finally, [34:50] what's the next 10 years going to look [34:52] like? And this is taken from a whole [34:54] wide range of sources, uh, everyone from [34:57] industry analysts to conversations I've [35:00] had to my own thoughts of analyzing what [35:04] we're seeing with AI to past digital [35:06] transformations to past tech waves. And [35:09] so we can divide it into really four [35:11] sections here. Uh, and we're between, I [35:16] would say, those first two. We know we [35:18] we're familiar with working as a [35:20] co-pilot with AI having it working with [35:23] us prompt engineering [35:26] uh as a developer [35:29] we're moving into this AI teammate [35:32] having our agents working alongside of [35:34] us right developing code alongside of us [35:38] then we move into the AI engineering [35:41] teams and finally to this point of [35:44] autonomous software factories it's a [35:47] wild concept where uh someone can [35:51] provide the the guidelines of a feature [35:54] they're looking for or even a product [35:56] they're looking for and the factory of [35:59] AI takes over and runs with it. Right? [36:03] But what I want to make sure people note [36:04] here is if you see those boxes on the [36:07] bottom for the human side, it never [36:12] disappears, [36:14] right? there's still a human there [36:16] figuring out how is the government [36:18] governance on this, how is the security [36:20] on this, how's the architecture on this, [36:22] how's the maintainability of this [36:24] solution uh going forward. But we're [36:27] seeing the roles change, right? We're [36:28] going from a developer to an AI [36:31] supervisor to a AI orchestrator to a [36:35] business strategist. [36:37] Okay? We're going from productivity to [36:40] speed to optimization to business [36:43] outcomes. [36:45] Okay? And the timing might be off, [36:46] right? We might be back here next year [36:48] and say we've already moved into uh the [36:50] third section, right? So the timing [36:53] might be way off. Don't know. It'll be [36:55] very interesting to see. [36:58] But in you know, in the end, the future [37:00] belongs to the organizations that build [37:02] an AI native engineering flywheel, [37:05] right? because those are the [37:06] organizations that are going to have the [37:07] extra capacity to work on innovation and [37:10] new products and be competitive in the [37:13] market, right? Every team is going to [37:16] learn faster. Every release is going to [37:18] deliver more value and every engineer is [37:21] going to be empowered to solve bigger [37:22] problems than ever before. Okay, that's [37:26] the end of my talk. So, thank you very [37:28] much. I'm very humbled that so many [37:29] people came. [applause] [37:35] [applause] [37:36] That's my information there if you'd [37:38] like to uh connect with me or have [37:40] questions. Again, I'm a perpetual [37:42] student, so always interested in what [37:45] other people are seeing and learning [37:47] from you.