QualityAI Bans AI Coding for Junior Hires to Curb Technical Debt

QualityAI禁止初级员工使用AI编程以遏制技术债 不受约束的合成代码生成速度已超出企业测试基础设施的承受能力，并削弱了初入职场者的解决问题能力，迫使工程领导层推行人工责任制，并限制初级开发者使用辅助工具，直至其掌握核心系统。 工程领导层审视了从人工软件交付向AI辅助及智能体开发的转变，并警告称，代码生成已成为大宗商品化技术，而验证、安全和架构设计则变得至关重要。专家组强调了主要的运营摩擦点，包括概率性智能体的非确定性、PR审查瓶颈、不断收窄的漏洞修复窗口以及数据主权风险。为缓解技术债务和技能退化，企业正在引入多级质量关卡、专门的AI治理机构，并审慎对初级工程师实施工具限制。讨论最终强调，软件工程正在转向规范驱动型开发，将开发者从单纯编写语法的打字员提升为全局问题解决者和系统编排者。 企业在落地AI时常会遭遇生产环境悬崖，因为开发者在本地生成代码时的高度信心并未转化为面向客户环境时的确定性可靠度。 (5:04) 成功的企业AI赋能依赖于四大相互关联的支柱：人员（上下文提示）、流程（语义验证）、技术（领域适配工具）和文化（人工代码责任制）。 (5:04) 由于自主智能体本质上具有非确定性，企业必须执行分层验证流水线，并强制要求由人类工程师对每一个AI生成的commit进行签核确认。 (8:19) 随着基础代码生成普及化，软件工程技艺正在从人工编写语法转向全局系统架构、上下文工程和领域问题求解。 (12:47) 在涵盖数据、模型、集成和业务成果验证层的AI保障金字塔（AI Assurance Pyramid）框架推动下，质量保证正在企业内部迎来重大复兴。 (16:01)

Engineering and quality leaders argue that generative coding tools shift the primary software engineering bottleneck from writing syntax to managing non-deterministic risks, architectural verification, and upstream requirements engineering. While AI accelerates initial code synthesis, enterprise production readiness requires strict human accountability, multi-layered quality gates, and stringent governance over intellectual property and data retention. The Production Gap and Developer Identity (5:04) Panelists Chris Johnson and Vikul Gupta emphasize that developer confidence during local code generation frequently collapses at production deployment because probabilistic agentic output lacks deterministic reliability. Gupta cites an industry benchmark indicating that roughly 95% of enterprise AI pilots fail before reaching production, pointing to organizational breakdowns in establishing trust, architectural grounding, and intellectual property compliance. Ravi Teja Prabhala Venkata contrasts deterministic code, which can be validated with dozens of unit tests, with fundamentally non-deterministic agents that demand stacked verification pipelines and bounded operational scopes. Accountability, Code Reviews, and Verification Gates (19:06) As automated generation floods code repositories, the panel mandates that every machine-generated pull request must have an assigned human engineer who retains full personal accountability for production behavior, security flaws, and maintenance. Chris Johnson argues that finite human review capacity must be redirected away from cosmetic syntax checks toward high-risk pathways, specifically authentication, authorization, access control, and input validation. To prevent cognitive review fatigue, Prabhala Venkata advocates treating PRs as granular mini-design documents, deploying independent secondary AI models to audit authoring tools, and maintaining a strict zero-trust posture toward AI-generated output. Skill Atrophy and Developer Onboarding Limits (25:28) Accelerated coding poses severe risks to fundamental engineering competencies. Gupta details a six-month internal pilot evaluating fresh college graduates who used AI coding assistants; the company found that their unassisted coding capabilities stalled while technical debt increased. Consequently, the firm instituted a mandatory two-year ban on AI coding assistants for entry-level engineers to ensure they master deployment pipelines, containerization, and complex portfolio dependencies before adopting automated tooling. Panelists agree that engineering prestige is decoupling from typing speed, redefining the profession around validation, problem-solving, and architectural design. Intellectual Property and Data Governance Controls (29:06) Deploying generative tools across proprietary repositories introduces significant legal and compliance exposure. Prabhala Venkata warns that unverified large language models risk introducing copyleft open-source licenses (such as GPLv1 or GPLv2) or compromising patent eligibility, recommending immutable audit trails that record prompts, model versions, and timestamps for all synthetic code. Madhavi Najana notes that poor governance leads firms to 'pay twice'—purchasing vendor tokens while leaking proprietary business logic. In response, regulated enterprises establish dedicated AI Offices to enforce regional data sovereignty, zero-retention contractual agreements, and sandboxed testing for pre-release models. Upstream Specification and Requirements Engineering (36:08) Software engineering effort is shifting upstream into specification creation, with Gupta noting that bad requirements account for 37% of testing defects. In response, teams deploy orchestration platforms like CoCo to ingest multi-modal documentation—including BPM flows, PDFs, meeting transcripts, and repository context—and convert ambiguous requests into structured engineering criteria. While traditional enterprises find engineers and product managers spending up to 70% of their time crafting product requirement documents, fast-moving technology companies often bypass upfront PRDs entirely, relying on AI to reverse-engineer user stories and architectural intent directly from engineering discussion transcripts to maintain institutional memory. The panel concludes that generative artificial intelligence does not eliminate software engineering roles, but instead evolves practitioners into orchestrators and forward-deployed engineers who oversee delivery from requirements to operations. However, reconciling rapid automated generation with strict enterprise compliance, developer skill preservation, and production stability remains an evolving operational challenge.

在Ai4研讨会上，多位企业技术高管指出，生成式AI编码工具虽极大加快了代码生成速度，却在生产一致性、系统安全性与团队工程底蕴上带来了严峻断层。专家们认为，企业必须建立以人类为最终责任主体的多层治理门禁，并将技术重心向上游规范设计与质量工程转移。 生产部署断崖与非确定性系统的信任困境 (5:04) Chris Johnson与Vikul Gupta指出，开发团队在本地生成代码时普遍信心充足，但投入生产环境时却频遭滑铁卢。由于大型语言模型本质上具备非确定性，无法通过传统几十个单元测试来穷尽覆盖，导致约95%的企业AI试点项目因无法验证可靠性与依赖映射而停滞于沙盒阶段。Gupta提出涵盖人员、流程、技术和文化的四大支柱框架，强调企业当前的瓶颈已从“如何编写提示词”转变为“如何建立组织与架构信任”。 在责任归属层面，Madhavi Najana与Ravi Teja Prabhala Venkata结合金融监管要求警告，未经验证的自主智能体极易受提示注入攻击或在孤岛化系统中偏离规则。为防止系统失控，所有由AI生成的代码拉取请求（PR）与部署操作必须强制绑定具体的人类工程师签署并全权负责，坚决消除匿名代理提交代码带来的合规盲区。 代码审查重构、门禁防御与初级工程师断代 (22:11) 面对AI引发的“代码海啸”，代码审查机制正在经历根本性重构。Johnson与Prabhala Venkata强调，审查不应耗费在排版等表面语法上，而必须严格聚焦于身份鉴权、访问控制和输入验证等核心安全路径。Prabhala Venkata主张建立多层防御管线：首先运行静态分析和密钥扫描，随后由独立的第二方模型进行对抗性交叉审计（避免由同一编写模型自行审查），最后由人类工程师进行最终验证。Najana指出，在自动化攻击工具普及的背景下，安全漏洞的修复窗口已从数周骤缩至几小时以内。 技术加速同时引发了工程能力的传承危机。Gupta分享了一项为期六个月的跟踪研究：直接使用AI辅助工具的应届大学毕业生，在自主编码能力和复杂分布式系统理解上毫无长进，反而滋生了更多技术债务。为此，其团队推行了严格决策，要求新入职员工必须在脱离AI工具的环境下手工编码两年以筑牢底层基础，方可获得辅助工具权限。 知识产权溯源、数据合规与双重付费陷阱 (29:06) 将生成式引擎直接接入专有代码库带来了显著的知识产权与协议合规风险。Prabhala Venkata提示，模型训练集若包含具有传染性的开源代码（如GPL许可），可能破坏企业自研算法的排他性或专利申请资格。为此，企业需在代码签入时建立包含模型版本、提示词和时间戳的不可变元数据审计链，以便在发生法律纠纷时实现定向隔离与溯源修正。 在数据资产安全维度，Najana提醒企业警惕“双重付费”陷阱——既向AI供应商采购算力令牌，又在交互中无意识泄露内部业务逻辑与敏感数据结构。针对服务商在预览版本中常设的30天遥测留存等条款漏洞，Gupta指出成熟金融与医疗机构已普遍设立独立的“AI办公室”，推行企业级零留存协议、区域数据驻留要求，并实施严格的沙盒试用机制以防泄密。 规范驱动开发与产品工程角色的上游迁移 (36:08) Gupta指出，测试周期中发现的缺陷有37%可直接归咎于需求规格不当。为消除源头瑕疵，企业正借助多模态编排平台将凌乱的业务会议录音、流程图与文档自动转化为结构化验收标准。随着底层代码生成趋向自动化，产品经理与工程师高达70%的精力正向上游转移，集中于产品需求文档（PRD）推敲、边界条件梳理及遗留系统上下文喂入。 工具的平民化促成了开发与产品边界的深度交融：产品经理可直接生成功能原型供工程团队评估架构弹性，而工程师也更早介入业务定义以确保技术可行性。与此同时，大型科技公司常因极速迭代而放弃书面文档，QA团队则通过AI反向解析架构会议录音并自动重构用户故事，从而在维持高速交付的同时沉淀组织代码记忆。 专家一致认为，AI并未淘汰软件工程，而是将从业者重塑为主导系统架构、业务需求与整体交付的协调者（如“前沿部署工程师”）。然而，在非确定性输出激增与漏洞修复窗口极限压缩的双重压力下，自动化验证流程与组织治理规范能否真正跟上代码膨胀的步伐，仍是整个行业面临的长期挑战。

## Background 本内容由 Ai4 于 2026 年 8 月 21 日发布在 YouTube 平台上。视频记录了一场由 Patrick Akil 主持的圆桌讨论，汇聚了来自 Capital One、QualityAI、Phase2 及辛辛那提联邦住房贷款银行的多位工程领袖，共同探讨 AI 编码时代下代码质量保障、安全红线合规、开发流程演进以及工程团队文化的重塑。 ## TL;DR 圆桌讨论深入剖析了 AI 编程助手在提升研发速度的同时所引发的质量信任危机、非确定性测试困境以及审查瓶颈。专家们强调无论代码由谁生成，人类工程师都必须承担绝对的最终兜底责任，并提出了异构多模型交叉审查、粒度化 PR 以及强制 PR 设计文档等治理方案。针对初级开发者培养，嘉宾分享了反共识的‘新手禁用 AI 纯手工编码两年’试点经验，以夯实系统工程直觉；同时提醒企业警惕开源许可证污染、尝鲜访问条款与数据泄露等法律暗坑。最后，讨论延伸至‘规范驱动开发’与需求源头质检，指出 AI 正在模糊研发、产品与销售的边界，催生出能够统揽全链路的复合型工程师。 ## Atmosphere & style 现场氛围专业务实且极具思辨色彩，既有资深工程老兵会心一笑的默契互动，也有直面失控案例与法律暗坑时的严肃警醒。主持人控场灵活自然，与台下经验丰富的资深观众频繁共鸣，嘉宾们各抒己见且毫无空洞说教，分享了大量一线踩坑的鲜活内幕。整场对话既充满对前沿技术落地的清醒审视，又散发着对软件工程本质与工程师角色重塑的理性乐观。 ## Key takeaways - [05:04](https://www.youtube.com/watch?v=aON2GZ6soIo&t=304s) 企业引入 AI 智能体时面临采纳不均与生产落地信任危机，必须从文化（代码所有权认知）、流程（审查演进）、技术（场景化选型）与人员（体系化赋能）四个维度（PPTC 模型）协同治理。 - [08:19](https://www.youtube.com/watch?v=aON2GZ6soIo&t=499s) 确立人类兜底责任制与加固非确定性防护：无论代码由何种 AI 生成，都必须明确指定具体工程师承担连带责任；面对智能体的非确定性输出，团队需大幅加固底层安全防御措施。 - [14:02](https://www.youtube.com/watch?v=aON2GZ6soIo&t=842s) 软件工程师的核心价值从单纯编码转向“问题解决者”：写代码只是实现手段之一，AI 工具大幅降低了学习与试错成本，使工程师能跨界处理更广泛的业务流程与系统架构问题。 - [16:01](https://www.youtube.com/watch?v=aON2GZ6soIo&t=961s) 构建四层 AI 质量保障金字塔：为打破 95% 企业 AI 项目无法上线的魔咒，QA 迎来复兴，企业需在数据基础、模型构建、系统集成可用性及业务产出四个层级逐级建立信任验证机制。 - [18:15](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1095s) 代码审查战略转向安全架构红线并引入异构多模型互审：放宽展示层等低风险代码的人工审查，全力聚焦鉴权、角色与输入校验等安全核心，且严禁用生成代码的同一模型复审自身产出。 - [20:08](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1208s) 警惕盲目服从的“氛围编码（Vibe Coding）”：提交 PR 时必须附带迷你设计文档以阐明技术意图与权衡，且 PR 粒度必须与敏捷 Story 严格对齐，防止巨幅 AI 劣质代码合入主干。 - [24:32](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1472s) “代码海啸”导致安全漏洞修复的时间窗口剧烈收缩：AI 代码生成速度远超团队下游测试与吸收能力，在对抗性智能体面前，安全响应窗口已从以往的数天数月压缩至数小时之内。 - [25:39](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1539s) 初级开发者应暂缓依赖 AI 工具以夯实工程基本功：企业真实对照试点表明过早使用 AI 会削弱独立开发能力，强制前两年纯手写代码才能建立对上下游架构、流水线与质量门禁的真实工程直觉。 - [27:36](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1656s) 代码审查文化范式转移：审查重心从“挑语法拼写与格式错误”转向“谁能向团队清晰解释业务逻辑、谁来兜底架构可重用性、合规授权及模型训练数据谱系”。 - [29:01](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1741s) 严防知识产权污染与“企业买单两次”风险：AI 代码暗藏 GPL 等传染性开源协议风险可能破坏专利申请，同时接入企业数据层时需建立元数据审计链与隐私隔离，防止核心数据沦为外部训练原料。 - [31:34](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1894s) 法务硬指标与“尝鲜访问（Early Access）”合规陷阱：企业应设立 AI 办公室严格管控数据留存周期与数据物理驻留，并警惕前沿模型预览版协议中默认存储 30 天数据的尝鲜条款击穿合规防线。 - [36:05](https://www.youtube.com/watch?v=aON2GZ6soIo&t=2165s) 规范驱动开发（Spec-Driven Development）让开发重心大幅前移：37% 的测试缺陷源于糟糕的需求定义，团队需将精力投向 Specs 打磨，借助 AI 吞吐多模态输入并建立双向追溯安全网。 - [42:04](https://www.youtube.com/watch?v=aON2GZ6soIo&t=2524s) 全链路角色边界消融与“前向部署工程师”兴起：AI 赋能从编码纵深溢出至 QA 自动化、运维故障分诊及商业化线索挖掘，复合型工程师可单兵编排打通从需求捕获到生产部署的全生命周期。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=aON2GZ6soIo&t=4s) 嘉宾背景介绍与工程领导力定位 圆桌主持人 Patrick Akil 热情开场，看着台下座无虚席的会场，给每位嘉宾一分钟时间简要介绍自己的身份与核心业务。 首先发言的是 Phase2 的首席 AI 技术专家 Chris Johnson。他之前曾担任工程副总裁，统管全体工程研发团队；公司主要为客户提供定制化开发服务，涵盖移动端与 Web 端应用，目前的核心业务不仅是用 AI 来辅助构建这些系统，还将 AI 直接融入系统的实际运行中。 接着是 QualityAI 的首席技术官 Vikul Gupta。他在该公司任职 5 年，专注利用 AI 贯穿研发全生命周期（AI for Dev、AI for QA、AI for Ops）。Vikul 强调质量是刻在他们 DNA 里的基因，他们在这个领域深耕了 28 年；在加入 QualityAI 之前，他曾担任惠普软件（HP Software）的 CTO，并在大型系统集成商（SI）负责测试业务。他幽默地总结道，自己先后在全球最大的测试软件提供商、全球最大的测试服务 SI 工作过，而如今身处“全球最智能的质量工程公司”。 随后是来自 Capital One（第一资本）的软件工程高级经理 Ravi Teja Prabhala Venkata。Ravi 笑称自己的全名太长，平时大家都叫他 Ravi。他目前在基础设施部门领导 EC2 实例团队，负责为全公司所有业务线应用团队提供安全加固的基础镜像（hardened images），同时主导多项创新 AI 项目。在此之前，他曾在多家金融科技机构担任高管，在移动开发、数据架构与数据工程等领域有广泛经验。 最后一位嘉宾是辛辛那提联邦住房贷款银行（Federal Home Loan Bank of Cincinnati）的软件工程经理 Madhavi Najana。作为拥有 20 年行业经验的资深技术专家，她同时也是俄亥俄州 Women in AI 大使、英国计算机学会会士（BCS Fellow）以及福布斯技术理事会（Forbes Technology Council）成员，致力于与行业领袖共同探索 AI 在金融受监管场景中的安全应用。 --- ### [02:51](https://www.youtube.com/watch?v=aON2GZ6soIo&t=171s) 现场观众画像：从业年限与 Agentic 工具链偏好调查 为了更好地调整演讲深度与沟通视角，主持人现场对观众进行了一系列举手互动调研。现场不仅有大量的工程师个体贡献者（IC）、产品经理（PM）和技术主管，还包括工程经理、高管（C-Level）与安全专家。Madhavi 敏锐地指出，现场来自安全（Security）领域的代表相对偏少。 在从业年限调查中，现场展现出了极高的资历壁垒：几乎全场举手超过 5 年，随着 10 年、15 年、20 年乃至 25 年的门槛依次递进，依然有大量资深从业者挺立，甚至一路飙升到 35 年与 40 年。最终，全场向一位从业超过 40 年的资深前辈致以敬意，主持人笑称“这位 40 年经验的先生获胜了”。 随后主持人调查了大家在日常开发中使用的智能体工具与开发框架（Agentic Harnesses）： - **主力编码助手**：Claude Code 和 OpenAI Codex 占据了相当大的比例，Google Gemini 也有部分拥趸。 - **新兴 AI 原生 IDE**：现场有不少开发者正在使用 Cursor 和 Windsurf。 - **开源框架与自主 Agent 探索**：部分团队开始使用 OpenCode、OpenClaw 以及 Hermes 等开源工具或完整的全自主 Agent 团队方案。 --- ### [05:04](https://www.youtube.com/watch?v=aON2GZ6soIo&t=304s) 引入 Agent 工具后的断层：生产落地信任危机与 PPTC 四维模型 围绕智能体工具如何真正改变研发节奏，主持人向 Chris 提问：当团队引入智能体工具后研发速度确实提升了，但随之而来的会是什么东西率先崩溃？ Chris 指出，最先出现的破裂往往是**不均衡的采纳率（uneven adoption）**。团队中部分技术先锋对工具爱不释手，极力推动整个组织往前跑；但第二个最致命的崩溃点在于**生产环境落地时的信心断崖**——在本地演示时一切看似完美，可一旦到了交付给真实客户和上线生产的关头，团队就会猛然发现其输出缺乏足够的连贯性与一致性，根本不敢轻易推向生产环境。 ```mermaid flowchart TD accTitle: AI Adoption PPTC Framework accDescription: 四维协同落地模型：人员、流程、技术与文化 subgraph Culture["文化层面 (Culture)"] C1["代码所有权认知"] C2["人机协同包容度"] end subgraph Process["流程层面 (Process)"] P1["代码审查重构"] P2["依赖关系与版权合规"] end subgraph Technology["技术层面 (Technology)"] T1["按场景选型 (Cursor / SAP Joule 等)"] T2["上下文与知识库注入"] end subgraph People["人员层面 (People)"] direction TB E1["AI Elevate 赋能体系"] E2["熟练度 (Fluency)"] E3["认证 (Certification)"] E4["实战专家 (Practitioner)"] E1 --> E2 --> E3 --> E4 end Culture <--> Process Process <--> Technology Technology <--> People ``` Vikul 对此深表赞同，并分享了一个典型客户案例：该客户不同业务线各自构建了大量 Agent，但没有一个能够上线生产，核心阻碍就在于**如何建立对 AI 的信任**。在工程师层面，大家普遍担心失业风险，同时苦恼于 AI 生成代码的版权归属（Copyright）与依赖关系映射（Dependency Mapping）是否准确。针对这些痛点，Vikul 提出了企业成功实施 AI 必须协同治理的四个维度： - **文化（Culture）**：如何看待“AI 生成代码与人类编写代码的融合”，建立对机器生成内容的合理预期。 - **流程（Process）**：旧有的研发流程必须发生形态演变（Morph），以适应人机协同开发。 - **技术（Technology）**：杜绝一刀切式的强制工具指令，针对具体场景匹配工具（例如企业级 ERP 场景可选用 SAP Joule）。 - **人员（People）**：单纯给员工分配 ChatGPT 或 Claude 账号远远不够，必须培训员工如何编写优质 Prompt 以及如何为模型提供精准的上下文与知识库。QualityAI 内部推出了名为 **AI Elevate** 的赋能体系，引导员工完成从“语言熟练度（Fluency）”到“专业认证（Certification）”再到“实战专家（Practitioner）”的系统化进阶。 --- ### [08:19](https://www.youtube.com/watch?v=aON2GZ6soIo&t=499s) 智能体失控案例、责任归属与非确定性挑战 Madhavi 从金融受监管行业的严谨视角切入，指出业界已有许多 Agent 脱离预设范围引发灾难的真实案例。近期就发生过客服 Chatbot 被客户通过提示词操控，不仅超越了原本仅提供咨询的边界，甚至违规以超低折扣价将产品直接出售给客户的事件。她强调，企业在部署 Agent 时必须明确其能力边界（Guardrails），坚决防止智能体成为各自为政的“系统孤岛（Siloed Agents）”，必须将它们有机编排并接入现有的工作流与批处理任务中。 针对主持人提到的“是否应为每个 Agent 分配具体的实际负责人”，嘉宾们展开了关于**代码审查与责任归属（Accountability）**的深入讨论： ```mermaid flowchart LR accTitle: Code Review and Ownership Workflow accDescription: AI代码审查与人类连带责任归属流程 A["AI Agent 生成代码"] --> B["指派人类工程师 (Owner)"] C["人类自写代码"] --> B B --> D["全量代码审查 (Code Review)"] D --> E["安全扫描与漏洞修复"] E --> F["生产环境发布与长期兜底责任"] ``` - **人类兜底机制**：Vikul 阐述了其工程团队践行的准则——无论代码由谁生成，AI 产出的代码必须明确指定给具体的人类工程师认领。该工程师必须将其视同己出，对合并后的代码质量、安全扫描、缺陷修复及后续维护负全部连带责任。 - **非确定性测试困境**：Ravi 指出，软件工程正面临根本性的范式转移。对于传统确定性（Deterministic）代码，工程师编写 10 到 30 个测试用例就能实现完备验证；但 Agent 本质上具有**非确定性（Non-deterministic）**，哪怕给它一个边界明确的任务，其行为路径也是动态多变的。这要求团队必须大幅加固底层安全防御措施，建立更为严苛的防护机制。 ### [11:59](https://www.youtube.com/watch?v=aON2GZ6soIo&t=719s) AI 智能体的现实落差与会议场景中的惊艳表现 在面向公众的业务中，尤其是受到强监管的金融机构，部署 AI 智能体（Agent）必须经历极其严苛的层层验证与护栏机制。一位讲者分享了自己昨晚入住酒店时的真实经历：他试图致电酒店协商提前入住，接听电话的是一个 AI 智能体，他与该智能体周旋了整整 20 分钟却一事无成，最终不得不转接人工才解决问题。这说明现阶段许多领域的智能体仍处于初级阶段，要想建立起能够放心交接任务的信任感，仍需要一段漫长的过程。 与此形成鲜明对比的是，另一位讲者分享了自己在本次 AI4 大会预约系统中的惊艳体验。在会议平台的角落里有一个 AI 智能体，用户只需告知自己的身份、所在公司以及想要寻找的潜在客户画像，智能体就会自动推荐匹配的客户，甚至能够追踪谁查看了你的展位或企业主页。更令人称奇的是，该智能体还能针对不同的客户高管（例如 GAP 或 Blue Origin 的 CTO）量身定制精准的理想客户画像（ICP, Ideal Customer Profile）推介词，并在几秒钟内自动检索出双方共同的空闲时间段，甚至主动推荐沟通话术并代发信息。这种极度流畅的体验表明，智能体在特定场景下确实大有可为，但前提是必须经过严密且充分的测试。 ```mermaid flowchart TD accTitle: AI 智能体在会议预约场景的全自动工作流 subgraph S1["潜在客户挖掘"] A["输入公司信息与目标画像"] --> B["分析展位/主页访客数据"] B --> C["筛选出前 10 位匹配客户"] end subgraph S2["推介与建联"] C --> D["根据客户背景生成定制化 ICP 推介词"] D --> E["自动跨日历检索双方空闲时间段"] E --> F["推荐沟通消息内容并一键发送"] end ``` --- ### [14:02](https://www.youtube.com/watch?v=aON2GZ6soIo&t=842s) 新一代工程师的职业认同危机与软件开发的本质重塑 讲者分享了一个发生在家里的真实故事：他的儿子刚从弗吉尼亚理工大学（Virginia Tech）软件工程专业毕业，并专修了 AI 相关模块。然而，在花费巨资完成学业并观察了当下市场后，儿子的第一反应竟然是"我不想做软件开发人员了"。年轻人认为，普通程序员费尽心思写出来的代码，自己借助 AI 只要 5 分钟就能搞定，因此传统开发岗位的价值已大打折扣。不仅如此，讲者在接触许多高校学生时也发现，大量原本学习技术的年轻人正试图转向"如何将 AI 应用于销售"等业务类岗位，因为他们觉得这类角色在长期来看更有保障。 针对这种初期的认知偏差，Chris Johnson 从工程文化层面给出了反思。他指出，如果一个人对软件开发的定义仅仅停留在"一行一行地写代码"，那么其职业未来的确面临巨变；但现代团队所寻找的开发者本质上是"问题解决者（Problem Solvers）"。写代码只是解决问题的手段之一，有时开发者的价值体现在为客户梳理出全新的业务流程或优化工作流。AI 工具的真正价值在于大幅降低了学习和上手成本，让工程师能够跨界解决过去无法触及的更广泛问题。 --- ### [16:01](https://www.youtube.com/watch?v=aON2GZ6soIo&t=961s) AI 质量保障（QA）的复兴与四层 AI 质量金字塔 随着编写基础代码的门槛不断降低，系统架构设计的地位急剧上升。在构建深度融合 AI 的应用时，开发团队必须应对一系列复杂架构挑战：如何选型工具、如何通过 MCP（Model Context Protocol）服务器等机制完成系统集成、如何处理上下文层（Context Layer）的准确接地（Grounding），以及最终如何完成系统化测试。过去软件行业曾经历过 QA 团队被缩减的阶段，而如今 QA 的需求却迎来了爆发式增长，核心原因在于传统开发者普遍缺乏测试和验证 AI 生成代码的经验与能力。 ```mermaid flowchart TD accTitle: AI 质量保障四层金字塔架构 subgraph L4["业务产出保障 (Outcomes Layer)"] D["是否达到高管预期：生产力提升、客户互动与业务回报"] end subgraph L3["系统集成保障 (Integration Layer)"] C["性能、可扩展性、可用性 (如构建的购物车是否真正可用)"] end subgraph L2["模型保障 (Model Assurance)"] B["传统模型/生成式/智能体：是否构建了正确的 AI 逻辑"] end subgraph L1["数据基础保障 (Data Layer)"] A["基础数据质量：传统数据与 GenAI 训练/提示词数据"] end L1 --> L2 --> L3 --> L4 ``` 讲者结合近期与 Forrester 的探讨，阐述了一个用于建立 AI 信任的四层"AI 质量保障金字塔（AI Assurance Framework Pyramid）"： - **底层：数据层保障（Data Layer）** —— 确保拥有正确的底层构建块与高质量数据（无论是传统数据还是生成式 AI 所需数据）。 - **第二层：模型保障（Model Layer / Model Assurance）** —— 确保构建 AI 的方式正确无误，涵盖传统机器学习模型、生成式模型及智能体链路。 - **第三层：系统集成保障（Integration Layer）** —— 确保构建出符合业务意图的 AI 系统，重点检验端到端集成后的性能、可扩展性以及可用性（例如开发了购物车功能，但用户却无法正常下单结算）。 - **顶层：业务成果保障（Business Outcomes Layer）** —— 衡量 AI 是否真正兑现了 C-Level 高管所期望的生产力跃迁和客户参与度提升。 如果企业无法在各层级建立起全方位的保障与信任机制，就会陷入永无止境的低效实验中；这也是相关调研中提到“高达 95% 的企业级 AI 试点项目最终胎死腹中、无法上线生产环境”的核心症结所在。 --- ### [18:15](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1095s) AI 时代的代码审查瓶颈与安全架构红线 主持人 Patrick Akil 提出了生产力提速背后的次生挑战：随着 AI 编码工具的大规模分发，编写代码的速度大幅提升，但"代码审查（Code Review）"却沦为了最严重的系统瓶颈。海量自动生成的代码导致高级工程师认知过载，整天陷入繁琐的手工审查中。目前业界分化为两种极端思路：一种是主张彻底废除代码审查，转而完全依赖自动化 QA 门禁；另一种则是识别出核心关键链路进行人工审查，非核心部分则放宽要求。 Chris Johnson 明确表示，Phase2 的准则非常清晰："无论代码是由谁或什么工具生成的，只要是你提交的 PR，你就必须对其承担全责（Accountable）"。团队审查的战略重心必须放在最容易引发灾难的底层架构与安全规范上： - **放行非关键逻辑**：例如对 CSS 样式等展示层代码不再进行逐行人工审查，因为这些细节出现瑕疵不会导致系统崩溃。 - **严守安全红线**：审查力量集中倾斜于**身份验证（Authentication）**、**权限授权（Authorization）**、**安全角色划分（Roles）**以及**数据输入校验与处理（Data Input Handling）**等关键安全维度。 - **引入交叉 AI 工具审查**：坚持工具隔离原则，绝对不使用编写该代码的同一个 AI 工具去执行审查与质疑，而是引入异构 AI 辅助工具交叉验证。 --- ### [20:08](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1208s) 警惕“氛围编码”与基于 PR 设计文档的质量护栏 随着行业评价体系从单纯考核"代码行数（Lines of Code）"转向聚焦"实际业务产出"，团队在使用 AI 时也暴露出了思维惰性。现场讨论提到了开发者对 AI 建议盲目服从的问题：很多工程师缺乏上下文工程能力或深入追问的习惯，甚至在 AI 给出错误回答时不敢直接反问质疑，最终沦为毫无设计把控的"氛围编码（Vibe Coding）"——就像一个 10 岁小孩也能直接提示生成一个网站，但却根本不懂生产级系统在可扩展性、安全合规与软件工程设计模式上的基本原则。 针对初级开发者动辄借助 AI 一键生成包含上千行代码的巨大 Pull Request（PR）这一现象，讲者们给出了具体的工程治理方案： - **强制编写 PR 迷你设计文档（Mini Design Document）**：开发者在提交 PR 时必须花费充分的时间撰写上下文描述，清晰阐明代码变更的核心意图、内部工作机制以及所作出的技术权衡（Trade-offs），以此证明自己对变更拥有完全的理解。 - **严密部署组织级自动化质量门禁（Quality Gates）**：绝不能无条件信任 AI 生成的原始代码，必须在流水线中构筑严格的代码检测与验证机制，阻断潜在风险向生产环境蔓延。 ### [23:00](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1380s) 零信任假设与多模型代码审查：将 PR 细化为可验证的单元 在引入 AI 编写代码时，工程团队必须采取“零信任”的态度。正如小组成员指出的那样，最基本的前提就是“始终假定 AI 写的代码是极其糟糕的（absolutely bad）”。正因如此，CI/CD 管道中的质量门禁（Quality Gates）必须全面设防，对静态代码分析、代码异味（Code Smells）以及安全漏洞进行地毯式扫描。更进一步，团队应当引入 AI 自身来执行代码审查，但绝不能让“写代码的同一个模型”去复审它自己的产出。理想的做法是使用一个全新的模型、业界顶尖的前沿模型（Frontier Model），或者是专门针对代码审查训练、熟悉多语言特征及安全漏洞签名模式的模型。 让不同的 AI 模型互相审查，能够捕捉到很多极易被人类开发者草率略过（glossed over）的隐蔽缺陷。但即便引入了双重 AI 保障，人类工程师仍旧必须在流程的最末端进行最终审查。此外，AI 辅助编程极易导致单次变更范围失控，若一个 Pull Request（PR）膨胀到数百甚至数千行代码，对所有参与者来说都是一场灾难。工程师不应全盘接受 AI 一股脑抛出的所有修改建议；PR 必须保持极高颗粒度，其粒度应与敏捷开发中的单个 Story 严格对齐。哪怕 AI 提出了绝妙的重构方案，也必须单独拆分为独立的 Story 提交，确保每一行合并进主干的代码都能被清楚验证，坚决杜绝“AI 代码泔水（slop）”混入系统。 ```mermaid flowchart TD accTitle: AI-Assisted Code Quality and Review Pipeline subgraph Development ["开发阶段"] A["AI 辅助生成代码"] --> B["颗粒化拆分 PR (与 Story 对齐)"] end subgraph QualityGates ["质量防护门禁"] B --> C["自动化静态检查与漏洞扫描"] C --> D["异构 AI 模型深度审查 (非生成该代码的模型)"] end subgraph HumanSignoff ["人工验收与归责"] D --> E["人类工程师终审 (验证、解释与定责)"] E --> F["合规入库部署"] end ``` ### [24:32](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1472s) 代码海啸与漏洞处置的时间窗口收缩 随着 AI 与智能体（Agents）的普及，安全响应的节奏发生了天翻地覆的变化。过去，当企业发现安全漏洞时，通常还能拥有数天乃至数月的缓冲期来排查和修复；但在具备自主探索与利用能力的智能体面前，安全窗口已被压缩到了数小时之内。当前软件工程领域正深陷于一场盲目加速的竞赛：开发端（生产力）一路狂飙，但下游的消费与吸收能力——包括代码质量把控、漏洞补救修复、以及针对对抗性智能体的红蓝对抗（Red Teaming）——却远远落后，这种严重失衡蕴含着系统性崩溃的巨大风险。 小组成员形象地引用了自己公司 CEO 的警示：“代码海啸（tsunami of code）正在席卷而来，因为代码产生的速度已经远远超过了测试能够跟上的极限。”单纯追求生成速率只会积压海量的未验证逻辑，使软件系统的安全防线变得愈发脆弱。 - **修复时效收缩**：漏洞修复响应周期由以往的数天/数月剧烈压缩至几小时。 - **失衡的工程能力**：AI 生成速度与团队测试、红蓝对抗及漏洞修复能力之间存在严重鸿沟。 ### [25:39](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1539s) 真实试点经验：初级开发者的 AI 禁令与“2年代码修行” 针对初级开发者使用 AI 的问题，一位嘉宾分享了团队几年前进行的长达 6 个月的真实对照试点。他们将应届毕业生、2 年经验、5 年经验与 10 年经验的工程师分为不同组别，为他们配备 AI 编程助手。半年后的跟踪结果令人大跌眼镜：给应届生配备 AI 后，他们脱离学校后的独立写代码能力完全没有得到任何提升，团队反而背负了比以往更多的技术债务。 基于这一教训，该团队做出了一个坚决且反共识的决策：**全面禁止应届生和新手访问 AI 编程助手，强制要求他们必须纯手工编写代码至少满 2 年**。实践证明，两年后再重新赋予他们 AI 工具时，成效截然不同。因为大学教育往往只教如何写出语法正确的单体代码，唯有在真实的大团队、多功能小队（Pod）或复杂业务组合中历练过，开发者才能深刻理解自身代码对上下游的影响、全流程流水线逻辑、质量门禁规范以及容器化运行环境的约束。只有建立起这些真实工程直觉，工程师才懂得如何正确驾驭 AI，而不是被工具反噬。 此外，该团队在多语言和架构栈上的评估也展现出显著差异： - **生态差异**：使用微软系编程助手时，.NET 和 Python 的表现非常优异，Java 次之； - **领域鸿沟**：一旦深入到复杂的云原生基础设施或精细的 AI 领域架构，代码助手的辅助能力就会出现断崖式差异。 ### [27:36](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1656s) 代码审查的文化范式转移：从挑语法错到“理解与定责” 传统的代码审查往往停留在“挑语法毛病、抠代码格式”的浅层阶段。但在 AI 时代，代码审查的本质必须发生文化转向（cultural shift）——代码审查的核心不再是“这行代码是谁敲出来的”，而是“谁能验证这行代码，谁能向大家解释清楚其背后的逻辑与风险”。 在这一范式下，无论代码由何种尖端 AI 自动生成，都必须有一个具体的人类工程师作为绝对责任人（Owner / Accountable Person）。审查人员的精力必须转移到一系列高维度的系统性风险上： | 审查维度 | 核心考量与业务影响 | |:--- |:--- | | **架构与可重用性 (Architecture & Reusability)** | 代码设计是否符合组织架构规范？是否引发架构腐化与冗余？ | | **业务正确性 (Business Correctness)** | AI 生成的业务逻辑是否精确贴合实际领域需求，是否存在逻辑幻觉？ | | **客户与合规授权 (Acceptable Use)** | 针对 IT 服务提供商，客户合同是否明确允许使用 AI 生成交付物？ | | **行业特定监管 (Domain Protection)** | 在医疗保健等严格受保护的强监管领域，使用相关模型是否存在合规硬伤？ | | **模型训练透明度 (Model Data Lineage)** | 传统机器学习模型与大语言模型的底层训练数据来源为何？是否存在法律纠纷或偏见？ | | **知识产权与版权 (Copyright & IP)** | 产出的代码是否存在版权侵权或开源许可证污染？ | ### [29:01](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1741s) 开源污染与专利风波：AI 资产的溯源与“二次买单”困境 小组成员严肃提醒，在工程体系中使用 AI 必须高度警惕知识产权（IP）和许可条款风险。企业采用特定供应商的 AI 模型生成的产出，其版权归属在法律层面往往并不明朗。由于大语言模型均训练自海量的公开开源代码库，代码中可能暗藏着类似 GPLv1、GPLv2 等强传染性开源协议的代码片段。如果企业打算对自己开发的核心创新模块申请专利或著作权，未经筛查的 AI 代码极有可能使整个专利主张化为乌有，甚至招致第三方的侵权指控。 为了从根本上规避此类法律纠纷，团队必须建立严格的代码元数据追踪体系：凡是 AI 编写或协助编写的代码，都必须打上详细的标签（Tag）并附带元数据审计追踪链（Audit Trail）。一旦日后爆发合规质疑，团队能够清晰回溯每一段代码的生成来源与演化历史，及时实施阻断与重构。 不仅如此，AI 对企业内部数据架构的蚕食同样暗藏杀机。AI 工具接入内部系统时，必须严格界定其对企业数据层、语义连接层的访问权限，并制定严密的隐私与数据治理政策。当前行业内广为流传一句话：“**如今使用 AI 的企业不仅是在为所消耗的 Token 付费，更是在把自家的组织专有数据双手奉上——企业本质上是在买单两次。**” ```mermaid flowchart LR accTitle: Corporate IP and Data Dual-Risk Model subgraph InboundRisk ["输入端数据风险"] A["内部专有数据与语义层"] -->|数据泄露 / 沦为训练原料| B["第三方 AI 供应商平台"] C["资金支出 (按 Token 付费)"] --> B end subgraph OutboundRisk ["输出端知识产权风险"] B --> D["AI 生成代码"] D -->|开源许可证污染 (如 GPL)| E["核心业务代码库"] E -->|破坏专利原创性 / 侵权指控| F["外部法律与合规诉讼"] end ``` ### [31:34](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1894s) 观众互动：企业法务防御、AI 办公室与“尝鲜访问”暗坑 讨论进入现场问答环节，台下一位观众举手提问：“你们刚才提到了复杂的许可证风险，那究竟该如何进行验证？是用 AI 工具来查 AI 吗？” 小组成员相视一笑，答道：“通常得靠法务律师（lawyers）。”在企业级环境中，单纯依赖技术扫描工具是远远不够的，关键在于签署采购合同时极其严苛的条款审阅。大型企业如今普遍成立了专职的“AI 办公室（AI Office）”，与采购部门、常年法律顾问并肩作战，审查长期的供应链依赖与业务合规风险。小组成员列举了企业在选型中必须死守的几大法律硬指标： - **数据留存周期（Data Retention）**：以客户从公有云团队版升级至企业版为例，供应商通常会设定 30 天的数据保留窗口（如用于故障排查或滥用监控），这在某些强监管场景下是不可接受的法律死线； - **数据主权与物理驻留（Data Residency）**：银行、保险公司以及医疗巨头面临严格的政府监管红线，其核心数据绝不能流出国境（例如禁止流出欧盟或北美），因此必须确切掌握云厂商（AWS、Azure）及底层大模型商（如 Anthropic）的物理算力与存储节点归属； - **训练数据免责承诺（Training Data Opt-Out）**：尽管几乎所有供应商都在口头上信誓旦旦声称“绝不用客户数据做二次训练”，但从采购和法律角度来看，唯有白纸黑字落在具有法律约束力的合同文本上才具有真实效力。 最后，另一位专家补充了一个极其隐蔽的现实陷阱——**“尝鲜访问（Early Access）条款”**。很多时候，标准协议上写明了绝不保留数据，但一旦企业内部团队迫不及待想要申请体验最新的前沿模型预览版时，厂商就会在预览协议里埋下特殊条款，要求“为评估模型性能，平台有权将交互数据完整存储 30 天”。即便对方承诺不用于模型训练，这也足以击穿很多受管辖行业的数据合规防线。因此，成熟的 AI 治理框架不仅要覆盖生产环境的权限规则，更必须为“试点探索（Pilot Access）”量身定制刚性的准入与审批边界。 ### [34:36](https://www.youtube.com/watch?v=aON2GZ6soIo&t=2076s) 模型灰度验证、领域知识缺失与组织数据隐私治理 企业在引入新的 AI 模型时，绝不能采取“全员直接可用”的粗放模式。成熟的做法通常是设立小规模的先锋测试小组（主要由 IT 团队和领域技术专家构成），在模型正式向全公司铺开前进行严密的试用、评估和有效性验证。大语言模型虽然通晓海量常识，却天然缺乏特定企业的业务上下文、特定痛点及领域专有知识。 发言嘉宾以某些具备自动驾驶功能的智能电动车举例：车企在推送重大版本更新时，往往会提供免费试用期，这不仅是为了让车主熟悉系统的驾驶行为，更是为了在可控范围内摸清边缘场景下的缺陷与不足。同样的逻辑也适用于 AI 工具的治理——几乎所有成熟模型与平台都提供了“退出模型训练（opt-out of training）”的配置选项。企业必须通过严格的组织级治理政策强制关闭数据回传，而个人开发者在日常使用中也务必主动关闭该开关，防止敏感提问和内部业务对话泄漏到公网公共数据集中。 --- ### [36:05](https://www.youtube.com/watch?v=aON2GZ6soIo&t=2165s) 提问环节：代码质量的源头——需求与 Specs 规范的 AI 化落地 现场观众提出了一个直击痛点的关键问题：当前大家都在关注代码编写、代码质量和初级工程师的培养，但 AI 编码模型的输出上限本质上取决于输入 Spec（规格说明书）的质量。组织内部是否采取了行动，让业务分析师（BA）在撰写客户需求时能够深入代码库或与代码上下文深度对齐，确保产出的需求能够真实锚定现有系统架构？ ```mermaid flowchart TD accTitle: 需求摄取、质检与自动化代码落地全流程 subgraph Ingestion["多模态需求摄取"] A["多模态输入<br/>(PDF/PPT/会议录音/Signavio)"] --> B["Coco 平台 / Jira AI (Rovo)"] end subgraph QualityCheck["需求质检与上下文强化"] B --> C{"质量评估维度<br/>(歧义性/完整性/验收标准)"} C -->|低/中质量| D["一键自动修复与重构"] C -->|高质量| E["结构化需求<br/>(Persona-Action-Outcome)"] D --> E end subgraph Implementation["下游交付与代码生成"] E --> F["Spec-Driven Development"] F --> G["AI 代码生成 / 原型构建"] end ``` 针对这一问题，QualityAI 的 CTO Vikul Gupta 抛出了一个行业核心数据：**在整个测试周期中发现的缺陷，有高达 37% 的根本原因在于糟糕的需求定义（bad requirements）。** 针对需求规范化，Vikul Gupta 介绍了他们打造的 Coco（Co-pilots of Co-pilots）平台，该平台通过集成主流 LLM，能够直接从混乱的会议纪要或简单口语中自动提取并生成符合行业规范（如 Persona-Action-Outcome 或 Given-When-Then 格式）的高质量需求。 - **多维需求质检**：平台不仅支持直接生成，还能对存量需求进行语义扫描，从“歧义性（Ambiguity）”、“结构规范性（Structure）”、“完整性（Completeness）”及“验收标准（Acceptance Criteria）”四大维度自动评级（高/中/低），甚至支持“一键自动化修复”。 - **多模态输入兼容**：在大型 SAP 客户的实际落地中，输入源极为分散复杂。平台能够直接吞吐解析 PDF 方案、PPT 幻灯片、音视频转录文本、UI 截图以及 Signavio 流程图等，全自动转换为可直接指导定制化开发的系统需求规范。 - **开箱即用工具协同**：对于使用 Jira 等标准敏捷工具的团队，类似 Atlassian 研发的 Jira Rovo AI 也开始逐步内置这些辅助生成能力，大幅降低 BA 与业务人员的上手门槛。 --- ### [38:49](https://www.youtube.com/watch?v=aON2GZ6soIo&t=2329s) 规范驱动开发与产品经理的话语权跃迁 在 AI 编码时代，“规范驱动开发（Spec-Driven Development）”正在成为主流范式。过去工程师把大量时间花在敲代码上，而现在的开发重心已经大幅前移——团队需要将高达 70% 的精力投入到产品需求文档（PRD）和 Specs 的反复推敲与精细打磨中。写好一份 Spec 绝非易事，不仅要精准界定当前业务状态，还必须具备前瞻性（Future-Proof），并且在非绿地项目（Brownfield Projects）中，必须将存量系统的全部技术约束与上下文完整喂给模型。 这一转变甚至引发了关于软件工程分工颠覆的讨论：部分观点认为“未来产品经理将统治软件开发”，因为产品经理过去对软件工程师的代码实现依赖将被极大削弱。然而，嘉宾们也指出了现实世界中截然相反的技术极端——某些全球顶尖的社交媒体和搜索引擎巨头，内部甚至“根本不写任何传统需求文档”。 - **大厂的“极简模块化”逻辑**：头部大厂推崇极端极简的开发节奏，功能拆解得极其模块化，单点任务在 1-2 天内即可上线，工程师与 PM 往往仅通过简短会议沟通便直接动手。 - **逆向追溯工程（Reverse Engineering Traceability）**：为了解决这种不写文档带来的“人员离职、上下文丢失、Bug 无法定位”的隐患，技术团队选择对这些口头讨论会议进行全程录音与自动转录，借助 AI 逆向生成完整的业务需求、User Story 与测试用例链条，为代码资产建立起可追溯的安全网。 --- ### [42:04](https://www.youtube.com/watch?v=aON2GZ6soIo&t=2524s) 全链路角色边界消融与“前向部署工程师”的兴起 Phase2 的 Principal AI Technologist Chris Johnson 指出，如今产品经理与研发人员正在共享同一套 AI 工具箱。PM 可以借助 AI 快速搭建具备交互逻辑的原型（Prototype），直接呈现预期效果；而研发人员则负责审查该原型在架构层面的可持续性、可维护性与扩展性。角色之间的边界正在全面模糊，工程师也更深地介入到前期的需求捕获之中。 ```mermaid flowchart LR accTitle: AI 赋能从研发向全业务链路扩散 subgraph Engineering["研发与交付侧"] Dev["开发人员<br/>(代码编写/原型审查)"] QA["测试工程师<br/>(应对代码海啸/快速自动化)"] Ops["运维与 SRE<br/>(AI 故障分诊/发布决策)"] end subgraph Business["业务与商业化侧"] PM["产品经理<br/>(AI 原型/需求生成)"] Sales["销售与客户经理<br/>(QBR 分析/商机挖掘/情绪识别)"] end Engineering <--> Business ``` AI 的普及正在从单纯的 Dev 编码向软件生命周期及商业全链路纵深演进： - **应对“代码海啸”的测试与运维**：AI 使得代码产出量呈指数级暴增，如果 QA 测试依然依赖传统人工节奏，测试环节瞬间就会成为整个交付链条的致命堵点。因此 QA 团队正全面借助 AI 生成自动化脚本；运维（Ops）团队则开始利用 AI 进行线上故障分诊（Triaging）与灰度发布中的“Go/No-Go”自动化决策。 - **突破研发边界的商业化赋能**：AI 的爆发力甚至溢出到了非技术部门。销售和客户成功（Account Manager）团队将季度业务复盘（QBR）演示文稿和客户沟通会议录音喂入 AI，进行潜在销售线索资格审查（Lead Qualification）、交叉销售（Cross-sell）与增销（Upsell）商机挖掘，并通过情绪分析自动标记客户支持度的“红黄绿”健康状态。 - **全栈统揽的全新角色**：面对工具链的高度整合，行业中正在涌现出诸如“前向部署工程师（Forward Deployed Engineer）”这类新型复合角色。他们借助 AI 作为核心编排器（Orchestrator），一个人即可独立打通从前沿需求对接、架构设计、代码生成到最终生产环境上线的全生命周期。 讨论在热烈的掌声中落下帷幕，嘉宾们总结强调：在 AI 时代，关键不在于某一个具体岗位是否会被取代，而在于每个人都必须主动将 AI 纳为核心辅助与编排工具，以适应不断重塑的软件开发与商业协作生态。 ## Notable quotes > [02:51](https://www.youtube.com/watch?v=aON2GZ6soIo&t=171s) 这位 40 年经验的先生获胜了 — Patrick Akil > [00:04](https://www.youtube.com/watch?v=aON2GZ6soIo&t=4s) 全球最智能的质量工程公司 — Vikul Gupta > [14:02](https://www.youtube.com/watch?v=aON2GZ6soIo&t=842s) 我不想做软件开发人员了 — Chris Johnson > [18:15](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1095s) 无论代码是由谁或什么工具生成的，只要是你提交的 PR，你就必须对其承担全责（Accountable） — Chris Johnson > [23:00](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1380s) 始终假定 AI 写的代码是极其糟糕的（absolutely bad） — 圆桌嘉宾 > [24:32](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1472s) 代码海啸（tsunami of code）正在席卷而来，因为代码产生的速度已经远远超过了测试能够跟上的极限。 — 圆桌嘉宾引用其公司 CEO > [29:01](https://www.youtube.com/watch?v=aON2GZ6soIo&t=1741s) 如今使用 AI 的企业不仅是在为所消耗的 Token 付费，更是在把自家的组织专有数据双手奉上——企业本质上是在买单两次。 — 圆桌嘉宾 > [36:05](https://www.youtube.com/watch?v=aON2GZ6soIo&t=2165s) 在整个测试周期中发现的缺陷，有高达 37% 的根本原因在于糟糕的需求定义（bad requirements）。 — Vikul Gupta ## Mentioned Patrick Akil, Chris Johnson, Vikul Gupta, Ravi Teja Prabhala Venkata, Madhavi Najana, Xebia, Phase2, QualityAI, Capital One, Federal Home Loan Bank of Cincinnati, Claude Code, OpenAI Codex, Google Gemini, Cursor, Windsurf, OpenCode, OpenClaw, Hermes, SAP Joule, SAP Signavio, Virginia Tech, Forrester, Model Context Protocol (MCP), Jira Rovo, Coco (Co-pilots of Co-pilots), AWS, Azure, Anthropic, Atlassian ## Video description Patrick Akil - Podcaster & Software Engineer, Xebia Ravi Teja Prabhala Venkata - Senior Manager, Software Engineering, Capital One Vikul Gupta - CTO, QualityAI Madhavi Najana - AI Trailblazer | Women in AI Ohio State Ambassador| Forbes Technology Council Member | Fellow BCS | Software Engineering Manager, Federal Home Loan Bank of Cincinnati Chris Johnson - Principal AI Technologist, Phase2 AI coding assistants promise speed and efficiency—but they also raise new questions about quality, security, and the developer experience. This panel will explore how engineering leaders are adapting processes to ensure AI-generated code is reliable, secure, and compliant with organizational and regulatory standards. Panelists will discuss real-world challenges: preventing subtle bugs, avoiding hidden vulnerabilities, navigating licensing/IP issues, and rethinking code review practices in the AI era. The conversation will also cover the human side—how to maintain strong engineering culture, support junior developer learning, and build trust between humans and machines. Attendees will gain practical insights into balancing the productivity gains of AI-assisted coding with the long-term integrity, safety, and culture of software development. [Source](https://www.youtube.com/watch?v=aON2GZ6soIo)

[2:51] Patrick Akil: 这位 40 年经验的先生获胜了 [0:04] Vikul Gupta: 全球最智能的质量工程公司 [14:02] Chris Johnson: 我不想做软件开发人员了 [18:15] Chris Johnson: 无论代码是由谁或什么工具生成的，只要是你提交的 PR，你就必须对其承担全责（Accountable） [23:00] 圆桌嘉宾: 始终假定 AI 写的代码是极其糟糕的（absolutely bad） [24:32] 圆桌嘉宾引用其公司 CEO: 代码海啸（tsunami of code）正在席卷而来，因为代码产生的速度已经远远超过了测试能够跟上的极限。 [29:01] 圆桌嘉宾: 如今使用 AI 的企业不仅是在为所消耗的 Token 付费，更是在把自家的组织专有数据双手奉上——企业本质上是在买单两次。 [36:05] Vikul Gupta: 在整个测试周期中发现的缺陷，有高达 37% 的根本原因在于糟糕的需求定义（bad requirements）。

[8:19] Ravi Teja Prabhala Venkata: If I were to write a deterministic piece of code I can create like 10, 20, 30 test scenarios for that, and agents are fundamentally non-deterministic in nature. So if you were to give it a bounded task, even then you would have to consider so many scenarios. You need to harden the security measures. You need to make sure everything has that stacked verification pipeline. [12:47] Vikul Gupta's son: I don't want to be a software developer because I can write code what a software developer can in 5 minutes. [19:06] Chris Johnson: However it got generated, you're the one submitting it, you're accountable for it. [19:06] Madhavi Najana: How many of you here would just accept whatever suggestion was given by an AI tool, whichever tool it might be? Just want to see: have you ever got a chance to ask it back, 'Hey, this may be wrong. Have you thought about this?' And do you think that might agree and return back the same answer? [25:28] Vikul Gupta: When we gave it to fresh college graduates, after six months we found out that their ability to write code on their own didn't improve at all after they left college. We incurred more technical debt than we did before. So we took a conscious decision of not giving coding assistant access to freshers. We mandated that they have to code for two years before they get access to coding assistants. [36:08] Audience Member: Coding models are good enough if your specs are good. Have you done anything around your business analysts to maybe have them base themselves into the code so that when they're writing the requirements for the customers they have access to the code base itself, so that what comes out of their effort is actually grounded into your code base? [36:08] Vikul Gupta: 37% of defects we find during testing cycles are because of bad requirements. Fact. [40:35] Engineers at hyper-growth tech companies: we don't have time to write requirements.

[0:04] Thank you all for attending. It's actually  quite full which is great to see because I [0:08] think we have some interesting topics as well as  interesting panelists. I'm going to give everyone [0:13] one minute to kind of talk about who they are  and specifically also what they do. Can you start [0:18] Chris? Sure. Uh so my name is Chris Johnson.  I'm the principal AI technologist for Phase [0:23] Studio Technology. Uh before that I was the VP of  engineering. So I was in charge of the entirety [0:27] of the engineering staff and our company primarily  does custom development for clients. So uh mobile [0:33] apps, web apps, web- based uh technologies uh  using AI to both build them and incorporating [0:39] AI as part of their uh operation. Great. Thank  you. Yep. So Vic Gupta, I'm the CTO for a company [0:47] called Quality AI. Uh I I've been with the company  for 5 years. Uh where we specialize is using AI [0:55] uh to help companies do the engineing work but  also help uh in the life cycle aspect of it. AI [1:01] for dev, AI for QA, AI for ops. Quality is what  we've been doing for 28 years. That's in our DNA, [1:08] in our blood. Prior to this, I was with a large  SI and before that I was with HP software where [1:14] I was their CTO. Uh so I tell people that I work  for the world's largest testing software provider, [1:19] one of the world's largest SI in the testing space  and now I work for one of the world's smartest [1:25] quality company which is AI nice. Hey uh my name  is uh Ravitja Prabal Kata. So it's a very long [1:34] name so I go with the right now. Uh I'm a senior  engineering manager at Capital 1. I currently lead [1:40] uh infrastructure uh a chapter in infrastructure  uh basically EC2 instances. So my team and I we [1:46] are responsible for provisioning uh hardened  images for all application teams across the [1:52] organization. uh we also deal with uh you know a  bunch of uh new AI initiatives and uh we're trying [1:57] to come up with some innovative solutions for  our innovative problems and before that I've been [2:04] uh a senior manager at uh you know various fintech  organizations and I've dabbled around a lot in [2:10] uh pretty much everything uh in software uh be  it uh mobile development uh data data engineering [2:16] data architecture software engineering pretty  much everything nice good afternoon Las Vegas [2:24] myself Madvi Najana and I work for Federal Home  Loan Bank of Cincinnati. Uh apart from that I also [2:31] um an ambassador for women in AI Ohio State  and I'm a BCS fellow as well as IT senior and [2:39] a Forbes technology council member been in in  this industry for around like two decades now [2:44] and I'm here to learn more along with uh major  leaders here. So here I am. Great. Thank you. [2:51] So now you know a little bit more about us. I'd  like to get to know you a little bit more. Also [2:56] to know how to structure this conversation and  to communicate it better. Who is or identifies [3:01] as individual contributor? Can we see a raise of  hands? Okay. Who identifies as a product person, [3:09] product manager, product owner? That's a couple  few technical leaders, engineering managers, [3:16] managers in general, sea level people, technology  officers, security people. Very nice. I think [3:25] I've had everyone then. How long have you been  in the field? I think we are missing the major [3:30] participants here. Which one? From the security  aspects. Oh yeah, security is low represented. If [3:36] you've been in the industry for five plus years,  can you raise your hand? All right. All right. [3:40] Now, keep your hands raised. If it's 10 plus,  I'm going to drop mine. If it's 15 plus, keep [3:46] them raised. If it's 20 plus, keep them raised.  25 plus there. Still, that's a lot. Actually, [3:53] there's good seniority. 30 plus. 35. Any any 35?  Great. And 40. We'll leave it at that. Mr. 40 wins [4:03] over there. That's fantastic. Yeah. Great. And  then last but not least, I'm interested in what is [4:09] your daily driver when we're talking about agentic  tooling or agentic harnesses. Who here loves cloud [4:15] code? Raise of hands. Yeah, that's a good chunk.  Specifically codeex. Is codeex your main driver? [4:23] That's decent. What about Gemini? There's a  few cursor specifically. That's a few as well. [4:33] And then anything I missed, anything we want  to know about. Open code. Open code. Those are [4:39] the open source harnesses. Anyone love open  source harnesses? There's a few. Openf. Yeah, [4:44] surf. Yeah, wind surf. I heard some companies  using open claw in some of the conference. Yeah. [4:50] Any full-on agentic open claw actually up and  running team agent in a team or Hermes. Great. [4:58] That's interesting. Interesting stuff. Cool. We're  going to start off first because as you can tell [5:04] people are working with agentic tooling and I'm  specifically interested in your perspective Chris [5:08] since you run in and out of organizations more  often than the rest of us. If we give agentic [5:14] tooling to teams they speed up but things also  might break. What have you typically seen break? [5:20] Um so usually what we see break uh first off  is more an uneven adoption right so you'll [5:27] have some people who take to it love it uh sort  of to push the organization forward uh and then [5:34] all of a sudden uh what the second thing that  we'll see break is everybody's confident on it [5:39] until it comes time to launch it into production  and they're like hey that's great it looks like [5:44] it works but it doesn't uh look like it works  consistently enough for us to rely on putting [5:49] it in front of our clients put it in front of  our customers there. So those are the the two [5:53] things that tend to break first or biggest for  us. Yeah. Does that resonate with you as well, [5:58] Vik? Yeah. So I'm actually uh uh working for a  customer who has this problem. So his problem was [6:05] uh the problem is not about how to use AI.  It's about how to build trust in AI because [6:10] he started giving me examples about how every  small portfolio or or or the small business unit [6:17] has built a lot of agents but none of them is  going to prod because they probably struggle to [6:23] find out right can can we can we trust it and so  on so that's one sea level kind of a problem but [6:29] when I talk to practitioners or software engineers  many people are worried about job security right [6:35] and then there are always people who worry about  right like what can I like engineering this is not [6:41] C level but engine is like how do I handle like  copyright issues how do I handle um whether it it [6:50] has done the dependency mapping correctly or not  and so on so I think these are one thing I will [6:55] say for any company which has been successful from  any adoption ideation incubation productization I [7:03] think all four aspects people process technology  ology and culture. The culture of uh understanding [7:10] right how do you treat AI generated code married  with human generated code and what processes needs [7:17] to morph I think is important then what tools  which is the technology aspect we talked about [7:22] cloud and code codeex and then we talked about  vinserf which one or what use case right it's [7:29] not that you get one tool and you just mandate  everyone use that different tools for like if [7:34] you're in SAP jewel is a good example right so  the technology aspect is important and then the [7:39] people part is many people think that just giving  people access to cloud and charges job done. No, [7:46] it is not. How to use them? How to how do you  how do you ensure uh they understand how to [7:51] provide context knowledge articles and then how  to write a good prompt? Mhm. Right. So how to use [7:57] the AI tools? So we are going through something  similar within our company where we've created a [8:02] enablement program called AI elevate. So how do  you get from fluency to certification to being [8:08] a practitioner or so on. So I think all which is  what is true for us is true for any company people [8:14] process technology culture if you handle that  you'll be successful. Yeah I like that a lot. [8:19] Are there people that are fearful for their jobs  with the role of AI actually and brave enough to [8:24] raise their hand? Patrick I can add some Yeah. Mi  I can add some context to what people just said. [8:33] Um so I work for a regulated organization. So  obviously I may not be able to speak anything [8:38] from my organization but I can speak to a little  in general where agentic AI or agents can go the [8:46] other way around right. So industry experiences  their you know outputs tell a lot of big stories. [8:54] Lately there was an example that you know agents  have gone the other way around beyond their scope. [9:00] An agent was able to sell out to a customer while  in while while the customer was interacting with [9:06] the chatbot. He was able to manipulate the agent  in such a way that it has gone beyond its scope [9:12] of just telling the information but also was  able to sell out the product at a discount [9:17] price. What it means is like the agents needs to  be scoped. They need to know their boundaries. [9:24] That's where uh you know accountability comes in  wherein we are assigning task to agents but who [9:30] is really accountable that's the real question we  may need to ask like what are the boundaries of [9:35] the agents where the agents can go wrong another  aspect may be the siloed agents we have a whole [9:43] lot of you know every organization would have a  whole lot of workflows end of day jobs and things [9:49] go in many ways that they keep working throughout  the process And if agents were to incorporate in [9:56] an existing systems, right, they need to know  uh how to work with an existing workflow and [10:04] also how to you know uh orchestrate and share the  responsibility rather than being a siloed agent [10:12] that can do because we definitely want to avoid  the siloed systems like we have in in many of the [10:19] organizational departments as well as the agents  they are specific things that the agent needs to [10:27] know in terms of uh having their guardrails  too. So there are multiple ways that agents [10:33] can go wrong. The first thing I would say is like  having accountability for the agents is the major [10:38] factor. Yeah. In this morning's keynote, I saw  actually the recommendation of an agent should [10:43] be assigned to a specific owner which can be a  person actual name assigned to that. Is that what [10:49] you mean with the accountability specifically?  Yes. Yeah. like so even I think one of the things [10:55] we were discussing about code reviews and so  on one of the things we have instituted within [11:00] our engineering organization is it doesn't matter  who created the code it's not about line by line [11:06] validation it is about uh is is this code which is  generated by AI the right code so what we mandate [11:14] is any AI generated code is assigned to a human  and he takes his code and the AI generated code [11:21] and then from then onwards he's responsible in  owning that code from a code review security your [11:28] any fixes and so on right so the the human aspect  of it right is important yeah I think uh there is [11:36] a fundamental challenge honestly like if I were to  write a deterministic piece of code I can create [11:42] like 10 20 30 you know test scenarios for that  and agents are fundamentally nondeterministic in [11:48] nature so if you were to give it a task a bonded  task even then you would have to consider so many [11:53] scenarios. So you need to harden the security  measures. You need to make sure everything has [11:59] that stacked verification pipeline. You need to  make sure you enforce all those guardrails. So you [12:04] know if you're a public facing company you will  have the pressure to say that hey we've deployed [12:08] you know agents uh you know for our services  but it's always a challenge uh and especially [12:14] for you know financial institutes uh they have  to be extremely rigorous right so yesterday I [12:20] was checking in at the hotel I was trying to  call them to see if I can do an early check-in [12:26] and you know they have AI agent I was talking to  the agent for 20 minutes and nothing happened I [12:30] had to in the end call a human and then no things  don't really work. Now the agencies are at their [12:37] infancy at this point in time. I think it'll  take a while to get and you know build a trust [12:42] where we can actually confidently delegate these  tasks to these agencies. Yeah. Speaking of agents, [12:47] I found out that AI for conference when you book  meetings there's a small dot at the top which is [12:53] an AI agent. You can easily say I'm so and so.  This is my company. Find prospective customers [13:00] I should have meeting with. Yeah, it'll do that.  Not only does it tell you that but it also tells [13:04] you who has looked at your booth or your company  profile. So it gives you so much of insight. Then [13:11] the next question is like okay you review these  10. Do you want me to look for do you want me to [13:17] create an ICP pitch? So it creates a pitch like  if you are CTO for GAP or you are CTO for Blue [13:26] Origin or you do something it'll it'll look at  what I do what he does and creates an ICB pitch [13:32] for you. The next thing it doesn't stop it says  do you want me to look for an open slot? How many [13:37] of you tried to book meetings and struggle with  finding an open slot? I spent at least 10 minutes [13:41] per person and still couldn't find a slot. The  agent did it automatically. And then he's like [13:46] do you want to send a message? I said yes. Do  you want a recommendation on what message you [13:51] want to send? I was like where is this going to  end? So the agents work but testing is important [13:56] like that's absolutely there's one point I  wanted to make. You asked about job security. [14:02] So this is a problem closer to home. I have a I  have a son who just passed out of Virginia Tech [14:07] uh software engineering uh with uh AI as one of  the m as one of the modules. I spent a lot getting [14:16] him graduated. The first thing he does after  looking at what is in the market he's like I [14:21] don't want to be a software developer. Oh really  is done. He's like I don't want to be a software [14:25] developer because uh I can write code what a  software developer can in 5 minutes. So that job [14:33] as per him and I I it took me a while to explain  it to him but he's like this generation is very [14:38] very like I don't know I I saw very less hands but  I went and talked to I am also an adviser to some [14:44] of these universities there. I went and talked  to a lot of kids. They're looking at like how [14:49] to use AI for sales. So they're trying to get in  those roles because those roles for them are much [14:54] more stable in the long run. So I just wanted to  share right this is closer to home. I've heard it [14:59] from one of the people who who have gone through  software development and doesn't want to do it. [15:04] Maybe he'll change over a period of time but this  is the initial perception which is building up. [15:08] Yeah. Yeah. It impacts I guess the new culture as  well. You wanted to mention something Chris? Yeah, [15:13] I was going to say the I think that really goes to  a fundamental culture of like what do we define as [15:18] software development, right? So, if you are  a person who loves sort of the line by line [15:23] uh aspect of writing that like yes, your future  is really going to change, but at least for us and [15:28] most of the developers that we hire, they think of  themselves more as problem solvers, right? And so [15:33] uh sometimes that and oftentimes that is done  by implementing software but sometimes it's [15:38] done via figuring out a different process for  a client or a different workflow there. And um [15:43] really that's a place where these tools really do  let you move into a lot of areas that you weren't [15:49] able to before because you can ramp up much faster  and figure out hey here's different ways to solve [15:54] a problem for a client. I I think writing code  will become easier as we move forward. But I think [16:01] architecture design is something which is going  to be much more important like especially when [16:07] you are designing an AI infused application right  first is the right tools then I built it now how [16:14] do I integrate it what are the different like MCP  servers or anything else third problem is context [16:20] layer grounding fourth is okay everything is ready  now how do I test it right that's that so we are [16:27] in the quality domain and that's the number one  problem we're seeing like there was a time when [16:32] QA was going down. Now there's a time when QA is  going up because the normal developers don't know [16:39] how to test AI generated code. So they're looking  for help. So we we I was just talking to Forester [16:45] about like what is the AI insurance framework like  we call it a pyramid at the bottom. Do we have the [16:51] right building blocks? Do we have the right data?  data is critical for AI whether whichever data [16:56] you whether it is traditional versus geni or so  on. Then the second is did we build the AI right [17:03] which is model assurance right whether in the  traditional or agentic or in the geni side. Then [17:10] the third is did we build the right AI is it doing  what business wanted to do? Yes, everything is [17:16] working fine but when you integrated performance  uh scalability uh usability like you build a [17:23] shopping cart but no one can use it what good is  it and the last part is outcomes is it generating [17:29] the business outcomes most of the sea levels  we talk to are using AI as a way of boosting [17:34] productivity customer engagement and so on so is  it giving me the outcomes I built this for so I [17:41] think at every layer there's a different way of  how do you provide assurance insurance right at [17:46] data layer, model layer, your integration layer  and then the business outcome layer. So I think [17:51] this is going to be very very critical right this  the current era is about building AI but from a [17:57] long-term perspective it is about how do you build  trust in AI if you don't pass that you're going to [18:02] get stuck in just experimenting and there was a I  think Mckenzie article or some article where they [18:08] said 95% of the p of AI pilots die without going  to production this is one of the main reasons [18:15] yeah we talked about kind of distributing tools  specifically coding agents and making people go [18:21] faster. Trust and adoption and building the right  thing is something we covered as well. I want to [18:25] touch on two things because from my perspective,  if we go faster, reviewing is what I've seen [18:31] becomes a bottleneck. And then lastly, I also want  to cover costs, but specifically talk about code [18:36] reviews or the verification process. I've heard  people say it's really uh an increase in cognitive [18:44] load and our seniors are completely occupied in  the amount of volume of code that they have to [18:49] manually verify. So two trains of thoughts, one is  don't do any code reviews anymore and then we need [18:54] a lot of quality assurance I guess in place uh and  artifacts to no longer do so. And the other one is [19:01] well we need to identify which critical paths  still need manual reviewing and the other ones [19:06] uh we care less for. Is this what you've seen in  organizations as well, Chris? Yes, for sure. Like [19:12] um and this is a place where understanding the  architectural patterns are really important as [19:16] well as focusing on so like what we tell people  is yes, you're accountable for whatever the [19:21] code is. However it got generated, you're the one  submitting it, you're accountable for it. And so, [19:27] uh part of the things that we make sure people  focus on are things around authorization, [19:31] things around authentication, things around  the security aspects. I don't care if someone [19:36] reviews the code line by line for like the CSS for  example like you know that's not going to be the [19:42] thing that makes or breaks the application but  if you mess up the authentication aspect or the [19:47] uh like the roles aspect there that's where you're  going to get in trouble. So definitely you know [19:52] data input handling those types of things that's  where we ask people to focus on and then yes we [19:57] definitely augment them with um different AI  tools right like we don't use the same tool [20:01] that wrote the code to review and challenge it  there um so that's our approach yeah I may want [20:08] to touch a little bit on the code review aspects  I think uh gone are the days when uh organization [20:15] has had their KPIs around the lines of codes now  it is more about like what are the outcomes that [20:22] organizations are going to get benefited out of  uh utilizing AI tools. So it's it people are like [20:32] there are aspects some organizations still kind  of uh not leveraging AI in both ways like right [20:40] now code reviews are being done by uh the agents  at the same time how many of you here would just [20:48] accept whatever suggestion was given by AI tool  whichever tool it might be just want to see have [20:55] you ever got a chance to ask it back. Hey, this  may be wrong. Have you thought about this? And [21:03] do you think that might agree and return back  the same answer? Yeah, I think uh there are [21:10] scenarios where u engineers by themselves have  gone through that in the loop process where they [21:18] keep on asking the question and you know it may  be lack of uh the context engineering the right [21:25] set of skills to be used in the files or maybe  uh the skills that you know engineers may not [21:32] have to it's a lot of wipe coding right now even  like uh 10 years old kid would ask hey generate a [21:39] website for me and you'll get the website out  of it. But the understanding is here what are [21:45] the best practices software engineers might have  and how the best principles are being across every [21:52] aspect not just only the architecture in terms of  security in terms of you know uh taking it to a [21:58] production level is different from just asking  and building it on the fly. Yeah. So scaling [22:04] the application is the important aspect rather  than just building it on the fly. Yeah. I uh I [22:11] have a couple of ideas actually speaking about  reviews, right? Like even a junior dev can whip [22:16] up thousands of lines of code in one single pull  request. Uh kind of defeats the purpose, right? [22:21] uh what we should ideally do uh again this is what  I advocate for is that uh uh when a junior dev or [22:28] you know anyone technically who's creating a pull  request uh pushing the code basically is to spend [22:34] enough time on writing the p uh pull request  details it is basically a mini design document [22:40] by itself where the engineer would be able to talk  about what exactly is going on in that change and [22:46] what what's the intent uh what exactly are the  trade-offs you know everything in those lines [22:50] And then obviously each organization  must enforce and employ a lot of these [22:55] uh uh quality gates. Obviously you don't have to  trust the code that is just written by AI. You [23:00] always have to assume that the code written by AI  is bad absolutely bad. So your quality gates would [23:06] absolutely check everything you know basically  static code analysis code smells you know security [23:11] vulnerabilities pretty much everything. And  then you would also employ AI itself as a code [23:16] reviewer. So you don't have to use the same model.  In fact, you should not use the same model that [23:20] you use to write the code. you have to employ a  new model or probably a frontier model or probably [23:26] a model that is you know tuned on uh code reviews  uh with a lot of languages and you know and uh uh [23:32] code code code signatures of a vulnerabilities  pretty much everything that can be exposed right [23:37] so when you have AI review the code written by  another AI or you know humans then you would be [23:43] able to look at some of those things which can be  easily glossed over by humans and then you'd also [23:47] have humans review that at the very end so you  want to maximize the number of checks in every [23:53] single change and you know if the PR ends up  having thousands of lines of code hundreds of [23:57] lines of code that is absolutely bad very bad for  everyone involved. So even if AI suggests you to [24:03] do so many changes in one single feature change  you need to change that approach you need to make [24:08] sure you your PRs are granular as granular as your  stories. So if the AI recommends more refactoring [24:16] or you know introducing some of the changes it  has to be its own story. So every pull request, [24:20] every code push must be easily verifiable by every  party involved. So you're not pushing some slop. [24:26] You're basically ensuring everything has to go,  must go and will go. I would touch a small point [24:32] about vulnerabilities here. Uh in past there  was a little bit of time like it could be days, [24:40] it could be months where a vulnerability is  being found by an organization and there is [24:45] a time to fix it. But now with agents the time  scope has been very narrowed and even it right [24:54] now it is even hours to fix it. So uh I think the  engineering by itself you're running too fast in [25:02] the race that development is going on but the  consumption in terms of quality the consumption [25:08] in terms of remediating the vulnerabilities and  the consumption in terms of uh red taming adversal [25:14] agents these there is a lot of area to improve  in that aspect and those are the areas where [25:22] things could go wrong in other direction. So my  my my CEO likes to say tsunami of code m because [25:29] code is coming much faster than testing is able  to keep up with now um two points one about how [25:39] uh junior developers so we did a pilot few years  back uh 6 months we had fresh college graduates [25:47] 2 years experience 5 years experience 10 years  experience so we found out that when we gave it [25:53] to fresh college gradu graduates after 6 months  uh we found out that their ability to write code [25:58] on their own didn't improve at all after they  left college. We incurred more technical debt [26:04] than we did before. So we to we took a conscious  decision u of not giving uh coding assistant [26:13] access to freshers. Uh we mandated that they have  to code for two years before they get access to [26:20] coding assistance. Now right or wrong but 2 years  later I see a lot of people becoming really really [26:28] those same percent of people understanding how  to use it because they have the basic knowledge [26:33] of how things work in a in an actual environment  right because in college they only learn about how [26:39] coding will be done but now when you're part of  a bigger team or bigger pod or a bigger portfolio [26:44] team how what you write impacts so many other  things the pipeline aspect of it quality gates as [26:51] aspect of it like working within containers and so  on. So uh long story short we we felt that giving [26:59] it to junior folks was was a mistake uh and we  instituted second we also looked at uh building [27:06] applications with net min and java we found out  depending on which which coding assistant you're [27:12] talking about of course we we started with  Microsoft it did well no wonder innet python [27:19] and then java then when we looked at cloud very  different when we looked closer AI very different. [27:27] So I think that that's one aspect. Coming back to  the code review, listen code review traditionally [27:36] has been about looking at the syntax, looking  at a lot of different things. I don't think [27:41] it is anymore. It is about uh explaining what's  happening, understanding the risk. Right? There [27:51] are different there different risk. I I knew I  I'm going to miss some. So I wrote some right like [27:56] uh copyright, reusability, architectural design,  security, business correctness, uh acceptable use. [28:04] Is it okay if you use AI? Do you have permission  from the client? Like we are a services company [28:09] like is it okay to use it or not? Uh it's a  healthcare uh protected domain. Is it okay to what [28:16] what was the training data used for a traditional  machine learning model versus an LL? and is it [28:22] fine from a legal perspective um if you're talking  about traditional is there bias and things like [28:27] those right there's so much of risk we have to  look at right so if if if you ask me right I will [28:35] it's a cultural shift the shift is not about who  typed this code but it's about who can verify and [28:42] explain this code and that goes back to this whole  shift about AI generated the code but someone owns [28:48] it and there has to be an owner an accountable  person and that person should be able to validate, [28:54] verify and explain. So I think those those some  of our own learning while incorporating AI into [29:01] our own engineering processes. Uh I I think uh  there are some uh serious uh concerns that people [29:08] you know or maybe aware of them or maybe they're  not aware of them but uh when you use AI in you [29:14] know in your systems always make sure you check  the licensing terms for that because if you use [29:19] AI from a specific vendor you may or may not  actually own what you're producing out of it. [29:25] So and obviously there are challenges about IP  infringement and you know pretty much everything [29:29] else that is tied to it. So if you use AI always,  you know, especially in coding, always make sure [29:36] you tag it appropriately. So when when there's a  question about provenence, you could always have, [29:41] you know, that audit trail that you can always go  back and, you know, when you tag it, tag it in a [29:46] way that you have all the metadata associated  to it. So you can always pinpoint and then you [29:50] can try to rectify if there's any infringement  and even if you have you know any innovative uh [29:56] modules being developed in your organization and  if you want to patent them you know have copyright [30:00] for them make sure you look at these licenses  make sure you look at the originality of the code [30:04] because you know all these LL are trained on a  public you know code repositories that also entail [30:09] a lot of these licenses so you may want to make  sure that you know if you're working on innovation [30:15] if you're working on patents uh you double check  on the originality of the source code that you're [30:21] going to produce so that in the end nobody can  come after you. This is very similar to like [30:25] worrying about GPL1, GPL2 licenses, right? Like  that's that's a very good point actually. Yeah. [30:30] And adding to that uh not only licensing, I think  it's uh also about how you're going to use uh the [30:38] data which is the foundation for everything,  right? uh what is the level of access your AI [30:45] is going to AI tools are going to have to your um  you know the data layer. So how is the semantic [30:53] layer is being maintained over the connectivity  and also um what level of security, what level of [31:00] data privacy, what level of restrictions. So it  it it touches more of you know data governance, [31:07] data architecture and things as such that also  kind of are open doors for you know some AI to get [31:15] hold of. There is a saying uh recently that people  who are using AI are not just only paying for the [31:22] tokens that are being leveraged but also the data  or the organizational information that you're [31:28] letting it. So you're paying twice basically.  Mhm. We talked about starting with verification [31:34] and some of the governance part also trust part  of AI. I want to go into costs but before we do [31:40] so are there any questions on some of the topics  we discussed so far that we can answer. I have one [31:45] person in the front here. You guys mentioned  licensing and uh you know right now you guys [31:51] were just discussing that. How do you how do you  validate that? Are you using AI to validate it? [31:56] use lawyers I believe but uh uh it's always a  good idea to go through the contracts when you [32:03] sign you know your agreements with the vendors  and it has to be extremely thorough there's a [32:07] reason enterprises actually have their own  dedicated advocates I know law legal firm [32:12] basically so it's always ideal to make sure you  know what you're getting into and uh you need to [32:19] know how it actually impacts eventually when you  want to use that product and when you actually use [32:25] any third party system you're also building that  dependency on them. So you have to look at the [32:30] long-term viability of that partnership too. Most  of the procurement teams now do this function but [32:40] a lot of large enterprise have an AI office now  separate office which whose job is to look at a [32:46] lot of these aspects. So I think uh licensing  is one of that right like we like one of our [32:53] customers we just they just moved from cloud teams  to cloud enterprise the main thing they wanted to [32:58] understand was data retention so uh without naming  whether it is fraud or jubility right like one of [33:04] them was saying 30-day retention right so is  it is it fine from a legal perspective right [33:11] uh again without going into specific the some  of the enterprises really especially banks and [33:17] insurance companies and healthcare companies they  worry about where is my data because it's mandated [33:22] by government that you cannot have your data  reside outside of let's say EU or North America [33:28] so if you're on AWS or Azure or or anthropic or  any of the hyperscalers where is your data going [33:36] to be right second thing people worry about is  data being used for training now at a high level [33:44] everyone says we don't use it but who puts it on  paper from a legal perspective this is important [33:50] from a from a from a procurement perspective.  So all these aspects come come into play. So I [33:57] think that's that's that's one of the things I'm  seeing a lot. Yeah. In regard to the training data [34:02] sometimes that even changes based on model. So we  have somewhere they're like yes we won't use it [34:07] except for if you want early access to the latest  model we get to store data for 30 days. And you [34:13] know they'll tend to limit it of hey we want to  use this so we can analyze how well the model's [34:17] working not to train the model but still that  brings in another uh sort of governance control [34:22] there you have to worry about that's such a good  example so we would we were explaining like AI [34:27] governance to one of the customers we created all  the rules right they will have this access that [34:31] access but then we created a rule specifically for  pilot access what does it mean if you want to try [34:36] a new model before the organization get access to  it this small group will have access it's mostly [34:41] IT and small good of like experts who will try  out that let's say fable or something right like [34:47] is coming in try it out validate and then get your  deployed it's not just it's available anyone uses [34:54] it right I think that is that is key I think that  brings a good point around like you know we have [35:00] various models but they may not know the context  or what hardships that organization might have and [35:07] how to solve it that all depends upon you know the  domain specific knowledge it's the model doesn't [35:13] have right um how many of you all use some sort  of electric cars that run all by yourself I'm not [35:20] uh telling any specific name or thing but uh  whenever they have a new release right they do [35:28] a some sort of trial period so that it's a free  trial period not just only to learn the behavior [35:36] but also know the drawbacks right similarly it's a  kind of every model every tool has a option to opt [35:44] out of the training. Uh most of the organizations  opt out and have their organ organizational [35:51] governance policies that kind of take ahead of it.  But if you're using it for your personal purpose, [35:58] make sure you make that flag off so that your  questions or your conversations are not public and [36:05] um visible to everyone. Yeah. One more over  here. Hey, so we are talking about code and [36:13] quality and everything and junior developers.  Um, I just love want to know like what you have [36:18] done in your organizations to talk about the  requirements and the quality of the specs that [36:23] are given to the coding models because coding  models are good enough if your specs are good. [36:29] Have you done anything around your business  analyst to maybe have them base themselves into [36:36] the code so that when they're require writing the  requirements for the customers they have access to [36:40] the code models like code base itself so that what  comes out of their effort is actually grounded [36:47] into your code base. I okay the 37% of defects  we find during testing cycle are because of bad [36:57] requirements fact so what have we learned um we  have a platform called coco which is co-pilots of [37:05] co-pilots we integrate with all the LLMs we build  models where we can generate requirements when we [37:11] say generate requirements every company has a  standard of requirements right the most common [37:16] I've seen is persona action outcome right or  given then what or different formats people have [37:24] uh so we can generate requirements from just  transcripts or simple language. How do we do [37:31] that? We provide context what Madita was talking  about and uh we provide the context and using that [37:37] context we generate uh the requirements. If you  already have requirements, a lot of requirements, [37:44] we can look at those requirements and validate  them for ambiguity, structure, completeness, [37:50] uh acceptance criteria, and then we can tell  you these are high quality, medium quality, [37:54] low quality. We don't stop there. We also  go help you fix those automatically with a [38:00] click of a button. So this is what we do. But  if you if you if you're using Jira, Jira has [38:06] something called RO, which is a AI, it does some  bit of this out of the box. So it's a question of [38:14] um what do you want to put in the hands of your  BAS? I think that's what you were asking about, [38:18] right? We've done this for a lot of SAP customers,  right? They get this uh the the requirements [38:24] coming from like BPM documents and so on, right?  Like how do you convert them into something which [38:29] can be used for custom coding and so on. So  that ability to consume input in any form PDF, [38:36] PPT, video transcription, audio transcription,  screenshot or signavio uh the screen uh where [38:44] uh images we could consume all of that and  create. So that's one of the ways we've seen. [38:49] If someone wants to add go ahead please. Yeah  sure of course uh I may not be able to speak [38:55] for my organization but in general you have heard  about like specdriven development. Yeah. So that [39:02] is something most of the organizations used uh  plugging into the you know development phase [39:08] where specs are converted into pieces of code.  But again uh time that back to the business users [39:16] or business analyst. Uh the thing that worked out  was to help them out with building that features, [39:22] building them out with the epics and lower level  user stories and things in that way that it can [39:30] be more productivity from their end and also  those tools help them iron out the things that [39:36] they might be missing out at the early phases  rather than catching them towards the end. [39:43] uh if you uh you know uh I'm pretty sure everybody  is using a lot of agents or you know coding tools [39:50] right here AI based coding tools. So today in  today's today's scenario you would spend more [39:56] time on writing specs. You'd actually spend a lot  of time in creating your own PRD. Uh in fact if I [40:02] could go on you could probably spend like 70% of  your time in refining that over and over because [40:07] you need to make sure that you're not only  addressing the current state of affairs but [40:10] you also need to make it future proof and if  it is not a green field project you also need [40:15] to feed in into the context you know everything  about the existing project too. So there's a lot [40:20] that you need to look at which is why you know  in in in the future product managers are going [40:25] to rule because they they have this dependence on  software engineers but you know they're not going [40:29] to have the dependence on software engineers going  forward. So that's a radical statement. I mean uh [40:35] say they still need it right like how do we how do  we validate product requirements right now product [40:41] managers traditional industries right still world  is about writing requirements writing test cases [40:46] writing the feature files writing automation  scripts creating test data but trust me I'm [40:52] working with some of like the largest social media  company the largest search company without naming [40:58] anyone they don't believe in writing requirements  like I've had this conversation right I'm [41:04] We are a testing organization. What do we need?  We need the requirements to create test scenarios [41:08] and test like we don't write we like the was  saying right like we we don't have time to write [41:15] requirements. So what do they do? They get into a  call they just discuss and they say we make it so [41:23] modular that it shouldn't take you more than a  day or two. So why should I spend high? So what [41:28] we did because we we still care that we have  the traceability this user story this business [41:33] requirement this user story this test case this  scenario blah blah blah. So we started recording [41:41] those meetings transcribing it converting it to  user they never looked at the user story but our [41:46] point was let's say the engineers leave there is a  bug someone has to come in and understand what is [41:53] the context you're giving them. So we we did that  reverse engineering for them. Um so that's another [41:59] world they don't care about requirements and then  for us um there's sort of two tactics we take. One [42:08] our product managers get the same access to tools  that the developers get right. So um they have the [42:14] capability to use those to generate requirements.  They can also use those to generate prototypes. [42:18] We've spent a lot of time building uh environments  to help make it easy for the business side to come [42:24] and say this is what it should look like. this is  how it should operate and sometimes they really [42:28] just need the developers to come through and  say okay yes that is actually put together in [42:32] a way that is sustainable and maintainable and  scalable uh there and then sometimes it's okay I [42:39] understand what you're going for now we can write  it you know sort of start over from that um but [42:44] there's definitely a lot of blending between the  roles now um and we've always traditionally had [42:49] our developers play a large role in even gathering  the requirements uh there because they tend to do [42:54] just a better job of understanding okay here's the  nuance that I need to know this is the part that I [43:00] don't need to know within the R&D organization  developers by like no-brainer but now we are [43:05] providing like a lot of our QA engineers are using  AI because like like I said tsunami of code but if [43:11] testing is still slow that blocks quickly so we  using that then I for for ops using AI triaging [43:21] uh making uh go no good go decisions right and  Then outside of engineering organization or SDLC [43:29] I'm surprised to see like we just enable AI for  all our sales organization account managers to [43:35] do what do lead qualifications account planning  crossell upsell opportunity identification these [43:41] were areas where we never thought we'll the  technology savvy but AI has made it so easy [43:46] for them to use they're uploading the QBR decks to  identify cross-ell opportunities identify looking [43:54] meeting transcripts identify red, green and  yellow from a customer advocate perspective, [44:00] who is supporting us, who is not supporting us and  so on. So the usage is just mind-boggling. Yeah. [44:06] Yeah. I may add a different perspective here. Uh  like it's not about the role whoever might be in [44:12] various roles, right? It's not about a specific  role. Everyone would be impacted in the sense of [44:18] changing their role by themsel being taking or  leveraging AI as an assisted tool. They will be [44:26] taking AI to help them uh better productivity as  well as taking it as an orchestrator. Right now [44:35] a new role has just emerged forward deployed  engineer who takes everything from beginning [44:42] to the end which is starting from requirements to  taking it to production. So uh roles are changing. [44:48] It's just us to adapt to new things and take it  forward. Yeah, we wanted to cover many more topics [44:56] but unfortunately we're out of time. Please  give a big hand to our panelists. [applause]