Equal Experts Vays Says Manual Controls Block AI Engineering Gains
Ai4
Enterprise AI software delivery fails to accelerate production releases unless companies replace monthly review boards and staging delays with automated governance.
- [00:29](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=29s) Enterprise AI adoption often results in a "melted Furby" outcome—inconsistent results, runaway token costs, poor code quality, and poor visibility—because tools are bolted onto legacy workflows.
## Key takeaways
- [01:59](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=119s) To achieve AI-native engineering, organizations need a framework built on three pillars: Shared Context, Governance & Tooling, and Ways of Working, supported by an underlying AI Hub.
- [02:38](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=158s) The AI Hub acts as a central meta-repository and context glue that aggregates local context from service repositories and enterprise business artifacts into an intentional context cache.
- [03:24](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=204s) Using a pre-computed context layer in the AI Hub reduces token spend, increases output determinism, and avoids the runtime cost and unpredictability of parsing code graphs or scraping Confluence.
- [07:05](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=425s) Shared context should be structured as a tree-like hierarchy from organizational goals down to domain PRDs and individual service repository docs.
- [07:05](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=425s) Index loader files placed locally in repositories guide LLMs directly to relevant documentation without requiring runtime system discovery.
- [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) Governance assets, agent instructions, and developer skills should be treated as software products—versioned, tracked, and modified exclusively via pull requests.
- [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) To prevent instruction bloat, flattening scripts can combine multi-layered governance and repository rules into single prompts sent to LLMs.
- [12:08](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=728s) Teams must enforce a updated Definition of Done where work is only complete when it is both code-complete and context-complete, preventing context drift across the organization.
- [12:37](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=757s) Token usage should be optimized by applying frontier models to high-leverage design and specification tasks, while passing execution and basic linting to cheaper, lower-tier models.
- [14:26](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=866s) Accelerating code generation yields little value if delivery is blocked by downstream organizational bottlenecks like infrequent architecture review boards or rigid staging soak times.
## Detailed walkthrough
Here is a detailed, faithful walkthrough of the transcript.
[00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) Introduction and the "Melted Furby" Problem of Enterprise AI
Andy Vays, a Technical Principal at Equal Experts, opens his presentation by thanking the audience for attending right before lunch. He apologizes in advance to startups, noting that the topic focuses primarily on DevOps and platform engineering at enterprise scale, though the principles can be implemented using existing infrastructure and stacks. Equal Experts was founded in 2007, is employee-owned, and operates an "experts-only" model where 90% of its network of 3,600 people have over 10 years of experience across more than 200 clients.
Addressing the core problem, Vays explains that while AI is delivering on expectations, it often falls short of the ideal outcome. Organizations expect a perfectly crafted product—humorously pictured as a "beautiful Furby with all its fine contours, freshly baked and tasting absolutely wonderful"—but instead receive something that looks "half melted, maybe some bulging eyes." While it might "taste okay," it fails to fulfill expectations. Common enterprise symptoms of this gap include:
- Inconsistency across different engineering teams working in silos.
- Runaway token costs caused by inefficient model usage.
- Poor code quality and significant rework due to a lack of shared context.
- An overarching feeling that leadership and developers are "flying blind" without clear visibility into outcomes.
[01:59](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=119s) The Three Pillars and the AI Hub Concept
To bridge this gap, Vays introduces a framework grounded in three pillars resting on a foundation called the **AI Hub**:
```
+-------------------------------------------------------------+
| THREE PILLARS |
+-------------------+--------------------+--------------------+
| Shared Context | Governance/Tooling | Ways of Working |
| (Versioned MD) | (Agents, Workflows)| (Preventing Drift) |
+-------------------+--------------------+--------------------+
| AI HUB |
| (Central Meta-Repository & Context Glue) |
+-------------------------------------------------------------+
```
1. **Shared Context:** Versioned knowledge structured in human- and machine-readable Markdown files.
2. **Governance and Tooling:** Standardized agents, workflows, instructions, and scripts.
3. **Ways of Working:** Operational habits and team behaviors required to keep context updated.
The underlying **AI Hub** acts as a centralized "meta-repository" or glue that unifies all three pillars to enable AI-native engineering at scale. In practice, its physical architecture adapts to an organization's existing code setup. While a monorepo simplifies context management, enterprise clients often manage hundreds of repositories segmented across various technology groups and business domains. Rather than relying solely on Model Context Protocol (MCP) servers, Confluence scraping, or real-time code graph parsing—which can be non-deterministic and expensive—the AI Hub acts as an intentional, curated context cache. This structured approach reduces token spend, establishes consistency, and provides a centralized place for governance files, skills, and business artifacts like call transcripts or notes.
[04:31](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=271s) Architecture: Aggregating and Distributing Context
The AI Hub operates as a central aggregator and distributor connecting individual service repositories to downstream execution harnesses. Service repositories contain the actual code developers work on, alongside local Markdown files in a `/docs` or `/context` directory. These files define the repository's purpose, business requirements, module boundaries, and dependencies.
```
+-------------------------------+
| Interactions & Business Context|
| (Transcripts, PRDs, Ontology) |
+---------------+---------------+
|
v
+------------------+ +---------------+ +--------------------+
| Service Repo A |---->| |====>| Cloud / Local IDEs |
| (Local Context) | | AI HUB | | (Developer Tools) |
+------------------+ | (Central | +--------------------+
| Service Repo B |---->| Meta-Repo) |====>| Headless Agentic |
| (Local Context) | | | | Harnesses |
+------------------+ +---------------+ +--------------------+
```
When developers modify code in a service repository, automation rolls those contextual changes up into the central AI Hub. This creates a unified, cross-cutting view of the entire software landscape. Key architectural dynamics include:
- **Indexed On-Demand Loading:** Downstream execution environments (such as local IDE tools or headless agent harnesses) pull down only the relevant indexed context from the AI Hub rather than loading entire repositories into LLM context windows.
- **Business Context Ingestion:** Transcripts, Slack messages, and meeting notes are processed using a defined ontology and stored within the AI Hub, capturing risk flags and new requirements outside of source code.
- **Deterministic Runs:** Providing a clean, pre-computed context layer reduces runtime exploration, lowering token consumption and making model outputs more reliable.
[07:05](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=425s) Structuring Shared Context as a Tree
Shared context relies on intentional Markdown files designed for both human review and LLM ingestion. Instead of forcing an LLM to discover system relationships at runtime through expensive code graphs or external searches, teams place index loader files locally to point models directly to critical context.
Organized as a hierarchical tree, context flows down through distinct levels:
- **Organizational Level:** High-level details about company goals, customer personas, and global standards.
- **Domain or Theme Level:** Product requirement documents (PRDs), overarching business logic, and cross-cutting dependencies like serverless functions that do not belong to a single codebase.
- **Service Repository Level (Leaves):** Specific architecture notes, interface descriptions, and local repository indexes.
[08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) Governance, Tooling, and Version Control
For governance and tooling, Vays advocates for portability and treating configuration assets as first-class software products. Orgs can manage agent capabilities using open standards like `AGENTS.md`, IDE-integrated extensions, or Microsoft's Agent Package Manager (APM). Simple automation scripts can be used to flatten multi-layered instructions before sending a prompt to an LLM.
Key operational practices for governance include:
- **Version Control and Pull Requests:** All skill definitions, agent instructions, and prompts must be modified exclusively via pull requests to maintain auditability.
- **Change Tracking:** Maintaining versioning history (e.g., tracking changes from v1.0 to v3.0) allows teams to evaluate how instruction changes impact code quality over time.
- **Controlled Distribution:** While experimentation ("letting a thousand flowers bloom") is fine initially, scaling requires strict controls over who can publish and distribute agent rules across the enterprise.
[11:09](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=669s) Ways of Working and Token Optimization
The final pillar—ways of working—focuses on embedding context maintenance directly into the developer workflow. Across the delivery lifecycle, different roles utilize the AI Hub to streamline their work:
- **Product Managers & Architects:** Use web interfaces to ingest the AI Hub's meta-repository, gaining full visibility into the system landscape to draft PRDs and system designs that flow back into the Hub.
- **Developers & Engineers:** Build features in local service repos using spec-driven development or similar methodologies.
To maintain context accuracy and manage token costs across the pipeline, Vays emphasizes two main strategies:
- **Definition of Done:** A pull request or feature is not complete when it is merely *code-complete*; it must be both **code- and context-complete**. When code changes, developers must update the corresponding local Markdown context. The automated pipeline then syncs these context updates back to the AI Hub, preventing context drift.
- **Token Optimization Strategy:** Use expensive frontier models early in the lifecycle on high-leverage tasks like architecture and spec definition. Once the specification is clear, execution can be handed off to cheaper, lower-tier models. For audit and linting loops, use lower-cost models in initial runs to filter out noise before escalating complex edge cases to frontier models.
Vays concludes with a caution drawn from real-world client engagements: implementing the AI Hub, contextual Markdown files, and automated agent workflows does not guarantee faster software delivery if human governance bottlenecks remain unaddressed.
- **Case Study A (Architecture Review Board):** A client successfully adopted AI-native developer workflows, enabling teams to write code significantly faster. However, production release speeds remained unchanged because every major architectural change required approval from a governance board that met only once a month. Rejections forced teams back into a month-long wait loop.
- **Case Study B (Staging Environments):** A client in a highly regulated industry required all software changes to soak in a staging environment for two weeks before production release. Any regression triggered a complete reset of the two-week waiting period, neutralizing the speed gains achieved through AI tools.
Vays stresses that engineering leaders must look beyond developer productivity metrics and evaluate the delivery pipeline holistically from left to right. Without streamlining approval gates, compliance checks, and deployment policies, AI speedups in code generation will fail to translate into faster production outcomes for end users.
## Notable quotes
> [00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) beautiful Furby with all its fine contours, freshly baked and tasting absolutely wonderful — Andy Vays
> [00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) half melted, maybe some bulging eyes — Andy Vays
> [00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) flying blind — Andy Vays
> [01:59](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=119s) AI Hub — Andy Vays
> [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) letting a thousand flowers bloom — Andy Vays
> [11:09](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=669s) code- and context-complete — Andy Vays
## Mentioned
Andy Vays, Equal Experts, Furby, Model Context Protocol, MCP, Confluence, Slack, Agent Package Manager, APM, Microsoft
## Video description
Andy Vays - Technical Principal, Equal Experts
Most engineering orgs are AI-enabled, with tools bolted onto old workflows. Few are AI-native, with the infrastructure and workflows built for AI from the ground up. During this session, we'll share the AI Hub, a pattern we're building across enterprise clients, for the infrastructure and ways of working that make AI-native engineering possible at scale. This is the difference between adopting AI and being built for it.
Equal Experts 的 Vays 指出：人工管控阻碍 AI 工程提效
企业若不以自动化治理取代月度评审委员会和预发布延误，AI 软件交付便无法加快生产环境的发布速度。
企业直接在传统工作流中套用 AI 工具，常会导致结果不稳定、Token 成本失控及代码质量低下等问题。要实现 AI 原生工程化，企业需要构建以“共享上下文”、“治理与工具”和“工作方式”为三大支柱的框架，并由底层的 AI Hub 提供支持；通过将从组织目标到具体服务文档的树状层级上下文聚合为预计算缓存，不仅能降低 Token 消耗并提高输出确定性，还能避免解析代码图谱或抓取 Confluence 带来的运行时成本与不可预测性。
Equal Experts 技术负责人 Andy Vays 指出，企业若仅将 AI 工具生硬拼接至传统工作流，往往会导致如“融化的菲比小怪兽（melted Furby）”般的不良后果，面临 Token 成本失控、代码质量差和缺乏全局可见性等困境。 (0:04)
为此团队提出了 AI Hub 模式，作为连接共享上下文、治理与工具以及工作方式三大支柱的中心元代码库（meta-repository），通过预计算的结构化上下文缓存来替代高昂且不稳定的实时代码图谱解析。 (1:59)
共享上下文被设计为自组织目标、领域 PRD 到具体服务仓库文档的树状层级，且所有 Agent 指令、规则和技能均被视作正式软件资产，必须严格通过 Pull Request 进行版本追踪与分发控制。 (7:05)
为防止上下文漂移，团队提出“代码与上下文双重完备（code- and context-complete）”的完成定义，并结合架构设计用前沿模型、执行阶段用平价模型的成本优化策略，同时警示组织必须同步清理月度审批等交付瓶颈。 (11:09)
Reading summary
Andy Vays, Technical Principal at Equal Experts, argues that enterprise AI engineering frequently produces inconsistent, substandard software because organizations lack structured context and governance across fragmented repositories. To close this gap, Vays advocates organizing engineering around an "AI Hub" meta-repository supported by versioned documentation, disciplined workflows, and pipeline-wide bottleneck management.
The AI Hub and Hierarchical Shared Context (1:59)
Vays describes the common outcome of enterprise AI initiatives as a "melted Furby"—technically functional, but marred by team silos, runaway token costs, and substantial rework. Rather than depending on ad-hoc Confluence scraping, live Model Context Protocol (MCP) servers, or costly real-time code graph parsing, organizations can establish an AI Hub. This central meta-repository acts as an intentional context cache that links fragmented service repositories to downstream developer tools and automated agent harnesses.
Context is structured hierarchically as a tree using human- and machine-readable Markdown files. High-level organizational standards and customer personas sit at the root, descending into domain-level product requirement documents (PRDs) and cross-cutting business logic, before terminating at service-level leaf repositories containing local architecture notes. When code changes, automated pipelines roll local documentation up into the AI Hub. Downstream tools then pull indexed context on demand, yielding deterministic runs and preventing large codebases from overwhelming LLM context windows.
Treating Agent Tooling and Rules as Software Assets (8:58)
For governance and tooling, Vays recommends treating prompts, agent instructions, and skill definitions with the same rigor as production code. Instead of allowing undocumented runtime experimentation to spread unchecked across teams, organizations should standardize on portable formats such as AGENTS.md, IDE extensions, or Microsoft's Agent Package Manager (APM).
Under this model, all modifications to agent capabilities require formal pull requests, enabling teams to maintain audit trails and track how rule version updates correlate with code quality over time. Simple automation scripts can flatten multi-tiered organizational and service-level rules into unified prompts before submission to language models, ensuring that developers operate within centrally governed enterprise boundaries.
Context-Complete Workflows and Tiered Token Allocation (11:09)
Embedding context maintenance into everyday delivery requires redefining team habits. Vays emphasizes that a feature or pull request must be deemed "code- and context-complete" rather than merely code-complete. Requiring engineers to update accompanying local Markdown files whenever code changes ensures that documentation stays synchronized with the AI Hub and prevents context drift.
To balance performance against operational cost, teams should deploy models in tiered phases across the software development lifecycle. High-leverage, upstream tasks such as architectural design and PRD creation warrant the use of expensive frontier models. Once detailed specifications exist, execution and code generation can be assigned to lower-cost models. Similarly, initial linting and code auditing loops can use cheaper models to filter out routine issues, escalating only ambiguous edge cases to frontier systems.
Addressing Delivery Bottlenecks Beyond Code Generation (14:26)
Vays cautions that optimizing developer environments and adopting the AI Hub cannot deliver faster business value if organizational approval structures remain static. AI-assisted tooling accelerates code authoring, but enterprise delivery timelines are frequently dictated by external governance checkpoints.
Drawing on client engagements, Vays notes two recurring obstacles. In one case, developer velocity improvements failed to alter release cadence because an Architecture Review Board met only once per month, forcing any flagged architectural change into a four-week delay cycle. In another regulated environment, mandatory two-week staging soak periods reset completely whenever a regression occurred, neutralizing coding acceleration. Consequently, engineering leaders must analyze the entire delivery pipeline holistically rather than focusing solely on developer-level output metrics.
Vays concludes that achieving AI-native engineering at scale requires pairing structured, version-controlled context architectures with systemic operational reforms. Accelerating code generation yields little practical benefit if downstream deployment gates, compliance policies, and governance boards remain unchanged.
精炼阅读摘要
Equal Experts 技术主管 Andy Vays 指出，企业规模化应用 AI 往往因团队孤立、缺乏共享上下文和 Token 成本失控而导致产出不及预期；为此，企业需依托由共享上下文、治理工具链与新工作方式构成的三支柱，并以“AI Hub”元仓库为基础建立确定性架构，同时破除下游流程瓶颈，才能实现真正的端到端工程提速。
企业级AI落地的困境与三支柱模型 (0:04)
Vays 将许多企业当前的 AI 落地现状形象地比喻为“熔化了的菲比小精灵（Melted Furby）”：组织原本期望获得轮廓精致、产出极佳的理想产品，实际得到的却是带有缺陷、勉强可用却远落后于预期的半成品。在拥有 3,600 多名专家网络（其中 90% 拥有 10 年以上经验）的 Equal Experts 服务 200 余家客户的实践中，Vays 观察到企业级 AI 的典型病症包括：各工程团队自成孤岛导致产出不一致、模型低效调用造成 Token 成本飞涨、缺乏统一上下文引发代码质量低下与频繁返工，以及管理层和开发者普遍处于缺乏可见度的“盲飞”状态。
为弥合这一鸿沟，Vays 提出了以“AI Hub（AI枢纽）”为底座的三支柱工程框架：第一支柱是采用人类与机器均可读的 Markdown 文件形式存储并具备版本控制的“共享上下文”；第二支柱是标准化的 Agent、工作流、指令和脚本等“治理与工具链”；第三支柱则是用于持续更新上下文、防止逻辑偏离的“工作方式”。该体系旨在充分利用既有基础设施，将分散在企业不同技术栈中的工程能力系统化串联起来。
AI Hub元仓库与树状上下文架构 (4:31)
在系统架构层面，AI Hub 被定义为连接各个独立服务代码仓库与下游执行工具的中央聚合与分发元仓库（Meta-Repository）。Vays 指出，在维护数百个代码仓库的企业中，仅依靠模型上下文协议（MCP）服务、Confluence 抓取或实时代码依赖图解析，往往成本过高且输出极不稳定。AI Hub 则作为经过人工精选的高效上下文缓存层，不仅整合了各服务仓库 `/docs` 或 `/context` 目录下的业务需求与模块边界，还能通过特定本体定义自动摄取并提炼会议纪要、Slack 讨论等非代码形态的业务需求与风险信号。
在逻辑组织上，共享上下文被设计为层级分明的树状结构：顶层为涵盖公司战略与客户画像的组织级上下文；中层为产品需求文档（PRD）、核心业务逻辑以及跨服务依赖（如无服务器函数）的领域或主题级上下文；底层则是具体服务仓库的代码规范、接口描述及本地索引。下游的本地 IDE 或无头 Agent 执行环境不直接全量加载代码库，而是按需拉取经过索引的局部上下文切片，以预计算的确定性上下文大幅减少模型在运行时的盲目探索并降低 Token 消耗。
治理与工具链：配置资产化与受控分发 (8:58)
在治理与工具链维度，Vays 倡导将配置与提示词等资产视为一等公民的软件产品，采用如 `AGENTS.md` 开放标准、IDE 集成插件或微软的 Agent Package Manager (APM) 进行标准化管理。为了在向大语言模型发起请求时平铺多层级规则，工程团队可使用自动化脚本，将组织全局规则、具体服务仓库规则与开发者技能指令统一打平融合为最终提示词。
为了保障企业级落地的可追溯性与合规性，Vays 强调所有 Agent 指令、技能定义与提示词配置的修改必须严格经由 Pull Request 流程进行，杜绝无版本记录的随意更动。通过对配置变更进行版本追踪（例如追踪从 v1.0 到 v3.0 的演进），团队能够量化分析指令微调对生成代码质量的长效影响。此外，虽然在早期探索阶段可以鼓励自由尝试，但在规模化推广阶段，必须对全局性 Agent 规则的发布与分发实施严格权限控制，避免指令冲突引发混乱。
工作方式重塑：上下文完备与Token优化 (11:09)
工作方式的变革是确保架构长期有效运作的关键。在交付生命周期中，产品经理与架构师可通过 Web 界面接入 AI Hub 纵览全局系统，制定并回传 PRD 与架构设计；开发者则基于规范驱动开发在本地服务仓库编写功能。为彻底根除上下文漂移问题，Vays 主张重塑团队的“完成定义（Definition of Done）”：一项功能或代码提交不能仅仅满足“代码完成（code-complete）”，而必须达到“代码与上下文双完备（code- and context-complete）”，即开发者修改代码时必须同步更新本地 Markdown 文档，由自动化流水线反向同步至 AI Hub。
在成本管控上，Vays 提出了一种按交付阶段分层的 Token 优化策略：在研发上游的设计与规范阶段，集中使用高单价的前沿顶级模型，处理系统架构和技术规范等高杠杆任务；一旦规范确立，进入下游的实现阶段（如代码生成与辅助编写），则全面切换至低成本的轻量级模型。在后续的代码审查与静态检查循环中，同样优先使用低成本模型过滤基础噪声，仅在遭遇复杂边缘案例时才升级交由顶级模型裁决，以此实现经济高效的阶梯式调用。
交付瓶颈警示：破除人工治理的流程制约 (14:26)
Vays 结合真实客户案例警示道：即使全面部署了 AI Hub、结构化上下文与自动化 Agent 工作流，若不消除传统的人工治理卡点，整体交付周期依然无法缩短。在案例 A 中，某客户虽然依托 AI 原生流程显著提升了编写代码的速度，但由于所有重大架构变更必须等待每月仅召开一次的架构审查委员会审批，方案一旦被驳回便需重新等待一个月，导致最终生产上线周期毫无改善。
类似地，在面临强监管的案例 B 中，企业强制要求所有代码变更必须在预发环境中浸泡观察两周方可发布，且测试期间一旦出现任何缺陷，两周的等待周期便会全额重置，这彻底抵消了 AI 工具带来的编写效率收益。因此，Vays 强调工程管理者必须自左向右全链路审视软件交付流水线。如果企业的审批准入机制、合规审查机制和部署发布策略未能同步现代化，由 AI 带来的前端代码生成加速最终只会转化为排队等待中的无效工时，无法向终端用户释放实际价值。
Vays 总结认为，企业实现规模化 AI 原生工程的核心不仅在于技术架构的升级与 AI Hub 元仓库的上下文治理，更在于工程组织在流程管控与文化上的深层转变。单纯依赖生成式 AI 提升编码速度无法解决端到端交付的系统性瓶颈；企业必须将上下文维护内化为开发者的日常工作标准，并同步重构阻碍快速验证的繁冗审批与合规流程，方能真正释放 AI 在企业级研发中的生产力潜力。
Detailed notes — zh
## Background
本视频由 Ai4 频道于 2026 年 8 月 15 日在 YouTube 发布。内容记录了 Equal Experts 技术主管 Andy Vays 的主题演讲，主要探讨如何通过构建“AI Hub”元代码库模式，从基础设施与协作流程层面帮助大型企业实现真正规模化的 AI 原生（AI-Native）工程演进。
## TL;DR
Andy Vays 指出规模化落地 AI 的核心本质在于平台工程与持续交付，单点的代码生成加速若脱离全局交付流往往会导致治理失控与返工。为此，Equal Experts 提出了基于共享上下文、治理工具链与工作模式重塑三大支柱的“AI Hub”架构方案。该方案以版本化、人工精心策划的 Markdown 文件作为确定性上下文缓存，推行“代码与上下文双重完备”的交付新标准，并实施前沿模型重顶层设计、轻量模型重代码实现的优化策略。最终，AI Hub 不仅能打通研发生命周期，更能赋能市场、数据工程与企业高管，成为全组织的数字化知识中枢。
## Atmosphere & style
整场演讲风格务实接地气且充满行业洞察，讲者开场以“阻隔大家与午餐”的幽默自嘲快速拉近距离，并用五官移位的甜点生动隐喻当前 AI 工程交付的理想与现实落差。叙述逻辑环环相扣，既有对多层级上下文合成与 Token 成本优化的精细剖析，也有对企业月度架构评审和两周等待期等现实官僚卡点的尖锐反思。整体氛围褪去了盲目的技术狂热，透着资深工程专家回归持续交付本质与严谨工程纪律的沉着与清醒。
## Key takeaways
- [00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) 规模化应用 AI 本质上是一个 DevOps 和平台工程问题，企业无需推翻现有基础设施即可构建支持大规模工程协作的 AI 原生模式。
- [01:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=64s) 解决 AI 交付中 Token 成本失控与代码质量参差不齐等痛点，需要依托三大支柱：共享上下文、治理与工具链，以及重塑的工作模式。
- [02:43](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=163s) AI Hub 作为元代码库（Meta Repo），充当企业知识与上下文的聚合与分发中心，为各服务代码库和 LLM 运行框架提供确定性的全局视角。
- [07:05](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=425s) 在代码库中主动维护精心策划的 Markdown 上下文，相当于构建了确定性缓存，大幅降低了运行时探索带来的 Token 消耗与偏差。
- [07:05](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=425s) 共享上下文需采用层级化树状结构设计，从组织全局、业务领域到单一服务代码库实现清晰分层。
- [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) 治理与工具链应保持便携性，在触发 LLM 前通过合成引擎将组织基准规则、代码库规范与个人工作流进行扁平化打包。
- [11:09](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=669s) AI 原生时代需重新定义完工标准，明确“一个功能特性只有在代码与上下文双重完备时才算真正完成”。
- [11:09](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=669s) 在流水线中推行“左重右轻”的模型选型策略：需求与架构设计使用前沿主力模型，具体代码实现则降级为低成本模型以优化支出。
- [14:26](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=866s) 局部代码生成的加速若受制于月度评审或长观察期等组织流程断层，将无法转化为实际的业务价值交付。
- [15:42](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=942s) 持续交付（Continuous Delivery）是 AI 工程化落地的真正基石，只有建立安全可信的发布流水线，AI 的生产力才能全力释放。
- [16:21](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=981s) 中心化的 AI Hub 价值超越纯软件工程，能够作为权威上下文平台直接赋能市场营销、数据调研及企业高管决策。
## Detailed walkthrough
### [00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) 开启规模化 AI 原生工程演进
Equal Experts 的技术主管 Andy Vays 登台演讲，开门见山地向现场听众致谢，并幽默地提到自己是“大家和午餐之间唯一的阻碍”，希望能为大家带来切实干货。Andy 重点探讨了 Equal Experts 如何重构自身内部的工作流程，并协助众多企业客户改变软件交付方式。他直言，规模化应用 AI 本质上是一个 DevOps 和平台工程问题，企业完全可以在不推翻现有基础设施与技术栈的前提下，搭建起这套支持大规模工程协作的模式。
Equal Experts 成立于 2007 年，是一家员工持股的咨询服务公司，拥有 200 多家客户和由 3600 多名专业人士构成的网络。其业务核心在于“专家专属模式”，网络中 90% 以上的工程师都拥有 10 年以上的深厚经验。与市场上随处可见的传统外包或服务机构不同，Equal Experts 专注于为大型组织构建高可靠的工程实践。
---
### [01:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=64s) 理想与现实的落差：AI 落地的三大支柱与 AI Hub 概念
在当前的工程实践中，AI 的交付往往未达到预期。Andy 用生动的比喻指出，大家原本期望得到一只外形精致、刚出炉且口感绝佳的“菲比小宠”（Furby）甜点，实际得到的却往往是一个五官移位、半融化变形的半成品。团队在日常实践中常常被一系列典型症状困扰：团队间协作脱节且方式各异、Token 成本失控飙升、代码质量参差不齐、缺乏统一的全景认知、返工不断，最终陷入一种“两眼一抹黑（flying blind）”的被动状态。
为了打破这种困境，Equal Experts 提出了由三大核心支柱构建的解决方案：
1. **共享上下文（Shared Context）**：以 Markdown 文件形式进行版本化管理的知识体系。
2. **治理与工具链（Governance and Tooling）**：涵盖 Agent 规则、工作流编排等标准化规范。
3. **工作模式（Ways of Working）**：调整日常研发流程，确保业务上下文与技术状态时刻保持最新。
在这三大支柱之下，**AI Hub** 作为核心的元代码库（Meta Repository）充当黏合剂，将知识、规则与日常工作流紧密缝合在一起，为规模化 AI 原生工程奠定坚实底座。
---
### [02:43](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=163s) AI Hub 的架构逻辑与运作机制
AI Hub 充当着组织内部知识与上下文的“聚合器与分发器”。在许多拥有数百个分散代码库的企业客户中，核心痛点在于：如何构建统一的知识与上下文层，以便在运行时按需精准加载，驱动 LLM 完成任务。虽然通过模型上下文协议（MCP）直连外部 Confluence 或动态构建代码图谱（Code Graph）也是一种补充方案，但 Equal Experts 倡导在代码库中主动维护经过精心筛选的 Markdown 上下文。这种做法相当于为 LLM 工作流构建了一层确定性的缓存，不仅大幅降低了 Token 消耗，还显著减少了非确定性偏差。
```mermaid
flowchart TD
accTitle: AI Hub Architecture and Workflow
accDescr: Diagram showing how service repositories and business artifacts aggregate into AI Hub and distribute down to LLM harnesses.
subgraph Sources["上游：业务输入与服务代码库"]
A["业务交互与产物<br/>(会议纪要/Slack/邮件/PRD)"]
S1["服务代码库 1<br/>(docs/context/*.md)"]
S2["服务代码库 N<br/>(docs/context/*.md)"]
end
subgraph Hub["核心：AI Hub (元代码库)"]
H["AI Hub 知识聚合与分发中心<br/>• 组织与域级别上下文<br/>• 全局索引与路由<br/>• 集中化 Skills 与治理策略"]
end
subgraph Consumers["下游：执行与消费端"]
C1["本地开发者工具<br/>(Claude Code / IDE)"]
C2["无头 Agent 运行环境<br/>(Headless Harness)"]
end
A -->|"提炼归纳"| H
S1 -->|"自动化汇总同步"| H
S2 -->|"自动化汇总同步"| H
H -->|"按需加载上下文与 Skills"| C1
H -->|"按需加载上下文与 Skills"| C2
```
在日常运作中，开发者工作在各自的具体服务代码库（Service Repos）中，每个代码库都在专属目录中维护轻量级的索引描述文件，阐明该服务的功能、业务需求、模块构成与外部依赖。当开发人员变更业务代码时，必须同步变更对应的上下文文件；自动化流水线随即捕获这些修改，并汇总更新至中央 AI Hub。无论是本地的 Claude Code 还是无头 Agent 运行框架，均可按需从 AI Hub 检索组织级的全局视角，从而更精确、低成本地生成所需代码。同时，Granola 会议纪要、邮件与聊天记录等非结构化业务输入，也能依照明确的本体规范被提炼归档在 AI Hub 中，避免宝贵的业务决策上下文在单次对话结束后丢失。
---
### [07:05](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=425s) 第一支柱：结构化共享上下文与分层设计
共享上下文的核心载体是高可读性的 Markdown 文件。这些文件虽然能够供人类团队直接审阅，但其主要受众是 LLM。团队通过在本地代码库建立索引加载器（Index Loader），指引大模型精准检索相关文件与 AI Hub 同步下来的外部依赖，彻底摒弃完全在运行时盲目猜测上下文的传统做法。
- **确定性与成本节约**：依靠预先固化的上下文减少大模型无休止的运行时探索，大幅缩短单次执行时间，并让代码生成更加贴合内部质量标准。
- **辅助性代码图谱**：代码图谱和外部实时检索应作为备用或补充手段，而非首选默认依赖。
- **层级化树状结构**：
- **组织层级（Organization Level）**：记录公司使命、目标客户画像、核心业务角色等全局知识。
- **领域/主题层级（Domain / Theme Level）**：承载业务 PRD、跨服务依赖关系、无服务器（Serverless）架构隐式依赖等跨代码库逻辑。
- **服务代码库层级（Service Repo Level）**：充当树状结构的叶子节点，专注记录单一代码库的具体实现与模块定义。
---
### [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) 第二支柱：治理、工具链与规则便携性
在治理与工具链层面，Andy 强调的首要原则是“保持便携性（keep it portable）”。无论是采用业界通用的 `agents.md` 规范、Claude Code 插件，还是微软技术栈常用的 Agent Package Manager (APM)，抑或是自研的轻量级 Bash 脚本，核心诉求均是在多层级规则之间实现可控的扁平化合成。
```mermaid
flowchart LR
accTitle: Skills and Governance Synthesis Flow
accDescr: Hierarchical skills synthesis before executing LLM workflows.
Org["组织级全局治理规则<br/>(安全/合规/基线)"] --> Synth["规则合成引擎<br/>(APM / 脚本)"]
Repo["服务库专属 Skills<br/>(业务逻辑/领域规范)"] --> Synth
Dev["开发者个人工作流<br/>(偏好/辅助自动化)"] --> Synth
Synth --> Exec["生成扁平化上下文<br/>驱动 LLM 执行任务"]
```
在触发 LLM 之前，系统会执行前置拉取与合成动作：从 AI Hub 拉取最新上下文，并将组织基准治理策略、服务库特有规则及开发者定制工作流打包平铺，再输入给大模型执行。
Andy 告诫团队必须“将这套体系视同产品（treat it as a product）”，严格落实版本控制与 PR 变更审查，确保历史可追溯与可审计性。在技术探索初期，“百花齐放（let a hundred flowers bloom）”固然有利于激发创意，但当工程团队迈向规模化运作时，必须建立严谨的发布治理机制，明确界定发布权限与分发渠道。
---
### [11:09](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=669s) 第三支柱：工作模式重塑与“上下文完工”标准
工作模式的转变被视为三大支柱中最关键的一环。AI Hub 应当贯穿从产品构思、架构设计到最终交付的整个研发生命周期：
- **产品与架构阶段**：产品经理与架构师可以直接借助 AI Hub 的全局知识全景编写高质量 PRD 与系统设计蓝图，产出的新规格文档反过来丰富 AI Hub 的知识沉淀。
- **“上下文完工”核心定义**：传统的开发理念认为功能写完测试通过即代表完工，但在 AI 原生时代，"一个功能特性只有在代码与上下文双重完备时才算真正完成（code and context-complete）"。代码审查（PR Review）必须将上下文文件的更新与代码变更放在同等重要的位置进行评审，防止上下文与实际系统产生漂移。
针对 Token 优化问题，Andy 建议在研发流水线中实施“左重右轻”的模型选型策略：
| 研发阶段 | 适用模型层级 | 策略与目的 |
|:--- |:--- |:--- |
| **流水线左侧（需求定义/规格设计/架构分析）** | 前沿主力模型（Frontier Models） | 确保规格与计划的严密性，高投入换取高质量蓝图 |
| **流水线右侧（具体代码编写与实现）** | 较低梯队/轻量模型 | 在具备详尽规范的前提下，代码实现已趋向商品化，降级模型以节省开销 |
| **代码审计与质量检测循环** | 先轻后重（多阶段过滤） | 前期使用廉价模型筛除明显噪点，后期再引入高级模型精准把关 |
---
### [14:26](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=866s) 交付瓶颈的现实痛点：警惕局部提速与组织断层
Andy 分享了两个真实客户案例，展示即使技术体系与上下文治理完全到位，如果缺乏端到端的交付视野，依然无法换来业务成果：
- **月度架构评审卡点**：某客户成功运用 AI 工具使代码编写速度大幅提升，但组织规定任何重大变更必须经过架构评审委员会审批，而该委员会每月仅召开一次会议。代码产出虽然变快，实际交付周期却依然被卡在月度例会的节拍上，一旦被退回就要再等一个月。
- **严苛的预发环境等待期**：另一家处于敏感行业的客户硬性规定，所有变更必须在预发环境（Staging）连续运行静默观察两周方可上线。中途一旦其他代码变更引发任何回归问题，整个验证周期便需全部重置。
这些实际教训表明，AI 驱动的代码生成加速如果不能与端到端的全局交付价值流相匹配，便无法转化为最终推向生产环境和终端用户的真实业务价值。
### [15:42](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=942s) 持续交付：AI 工程化加速的真正瓶颈与底座
谈到当下许多组织投入大量时间和金钱来试图让 AI 工程化能力跟上节奏，真正的核心答案其实自始至终都没有改变——那就是“持续交付”（Continuous Delivery）。团队必须思考如何才能达到一个可以“自信、安全”发布成果的状态，并在一个自己完全信任的环境中运作。因为只有建立了这种确定性与信任机制，底层的 LLM、编写的代码以及整体工程链路才能在这个流水线所允许的最快速度下全力狂奔。
因此，在制定 AI 采纳策略时，不能只盯住单点的模型调用，而是必须通盘审视整个交付流水线（pipeline）。企业应当先花时间将端到端的交付流程优化到位，然后再进一步去探索如何利用 AI 将这个流水线推向更高维度的效率提升。
```mermaid
flowchart LR
accTitle: Continuous Delivery as the Foundation for AI Speed
subgraph Foundation["底层交付底座"]
direction TB
CD["成熟的持续交付 (CD)"]
Trust["可信、安全的发布环境"]
CD --> Trust
end
subgraph Acceleration["AI 赋能加速"]
direction TB
LLM["LLM 与工程代码"]
Speed["以管道极限速度敏捷迭代"]
LLM --> Speed
end
Trust --> LLM
```
---
### [16:21](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=981s) 超越软件工程：AI Hub 赋能整个企业知识生态
作为工程师或产品人员，大家往往习惯站在自身日常写代码、做具体交付的角度看问题，但实际上团队正在构建的，是整个企业运作的数字化基石。当企业建立起 AI Hub 这一中心化的组织上下文枢纽（centralized context）后，其受益者将远远超出研发部门：
- **市场营销人员**：在规划围绕特定用户旅程（User Journey）的推广活动时，可以直接接入 AI Hub，精准调取并理解在真实屏幕界面交互维度上的具体操作流。
- **数据工程师**：在跨各个不同微服务调研已存在的数据类型及架构依赖时，AI Hub 就是最权威的查询入口与解答工具。
- **企业高管**：如果周五收到的项目周报只有寥寥“五个字”，高管完全可以借助 AI Hub 深入穿透到底层知识库中，去挖掘产品细节、底层技术实现以及全局运作形态。
市面上固然存在大量解决类似问题的 SaaS 产品，但团队不一定非要采购外部 SaaS。自建并采用这种模式在某些维度上其实更具优势——因为它是“人工精心策划”（human curated）的，企业对产出结果拥有完全的掌控权（own that outcome）。团队不仅会对这种协作节奏产生认同与共鸣，AI Hub 最终也会水到渠成地演变为整个组织日常运作的坚实基石。
---
### [17:44](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=1064s) 总结与后续交流
在演讲尾声，Andy Vays 感谢了现场所有听众的聆听，并表达了与大家继续深入探讨的意愿。他欢迎对在真实企业客户中落地实践该方案感兴趣的同行通过 LinkedIn 建立联系，或扫描屏幕上的二维码预约交流，共同探讨 AI-Native 工程化与 AI Hub 模式在具体业务组织中的实际落地应用。
## Notable quotes
> [00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) 大家和午餐之间唯一的阻碍 — Andy Vays
> [00:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=4s) 规模化应用 AI 本质上是一个 DevOps 和平台工程问题 — Andy Vays
> [01:04](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=64s) 两眼一抹黑（flying blind） — Andy Vays
> [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) 保持便携性（keep it portable） — Andy Vays
> [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) 将这套体系视同产品（treat it as a product） — Andy Vays
> [08:58](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=538s) 百花齐放（let a hundred flowers bloom） — Andy Vays
> [11:09](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=669s) 一个功能特性只有在代码与上下文双重完备时才算真正完成（code and context-complete） — Andy Vays
> [15:42](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=942s) 持续交付 — Andy Vays
> [16:21](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=981s) 人工精心策划（human curated） — Andy Vays
> [16:21](https://www.youtube.com/watch?v=VKoNZzGt-iI&t=981s) 拥有完全的掌控权（own that outcome） — Andy Vays
## Mentioned
Andy Vays, Equal Experts, AI Hub, Claude Code, Agent Package Manager (APM), Granola, Confluence, Model Context Protocol (MCP), LinkedIn
## Video description
Andy Vays - Technical Principal, Equal Experts
Most engineering orgs are AI-enabled, with tools bolted onto old workflows. Few are AI-native, with the infrastructure and workflows built for AI from the ground up. During this session, we'll share the AI Hub, a pattern we're building across enterprise clients, for the infrastructure and ways of working that make AI-native engineering possible at scale. This is the difference between adopting AI and being built for it.
[Source](https://www.youtube.com/watch?v=VKoNZzGt-iI)
Source quotes
[0:04] Andy Vays: 大家和午餐之间唯一的阻碍
[0:04] Andy Vays: 规模化应用 AI 本质上是一个 DevOps 和平台工程问题
[1:04] Andy Vays: 两眼一抹黑（flying blind）
[8:58] Andy Vays: 保持便携性（keep it portable）
[8:58] Andy Vays: 将这套体系视同产品（treat it as a product）
[8:58] Andy Vays: 百花齐放（let a hundred flowers bloom）
[11:09] Andy Vays: 一个功能特性只有在代码与上下文双重完备时才算真正完成（code and context-complete）
[15:42] Andy Vays: 持续交付
[16:21] Andy Vays: 人工精心策划（human curated）
[16:21] Andy Vays: 拥有完全的掌控权（own that outcome）
Source quotes
[0:04] Andy Vays: beautiful Furby with all its fine contours, freshly baked and tasting absolutely wonderful
[0:04] Andy Vays: half melted, maybe some bulging eyes
[0:04] Andy Vays: flying blind
[1:59] Andy Vays: AI Hub
[8:58] Andy Vays: letting a thousand flowers bloom
[11:09] Andy Vays: code- and context-complete
Original transcript
[0:04] So first, thanks everyone for attending. I know
I'm the only thing standing between everyone
[0:07] here and lunch, so I really appreciate your
attendance here, and hopefully you'll get some
[0:11] value out of it. Uh so my name's Andy Vays,
I'm a technical principal at Equal Experts.
[0:16] Uh excited to share how we've transformed the way
we work internally and how we've transformed the
[0:21] way our clients deliver software and work as well.
Um and I'm just going to apologize now to all the
[0:26] uh startups here. Uh what we're going to talk
about today is generally uh DevOps and platform
[0:32] engineering problem, and you could do this
with your existing infrastructure and stack
[0:35] and create this type of scale. Uh so excited
to share with you some of the patterns we've
[0:39] done and then how we've accomplished that.
So really quickly, just about Equal Experts,
[0:44] we were founded in 2007, employee-owned,
200-plus clients, 3,600 folks in our network,
[0:50] um and we have an experts-only model, right? So
90% of our folks have 10-plus years of experience.
[0:55] Uh I know you've probably encountered many
services companies out there today the last
[0:58] few days. I assure you we're not like any of the
others, and you should definitely check us out.
[1:04] All right, cool. So um what's the problem
here, right? AI is delivering on expectations,
[1:10] but not quite. We're all expecting this
beautiful Furby with all its fine contours,
[1:15] freshly baked and tasting absolutely wonderful,
but we kind of end up getting something that looks
[1:20] a little bit like this, right? And so half melted,
maybe some bulging eyes, probably tastes okay,
[1:25] but not exactly what we were hoping for. Uh
and we want to talk to you about like how we um
[1:30] conquer that divide. And and some of the
symptoms that align with this that you might
[1:34] be experiencing yourselves is inconsistency across
teams, different teams working different ways,
[1:39] uh runaway token costs, which has been a
very hot topic here, and I'm sure we're
[1:43] all thinking about it, poor code quality, a
lack of a shared picture, some rework, right?
[1:49] And just this overall feeling that you're flying
blind, uh and don't really have a good grasp of
[1:53] how things are going and how and if you're really
getting the outcomes that you're hoping for.
[1:59] And so, we're going to talk about the solution
to that and just because everybody loves three
[2:02] pillars, we got our three pillars right here
as well, right? And they really come down to
[2:06] shared context, which we'll talk more about
in depth and that's a big part of what we're
[2:10] going to talk about. Governance and tooling, so
agents, workflows, and all that kind of stuff. I
[2:15] know it's probably what we're most familiar with
here. And then maybe most important of all, ways
[2:19] of working. How do you change the way you work to
keep your context up to date? When I say context,
[2:24] I mean knowledge, version knowledge in markdown
files and we're going to talk more about that.
[2:28] And then here at the bottom what you have is AI
Hub, which you can think of as a meta repository,
[2:32] but it's the glue that ties all three of
these things together and we're going to
[2:36] talk more about how we apply that and and how
we use that to deliver engineering at scale.
[2:43] And so, you might be thinking there what is AI
Hub, right? And so, it's an idea that really takes
[2:48] on a physical shape and it actually could look a
little bit different in different organizations.
[2:53] If you're working with a mono repo, good for
you, a lot of this becomes a lot easier. We
[2:57] have clients with not exaggerating hundreds
of repositories all segmented across different
[3:02] domains and technology groups. And so, the
challenge becomes how do you create that single
[3:06] lens, that knowledge and context layer that gets
loaded in real time at the right time that helps
[3:12] drive your LLMs to get what they need to do. We're
not talking about we're always talking a little
[3:19] more about this more, but you can go and use MCP
and gather all that information from confluence
[3:23] or other external sources. You could go read the
code. You can create code graphs and all those are
[3:28] great and part of the solution, but what we really
believe in is creating this intentional curated
[3:34] piece of context in markdown and repositories that
really drive the outcomes of the LLMs, minimize
[3:40] token costs, right? Create more consistency, make
it non-deterministic, and really think of it as
[3:45] like your cash for for your workflows more than
anything. And then this central hub is also where
[3:51] we like to put our like skills or governance
or our instructions, all those agent files.
[3:56] We have a client that split these up and that's
totally okay. You can create like a marketplace.
[4:00] You could use cloud plugins as well. But the idea
of AI Hub is a centralized governed versioned
[4:06] sort of meta repository that captures all that
information and then distributes it downstream
[4:11] from there. And then it's also home for all
your artifacts and interactions. I'm sure we
[4:16] have many conversations. You get all your granola
notes. You get your resume notes and what do you
[4:21] do with them and how do you use that to enrich
the knowledge that's ultimately going to drive
[4:25] your LLMs when they're going to build something?
And so that takes us to a little bit more of a
[4:31] granular version of AI Hub. And so you can
think of it as AI Hub sits in the middle and
[4:35] acts as an aggregator and distributor of all that
knowledge and context. Service repos, which are
[4:41] the repositories that people are actually working
in and mutating the code, that's where developers
[4:46] work out of and each one has their own context
within it. They can be markdown files, right?
[4:52] You can put in a docs folder or context folder. It
could be flexible. But but ultimately what we're
[4:56] really trying to capture is what does that repo
do? What are the business requirements behind it?
[5:01] What are the dependencies? What are the different
modules? And so it's this brief index description
[5:06] of what that repository does. So when the LLM is
trying to figure out what it needs to generate,
[5:11] it doesn't have to go at runtime and generate
all this, you know, non-deterministic context.
[5:15] It could read those files and understand what it
really needs to do next. Um and that essentially
[5:22] rolls up to AI Hub with some automation. And so
you have developers working in these service repos
[5:26] and when they mutate their code, they probably
also need to mutate their context, right? Because
[5:31] something about that repository has changed. And
the automation takes that and rolls it up into
[5:36] the central lens. And so now you get this central
lens that has this full view of your organization.
[5:40] It's indexed, so not everything gets loaded.
It gets loaded on demand and as you need it,
[5:45] right? So when you're working downstream
on the right and you have your harnesses,
[5:49] whether you're using it as like you're using cloud
code locally or you have a headless agenda harness
[5:54] running, they can both pull down AI Hub, which
gives us cross-cutting view of everything across
[5:59] all your different services. So, it can get to
the right answer quicker, and if it does need to
[6:04] go to MCP or it does need to read the code or go
to the code graph, it can. That's okay. But again,
[6:09] the goal is to minimize that as much as you can,
so your runs are as deterministic as possible.
[6:15] Um and then this also creates a really nice
pattern, and you see in the top left there where
[6:19] we're talking about interactions and artifacts.
And I will talk more about the structure of AI
[6:22] Hub. But what do you do with all that business
context, right? All those emails, Slack messages,
[6:26] conversations, insights, right? How do you get
product to use this, which is the big question.
[6:31] How do you get the rest of the organization to buy
in and get it? And so, this ends up being a home
[6:36] for where you can take not the raw transcripts,
but take a transcript, figure out your ontology
[6:41] that makes sense, and then distill that down and
put it in the AI repo in the place that it that
[6:46] it belongs, right? And so, you might flag some
risks, some new requirements, whatever. AI Hub
[6:52] gives you a place to put that business logic and
business knowledge and preserve it between runs.
[6:57] And then it actually functions as a base for the
rest of the organization to tap into and use.
[7:05] And so, we'll talk a little bit more shared
context. And so, as I mentioned earlier,
[7:08] it's it's it's markdown files, very intentional.
You want this to be human-reviewable,
[7:13] so it's meant for both humans and LLMs.
But it's really meant for the LLMs,
[7:16] and so you want to live in the local repository.
You want LLMs to read it at runtime. You'll create
[7:22] maybe an index loader file that tells them which
files matter and where it needs to look and where
[7:26] AI Hub has brought down the rest of the context
that it needs to figure things out. Um but what
[7:31] we're really trying to avoid is figuring all
this out at runtime, right? Um it's going to
[7:36] make it more deterministic, alleviate unnecessary
token spend, and make your runs shorter,
[7:41] um and it'll give you more control and confidence
in what it's producing that it aligns with your
[7:45] standards and what you expect. And so, code graphs
and all that stuff are great, but think of those
[7:50] as supplemental things rather than the primary
default thing that you're going to have your
[7:54] LLM let reference when it's going to figure
out whatever it is you're asking it to go to.
[7:59] And so, the structure can really follow kind
of this pattern, right? Where you have AI Hub,
[8:04] you have like context that belongs at the
organizational level, right? Maybe it's what
[8:07] your company does, who your customers are, who
the personas are. Uh, and then as you go lower,
[8:12] you might have specific domains, right?
Or specific themes or functionality.
[8:16] And those also have a place for business context.
Like maybe you'll put your PRDs in there,
[8:20] or you'll find your own kind of ontology that
makes sense for you for how you want to segment
[8:25] it. But it gives it a home for where you can
put stuff that sits above the repositories,
[8:30] but is very useful for interpreting what is in the
repository. Think about serverless functions or
[8:35] stuff that doesn't explicitly live in code, right?
But they're dependencies on what you're doing.
[8:39] Where does the LLM go to know that? And so, this
gives you a place to put all that information.
[8:43] And you basically organize it in a hierarchical
order, right? In a tree-like structure,
[8:47] where the service repositories are the bottom
nodes, and they generally roll up to, you know,
[8:52] either theme or domain, whatever makes
the most sense for your organization.
[8:58] So, let's talk a little bit about governance and
tooling. Um, you know, our general philosophy is
[9:02] keep it portable, right? And so, whether you're
following the agents.md standard, you want to use
[9:07] cloud code. Um, I had a client that really liked
APM. They were a Microsoft shop shop agent package
[9:13] manager. It was it was pretty cool, actually,
uh, in how they were able to synthesize, um,
[9:17] different levels and of structure of scripts that
they needed to go build stuff. You can even build
[9:21] your own simple bash scripts. And we'll talk,
uh, I guess I'll just show you here, right?
[9:26] And and and the reason for that is you're going
to have this central baseline of governance,
[9:30] right? So, at the organizational level, you're
going to have what's been approved and validated
[9:34] and distributed across organizations. Most of
you probably already doing this, right? But
[9:38] then you're going to have service repo specific
skills or rules or other things that you're going
[9:43] to need and you might even have developers that
have workflows that they've created that they like
[9:47] and use personally. And so either with APM or a
bash script, you could basically flatten that and
[9:52] that becomes a first step before you start working
with an LLM and giving it a request. Pull down the
[9:57] context from AI Hub, synthesize your skills into
the skill level that you need to operationalize
[10:03] whatever you're trying to do, and then go
ahead and execute that action and workflow.
[10:09] And you know, really the big idea
here is treat it as a product,
[10:11] right? Keep everything versioned, use
PRs to mutate it, um keep it intentional,
[10:17] uh treat it as you would any other product
that you have within your organization and
[10:22] you'll be able to make it repeatable backwards.
Auditability is a very big thing as well and so
[10:28] if you use version 1.0 to produce this particular
artifact, but we migrated to 3.0, sure you have
[10:33] e-vals and other ways you test progressions. This
gives you a great way to understand like how have
[10:38] things changed over time and what's been the
impact on the quality of code as you go out
[10:42] and go along with it. And so if there's one big
takeaway from this is be intentional about it. Um
[10:48] I've heard the phrase let a hundred flowers bloom
or a thousand flowers bloom thrown around quite a
[10:52] bit and that's great in the experimentation phase,
but as you're trying to get serious and more
[10:56] structure and trying to create a more predictable
pipeline, you really want to be responsible about
[11:01] how you're versioning it, what you're publishing,
who can publish, and how that gets distributed.
[11:09] Um And so the last pillar here, ways of
working, is is probably the most important.
[11:15] Um and so I'll share some anecdotes of of
clients and how we've done everything we've
[11:19] talked about and they still haven't quite gotten
the outcomes they were hoping for. Um but first
[11:24] let's just talk about the general way of of the
way we work. And so each of these steps now has
[11:29] AI Hub that they can use to do their particular
roles and then feed back to further enrich it. So,
[11:34] think about product that's trying to find a new
feature PRD. They could be using Cloud in the
[11:39] in the web if for all they care, right? And they
just ingest that meta repository, and they get a
[11:44] full lens and view of everything happening in the
organization that can help that or in their code
[11:49] that can help them go and formulate the next thing
they're trying to do. Same with your architects
[11:54] in the design phase, right? You have all that
context, that rich information. You have your,
[11:58] you know, previous um systems landscapes or other
artifacts that you've produced that help influence
[12:03] things further, and that lives in AI Hub, too. And
so, your artifacts so your architects and product
[12:08] folks can use this to do their roles, and as they
produce new artifacts, that goes back into AI Hub
[12:13] to kind of complete the picture. And then once
you get into the implementation side of things,
[12:18] right? It's a pretty predictable way of working.
I personally like spec-driven development,
[12:22] but it really doesn't matter. If there's one thing
I could drive home and one big takeaway is the
[12:29] change that you have to fundamentally make is your
PRs, your your your features are not complete when
[12:35] they're just code complete. They're complete when
they're code and context-complete. And so, if you
[12:41] want to keep and maintain this kind of cadence,
you want to make sure that the context you curated
[12:46] accurately represents the current state of things
and prevent drift, you have to bake that into your
[12:51] workflow. So, when you're mutating the source
repositories or you're mutating your artifacts,
[12:56] you have to feed that back into AI Hub to
keep that up to date. And again, we make
[13:02] this really easy. So, as a developer, you don't
really have to know much. You just work in your
[13:07] service repository, you're building your feature
in code, and then when you're ready to release it,
[13:12] it just goes ahead and mutates, you know, the last
step in that pipeline is to mutate your context.
[13:16] And that should be part of your PR review as well,
right? Like you're reviewing the code that changed
[13:21] as well as um as well as the context
mutations that have occurred because of it.
[13:27] And so, this just felt like a good place to put
this slide, especially as we're thinking about
[13:31] workflows, right? Token optimization is a hot
topic. And so, when you think about your entire
[13:35] pipeline from left to right, there are certain
places where you'll get more value out of more
[13:40] frontier more mature models. And then as you move
further to the right, if you do your work to the
[13:45] left, they become a little bit simpler. So, a good
example is when you're producing your artifacts,
[13:49] your your your you know, your architecture
designing things or you're building your spec,
[13:53] use a frontier model or a higher-tier model to
make sure the quality of it is ideal. But then
[13:59] maybe when you're going to write your code, you
can maybe drop down [clears throat] a couple of
[14:02] notches, right? Because you have a really good
plan and execution is kind of more commoditized.
[14:08] You know, I like to do loops for audit work as
well when I'm kind of doing my my pipelines.
[14:13] And so, using cheaper models in the earlier stages
of those loops to kind of get rid of some of the
[14:17] noise before investing that in the in
the higher models is another pattern
[14:21] we like to follow. So, spend
tokens where it matters.
[14:26] And so, this is probably like going
back to some some experiences I have.
[14:31] You know, I can think of two particular clients
that I was on and we did everything we said. We
[14:34] we set up the I hub, we set up like the contacts,
we we worked with their teams to change the way
[14:40] they engineer and write code. But they really
didn't get the results that they wanted. I mean,
[14:44] they were producing code faster, but nothing was
actually making it to production faster, right?
[14:48] And and the reason for that is really human. You
know, one particular client had an architecture
[14:54] review had to sign off on every major change, but
they only met once a month. And so, you could only
[14:59] go as fast as that architecture review board
went. And if it didn't work, they would kick
[15:03] it back out and you have to start again. A
different client that was in a very sensitive
[15:07] industry required everything sits in staging for
2 weeks before it can be released to production.
[15:13] And if there's a regression or something else
causes that regression change staging, guess what?
[15:17] You're going to get kicked back out and you're
going to have to do it all over again. And so,
[15:22] one of the big lessons I've learned as I'm working
with different clients in the field is all these
[15:26] ideas are great, but if you don't take a step back
and understand how you deliver software at from a
[15:31] holistic perspective, what does that delivery work
stream look left to right, you're really not going
[15:36] to get the acceleration you're looking for, which
is outcomes delivered to production to users.
[15:42] Um [snorts] and you know, the answer always
has been and still is and you think of all
[15:47] these organizations investing so much time and
money in getting AI engineering up to speed,
[15:52] but it's continuous delivery, right? How do you
get to that point where you can release things
[15:56] confidently, safely in an environment that
you can that you have confidence in and trust
[16:02] because if you could do that, then
you can go then your LLMs and your
[16:05] code and your engineering can go as
fast as that process allows you to.
[16:09] Uh so, as you're thinking about your AI adoption
strategy, think about your entire pipeline
[16:14] and take the time to optimize it and then figure
out how to use AI to do that even further.
[16:21] And so, this is probably my favorite slide of
all. The stuff that we're building, we're mostly
[16:26] a lot of us are engineers or product folks and
so, we think about ourselves and how we produce
[16:31] code and how we're trying to do our particular
jobs, but what we're building is actually the
[16:35] foundation for the organization. So, a couple of
examples I always like to give is let's say you're
[16:39] a marketing person and you're trying to create,
you know, a campaign around a user journey. Well,
[16:44] now you have AI hub or this centralized context
that you can tap into and understand what is
[16:49] actually the journey from a screen perspective,
right? Or you're a data engineer and trying to
[16:54] understand the different types and what else
is existing in different different services,
[17:00] AI hub is your answer. Or you're an executive that
wants to drill down and understand greater details
[17:05] in the five-word status report you got on Friday,
right? You can take that and drill into that same
[17:11] corpus of knowledge to understand your product,
your technology and how everything is shaped. And
[17:16] so, I really want us all to start thinking about
this is not just a pattern for developing software
[17:21] but also as enabling the organization writ
large. I know there are lots of SaaS products
[17:25] out there that tackle this problem but you don't
necessarily need a SaaS product and in some ways
[17:31] I think this is better because it's human curated
and you own that outcome and your team kind of
[17:36] buys into that cadence and that ends up becoming
the foundation for how your organization works.
[17:44] And so that's it. I appreciate everyone's time.
Again, my name's Andy Vase. I'd love to chat
[17:48] more with you all about how we've done this with
clients, how this can apply to your organization.
[17:54] So please feel free to look me up on LinkedIn or
scan that fancy QR code to book some time with me.
[17:59] Happy to chat and talk about the practical
applications of all this. Thank you so much.
