LinkedIn, Tech Chiefs Warn AI Code Surge Breaks Enterprise DevOps

LinkedIn与多位技术高管警告：AI代码激增正在压垮企业DevOps 加速的AI代码生成正在让传统发布流水线不堪重负，并使传统的待命模式失效，迫使工程团队将自动化重心从单纯的语法编写转向确定性的运维分诊。 专家小组探讨了从手动软件开发向AI辅助工作流的转变，强调在应对大规模代码转换时，确定性工具和自动化重构方案的表现显著优于概率型大语言模型。尽管AI编码工具直接提升了个体开发者的产出，但测试、合规及传统DevOps流水线等下游瓶颈制约了端到端的交付速度。企业必须推行严格的零信任安全和分层治理模型，以管理自主智能体工作流以及平民开发者的涌入。随着语法生成日益商品化，传统软件工程正在转变为一门以架构设计、代码评估和跨职能产品领导力为核心的学科。 单纯依赖概率型大语言模型进行单体代码库迁移会导致过度的Token消耗和更新不完整；将智能体与确定性的AST（抽象语法树）级重构方案相结合，能以高得多的效率实现100%的准确率。 (4:04) 上游代码生成速度的提升，在自动化测试、合规审查和生产部署等传统下游流水线中造成了严重的瓶颈。 (7:41) 当代码由AI编写时，传统DevOps“谁构建，谁运行”（you build it, you run it）的理念便宣告失效，这促使AI必须直接延伸至运行时运维、故障分诊与自动修复领域。 (7:41) AI在基础设施运维中的核心投资回报，来自跨大型计算集群的自主诊断与分诊集群，而非语法生成。 (10:30) 软件工程师的核心角色正在从手动编写代码转向系统级的审慎评估与代码质量把控。 (13:37)

AI code models significantly accelerate upstream feature authoring, but engineering leaders caution that scaling them effectively requires deterministic tooling, automated runtime remediation, and strict governance to overcome downstream delivery bottlenecks and security risks. Deterministic Tooling Over Probabilistic Generation (4:04) Nick Patterson of Moderne observes that using off-the-shelf conversational models directly for monolithic codebase modernizations leads to costly operational dead ends. In an internal benchmark directing Claude to migrate an enterprise Java application from Java 8 to Java 25, the probabilistic model spent 60 minutes and 60 million tokens exploring the codebase, ultimately achieving only 25% of the task by merely updating version strings in build files. In contrast, providing the agent with composable, deterministic source-code transformation recipes completed the identical migration with 100% accuracy using 30,000 tokens. Patterson emphasizes that rather than asking probabilistic language models to generate abstract syntax trees line by line, engineering teams should instruct agents to author or compose deterministic transformation programs once, and then execute those programs repeatedly across the codebase. Downstream Bottlenecks and the Breakdown of DevOps (7:41) While individual developer authoring velocity accelerates, overall organizational throughput faces severe constraints. Justin Johnson of Renaissance Health and Benefits notes that while hands-on engineer productivity increased by approximately 25% (1.25x), downstream delivery gains compressed to roughly 1.1x once legacy automated test suites, compliance reviews, and deployment pipelines absorbed the output surge. Traditional vanity metrics like lines of code or pull request volume further distort productivity, particularly as token-based model pricing incentivizes verbose model generations, such as 700-line "comment essays." Byron Ellis of LinkedIn warns that the foundational industry doctrine "you build it, you run it" breaks down entirely when humans are assigned on-call rotations for code authored by AI agents. Because engineers cannot sustainably troubleshoot unfamiliar machine-generated code during live production incidents, LinkedIn and Renaissance argue that automation must expand past the IDE. Both organizations deploy autonomous operational agents—such as cluster surveillance bots and specialized agent swarms—to handle runtime triage, continuous model optimization, and automated remediation across massive compute clusters. From Syntax Authors to Evaluators and Enablers (13:37) As code models commoditize raw syntax generation, the primary engineering competency is shifting from writing code to evaluating, testing, and architecting systems. Incoming developers increasingly treat models as their core programming interface, minimizing the need to memorize arbitrary syntax quirks but creating an experiential deficit in distinguishing robust implementations from fragile ones. The panel stresses that engineers now gain far more career leverage from mastering distributed systems architecture, component connectivity, and interface contracts rather than perfecting language-specific semantics. Simultaneously, the rise of AI tooling is empowering non-technical citizen developers and product managers to assemble working prototypes directly. To manage operational risk, Johnson outlines a tiered governance framework that confines citizen projects to local scripts or team utilities until central platform gates enforce security linting and identity authentication. Classically trained engineers must transition from gatekeepers of an exclusive craft to cross-functional enablers who guide non-technical builders, enforce architecture standards, and maintain system-level guardrails. Token Economics, Small Models, and Zero-Trust Security (22:48) The operational realities of running autonomous agents require strict economic and security boundaries. The panel cautions that running continuous, multi-day agent loops against commercial frontier models is financially unsustainable, noting that enterprise token pricing currently benefits from venture capital subsidies. To control inference bills, teams are actively routing narrow, domain-specific tasks to custom fine-tuned Small Language Models (SLMs), reserving frontier models strictly for high-level reasoning. Enterprise security architectures must also adapt. Ellis argues that conventional perimeter VPNs and broad role-based access controls fail against autonomous agents capable of querying and moving data at machine speed. Enterprise safety requires granular, zero-trust authorization enforced at the row and column level. Additionally, because transmitting context to external cloud models represents potential data exfiltration and triggers vendor data retention windows, LinkedIn maintains on-premise infrastructure and local models, enforcing auditable, deterministic data governance rules rather than relying on probabilistic agent decisions. The panel concludes that future developer workflows will center on continuous "agent factories" dedicated to resolving legacy technical debt under human orchestration, even though supervising early-stage autonomous agents currently introduces extra operational overhead. As traditional software development and product management converge toward unified system builders, coding is anticipated to evolve from a specialized job title into an ambient, ubiquitous capability.

在由 Ai4 主办的工程领导者研讨会上，来自 LinkedIn、Moderne 和 Renaissance Health 的技术主管指出，AI 代码生成正从简单的交互式补全转向由自主智能体驱动的运维诊断与大规模代码库重构；然而，大语言模型的概率性缺陷、下游交付与运维链条的阻滞，以及数据外泄风险，迫使企业必须以确定性工具链和细粒度零信任架构替代单纯的模型依赖，推动软件工程师向高维系统架构师与“代码耳语者”转型。 确定性工具破解概率模型重构瓶颈 (4:04) Moderne 解决方案工程负责人 Nick Patterson 指出，企业常试图直接依赖通用对话大模型解决长达数十年的遗留技术债务，但在复杂代码重构任务中，单纯依赖概率型大模型会产生极高的计算开销与低效循环。在 Moderne 的内部基准测试中，指示 Claude 执行一项将企业应用从 Java 8 升级至 Java 25 的整体迁移任务，该模型在经过 60 分钟深度思考与上下文探索、消耗了 6000 万 token 之后，仅更新了构建文件版本号并修改了少量周边代码，任务完成度不足 25%。为此，Moderne 提出将概率生成转变为“确定性配方”驱动，即让智能体调用基于抽象语法树（AST）编写的确定性源码转换程序，最终仅使用 3 万 token 且在更短时间内实现了 100% 准确迁移。Patterson 强调，高效架构应指导 AI 编写一次确定性脚本或测试框架，随后重复执行该程序，而非让模型逐行拼凑代码。 LinkedIn 平台首席主任软件工程师 Ankit Goyal 同样证实了专用架构的重要性。LinkedIn 正利用专用自主智能体将超过 400 个经过多年调优的生产级机器学习模型从 TensorFlow 迁移至 PyTorch，这一规模若依靠人工手动调优需耗费数年时间。除了静态模型代码转换，LinkedIn 还部署了自动化集群优化智能体，实时监控计算资源的硬件利用率，在检测到低效计算任务时自动优化模型训练参数并提交拉取请求（PR）。由于商用通用代码智能体在执行多步骤、长时间任务时容易偏离既定目标，LinkedIn 专门研发了评测框架，为智能体划定严格的任务执行边界。 下游交付瓶颈与传统运维模式瓦解 (7:41) Renaissance Health 副总裁 Justin Johnson 表示，引入代码生成工具后，软件工程师的一线直接编码速度获得了约 25%（即 1.25 倍）的即时提升。但这一提速暴露出企业整体工程交付的结构性脱节：由于合规审查、人工 QA 验证和部署流水线等下游环节仍遵循传统长周期模式，端到端实际交付效率的提升被压缩至 1.1 倍左右。随着生成速度大幅加快，衡量开发效率的传统指标（如代码行数或 PR 提交数量）彻底失效。Johnson 警告称，模型提供商的计费机制天然鼓励更多 token 消耗，甚至出现模型撰写 700 行“注释论文”来敷衍审查的防御性现象；不以最终合并投产为导向的高频提交本质上只是在购买工程噪音，团队评估指标必须全面转向从构想到上线的“时间价值”（time to value）。 LinkedIn 主任工程师 Byron Ellis 补充指出，上游代码产出的爆发直接给底层大数据平台的基础设施带来了巨大运行压力。更深层次的危机在于，过去 25 年工程界奉行的“谁构建、谁负责”（you build it, you run it）核心 DevOps 理念在 AI 时代彻底失效。如果让值班工程师在深夜为机器自主编写的代码排查生产事故，其难度如同被空降到陌生的遗留系统。此外，在数据管道中依赖 AI 生成单元测试常陷入逻辑循环——若开发者或模型已完全掌握边界情况以生成完备测试，则说明其早已掌握解决底层问题的方案。Ellis 认为，人类无法持续维护由机器编写的系统，AI 自动化必须走出 IDE 编辑器，直接延伸至运行时的故障分诊与自动化修复链路。 平民开发治理与细粒度零信任防御 (22:48) 大模型大幅降低了编码门槛，促使不具备传统计算机科学背景的业务人员与“氛围编码者”（vibe coders）重返软件构建流程。然而，缺乏治理的平民开发极易引发经济与运行风险。Johnson 提到，曾有非技术人员因无限制调用生成工具而导致云端计算与 API 账单激增。为此，Renaissance Health 建立了分级治理模型：Tier 0 仅限本地个人脚本，Tier 1 为团队内部小工具；一旦涉及全公司协作的 Tier 2 级别，项目必须强制收归中央基础设施，统一纳入 GitHub 托管，并强制实施 Okta 身份验证、静态分析与安全扫描。 在数据安全与模型访问边界方面，Ellis 强调向外部商用模型传输数据在本质上构成了数据外泄，连带上下文交互都存在泄露隐患。传统的边界 VPN 和基于角色的粗粒度访问控制（RBAC）在响应敏捷的自主智能体面前已经过时，企业必须建立细化到单行和单列数据级别的零信任授权与数据脱敏架构。会议主持人 Ron Schmelzer 补充提醒，部分主流商业模型的服务条款规定用户反馈交互将触发长达 5 年的完整会话保留期，企业对此必须保持审慎。为满足强合规与隐私保护诉求，LinkedIn 选择依托内部自建算力部署开源模型，通过确定的审计策略对敏感与非敏感数据实施严格的本地与云端物理分流。 从代码编写者到产品级代码耳语者 (41:18) 底层语法生成的商品化正驱动软件工程人才培养模式与职责分工的全面变革。与会者一致认为，资深工程师的核心价值不再是熟记特定语言的琐碎语法，而是把握分布式系统拓扑、组件接口契约以及对系统代码的审判评估能力。面对早期代码构建，开发者应当像产品经理一样专注于业务逻辑与意图表达，利用大模型快速将自然语言需求转化为可执行雏形，随后部署专门的智能体对粗糙的原型进行重构和架构规范化。此外，考虑到多日长时间运行智能体在商用前沿模型上的成本极高，工程团队正积极采用任务分流机制，将复杂推理与特定狭窄任务解耦，分发至经过微调的高性价比小型语言模型（SLM）。 针对开发者的职业前景，Goyal 坦承当前工程师面临着沉重的“智能体看护税”（supervision tax），因担心模型卡壳而不得不经常在深夜上线跟进智能体执行进度；但小组普遍对工程职业的未来持积极态度。与会者预测，在未来数年内，软件工程师与产品经理的角色界限将加速消融，融合成兼具深厚产品直觉与技术架构落地能力的“代码耳语者”（Code Whisperer）。正如“计算员”（computer）曾是一项专职人类职业而后演变为通用机器能力一样，“程序员”未来或许也将不再作为独立隔绝的专业工种，而成为一项深度融入日常业务构建的通用底层能力。 当前 AI 辅助编程展现出极高的原型构建与代码翻译效率，但其向企业级规模化推进的阻力仍集中于长时间复杂推理的不稳定性、高昂的智能体看护成本以及遗留系统在交付与治理上的结构性滞后。如何减少人工监督摩擦、利用确定性架构确保生成成果的可控性与经济性，仍是整个行业有待解决的核心工程命题。

## Background 本视频由 Ai4 频道发布于 YouTube 平台（发布日期为 2026 年 8 月 21 日）。视频记录了一场由 Forbes 专栏作家 Ron Schmelzer 主持，汇集了来自 LinkedIn、Moderne 及 Renaissance Benefits 等企业工程负责人的圆桌论坛，探讨开发者如何将 AI 作为结对编程伙伴，利用智能体从手动开发向 AI 辅助工作流转型，并直面软件开发模式的深刻变迁。 ## TL;DR 圆桌深入探讨了 AI 编程在企业实际落地中的机遇与挑战，指出必须结合确定性工具链来克服大模型在复杂代码重构中的概率性幻觉与高额 Token 消耗。嘉宾们强调，随着 AI 生成代码的大幅提速，研发瓶颈已迅速转移至下游的评审、测试与生产运维，传统的“谁写谁维护”DevOps 责任机制面临解体。软件工程师的核心职责正从底层的代码手写者全面转向系统架构设计者、代码评判者与赋能者，团队衡量生产力的标尺也正从代码行数转向最终的业务价值交付时间。 ## Atmosphere & style 整场研讨氛围务实坦诚、充满一线工程师特有的冷幽默与清醒洞察，彻底摒弃了浮躁的技术宣讲。台下互动极为活跃，台上嘉宾在分享亮眼提效成果的同时，毫不避讳地吐槽“深夜看手机查智能体进度”的工作量反增悖论，以及运维黑盒和上下游流程滞后的真实阵痛，生动传达出软件工程处于剧烈范式变革前夕既兴奋又审慎的探索质感。 ## Key takeaways - [03:37](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=217s) 大模型在长链路重构中容易走偏，最有效的实践不是让 AI 逐步直接执行，而是让 AI 编写可复用的确定性脚本或程序（Recipes）来高效执行任务并节省 Token。 - [06:17](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=377s) 前端编码提速后，软件交付瓶颈已转移至工程下游：传统的 QA、安全合规与部署流水线难以匹配 AI 的生产速度，迫使企业必须重构交付管道。 - [08:38](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=518s) 推行近 25 年的“谁编写、谁维护（You build it, you run it）”原则在 AI 时代失效，运维侧正面临维护人类未曾读过的“黑盒代码”危机，必须借助 AI 运维闭环。 - [13:38](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=818s) 软件工程师的核心职责从“手写代码”根本性转变为“评判代码”（Judging code），要求工程师更早培养全局系统架构与数据流转的审阅把关能力。 - [18:58](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1138s) 生产力度量指标正在经历痛苦迭代：代码行数（LoC）和未合并的 PR 是制造噪声的虚荣指标，团队已转向关注“价值实现时间”与“实际合并的上线产出”。 - [22:44](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1364s) AI 时代的快速行动使传统 VPN 和粗粒度权限失效，企业必须采用基于工作负载的细粒度零信任隔离沙箱，以防敏感数据在极短时间内被 Agent 外发泄露。 - [25:34](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1534s) 企业应对“平民开发者”或“氛围编码”需要建立分级准则（如本地、组内共享、全公司发布），并在生产交付中强制接入自动化扫描与单点登录规范。 - [30:43](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1843s) 软件工程在从 0 到 1 的原型阶段必然是不完美的，承认初期代码的混乱后，应交由后续的代码 Agent 介入进行架构重构与模式抽象。 - [34:13](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2053s) 长期运行的自主智能体若完全依赖前沿大模型在经济上难以持续，工程团队需探索特定任务微调的小型语言模型（SLM）来动态优化推理成本曲线。 - [35:50](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2150s) 工程师必须打破“神秘知识所有者”的高墙花园心态，其核心价值不再是键入晦涩语法，而是转型为全局架构设计、安全合规规范的赋能者与守门人。 - [37:13](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2233s) 企业级数据治理必须建立在可严格解释审计的确定性规则之上，涉及高敏感合规场景时严禁依赖概率性 AI 或直接上传至有历史留存机制的云端模型。 - [39:30](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2370s) 未来的软件工程流水线将部署全天候运转的“智能体工厂”，持续自动化清理历史技术债务并升级依赖，使企业代码库长期保持常青。 - [41:16](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2476s) 软件工程师与产品经理的角色边界将逐渐融为一体，演化出兼具敏锐业务洞察与 AI 工具驾驭能力的“代码低语者（Code Whisperer）”。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=4s) 圆桌开场与嘉宾阵容介绍 主持人 Ron Schmelzer（Forbes AI 专栏作家，自 1995 年起报道 AI 领域）向全场观众致欢迎词，宣布本场圆桌主题为“AI 作为你的结对编程伙伴（AI as Your Pair Programmer）”。他热情鼓励观众随时举手互动，不必等结语环节，避免遗忘问题。 紧接着，四位嘉宾依次登台并分享了自己当前最核心的工程待办事项： - **Byron Ellis**（LinkedIn 首席主任软件工程师，负责大数据管道与平台基础设施）：当前首要任务是探索如何利用 AI 让基础设施监控（infrastructure monitoring）与值班（on-call）响应变得更加可控与高效。 - **Justin Johnson**（Renaissance Health and Benefits AI 与架构副总裁，同时在 Overclock Accelerator 担任 AI 工程与 AI 运营讲师）：目前全力推动“平民开发者计划（citizen developer program）”，让非技术人员借助 AI 自由构建应用，而他负责提供底层支撑与兜底。 - **Ankit Goyal**（LinkedIn AI 平台首席主任软件工程师，专注于模型训练）：核心目标是提高模型训练效率，打造一套智能体平台（agentic platform），通过增加“射门尝试次数（shots at the goal）”来持续优化模型并提升会员体验。 - **Nick Patterson**（Moderne 解决方案工程负责人，统管前线工程、平台工程及客户成功）：Moderne 专注于为智能体构建工具链（agent tools），致力于让 AI 智能体在处理复杂代码重构任务时更具确定性（deterministic）、熟练度与 Token 成本效益。 随后主持人现场互动调查，台下几乎所有人都是开发者，且所有人日常都已在写代码中深度使用 AI。 --- ### [03:37](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=217s) 大规模代码重构中的“幻觉陷阱”与确定性工具解法 讨论首先聚焦于生产力提升。Nick Patterson 结合过去二十年企业遗留的“技术债务大山”指出，许多团队试图让大模型直接处理底层架构升级，却往往陷入低效循环。例如要求 Claude 将一套老旧的 Java 应用从 Java 8 升级到 Java 25： ```mermaid flowchart TD accTitle: AI 概率性重构与确定性 Recipe 方案对比 subgraph Probabilistic["纯概率性 LLM 提示词方案"] A["提示词: 升级 Java 8 至 Java 25"] --> B["Claude 深度思考/探索 60 分钟"] B --> C["消耗 60,000,000 Tokens"] C --> D["结果: 仅完成 25% 任务<br/>(仅机械修改版本号文本与极少数代码)"] end subgraph Deterministic["Moderne 确定性 Recipe 方案"] E["LLM 调用预设 Recipe 程序库"] --> F["执行可组合的确定性代码转换脚本"] F --> G["消耗仅 30,000 Tokens"] G --> H["结果: 100% 自动化精准完成"] end ``` Nick 强调，大语言模型本质上是概率性的，直接让其处理长链路修改容易“走偏”。Moderne 提出了可组合的确定性程序（Recipes）目录，让 AI 智能体去调用确定性工具，将 Token 消耗从 6000 万暴跌至 3 万，并实现 100% 的准确交付。他提炼出的核心实践法则是：**不要直接让 AI 智能体去一步步执行任务，而是让 AI 编写可复用的脚本或程序，后续直接运行脚本完成任务**。 --- ### [06:17](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=377s) LinkedIn 的模型迁移实践与生产部署瓶颈 Ankit Goyal 介绍了 LinkedIn AI 基础设施团队的实战案例。他们正将集群中超过 400 多个由工程师历经数年手工调优的生产模型从 TensorFlow 迁移至 PyTorch。 - 若由人工逐一迁移调优，将耗费数年时间； - 团队构建了专门的“模型生成智能体（model generation agents）”与性能优化智能体，不仅能实现等价的生产环境性能，还会持续监控集群中资源利用率较低的任务，自动优化模型并自动提 Pull Request 供工程师审查； - 针对智能体在长运行任务（long-running tasks）中容易偏离轨道的短板，团队开发了专属测试测试床（harnesses）进行路径约束与护航。 Justin Johnson 则从业务落地端带来数据：团队目前人均生产力提升了约 25%（他幽默调侃道“相当于每位工程师变成了 1.25 个人，虽然不知道多出来那四分之一算身体哪个部位，但绝不是我想要的会干活的手”）。然而，他指出真正的瓶颈已转移至工程下游：虽然前端编码变快了，但过去几十年建立的 QA、产品评审与部署流水线依然滞后，导致整体发布周期难以跟上 AI 编码的速度，企业必须重构整套交付管道。 --- ### [08:38](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=518s) 运维撞墙期：当“机器人写的代码”遇上 DevOps Byron Ellis 从底层数据管道架构师的视角指出了更为深刻的运维矛盾。作为 Ankit 的下游“接盘方”，他直言业务方生产代码的速度飙升给基础设施带来了巨大冲击。 - **测试悖论**：在传统数据工程中，如果工程师已经清晰到能够为特定异常生成精准的单元测试，往往意味着问题已经被搞懂，测试本身的防御意义反而削弱； - **DevOps 责任断层**：软件工程界推行了近 25 年的“谁编写、谁维护（You build it, you run it）”理念彻底失效。如今大量合并到主干的代码是机器人生成的，甚至没有任何人类真正读过、写过它； - **运维黑盒危机**：让没有参与过代码编写的人类去值班并维护 AI 生成的代码，就如同“把一个人突然空降到一个从未见过的遗留代码库中并强行要求他上岗值班”，极其折磨且不可持续； - Byron 总结道，代码生成已经解决，当前的真正挑战在于**如何把 AI 深度融入运维（Ops）侧**，必须由机器人去闭环维护机器人生成的代码，自动定位并修复系统的故障。 ### [10:30](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=630s) 运维自动化与自主命名的 AI 智能体 团队在 AI 赋能方面的最大价值并不是单纯的代码生成，因为日常工作中实际需要手写的代码量并不大。团队的核心挑战在于日常的大规模系统运维：在遍布集群的数十万个计算核心（Cores）中，随时可能有某一个核心发生故障。过去需要工程师手动定位故障节点、排查原因并予以修复；而如今将整个排查与修复流程自动化，才是团队投入大量精力并获得最高投资回报的地方。 当被问及这些智能体的命名时，现场透露这些智能体实际上是在遵循基础指引的前提下“自行挑选名字”。系统内维护着一个包含《布偶大电影》（The Muppets）角色和各类经典卡通人物的大型名称库供它们选择。例如，专门负责为其他所有智能体优化 Prompt 的智能体给自己挑中了《飞出个未来》里的机器人名字“Bender”，这个形象非常贴切，甚至被直接硬编码成了固定代号；负责底层探索的智能体则选择了布偶秀里的科学家角色“Dr. Bunsen Honeydew”，还有象征狂躁干劲的“Animal”。在任何给定的运行时刻，系统中大约有 45 个 AI 智能体在协同工作。 ```mermaid flowchart TD accTitle: AI 运维与智能体协作架构 subgraph S1["大规模基础设施层"] A["数十万计算核心 (Cores)"] --> B["故障检测与告警"] end subgraph S2["自主协作智能体网络 (~45 Agents)"] B --> C["排查与修复智能体 (Animal / Honeydew)"] D["Prompt 优化智能体 (Bender)"] --> C end subgraph S3["自动化交付"] C --> E["自动定位根因与修复上线"] end ``` ### [11:40](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=700s) 平民开发者崛起与传统工程体系的重塑 随着生成式 AI 和无代码（No-Code）理念的落地，非科班出身的“平民开发者”（Citizen Developers）开始有能力构建复杂的软件系统。这场技术平权让统计学专业出身、靠自学写代码的技术专家感同身受。早年间甚至有牙医父亲自行编写牙科诊所管理软件的先例，但过去 30 年中软件行业构筑了过于森严的专业工程壁垒与分工门槛。现在，AI 重新赋予了所有人进入这个领域的权力，即便这需要传统软件工程界进行深刻的“灵魂反思”（Soul-searching）来拥抱外部人群，但长远来看这无疑是一次积极的飞跃。 然而，非专业开发者的涌入也带来了现实管理挑战。如果不提前做好规范，可能会出现员工拿到工具后盲目调用、跑出惊人账单导致管理层被迫介入收拾烂摊子的尴尬局面。因此，针对平民开发者的指引与沟通至关重要。 - **前期对话与规范建立**：必须明确可用工具的边界，指导非技术人员如何与大模型交互、如何要求 AI 编写操作脚本或先输出规划方案。 - **避免流程失控**：省略前期的基础引导，业务探索很容易迅速偏离轨道，反而造成高昂的试错与资源成本。 ### [13:38](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=818s) 工程师角色的根本转变：从“写代码”到“评判代码” 开发者的核心职责已经发生根本性转移——从过去的手动编写代码，转变为现在的**评判代码**（Judging code）。工程师需要具备一眼看出某段代码是否正确、其设计路径是否合理的能力。以往这种技术直觉（Muscle memory）是通过日积月累手写成千上万行代码打磨出来的，而当代码大多交由模型生成时，行业正面临初级工程师缺乏基础代码实战经验的断层断档。这要求企业必须调整培训机制，通过强化师徒制（Apprenticeship）、代码评审辅导以及对生成工具底层原理的深度理解，来培养新人的鉴别与把关能力。 ```mermaid flowchart LR accTitle: 软件工程师核心能力重心的迁移 subgraph Past["传统开发范式"] A["学习语法与库函数"] --> B["海量手写代码实战"] B --> C["建立代码直觉与判断力"] end subgraph Present["AI 协同开发范式"] D["大模型生成代码"] --> E["工程师审阅与架构评判"] E --> F["系统集成与业务落地"] end ``` 在 LinkedIn 的 AI 平台基础设施团队中，这一演进极大地释放了科研人员的生产力。许多拥有深厚科学背景但缺乏软件工程经验的用户，过去常常被复杂的训练流水线配置和基础设施运维拖慢脚步，甚至需要占用大量 On-call 支持资源。AI 辅助将代码编写门槛大幅降低后，编程不再是制约优秀想法落地的瓶颈，科研团队得以快速将算法推向生产环境。 ### [15:18](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=918s) 新一代工程师的思维重塑：系统架构胜于语法细节 新生代开发者接触编程的方式已经与老一辈工程师截然不同。对于新入行的实习生和年轻人来说，大语言模型本身就是他们的“编程语言”，他们不再对底层语言的语法细节（如 Java 或 Python 的繁琐规则）抱有执念。以早期的 Python 教学为例，学生们通常能够清晰地理解算法逻辑与程序控制流，但往往会因为记不住官方标准库函数名而受挫；如今，开发者只需要按照直觉描述函数的功能，AI 就能自动生成符合语义的实现。 这也重新定义了“初级工程师”（Junior Engineer）的核心价值标准： - **从语言语法转向系统架构**：具体语法和代码实现可以交给 AI 完成，初级工程师必须更早地培养全局视野，理解分布式系统架构、模块间如何连接以及服务如何通信。 - **差异化竞争优势**：在代码生成唾手可得的时代，深刻理解系统集成与数据流转的初级工程师，将显著比只懂代码语法的同行更具竞争力。 ### [17:46](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1066s) Hacker News 技能争论：该手写重构还是让 AI 教学？ 技术社区 Hacker News 上曾爆发过一场关于“如何利用 LLM 学习编程”的热门辩论。一种观点主张让 AI 生成代码后，工程师应当自己手动重新默写一遍以加深理解；反对者则认为这种做法不仅毫无效率收益，也违背了使用大模型的初衷。 针对这一争论，工程师们更倾向于将 AI 视为定制化的**教学导师**。如果面对一段复杂的逻辑，最高效的掌握方式并不是低效地机械抄写，而是直接向 AI 提问：“我不太理解这里的实现，请为我编写一份分步教程，拆解重建该逻辑的核心步骤与思路。”这种交互式学习既保留了理解底层原理的深度，又避免了无谓的重复体力劳动。 ### [18:58](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1138s) 生产力度量标准的进化：从代码行数转向商业价值 随着 AI 编程工具的大规模应用，衡量开发生产力的标准正在经历痛苦但必要的迭代。最初，许多团队试图沿用传统的“代码行数”（Lines of Code）或 Pull Request（PR）创建数量来评估产出，但实践证明这是“最糟糕的指标”。由于大模型极擅长批量生成代码，这导致企业内部出现了海量的低质 PR 洪峰，甚至一度压垮了内部代码评审与 CI/CD 系统。 ```mermaid flowchart TD accTitle: 生产力度量标准演进 subgraph Bad["失效的传统指标 (反模式)"] M1["代码生成行数 (LoC)"] M2["Pull Request (PR) 发起数量"] end subgraph Good["面向商业价值的现代指标"] N1["模型/特性成功上线生产环境的数量"] N2["成功运行并在生产环境 A/B 测试的实验数量"] N3["业务端到端落地周期与迭代效率"] end Bad -->|范式转变| Good ``` 团队已全面转向以业务实际产出为核心的评估体系： - **模型投产率**：重点统计最终成功部署到生产环境中的模型数量。 - **有效实验吞吐量**：衡量团队能够推向线上进行 A/B 测试的业务实验总数，以此作为衡量工程效能与业务增量的真实标尺。 ### [20:04](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1204s) 代码行数陷阱与真正的生产力指标：从“注释长文”到价值交付时间 在评估 AI 辅助编程对生产力的影响时，嘉宾们深入剖析了传统的评估误区。有嘉宾幽默地分享了一个观察：在最近的一些前沿代码大模型中，生成的代码注释居然比函数本体还要长得多。团队有一次在向模型质疑“你到底在干什么？为什么这段注释有 700 行长？”时，模型甚至开始表现得有些防御性，甚至在回复中将自己的行为称为在写“注释长文”（comment essay）。嘉宾指出，这背后存在着供应商的商业利益驱动——模型和 API 提供商本质上有动力促使开发者消耗更多 Token。 ```mermaid flowchart TD accTitle: 软件工程效能衡量指标演进 subgraph 虚荣指标 ["虚假/噪声指标 (Vanity Metrics)"] A["生成代码行数 (LOC)"] B["生成的 PR 数量 (未合并)"] A -.->|导致噪声与 Token 浪费| C["低效与虚假繁荣"] B -.->|未合并的 PR = 纯粹的噪声| C end subgraph 真实价值 ["真实业务指标 (Real Baseline)"] D["价值实现时间 (Time to Value)<br/>从构想到上线生产"] E["已合并变更数 (Merged Changes)"] D -->|交付周期缩短| F["真实生产力提升"] E -->|高质量有效代码交付| F end ``` 正因如此，“生成的代码行数”绝不能作为衡量生产力的标准，甚至单纯统计“拉取请求（PR）数量”也是不可靠的指标。如果团队只是生成了大量 PR 却无法顺利合并，那并不是在购买生产力，而是在“购买噪声（buying noise）”。企业目前正更加严密地关注“价值实现时间”（Time to Value），即从最初的业务构想到最终上线生产环境的总耗时，并将“实际合并的变更数量（number of changes merged）”作为真正的基准线。 --- ### [21:35](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1295s) 效率提升数据的拆解：开发者个体 vs 流程瓶颈 现场观众向台上的 Justin 提问：此前提到开发者生产力大约获得了 1.25 倍（即 25%）的提升，这一数据是仅仅指一线开发人员，还是已经将 QA 和审批流程等瓶颈考虑在内？如果仅看编写代码的开发者，提效幅度是否会更高？ Justin 澄清并拆解了该数据背后的具体构成： - **纯一线编码工程师（Hands-on-keyboard Engineers）：** 生产力提升确实在 1.25 倍左右。 - **全流程聚合指标（Aggregate Metric）：** 团队中虽然也有编写自动化测试代码的 QA 工程师，但由于上下游测试验证、安全审批及合规流程等传统环节的拖累，整体端到端交付的提效幅度会被拉平到大约 1.1 倍甚至更低。 --- ### [22:44](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1364s) 数据泄漏与 PII 防护：从传统边界安全到基于工作负载的零信任机制 针对现场观众关于“代码生成提速时如何避免模型泄露个人可识别信息（PII）与企业敏感架构数据”的提问，Byron 与现场嘉宾展开了深度讨论。Byron 指出，传统基于 VPN 或粗粒度角色访问控制（RBAC）的安全防护时代已经终结，那种让用户或程序在一个系统内部自由漫游、随意访问资产的做法在 AI 时代极为危险。 ```mermaid flowchart LR accTitle: AI 时代的数据访问与隔离机制 subgraph 传统边界防护 ["传统模式 (已失效)"] VPN["企业内网/VPN"] --> Role["粗粒度角色权限"] Role --> DataAll["大范围数据自由访问"] end subgraph 零信任与细粒度防护 ["Beyond Zero 模式 (AI 时代)"] Workload["细粒度工作负载隔离"] --> RowCol["逐行 / 逐列动态鉴权"] RowCol --> Box["受限安全沙箱 (Box)"] Box --> Agent["AI 智能体操作"] end ``` Byron 提到了 ACM 最近发表的关于 Google 下一代安全架构“Beyond Zero”的论文。面对反应极快的 AI Agent，企业必须将安全管理细化到每一个工作负载乃至每行、每列数据的级别： - **人类时间尺度 vs Agent 速度：** 现有的安全信任和缓解机制大多是基于“人类时间尺度”构建的；而 AI Agent 的行动极其迅速，可以在人类“眨眼之间”就将敏感数据窃取并外发（exfiltrated）。 - **细粒度沙箱限制：** 必须在基础设施层面实施极其严格的限制，企业在没有严格鉴权的情况下“不能信任任何实体”。 - **模型数据留存条款（Data Retention）：** 现场主持人补充提醒，许多企业甚至不了解第三方模型的条款。例如在 Claude 中，若用户对反馈请求进行了互动或回复，按照其服务条款，该会话线程可能会被保留长达 5 年用于训练或分析。 --- ### [25:34](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1534s) “氛围编码（Vibe Coding）”的企业落地准则与 Agent 间的代码冲突 观众进一步提问：企业是否允许业务人员、非专业开发者的“公民开发者（Citizen Developers）”或“氛围编码者（Vibe Coders）”直接将工作流构建并部署到生产环境中？此外，高昂的 AI 工具订阅与 Token 成本是否存在一个打破平衡的临界点（Break-even Point）？ Justin 介绍了其团队在企业内部推行的公民开发者三级管理体系： | 等级 | 适用范围与部署位置 | 权限与安全管控规范 | |:--- |:--- |:--- | | **Tier 0** | 个人本地工具（运行在自己电脑上，辅助日常办公） | 开发者本地运行，无需审批 | | **Tier 1** | 团队内部工具（仅限同组人员共享使用） | 团队内部管理，基础合规 | | **Tier 2** | 全公司公开内部工具（面向全体员工使用） | 强制接入 Okta 单点登录认证；禁止自主部署，必须走规范化发布流 | 在 Tier 2 流程中，公民开发者只能将代码提交到 GitHub 仓库，随后由工程团队编写的自动化 GitHub Actions 进行安全扫描、代码风格检查（Linting）和静态分析。Justin 坦言，团队目前遇到的一个未解难题是：**当自动化检查发现代码缺陷并打回时，到底该由谁来修复？** 是让原作者（不懂底层代码的公民开发者）、中心工程团队，还是让仓库里的自动修复 Agent 来接管？ ```mermaid flowchart TD accTitle: 公民开发者多级权限与安全流水线 subgraph 权限分级 ["公民开发者权限层级"] T0["Tier 0: 个人本地运行"] T1["Tier 1: 团队内部共享"] T2["Tier 2: 全公司内部公开发布"] end subgraph 交付流水线 ["Tier 2 安全与自动化流水线"] T2 --> GH["提交至 GitHub 仓库 (禁止自主部署)"] GH --> CI["GitHub Actions 自动化流水线"] CI --> Scan["安全扫描 / Linting / 静态代码分析"] Scan -->|发现代码错误| Debate{"由谁负责修复？<br/>(业务人员 / 平台团队 / AI Agent)"} Scan -->|校验通过| Okta["接入 Okta 认证并部署上线"] end ``` 谈及代码审查与修复责任，Byron 幽默地指出，无论是传统工程师还是公民开发者，标准软件工程规范都不可逾越。在 LinkedIn 内部，处理这类检查冲突甚至演变成了 AI 之间的较量——Byron 的代码生成 Agent 每天都在与内部负责代码审查的 DevX Agent（名为“May”）打嘴仗，他甚至专门为自己的 Agent 设计了用于应对审查争议的“子人格（sub-persona）”。 --- ### [28:44](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1724s) 从 0 到 1 的软件构建：产品经理、应届毕业生与编程思维方式 一位没有软件工程背景的产品经理现场分享了自己的经验：通过利用 AI，他能够从 0 到 1 独立构建项目；虽然看不懂具体代码，但他明确了解业务问题并清楚所需的解决方案，完全依据“系统是否达成了预期结果”来验证工具。他向专家请教：这种无编码背景的公民开发者与应届计算机毕业生之间究竟存在怎样的差距？对于非遗留系统、从零构建的新项目，如何确保软件的质量？ Byron 针对“编程思维”给出了深刻见解： - **写代码作为思考工具：** 专业程序员与非专业人士的核心差异并不单纯在于对工具的掌握，而在于“写代码本身就是程序员被训练出来的思考方式”。 - **产品设计融入代码：** Byron 自述从 7 岁起就开始写代码，对他而言，即使在 AI 时代依然会手写一部分代码，因为编写代码的过程正是他进行产品设计、理清逻辑脉络的方式。 - **非背景开发者的心智模型：** 对于非计算机背景的人士，不必强行去模仿手写代码的底层细节，而是应当将 AI 编程置于自身擅长的思维上下文（如业务逻辑、用户需求与系统行为预期）中去驾驭。 ### [30:43](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1843s) 从零到一的原型开发与重构：LLM 让产品思维直接转化为代码 大语言模型为软件开发范式带来了颠覆性的转变。工程师曾受限于 Java 等传统编程语言的思维框架，而如今开发者可以直接以产品经理的视角构思功能，并直接将产品构想转化为可执行的代码。计算机科学专业的应届毕业生通常被训练以固定的传统工程语境去拆解问题，但借助大语言模型，任何人都可以将自己熟悉的思维模型直接编译成底层机器逻辑。 在探讨软件工程“从零到一”（0 to 1）的阶段时，嘉宾指出软件工程往往存在一个奇特误区：它是唯一一个自认为“可以不通过原型测试就直接造出完美产品”的工程学科。相比之下，制造赛车在真正上赛道前必须炸毁几台引擎、经历多次撞车事故。在软件领域，0 到 1 的探索阶段写出的代码注定是不完美的，“甚至就应该是一团糟”，而这正是全球所有初创企业的真实常态。关键在于进入下一阶段后，将这段初版代码视作已有的遗留代码库（legacy codebase），派遣代码智能体（Agent）介入进行重构、梳理架构并提取模式，就像空降到一个陌生的复杂代码库中持续迭代。 - 软件工程的原型验证法则：承认原型阶段的混乱是必然过程，不应苛求初版代码的完美度。 - 智能体驱动的架构重构：0 到 1 阶段完成后，利用 AI 智能体寻找设计模式、重构凌乱代码并建立长期规范。 --- ### [32:43](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1963s) LLM 作为“无限耐心”的导师与质量标准的定义 大语言模型在教育和知识传递方面表现出了极高价值，其核心优势在于拥有“无限的耐心”。面对完全陌生的领域或复杂的数学公式，开发者可以直接拍照上传，并使用分级提示词策略来逐步消化难点——从“请像对待研究生一样解释”逐步降级为“像对高一学生解释”、“像对小学五年级学生解释”，甚至降到“像对幼儿解释”（ELI5 / Explain Like I'm a Toddler）的级别，直到彻底吃透底层概念。 ```mermaid flowchart TD accTitle: Multi-Tier Knowledge Simplification with LLMs accDescr: Progressive ELI prompts used by engineers to master complex technical and mathematical concepts. subgraph Concept ["输入复杂概念 / 陌生领域公式"] A["复杂理论 / 架构公式"] end subgraph GradualDeconstruction ["分层理解梯度 (ELI 递减法)"] A --> B["研究生理解水平 (Graduate Level)"] B --> C["高中生理解水平 (10th Grader)"] C --> D["小学生理解水平 (5th Grader)"] D --> E["幼儿理解水平 (Toddler / ELI5)"] end subgraph Mastery ["最终落地"] E --> F["掌握底层基本原理，支撑规模化系统架构"] end ``` 这种教学能力让非科班出身的工程师也能快速补齐基础。虽然使用 AI 快速搭建一个初始原型非常简单，但系统一旦进入规模化（Scale）阶段，深厚的底层基本功仍然不可或缺。此外，针对如何保障交付质量的问题，嘉宾强调不同背景的人对“质量”的定义大相径庭；团队在动手编码前，必须先共同锚定明确的质量标准，才能逆向推导（work backward）出切实可行的技术路径。 - 循序渐进的降维理解法：利用大语言模型拆解复杂概念，直到符合个人的认知边界。 - 质量的逆向设计：先确立团队对质量（代码规范、安全性、系统鲁棒性）的共识定义，再反向规划实现步骤。 --- ### [34:13](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2053s) Token 成本曲线、VC 补贴与小型语言模型（SLM）的探索 围绕 Token 消耗成本与边际生产力收益的讨论正在成为企业关注的重点。部分嘉宾认为当前阶段的模型调用费用依然相对低廉，如果每月在 Token 上投入 10 万美元，但能换回 5 到 10 倍的业务营收增长，这种支出便是完全合理的。 然而，在运行需要持续工作数天的全自主智能体（Autonomous Agents）场景下，长期调用前沿大模型（Frontier Models）的成本曲线正在变得难以承受。针对这一问题，团队正在积极评估针对特定任务进行微调的定制化小型语言模型（SLMs），这些专有小模型在特定垂直场景中的表现完全可以媲美顶级大模型。同时，嘉宾们幽默地调侃道，当前的低廉 Token 实际上得到了风险投资（VC）的大额补贴，这种市场红利终将改变。因此，工程团队和工具供应商必须持续优化成本架构，动态选择当前操作下最具性价比的模型。 ```mermaid flowchart LR accTitle: Dual Track Model Strategy for Cost Optimization accDescr: Balancing expensive frontier models with task-specific SLMs to optimize agent execution costs. subgraph Workloads ["任务负载分类"] W1["高复杂度架构规划 / 泛化探索"] W2["长周期自主智能体 / 持续性底层重构"] end subgraph ModelRouting ["成本与能力分流"] W1 --> M1["前沿大模型<br/>(Frontier Models / Cloud APIs)"] W2 --> M2["专有小型语言模型<br/>(Task-Specific SLMs)"] end subgraph Optimization ["收益平衡"] M1 --> O1["高单价但高智能，攻克攻坚节点"] M2 --> O2["低成本、低延迟，解决长周期运行瓶颈"] end ``` - 长期运行智能体的成本瓶颈：持续数天的自主智能体如果完全依赖前沿大模型，在经济效益上不可持续。 - 垂直小型模型的替代路径：利用特定领域任务训练的 SLM，在保障输出质量的同时大幅拉平推理成本曲线。 --- ### [35:50](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2150s) 打破“高墙花园”：工程师从代码编写者向赋能者的转型 现场观众提问：如何引导工程师打破“软件工程是专属高墙花园”的旧思维，转而将“赋能他人开发”视为自身的核心工作职责？ 嘉宾直言不讳地指出，工程师必须直面一个现实——“你们不再是特殊的了”（"You're not special anymore"）。长期以来，软件工程师被视作掌握神秘知识的特殊群体，只有他们能够理解并键入那些晦涩难懂的代码指令。如今 AI 打破了这一技术壁垒，任何人都可以生成代码。工程师的新价值不再体现在敲击秘密代码，而在于成为掌握新技术的引路人：设计高可靠的系统架构、制定安全规范、把控质量基准，并指导全员正确、合规地利用 AI 工具释放生产力。 - 工程师角色的根本转变：从“敲击代码的特权阶层”转变为“全局架构设计者与安全守门人”。 - 赋能型组织建设：将精力投入到系统稳定性、扩展性与开发规范的制定，而非底层的语法实现。 --- ### [37:13](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2233s) 企业级数据安全与合规：确定性治理与本地模型的边界 在多供应商（Vendors）和 OpenAI 等外部云端模型并存的环境下，企业敏感数据的防护成为焦点。嘉宾明确指出，一旦请求触碰外部大语言模型，数据在物理层面上就已经被回传外流（Exfiltrated）。尽管主流 B2B AI 供应商基于商业信誉不会恶意转售数据，但在金融、隐私合规及高敏感业务场景下，企业严禁将核心数据上传至具有历史记录留存机制的云端模型中。 ```mermaid flowchart TD accTitle: Deterministic Data Governance and Model Routing Flow accDescr: A deterministic policy engine determines whether sensitive data goes to on-premise local models or cloud frontier models. subgraph Ingestion ["数据输入流"] A["开发者 / 应用数据请求"] --> B{"确定性治理引擎<br/>(Deterministic Policy Gate)"} end subgraph SecurityRouting ["安全路由决策"] B -->|"高敏感数据 / 严格合规场景"| C["本地私有部署模型<br/>(On-Prem / Local Models)"] B -->|"非敏感开发 / 常规探索任务"| D["公有云前沿大模型<br/>(Cloud Frontier Models)"] end subgraph Auditing ["合规审计"] C --> E["完全本地隔离，历史记录不可外泄"] D --> F["受信 B2B 链路交互"] E --> G["可解释的确定性审计日志"] F --> G end ``` 针对敏感数据，企业必须建立完全本地化（On-Premise）的模型运行环境。更关键的是，企业级数据治理控制必须建立在“确定性规则”（Deterministic Rules）之上，而非依赖于概率性的 AI 智能体决策。因为在面对合规审查时，企业必须能够百分之百确定并解释每一条敏感数据被允许或禁止访问特定模型的根本原因。 - 数据外流风险认知：与云端 LLM 的每次交互本质上都构成了外部数据传输链路。 - 确定性治理原则：在引入概率型智能体优化前，核心安全网关必须由可严格审计的确定性规则主导。 --- ### [39:30](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2370s) 未来开发者工作流展望：消除技术债务的“智能体工厂” 在讨论未来人机协同达到理想状态时软件工程师的日常工作形态时，嘉宾展望了一个由“智能体工厂”（Agent Factories）主导的新生态。 在过去的软件生命周期中，技术债务（Tech Debt）、系统现代化改造（App Modernization）以及各类重复性的底层琐事（Developer Toil）往往因为资源受限而被长期搁置。未来的开发流水线中将部署大量自主智能体，它们如同一座全天候运转的后台工厂，持续不断地清理遗留代码、升级过时依赖并解决繁琐杂务，让代码库始终保持常青（Evergreen）状态。开发者未来的核心挑战，将是如何在 AI 智能体的概率性输出（Probabilistic Nature）与企业系统所需的确定性结果（Deterministic Outcomes）之间取得精准平衡。 - 智能体工厂（Agent Factories）：构建全天候运转的后台 AI 代理，专门用于自动吞吐和消除存量技术债务。 - 概率与确定性的平衡：软件工程演进为协调 AI 概率性创造力与生产系统确定性可靠性的双重艺术。 ### [40:50](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2450s) 智能体时代的开发者焦虑与职业安全感 对于软件工程的未来走向，嘉宾们展现出一种既现实又带有些许幽默的审视。谈及对未来的期许时，Ankit Goyal 直言自己虽然无法精准预测未来的全貌，但由衷希望自己能“少忙一点”（less busy）。自从引入 AI 智能体（Agent）之后，现实情况却有些反直觉——开发者的工作量反而比过去更多了。Ankit 分享了自己当下的日常状态：哪怕到了深夜，自己也会忍不住去查看手机或控制台，反复确认“我的智能体是否还在正常推进任务、有没有卡住”。他希望未来的智能体能够进化得足够稳健（robust），实现真正的自主运行，而不再需要人类工程师时刻保持警惕、充当“全天候保姆”。 当被问及“软件开发目前是否仍是一个安全的职业选择”时，嘉宾给出了非常坚定的肯定回答（"I think so"）。尽管工具形态在巨变，开发者的核心价值与需求依然坚挺，只是工作重心正在经历深刻的重构。 - **工作负荷的现实反差**：虽然 AI 智能体旨在提升效率，但由于当前系统仍需人类频繁监督，开发者常常在夜间还要跟进任务进度，导致心理负担和实际工作量上升。 - **对未来智能体的诉求**：期待智能体具备更强的鲁棒性与自主执行能力，使工程师能真正从细碎的任务监管中解脱出来。 --- ### [41:16](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2476s) 软件工程师与产品经理的融合：“代码低语者”的诞生与圆桌闭幕 随着与智能体协作模式的常态化，软件研发的角色边界正迎来剧烈洗牌。嘉宾指出，未来几年内，“软件工程师”（Software Engineer）与“产品经理 / 产品负责人”（Product Manager / Product Owner）这两个曾经分工明确的岗位将会逐渐融为一体。未来可能会诞生一个全新的职业头衔——例如现场讨论中提到的“代码低语者”（Code Whisperer）。这类新型人才兼具敏锐的产品业务洞察力与强大的技术工具驾驭能力，能够直接通过技术手段将自己的产品构想转化为现实落地。 ```mermaid flowchart LR accTitle: 传统研发角色向新型融合角色的演进 subgraph Past["传统分工模式"] A["产品经理 / PO<br/>(业务构想 & 需求定义)"] B["软件工程师<br/>(编码实现 & 技术落地)"] end subgraph Future["未来融合形态"] C["代码低语者 (Code Whisperer)<br/>• 兼具深厚产品洞察<br/>• 驾驭 AI 智能体与工具链<br/>• 端到端独立交付愿景"] end A --> C B --> C ``` 嘉宾进一步用科技史的演进做类比：在历史上，“计算员”（Computer）曾是一个具体的人类职业头衔，随后“程序员”（Programmer）也曾是一个高度专业化的专属岗位；而在不远的将来，“编写程序”将演变为一种基础能力，大多数人无需刻意学习底层细节就能自然而然地完成编程。 在讨论尾声，主持人 Ron Schmelzer 宣布研讨时间已到，对现场观众的积极参与以及四位嘉宾——Nick Patterson（Moderne 解决方案工程主管）、Justin Johnson（Renaissance Benefits 人工智能与工程副总裁）、Ankit Goyal（LinkedIn AI 平台首席主任软件工程师）与 Byron Ellis（LinkedIn 大数据平台基础设施首席主任软件工程师）的深度分享致以谢意，鼓励大家在会后继续保持交流与探索，圆满结束了本次圆桌对话。 - **角色界限消融**：产品经理的需求规划能力与工程师的技术执行力将在 AI 赋能下深度统一，工程师不再只是被动接需求的“实现者”。 - **历史周期的规律**：正如“Computer”由人工计算岗位演变为通用设备一样，“编程”也将从专用工种演变为人人皆可信手拈来的通用技能。 ## Notable quotes > [03:37](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=217s) 不要直接让 AI 智能体去一步步执行任务，而是让 AI 编写可复用的脚本或程序，后续直接运行脚本完成任务。 — Nick Patterson > [06:17](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=377s) 相当于每位工程师变成了 1.25 个人，虽然不知道多出来那四分之一算身体哪个部位，但绝不是我想要的会干活的手。 — Justin Johnson > [08:38](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=518s) 把一个人突然空降到一个从未见过的遗留代码库中并强行要求他上岗值班，极其折磨且不可持续。 — Byron Ellis > [17:46](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1066s) 我不太理解这里的实现，请为我编写一份分步教程，拆解重建该逻辑的核心步骤与思路。 > [20:04](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1204s) 如果团队只是生成了大量 PR 却无法顺利合并，那并不是在购买生产力，而是在购买噪声（buying noise）。 > [28:44](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1724s) 写代码本身就是程序员被训练出来的思考方式。 — Byron Ellis > [30:43](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=1843s) 软件工程是唯一一个自认为可以不通过原型测试就直接造出完美产品的工程学科。0 到 1 阶段写出的代码注定是不完美的，甚至就应该是一团糟。 > [35:50](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2150s) 你们不再是特殊的了（You're not special anymore）。 > [40:50](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2450s) 哪怕到了深夜，自己也会忍不住去查看手机或控制台，反复确认我的智能体是否还在正常推进任务、有没有卡住。 — Ankit Goyal > [41:16](https://www.youtube.com/watch?v=kD9tcO6mz9g&t=2476s) 编写程序将演变为一种基础能力，大多数人无需刻意学习底层细节就能自然而然地完成编程。 ## Mentioned Ron Schmelzer, Forbes, Byron Ellis, Justin Johnson, Renaissance Benefits, Overclock Accelerator, Ankit Goyal, LinkedIn, Nick Patterson, Moderne, Claude, Java, PyTorch, TensorFlow, Bender, Dr. Bunsen Honeydew, Animal, Hacker News, Okta, GitHub, GitHub Actions, Google, Beyond Zero, OpenAI ## Video description Justin Johnson - VP of AI & Engineering, Renaissance Benefits Byron Ellis - Principal Staff Software Engineer, Big Data Pipelines & Platform Infrastructure, LinkedIn Corporation Ankit Goyal - Principal Staff Software Engineer, AI Platform, LinkedIn Ron Schmelzer - AI Columnist / Host, Forbes / Scalebrate Nick Patterson - Head of Solutions Engineering, Moderne The way we write software is changing—fast. This panel brings together engineers and AI experts who understand AI powered coding to discuss how they are using AI daily to boost productivity, reduce bugs, and streamline release cycles. We’ll look at how teams are leveraging tools and code agents to shift from manual development to AI-assisted workflows. Expect honest discussion about what works, what doesn’t, and what the future of software development looks like when the machine writes with you. [Source](https://www.youtube.com/watch?v=kD9tcO6mz9g)

[3:37] Nick Patterson: 不要直接让 AI 智能体去一步步执行任务，而是让 AI 编写可复用的脚本或程序，后续直接运行脚本完成任务。 [6:17] Justin Johnson: 相当于每位工程师变成了 1.25 个人，虽然不知道多出来那四分之一算身体哪个部位，但绝不是我想要的会干活的手。 [8:38] Byron Ellis: 把一个人突然空降到一个从未见过的遗留代码库中并强行要求他上岗值班，极其折磨且不可持续。 [17:46] 我不太理解这里的实现，请为我编写一份分步教程，拆解重建该逻辑的核心步骤与思路。 [20:04] 如果团队只是生成了大量 PR 却无法顺利合并，那并不是在购买生产力，而是在购买噪声（buying noise）。 [28:44] Byron Ellis: 写代码本身就是程序员被训练出来的思考方式。 [30:43] 软件工程是唯一一个自认为可以不通过原型测试就直接造出完美产品的工程学科。0 到 1 阶段写出的代码注定是不完美的，甚至就应该是一团糟。 [35:50] 你们不再是特殊的了（You're not special anymore）。 [40:50] Ankit Goyal: 哪怕到了深夜，自己也会忍不住去查看手机或控制台，反复确认我的智能体是否还在正常推进任务、有没有卡住。 [41:16] 编写程序将演变为一种基础能力，大多数人无需刻意学习底层细节就能自然而然地完成编程。

[4:04] Nick Patterson: conjugating, ruminating, and spelunking [7:41] Justin Johnson: one and a quarter [7:41] Byron Ellis: you build it, you run it [20:04] Justin Johnson: comment essay [20:04] Justin Johnson: buying noise [22:48] Byron Ellis: before you can blink [22:48] Byron Ellis: expensive as hell [35:50] I tell engineers like, you're not special anymore, right? For the longest time, we were this special breed and we were the only ones that knew how to do this thing... Now everyone can do it. [35:50] walled garden [39:49] Nick Patterson: agent factories [41:18] code whisperers

[0:04] Well, uh, welcome everybody. Thank you so much  for being here. We have a fantastic panel. We [0:09] have some great, um, folks who are going  to share their insights. AI as your best [0:13] best programming buddy. Uh, I'm going to,  uh, have them come on stage. We're going [0:17] to introduce them and then we're going to have  them introduce themselves. But this whole thing [0:21] is for you. So even though sometimes we share  questions at the end, if you have a question, [0:26] just like let's get your hands up right away.  And we're going to before you forget what the [0:30] topic is before what we do uh we'll make sure you  ask the question so that we can make it happen. So [0:35] uh as mentioned uh this is AI as a pair  programmer. I'm Ron Schmemellzer AI columnist [0:39] at Forbes. I've been writing at Forbes since 2018.  I've been covering AI yes since 1995. It's pretty [0:45] crazy. Uh but AI goes back to the 1950s as we  all know. So without further ado, I have our [0:50] panel. Nick Patterson who's head of solutions at  Madern, Justin Johnson, VP of AI and engineering [0:56] and renaissance benefits and our two fabulous  folks from LinkedIn, Byron Ellis, principal [1:00] staff software engineer and An Goyal. Welcome to  the stage. Well, let's before I introduce them, [1:07] I'm just going to have them introduce themselves.  Let's start with Byron. tell us the big answer to [1:12] this question which is give us an introduction  to yourself and what AI priority is top of your [1:18] engineering to-do list today. Uh so hi I'm Byron.  I'm a uh principal staff engineer at LinkedIn. I [1:26] work primarily on data infrastructure products.  Uh and my current top priority is actually how [1:33] to use AI to make our infrastructure monitoring  and on call situation uh much more manageable [1:40] than it is today. Great. So I'm Justin Johnson.  I'm VP of AI and architecture at Renaissance [1:47] Health and Benefits and I also work at Overclock  Accelerator as an instructor for AI engineering [1:53] and AI operations. And my biggest thing right  now is a citizen developer program. So allowing [2:01] non-technical folks to go wild with AI and build  whatever they want and then I have to support it. [2:09] Oh uh among I'm a principal engineer at LinkedIn  in AI platforms team. We work on model training. [2:15] Our primary AI priority is making uh model  training more efficient and building an agentic [2:21] platform that sort of allows us to take more shots  at the goal. Uh more shots at the goal we take, we [2:27] make our models better and thus improve the member  experience. Nick Patterson uh I lead solution [2:33] engineering at Madern. Um so that includes for  deployed engineering, platform engineering, [2:38] customer success. Madern is the Asian tools  company. So we are building software for agents, [2:44] not just developers anymore since the agents are  doing a lot of the work. Uh so we're trying to [2:48] make agents more proficient, more deterministic,  more cost- effective with tokens um and being able [2:54] to to provide developers the tools they need  to be able to do really complex uh tasks with [2:59] their AI. Great. Well, let's do a little pulse  of the room here. How many of you would consider [3:03] yourselves to be developers? Okay. Yeah, like  that's all the hands. How many of you would not [3:09] have considered yourself to be a developer?  maybe a year ago. Okay. All right. Okay. So, [3:14] it's getting there. People getting getting into  the developer vibes. No pun intended. So, let's [3:20] actually start a little bit about that. Actually,  one more question for all of you. How many of you [3:23] are using like AI daily as like your coding?  Okay. Yeah, that's all that's that's even more [3:29] hands on the first question. I don't even know  how that worked out. It's like an AI conference [3:32] or something. [laughter] Okay. So, we're all  using AI all day all day for everything. So, [3:37] let let's start here with uh with you, Nick. Uh  let's go sort of backwards here. Talk a little [3:42] bit about productivity because that's supposedly  why we're using AI to make us better, faster, [3:48] and so we all hear about the productivity gains.  We're probably all experiencing them to some [3:52] extent. Uh so can you talk a little bit about what  you're actually seeing with your teams in terms of [3:58] productivity and maybe just some rabbit holes that  we that people may not experience when they're [4:04] working perhaps in a larger team. Yeah, Cody.  Yeah, it's interesting. Over the last 20 years, [4:09] you know, a lot of our companies or clients have  had mountains of technical debt um that they've [4:14] not been able to remediate. When AI came around,  that was the aha moment of like we can use AI to [4:19] go knock all of this, you know, technical debt,  old legacy stuff. We can up upgrade frameworks, [4:25] we can upgra up upgrade languages. What  we found is when we go and ask Claude to [4:29] go like update this Java app from 8 Java 8 to  Java 25, right? cloud would go off and it try [4:35] it was like conjugating and like ruminating and  spelunking and like thinks about it. It comes back [4:42] after like 10 minutes and you're looking at the  changes and it really only changed like the text [4:47] from version 8 to version 25 and a couple bots are  like claw that's not really what I meant to do. So [4:54] he'll pro it a little bit more and goes back off  spelunking and it goes thinking and ruminating. [4:59] 50 60 minutes later it comes back after we keep  on proddding and what what you've realized is it [5:04] really didn't get the task done at all. And so we  actually did a study on this and uh in that exact [5:11] same circumstance in that same scenario, that  same prompt, you know, it took 60 minutes uh [5:16] spent 60 million tokens and then when you looked  at what the the task was actually accomplished, [5:21] it got like 25% of the way there. And so we took  it upon ourselves to really build tooling to make [5:28] uh these types of tasks more deterministic.  And so we've got uh what we call recipes uh at [5:34] Madern. just a massive uh catalog of marketplace.  These deterministic programs that can actually [5:40] uh compose together to to do these really complex  tasks and do it in a deterministic way instead of [5:45] probabilistically like a lot of the AI is is  behaving today. And so now we the the AI can [5:51] reach to those tools and accomplish that task  30,000 tokens instead of 60 million tokens. [5:57] It gets 100% of the way done um in you know a  fraction of the time. So that's kind of worked. [6:02] So a little tip here is instead of asking  Claude or the agents to accomplish a task, [6:08] you ask them to build a script or a program to  to do that task and then next time just execute [6:13] the script to to basically do it. Seems like a  pattern. I think we're all starting to figure [6:17] out okay go an yeah so like our we are in AI  infrastructure team. So we have like lot of you [6:24] know changes to the infrastructure that we're  making and I think one of the examples is like [6:28] we are trying to migrate all our 400 plus models  from like tensflow to pytor. I think without sort [6:34] of agents it would have taken like multiple years  for us to like get the same level of performance [6:39] that our production models are giving us. So like  so we have built like multiple agents for like [6:44] model generation that can convert these models get  like the same sort of performance in production. [6:50] uh like the the models in production have been  hand tuned like by engineers over the years. So [6:56] um so we we're observing like lot of perform  like productivity gains in that sense like we [7:00] have you know performance optimization agents  that are continuously looking at our cluster [7:05] for low utilization jobs you know those models  automatically trigger they optimize the models [7:11] and create like a pull request for our engineers  to review. we have like lot of such use cases. [7:17] Uh but at the same time you know agents are not  good at longunning tasks. So we have we are like [7:23] uh improve improving the way we write this models  like we have sort of built our own harnesses so [7:29] that agents don't deviate from from the path  but yeah I think we are seeing like tremendous [7:34] gains and like uh you've removed like sort of  the friction from like our engineers. That's [7:41] good. So I'm curious at Renaissance what you're  seeing there. Yeah. So we're seeing I would say [7:46] about 25% more from a productivity perspective.  So each engineer is about one and a quarter now. [7:52] I don't know what a quarter of an engineer  is. I guess that's like knee down. I don't [7:56] know. [laughter] But what we're seeing is not  the quarter I would have picked, but All right. [7:59] Yeah. Yeah. Yeah. I'd want the one with the  hands, right? But the interesting thing that [8:04] we're seeing there is that while the engineering  process has has evolved and it's gotten faster, [8:09] the the release cycle and and how quickly stuff  is hitting, you know, production is a little bit [8:14] slower because those systems that have existed for  decades haven't updated as fast as the engineering [8:21] team has with their processes. And so we actually  got to a level of engineering productivity very [8:27] quickly, but now we have to readapt all of our  QA, our product processes and and our deployment [8:33] pipelines. We have to get those up to speed so  that we can be rapid in our deployments. Sounds [8:38] good. I think that's a good tea up for you, Byron.  Yeah, I mean so is my customer. Uh, and as you've [8:46] seen, he can now work a lot faster uh and put  more and more stuff onto my systems. Um and you [8:53] know for this is I think true of all software  engineering but data in particular right has [8:59] challenges historically with testing and things  like that and actually operations because a lot [9:06] of the time um you know if you can generate the  appropriate unit test you don't actually need the [9:11] unit test anymore because you know so much about  what you're trying to do that that you solve the [9:15] problem right it's one of those convent arguments  it's like if I knew that I wouldn't have to [9:19] uh I wouldn't have to test in the first place uh  and So like a lot of our bottleneck like yes code [9:23] generation has got a lot faster you know we can do  things like upgrade our backend systems much much [9:29] more quickly than before right we run a lot of  open source software we can patch it we can bring [9:33] it up uh and then it hits an operational wall  right either you know there's still code review [9:40] that happens but even if you leave that aside  right you now have a lot of code out there that [9:44] you didn't write uh and that no one wrote right a  robot wrote it uh I I give my robots's name so at [9:50] least I have a name for the robot that wrote it.  But um but nobody wrote it. And you know, like [9:55] for the last 25 years or so, we've kind of been in  this model of DevOps, right? Like if you wrote it, [10:00] you maintain it. Well, who maintains it now?  Obviously, that has to be the robots. Uh right, [10:04] a person maintaining AI code is going to  have a bad time. It's just like, you know, [10:09] getting air dropped into some legacy codebase  you've never seen before and then put on call. We [10:13] don't do that to people. Uh so like automating  that process is probably not a good idea. [10:18] Uh and so our main challenge is actually how do  we start to integrate things into the operational [10:24] side of things. So you know if there are systems  that are failing uh for whatever reason you know [10:30] we want to be able to automatically uh respond  to that and I think that's actually where where [10:34] most of the value for us is going to come. It's  less so on the code generation side. We actually [10:38] don't have to write that much code. Um, and we do  have to do like kind of operational upgrade stuff, [10:43] but our day-to-day is really, you know, one of  the thousands, hundreds of thousands of cores [10:49] out there is having trouble. Go find it. Go figure  out why it's having trouble. Go fix it. Automating [10:54] that process is really where we're spending a lot  of time and seeing the most value. So, of course, [10:57] I'm going to be curious about these agent names.  Uh, what are you calling your agents? Uh, they [11:01] actually pick their own. Uh, so I have uh there's  a huge list of names which I have never seen [11:07] um that they that they choose from. I kind of gave  them guidelines. So like the Muppets are in there. [11:12] Various CDs cartoons are in there. So you know, uh  I have an agent who's in charge of like optimizing [11:18] the props for all the other agents, right? Kind  of one of those loopy things. It chose the name [11:22] Bender for itself, which was perfect and is  now hardcoded. Um but yeah, so there's there [11:28] I have at any given moment probably 45 agents. So  they have So I guess animal is your key. Animal [11:33] is definitely there. Uh is just going Dr. Bunson  Honeydew is in the research section. Yeah. So, um, [11:40] actually, let's pull it this backwardly because  one of the things you're enabling are citizen [11:44] developers. Like this whole, you know, no code  dream, which is that people who don't know how [11:48] to develop can build stuff. Is that making your  life easier or harder? Uh, well, I'm a citizen [11:53] developer. I do not have a software engineering  background. Uh, I'm a statistician by training. [11:58] Oh. Uh, and I'm almost entirely self-taught. So, I  think this is great. Uh, I think everybody should [12:04] come play in the pool with me. Um, you know, it  reminds me of like when I was growing up, my dad [12:09] is a dentist. He wrote his own dental management  practice software. You can't do that anymore, [12:13] but now you can all of a sudden it's amazing.  Uh, so I think it makes uh it is definitely a [12:18] good thing. Um, will there be challenges along the  way? Yeah, of course, because we've kind of built [12:23] up this like professional software engineering  edifice over the last 30 years uh that, you know, [12:28] maybe we're just going to have to have some uh  some soularching uh to let other folks in. But I [12:35] think ultimately it's gonna be a good thing. Any  any thoughts? Yeah, Justin, good good tea up for [12:40] you because you're looking at the gains. So, I  mean, when it comes to challenges, I I think one [12:45] of my favorite ones is is I had a guy a couple  weeks ago, he he got a hold of Fable and he went [12:50] wild and that bill had to be paid. And so, I had  to answer a lot of questions on that. But when you [12:57] get into it, if you don't sit down with the folks  that want to be, you know, citizen developers, [13:03] for lack of a better term, we'll call it that.  If you don't sit down with them upfront and say, [13:07] "These are the tools that you have available.  This is how you should talk to it. This is [13:11] maybe what you should consider. This is how  you can, you know, like like Nick was saying [13:16] about how you have it write a script that can do  something for you or have it write a plan for you. [13:21] If you don't give this basic overview with folks,  it can get derailed really, really quickly. And [13:27] so I think a, you know, I'm going to air quote the  word training, but I think more of a conversation [13:32] just with somebody about how to use it is going  to pay off in dividends as you go through the [13:37] process. You know, I just add that the role of  the developer is really shifted from writing [13:43] code to to judging code, right? and being able to  like look at a a bit of code and and be able to [13:48] say yes, that's correct or that's the right way  to approach things. [clears throat] And the way [13:54] we've established that muscle is by writing lots  and lots and lots and lots of code over the years, [14:00] but now that's mostly gone, right? And so I think  there's going to be kind of an inflection point [14:04] in the industry where there's going to be a  gap where junior junior developers are coming [14:09] online and they don't have that background. They  don't have the experience writing that code. So, [14:13] we're going to have to be really purposeful in  how we train them to judge code accurately and [14:19] to and there's going to be like a really like,  you know, apprenticeship and coaching and a [14:24] lot of work that goes into not just learning the  syntax and learning, you know, what what good code [14:29] looks like, but just really like fundamentally  understanding the tools that you're talking about, [14:33] how they're generated, how they're used, what  the output is, so that we can accurately say yes, [14:37] this is good to go or no, it's not. Yeah.  So, I think um we are like infrastructure. [14:42] So we have like lot of users who have who don't  have like coding background they have like more [14:46] of a science background and in the past like we  used to have like lot of on call or like you know [14:52] people trying to figure out how to write training  pipelines or they trying to figure out like how to [14:56] use the infrastructure and we spent a lot of time  in like simplifying the way people could author [15:02] code. I think that has simplified like people who  didn't have a coding background now they are very [15:07] easily able to like you know get their things to  production. So like overall I think there's a lot [15:12] of positive effect we are seeing uh from everyone  you know coding not being the bottleneck for a lot [15:17] of people who had like good ideas. You guys want  to jump into that? Yeah. Yeah. I mean so I have a [15:24] uh I maybe challenge the idea of the the training  aspect a little bit because I think uh you know [15:30] it's intern season so I'm spending a lot of time  talking with interns as well. Um, and one of the [15:36] things I think that is a danger of kind of coming  at it from from where where we all sit, right, [15:42] where we all learned how to I mean I learned to  program to cheat at video games, right? Um, right, [15:47] you know, but we all like practice a lot over the  years, but I think like the way folks who are just [15:52] entering the industry now, they're going to access  the idea of programming very differently than us, [15:58] right? Because for them, you know, the the  programming language is the model, right? like [16:03] they don't they don't want to care about Java.  They don't want to care about Python. I used to uh [16:08] teach high school kids uh in an afterchool program  uh Python. And honestly like the Python part of [16:15] Python they actually got pretty well right like  the the structure the algorithm like kind of how [16:20] the program should flow that was always fine. the  thing they got wrong was the name of the function, [16:26] right? And how nice would it be if you know  because they would write down the name of function [16:32] that has an obvious name. You're like, "Yeah,  that function should probably exist." Uh like like [16:37] that's a great name for that function because it  it very it it explains what that function should [16:41] do better than what GTO decided, you know, in  1999. Uh and you're like now that can just exist. [16:48] And so like the way they think about coding might  be very different than the way we think about it. [16:53] uh and trying to lock things into kind of how we  learned is is you know we're that's maybe not like [17:01] going to be the most effective strategy uh for  a lot of folks who didn't come at it from the [17:05] beginning. Yeah. And and I think what we're all  hitting on too is is the the concept of being a [17:11] junior engineer is not the same as it was you  know 3 four years ago right a year ago. Yeah. [17:17] Five minutes ago. So you're going to see like  personally I see more focus kind of to your [17:23] point on like junior engineers should be coming  up thinking more about system architecture and [17:28] how do things connect and how do things talk to  each other because who cares what language it's [17:32] in? Who cares what code it's in? I'm just going to  ask AI to write it for me. But if I understand a [17:36] system and how everything connects, that makes  me as a junior engineer more valuable than one [17:42] beside me that may not have that knowledge. Yeah,  that's actually a really good interesting point. [17:47] Does anybody here in this room read Hacker News,  HN News, Y Combinator? So, a few people. Well, [17:51] there was like a top trending article that goes  yesterday or maybe even today. I can't even I [17:56] don't even know what day it is. Um where people  were talking about one of the best things to do [18:00] with LLM is to have it write the code and then try  to rewrite the code yourself as a way of learning. [18:05] And then there's this vigorous debate like what  are you talking about here? That's like you're [18:08] going to get no gains at all if you do that. But  then people are saying, well, but then you're not [18:12] going to learn anything at all. What do you think  about this in terms of where we are with skills? [18:16] Um maybe I could see Justinia or you want to jump  in on that one? Yeah. Does that even make sense [18:21] to do it that way? I mean I mean on a personal  method I don't want to do it that way at all. [18:27] Like I I want to tell it to write the code  and then I just want it to go. But I mean I [18:30] think if if I'm looking at it from a learning  perspective, I would rather maybe have it, [18:36] let's say I had to write a big function that  did, you know, add three numbers together, [18:39] right? Give me that function. I would want to read  it and understand it, but then I would tell it, [18:45] I don't understand this. I want to learn this.  Write a tutorial for me that's step by step and [18:50] walk me through how I would rebuild this. Um,  so I I would maybe approach it that way. Uh, [18:55] but that again that's just me. So this a good  transition point here. Let's talk about gains [19:00] because one of the things we've been thinking  about is like how do you measure you're talking [19:03] about this 25% improvement. How are we measuring  productivity now? Is it in terms of it used to [19:09] be a long time ago lines of code? It used to be  functionality test like how how are we measuring [19:13] productivity? How do we know the gains are  happening? How do we balance the iteration time [19:18] the token cost all that all that sort of stuff and  what's a jump in on that one? Yeah. So I think um [19:24] mostly like for we started with lines of code as  well like the number of PRs but that's probably [19:29] like the worst metric you can choose right LLM  are really good at generating code. So um so [19:34] eventually you know everyone sort of realized that  this we had like an influx of PRs like you know [19:38] systems were going down because we could couldn't  handle the number of PRs people were creating and [19:44] eventually like so now you know we've shifted  our goal to like sort of tracking the you know [19:49] business impact we're getting. So in training like  it depends on how many models are actually getting [19:54] into production or how many number of experiments  you're able to run that are put in AB testing in [19:59] production because that's the real metric we we  are trying to chase not the number of PRs or the [20:04] amount of code you're writing. So the I think the  landscape of like productivity sort of shifting [20:09] towards your eventual goal and it it can vary  depending on the work you're trying to do. Yeah, [20:15] I'll just piggyback on that too just uh on the  the lines of code generated. It's hilarious [20:20] that we've we've started noticing in some of  these most recent models that the comments [20:24] that it would generate within these files are  like longer than the functions themselves, [20:30] right? And when we would push back on the model,  we would say, "What are you do? Why is this [20:35] comment 700 lines long?" And it would kind of get  defensive a little bit and started calling it the [20:40] com it the agent actually started calling it the  comment essay. And so it's like but you have to [20:47] remember like these models and these providers are  incentivized you know to for you to spend tokens [20:53] right so you have to be really kind of diligent  lines of code is definitely not something uh you [20:57] know you want to measure we've been looking  a lot clo more closely at essentially time to [21:01] value right so what's what's the duration from  ideiation to getting something into production [21:08] and you know number of PRs also doesn't really  work either really have to kind of look at [21:13] um the number of changes merged Right? That's kind  of the the actual the real the real baseline that [21:19] you want to look for because if you're if you're  just generating a bunch PRs and not merging those, [21:23] you're you're not buying productivity, you're just  buying noise. So that's really what you want to [21:27] work. Just a reminder for our audience, you have  a bunch of seats up here. If you want to fill in, [21:30] you can. And of course, if you have a burning  question, just raise your hand, Lawrence. Oh, [21:35] we got one right here already. You can come.  Yeah, we'll get a mic for you as well, just for [21:39] the recording. And but but here we go. Yeah. Yeah.  Uh so you say you said that um you're seeing about [21:49] one and a quarter uh increase in production for  developers. Is that just for developers or are you [21:56] uh I I think you mentioned that you you're seeing  certain bottlenecks with like QA and uh the the [22:02] approval process and things like that. If it  was just the developer, are you seeing actually [22:07] more than than just 1.25? That's that's a great  question. It's it's really cool that people ask me [22:13] a question. That's kind of awesome. [laughter]  Uh you know that metric was purely for the [22:19] engineering team themselves. Um so the QA team I  I do have QA engineers there that are writing code [22:26] as well. But that two separate metrics. You know  if I did like an aggregate there it'd probably be [22:31] like 1.1 or or you know a little bit lower just  because some of those other processes slow down. [22:37] But I'd say it's about one and a quarter just for  hands-on keyboard engineers. Let's actually Oh, [22:44] I got a couple of questions. Yes, there and there  and there. So, we got three questions. This is for [22:47] you guys. So, feel free. Let's go ahead. When it's  becoming obvious to have like more code generated [22:53] really fast. How do you guys work about guard  railing the model so it doesn't lose the context [23:00] but at the same time does not leak PII? Because  now a lot of systems they need the data to be fed [23:06] into the the the models to generate the right you  know the right architecture but at the same time [23:12] we need to worry about if it's leaking some of  this because cloud or any other uh frontier model [23:17] can save that data into their systems and then  generate uh some more insights. That wasn't one [23:22] of my panel questions. I might want to talk about  leaking data saving any you know it's it's a hard [23:26] problem. Um you know I think uh Ana and I probably  have that every day. uh but um you know I think [23:34] there are a few different approaches. So I think  for one and actually there was actually a paper [23:43] about this just the other day at ACM uh beyond  zero I think it's called is Google's nextG um [23:49] you really have to move away from a lot of the the  traditional kind of ways we organize security and [23:55] uh data management down to a uh per workload and  maybe a per data item level. Right? So you have [24:03] to be deciding and this is going to be expensive  as hell uh but you have to be deciding whether or [24:09] not a model should have access to a piece of data  almost on a rowby row column by column basis. Uh [24:15] and infrastructure has to change to allow that.  So like VPNs where or like like role level access [24:22] where you're just kind of like wandering around  inside of a system with free access to stuff. [24:25] Those days are gone. You got to be locking those  things down inside of a box. uh what that box [24:32] looks like is going to depend on your organization  and and essentially restricting it, right? You [24:37] can't trust anybody for anything. Um because  agents, you know, all of our trust systems right [24:43] now are really built around human time scale,  right? And your ability to mitigate a human actor, [24:48] but the agent moves so fast that they will have  that exfiltrated before you can blink. Um and so [24:55] you got to start moving that. The the Beyond Zero  paper is actually quite good. I was reading it on [24:59] the flight over. Um, and I think that's kind of  the right model. Um, and you know, I'm a Zooler, [25:04] so maybe I'm biased. Yeah. And you guys know about  the data retention policies with Claude. So if you [25:08] ever get this question like how is Claude doing  the feedback, you know that if you answer that, [25:12] you give them fiveyear retention on the whole  thread conversation session, right? If you don't [25:18] know that, you should read the terms of use. So if  you even just answer it or even just say cancel, [25:23] the that whole feedback is saved for 5 years. I  and I it always surprised me that companies are [25:29] not aware of that. But anyway, uh yes, we have a  cub question in the middle. Yeah, my my question [25:34] is um this citizens developers or vibe coders, are  you actually allowing them at work to develop and [25:44] deploy their workflows or is it for like more  personal projects? And my my second question is [25:53] um have you guys thought about a break even  point where the the gains that we're seeing from [26:00] uh these tools um are the cost the cost of these  um you know tools is is higher than using doing it [26:11] manually. Is there a break even point? Okay,  great. So I got two questions. First of all, [26:15] VI is all yolo all day at business work. Is  that how it works? Yeah. I just want to fire and [26:19] forget. No. What what we do there with that is we  we have several tiers of what we call our citizen [26:24] developer. You know, like tier zero is I'm going  to build something that's just for me. I'm running [26:29] on my computer. It helps me in my day-to-day. Tier  one is maybe it's on my team. And then, you know, [26:34] tier two is, hey, we can share this with the  entire company. And so, we have different criteria [26:40] around those as far as deployment and management  of that. when it gets to tier two where it's got [26:45] a a public face even though it's an internal tool  you know that's where my team will step in and say [26:51] okay well now we have to follow you know everybody  loves octa so we have to follow octa as far as [26:56] a login mechanism there right it's got to be  deployed in our environment but citizen developer [27:01] you're not allowed to deploy you only go as far  as github right and then my team has written [27:07] some automations and some actions that are doing  security scans and and linting and static analysis [27:13] and all of that. And here's the fun part. We  haven't really figured out a good answer for [27:18] this yet. When it kicks it back and it says, "Hey,  there's something wrong with this code." Like, [27:23] who who fixes it? Right? Like, is it my team?  Is it the original person? Do I have an agent [27:28] that sits there and running runs in GitHub? You  know, that's one we're working on and trying to [27:32] figure out the right answer to that. I I don't  know that we've actually gotten there yet. Um, [27:37] but but we're throwing around some ideas for  that. Yeah. So Byron, I'm curious because is it [27:41] because you're a champion of citizen development,  same same idea. Is it just go for it? Uh so what [27:48] makes you think a normal developer doesn't have  those same problems, right? Like all the things [27:52] that we just described are standard practice and  you know you shouldn't skip standard practice, [27:58] right? They're they're there for good reason,  especially on the you know code check and things [28:01] like that. But once if you're if you don't trust  your standard practice for normal developers, [28:07] right? you obviously can't trust it for for anyone  else, but you shouldn't have trusted your normal [28:12] developer either. So, so you know, you either  trust or you don't and it doesn't really matter [28:17] who wrote the code at that point. Uh, and to  answer the question about who fixes the code when [28:21] it gets back, my agents get in fights with the  DevX agents all day long. Yeah, I have an entire [28:27] like sub persona for getting in fights with May,  which is our internal uh code review agent. Is it [28:32] Animal from the Muppets that gets into fights? Uh,  I mean it's whoever happened to write the code of [28:36] course you know we're we're firmly in a DevOps  kind of situation. [laughter] So great. I have [28:41] one question up here. Oh, one question back there  and one question up here. Yes, real quick. So, [28:44] uh, I'm a citizen developer. Uh, don't have a  software background. I'm a product manager and [28:51] um, I've been very grateful for, you know, the  ability to code with AI. uh specifically for [28:56] building project 0ero to one my approach has been  identifying the problem and knowing exactly how I [29:03] need to solve it and that's kind of helped me  with not knowing how to read the code because [29:08] essentially is it doing what I I need to do or is  it not doing what I need to do so I there's two [29:14] parts one I want you guys to kind of opine on the  gap between someone who does not have a background [29:20] in coding versus uh a a new graduate as a software  engineer And then two for people who are building [29:27] project 0 to1 not join legacy software uh how  would you approach ensuring that the software [29:34] is like a high quality essentially right good  question is are are citizen developers becoming [29:40] product managers is this is this what's happening  right now and they got a question go ahead who [29:45] wants to take that fabulous question I have so  many opinion uh about all of it um so I think you [29:55] What people don't realize or don't think about too  much is if you're trained as a as a programmer, [30:01] right? Not even a necessarily professional  software engineer. Those are two different [30:04] things. Um kind of like writing code is is how  we were trained to think, right? So so that I [30:11] have to write code to actually work through the  the problem that that I'm trying to solve, right? [30:17] Because that's just kind of how I grew up doing.  I've been doing it since I was seven. Um and and [30:22] that's why I think the way I do and that's why  I write code by hand still even a little bit is [30:27] because that's where where I do my product design  right I do that in terms of code and I think for [30:34] the nonbackground right you got to kind of put it  in the like context of of how you think and that's [30:43] what really these lens are letting you do right  like you can think as a product manager I was [30:47] actually on the product side for a while um and  think in those terms and code comes out the other [30:53] end, right? So you can you can now actually do  the thing that I that that I have to do with Java, [30:59] which is kind of a weird way of doing it when you  get right down to it. U so I think like that's [31:04] kind of the big difference between you know like  a new grad coming out of a CS program is they've [31:09] been trained to think through their problem in  that context whereas you haven't and so their [31:16] learning is maybe not as useful for you. Uh but if  you think about it like okay how would I sol like [31:21] how would I think about this in the way I've been  trained and now the LLM can help you basically [31:25] build a programming language from that to machine  code um is kind of the way to do it and you know [31:33] that's awesome right and uh there was a second  part to the question uh I think so and there [31:38] was a second part of the previous question too  about productivity gains and tokens and managing [31:43] the crossover but oh yeah I think there's a  second part to your question too we had two [31:46] two partners but anyway if you want John, we did  the one I forget the second part of. Right. Oh, [31:50] yeah. Zero to one. Right. Um, yeah, it's okay.  Zero to one. It's not supposed to be good. Uh, [31:56] right. Like software engineering is kind of weird.  It's the only engineering discipline that thinks [32:01] it can get away without building prototypes.  Uh, you know, you want to build a race car, [32:05] you got to go like blow up a couple engines on the  track before you can do it. Maybe many engines on [32:10] the track uh and crash a few times, right? Like  it's it's part of the process. And as you know, [32:16] as long as you iterate on that process and start  to go back uh and you know, treat it like a legacy [32:23] codebase, right? Like once you've done zero to  one, you're going to have this huge mess. Guess [32:26] what? That's every startup on the planet. Uh so go  back, have the agent go in, refactor it, organize [32:32] it, try to find patterns, right? Um and and treat  it as if you just got air dropped into a data into [32:38] a codebase you don't know. And you just do that  forever. That's that's software engineering, [32:43] right? to add to that like I think one of the  things LLMs are really good at is like teaching [32:47] you. I think they have sort of endless patience  like I'm I'm trying fields that I don't understand [32:53] and I'll go from explain it like I'm graduate  student explain it to me like I'm 10th grader or [32:58] like explain it to me like fifth grader you know  like I keep going down until I get the concept. So [33:03] I think even if like you don't have the background  like I think this is sort of the best time right [33:08] now to learn anything like you can take a photo  of a equation you don't understand and try to [33:13] break it down like as simple as possible. I think  even if like you don't have the background like I [33:19] I wouldn't worry too much as long as you're sort  of willing to you know put the time to learn the [33:24] fundamentals because once you scale like that's  when you start seeing problems like creating a [33:29] prototype is simple but I think beyond a certain  point you sort of that's when you sort of need to [33:34] understand the fundamentals and I think are a  great way to learn those. I like stepping down [33:40] the ELI level. I usually stop at EL. I explain  like I'm a toddler is how I stop because that's [33:45] when it gets a little weird. But yeah, go ahead.  Yeah, I was just going to do like like a 10-second [33:48] thing there. So, you asked the question of how  do you keep quality with your background and my [33:54] background? I bet if we sat down and defined  quality, we would probably have two different [33:59] answers. There would probably be some overlap  for sure. But I think when you ask the question [34:03] of how do I build something that hits quality,  define quality first. And again for you it may [34:09] be one thing for me something else but if you get  that definition down then you can work the problem [34:13] backwards. And then there was a question on  diminishing productivity gains and token costs. Is [34:18] anybody rethinking that or want to I haven't seen  it yet. I mean it's cheap enough right now that [34:25] that it's not been an issue. Um, I would like to  think that if it does become an issue, like if I'm [34:32] spending 100 grand a month on tokens, I'm making,  you know, 5 to 10 times that in revenue a month to [34:38] balance it out. But I I haven't seen anything to  the negative in that yet. I don't know if I can I [34:44] can add to that like so we we do like autonomous  agents which run for like days. I think we are [34:49] seeing the cost like curve there as well that it  might it's not sustainable. So we are evaluating [34:55] like you know custom small language models which  can do you know as good as frontier models if they [35:02] are trained for like uh you know that specific  task. Yeah. I'm just I'm just curious what [35:06] LinkedIn's monthly token bill is. Just curious. We  don't we're we're we're engineers. We don't know [35:13] what uh we know our personal we know our personal  like budgets and spend but we don't know what the [35:19] the Yeah. Also like we're on co-pilot so it's  I know it's Well, I keep forgetting link money [35:25] when I thought it doesn't really ever gro in my  head that way. But anyway, yeah, but but I think [35:29] like the the efficiency question is going to come  up. Uh right, because we all know that tokens are [35:34] currently VC subsidized, right? Uh and so that's  going to change. But like like said, like I do the [35:40] same thing even in my own practice, right? Like  that vendor one of vendor's jobs is to try to find [35:45] the cheaper model for a given operation at every  single moment. I think we're all doing that. Okay, [35:50] we got two questions in front here. You guys  are doing a good job because I have all these [35:52] questions but you guys are doing a fantastic job.  Yeah. Go ahead. So I'd really like to know what [35:57] you have found effective in helping engineers to  break out of the old paradigm that engineering is [36:03] this walled garden and to shift toward we're going  to have to adopt enablement activities as part of [36:10] our new job. Oh, okay. You go first. Oh, no. Yeah,  he's rubbing his hands on that one. So, push up [36:16] front right there. Yeah. Um, so I I think what I  what I like to tell engineers and and please those [36:22] of you who raised your hands, there's more of you  here than me, so I don't want to be like pummeled [36:26] after this. I I tell engineers like you're not  special anymore, right? For the longest time, [36:32] we we were this this special breed and we were the  only ones that knew how to do this thing, right? [36:39] That's changed. Now everyone can do it. And so  what we need to do as as far as an adaption there [36:45] is we need to become the ones that show, hey,  there's this new thing out here and I'm special [36:50] now because I know how to use it. I can help you  use it. I can make sure that when it's used, it is [36:56] used properly. Quality, you know, based upon your  definition, security, like I can make the system [37:02] architecture. I can make sure that all of that is  running well, but I don't necessarily have to be [37:07] the one that's typing in the secret language that  no one else can decrypt anymore. Okay, question [37:13] up front here and then I got one or two more for  you guys. Yeah, sure. So my question all about uh [37:18] enterprise data security perspective like you guys  are talking about there are so many vendors right [37:23] now trying to get access with open AI and creating  all the solutions. So in that perspective, [37:28] how should we pro process all this stuff in  terms of a security standpoint and how can we [37:34] basically secure those sensitive data? Yeah, you  guys probably got different perspectives, right? [37:40] Because you got internal models, external models  make Yeah. How how are you approaching that? Yeah, [37:45] I mean for super sensitive stuff you may have to  go to on like this is where LinkedIn's on-prem [37:50] nature right is something of an advantage because  we actually have that that ability to go to fully [37:55] on prim models or stuff that's very very sensitive  right I think the thing to keep in mind is if you [38:01] touch an LLM it's leave like you're xfiltrating  data right that data that whole session and some [38:08] stuff you can't see is leaving your machine going  to some other machine and coming back it's going [38:14] over a loop Now on the other side, like do I think  they're stealing data? No. Like they're they're [38:19] B2B businesses, right? Like if if they got out  that they were, you know, selling that data to [38:24] somebody else that they weren't allowed to, they  would cease to be businesses. Same way that like, [38:28] you know, Google and Gmail, right? Like they have  to you have to trust them with your mail. Uh but [38:34] in certain cir in certain sensitive use cases,  right, like you can't send it somewhere else, [38:39] right? Like there are models you will  not be able to use. Uh Fable for example, [38:43] right? because it keeps history can't use it. Uh  and so there you will have to use local models. [38:48] You will have to ensure that those workloads  only go to local models, right? And you have [38:53] to you're going to have to govern that at a not  like a a personal level, right? That's going to [38:58] be or orwide governance. That's why I was saying  earlier around like you have to be checking on [39:02] every single data point that comes in and deciding  whether or not that specific model, right, can [39:09] see that data and and having controls there. And  those controls should probably be deterministic, [39:14] not agentic, at least at first. Um, I think, you  know, you could have agentic optimization kind of [39:21] like auto mode and claude. Um, that can come in  later, but the core set of rules has to be fully [39:27] deterministic because you're going to have to  explain it to somebody someday. Yeah, we have take [39:30] on the data privacy explicit. All good. I'm only  got about two minutes here in the panel here. I [39:35] know we got a question here, but I'm going to ask  the one general question before we do the wrap-up, [39:39] unless it's a is it a quick question or maybe  not. Uh, okay. We we'll hold the we'll do them for [39:44] after I notice I'm seeing my clock here, so I only  got two minutes left. So, um, let's, if you can, [39:49] let's fast forward the future given kind of  where you are and where in your organization. [39:53] What do you think the day-to-day workflow will  look like for a software engineer, for developers [40:01] when maybe human AI potential kind of reaches  where you expect it to go? Maybe you can each [40:06] give a ticket. Yeah. Yeah. I think we focus a lot  on tech debt and app modernization efforts and all [40:14] the developer toil that we've kind of faced over  years and years and years. So we foresee a vision [40:19] where there are agent factories essentially of  agents continuously kind of you know alleviating [40:26] us from that toil and kind of doing the grunt work  a lot of the stuff that's been mundane and kind of [40:31] shoved under the rug for decades. Um and then kind  of keeping us evergreen from there. I think we'll [40:37] also have to kind of start to balance between uh  kind of the probabilistic nature of of agents and [40:43] AI versus like deterministic outcomes and being  able to kind of uh balance those two things to [40:50] to really achieve uh to to achieve our goals at  scale. Yeah. I think for me, I don't know what the [40:55] future looks like, but I hope I am less busy. Like  since the agent started, I feel like I'm doing a [41:00] lot more work than I used to. Like I'm at night  looking, oh, is my agent still making progress? [41:05] So I'm hoping like you know agents are robust  enough that you know they can work on their own [41:10] without yeah developer still a safe job choice. I  I think so. All right. Okay. I think well one I I [41:18] agree with Ankit. I think An just talking to our  agents and letting them do work. But I think the [41:24] role in of itself of of software engineer and  product owner, product manager, whatever you [41:29] want to call it, I think those two are going to  become one over over the next handful of years. [41:34] uh probably with a new title, you know. I I don't  know what that is. I'm not super creative. But I [41:39] think you have this this code whisperer. I like  that. You'll have code whisperers who are this [41:45] kind of mix of product knowledge and and skills,  but then they also have the technical tool set [41:52] available to them to execute their vision. And I  think that's where the world is kind of shifting [41:58] when you look at software engineer, right? I think  computer used to be a job title. Programmer also [42:05] will used to be a job title. Programming will be  a thing that most people do without even thinking [42:09] about it. Well, fantastic. We've hit time.  You guys have been amazing. Thank you all for [42:14] participating. Panel, you guys have been amazing.  Nick Patterson, Justin Johnson, Ana Goyel, [42:20] and Byron Ellis. You guys have been amazing.  Connect with them if you like and keep vibing.