Sixt Reaches 85% AI-Written Code With Shared Context Infrastructure

Context as Infrastructure: How SIXT Wired Its Enterprise for AI Productivity at Scale With SIXT SE — Ai4

Ai4

Enterprise AI productivity stalls when models lack domain context, but centralizing business ontologies and system maps enables non-engineers to ship over 1,200 production tools while accelerating software delivery up to 17-fold.

AI-assisted summary of Context as Infrastructure: How SIXT Wired Its Enterprise for AI Productivity at Scale With SIXT SE — original source. Check the original for full context.

Source published: 2026-08-18

Detailed notes

## Background Published on YouTube by Ai4 on August 18, 2026, this presentation features Boyan Dimitrov, CTO of SIXT SE. The session outlines how SIXT resolved enterprise AI bottlenecks not by focusing on models or GPU costs, but by engineering a foundational shared context layer that bridges proprietary data and standard operating procedures for both engineers and business users.

## TL;DR After discovering that 70% to 75% of early generative AI development time was consumed by context gathering and data archaeology, SIXT architected a centralized four-layer enterprise context platform covering semantics and ontologies, unified knowledge, dynamic tech landscape intelligence, and centralized engineering standards. Integrated via the Model Context Protocol (MCP), this infrastructure transformed software delivery through spec-driven development—increasing AI-authored code to over 85% and delivering delivery speedups up to 17x. Furthermore, the context layer enabled an internal 'vibe coding' platform equipped with autonomous guardrails, empowering non-technical employees to build and maintain over 1,200 production applications.

## Atmosphere & style The presentation is pragmatic, engineering-centric, and refreshingly devoid of superficial AI hype, focusing squarely on the hard architectural realities of enterprise scaling. Dimitrov speaks with methodical clarity and authoritative confidence, guiding the audience through a structured narrative arc from initial operational friction to compounding technical and organizational velocity. Watching it feels like a blueprint masterclass in modern systems design, leaving the audience with an actionable perspective on enterprise readiness.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=odPx2okPVDE&t=4s) Early generative AI projects revealed that 70% to 75% of project timelines were consumed by preparatory groundwork—hunting down data access, KPI definitions, and SOPs—rather than engineering automation. - [02:58](https://www.youtube.com/watch?v=odPx2okPVDE&t=178s) SIXT established a centralized agentic context layer as shared enterprise infrastructure to eliminate context silos and feed all downstream AI initiatives. - [03:59](https://www.youtube.com/watch?v=odPx2okPVDE&t=239s) The semantic and ontology layer standardizes business metrics and domain entities, eliminating conflicting definitions—such as 20+ meanings for 'revenue'—that cause agent hallucinations. - [07:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=468s) A unified knowledge layer with automated contradiction detection and human-in-the-loop governance ensures customer-facing bots and internal support co-pilots operate from the same ground truth. - [09:42](https://www.youtube.com/watch?v=odPx2okPVDE&t=582s) The tech landscape intelligence layer provides dynamic maps of system interfaces, event streams, and dependencies, preventing coding agents from burning context windows by brute-forcing repositories. - [10:40](https://www.youtube.com/watch?v=odPx2okPVDE&t=640s) Company-wide engineering standards and repo-specific domain files are centralized to enforce code quality and non-functional requirements across local IDEs and autonomous cloud agents. - [12:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=768s) Exposing context layers via the Model Context Protocol (MCP) enabled spec-driven development, raising AI-generated code to over 85% across SIXT. - [13:30](https://www.youtube.com/watch?v=odPx2okPVDE&t=810s) Context-backed development dramatically compressed engineering cycle times, delivering greenfield launches 3x faster, core features 5x faster, and legacy re-engineering 17x faster. - [15:11](https://www.youtube.com/watch?v=odPx2okPVDE&t=911s) The vibe coding platform allows non-engineers to build production tools while autonomous policy agents validate architecture, security, and data compliance before deployment. - [16:00](https://www.youtube.com/watch?v=odPx2okPVDE&t=960s) Non-technical employees built and maintain over 1,200 production applications in under six months, proving that foundational context infrastructure produces compounding productivity returns.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=odPx2okPVDE&t=4s) SIXT's Operational Scale and the 70% Preparation Bottleneck

SIXT operates as a global mobility powerhouse well beyond traditional car rental, spanning car subscriptions, car sharing, e-hailing, and commercial vans and trucks. Operating at this scale involves orchestrating a fleet of roughly 300,000 vehicles across more than 2,000 locations in 105 countries. Managing this footprint generates immense operational complexity, pushing the company to invest heavily in modern technology and artificial intelligence. When SIXT embarked on its generative AI journey in late 2023 and early 2024, spinning up pilot projects across diverse business units quickly brought an unexpected and frustrating realization to light: engineering and automation were not the primary bottlenecks.

Instead, project retrospectives revealed that over 70% to 75% of total project timelines were consumed strictly by preparatory groundwork. Teams found themselves bogged down trying to decipher what specific metrics and KPIs actually meant, where data was hosted, how to access it, and how core business processes functioned end-to-end. Engineers had to conduct organizational archaeology to track down current standard operating procedures (SOPs) and map out the labyrinth of underlying software systems, integration touchpoints, and best practices. For a company aspiring to operate as an "AI frontier company" by infusing autonomous agents into core business operations, spending three-quarters of every development cycle merely gathering context was fundamentally unsustainable.

- Fleet scale: ~300,000 vehicles managed across 2,000 locations in over 105 countries. - Timeline: Enterprise generative AI journey kicked off in late 2023 / early 2024. - The preparation tax: Over 70% to 75% of early project hours were spent hunting down data access, KPI definitions, SOPs, and system integration points rather than writing automation logic.

---

[02:58](https://www.youtube.com/watch?v=odPx2okPVDE&t=178s) Designing the Agentic Enterprise Context Layer

To eliminate the recurring tax of preparation, SIXT audited its entire data warehouse footprint, core application landscape, and fragmented data sources to establish a centralized "agentic context layer." Rather than having each team rebuild context silos from scratch, this shared platform acts as the unified connective tissue feeding every AI and agentic initiative across the enterprise.

This architectural shift was designed to unlock substantial economies of scale, optimize token efficiency, and dramatically improve the reliability of model integrations. By decoupling contextual data from point-to-point application logic and serving it as a first-class foundational platform, any autonomous agent or developer across the company can immediately orient itself, reason about domain problems, and execute tasks without exhaustive setup cycles.

```mermaid flowchart TD accTitle: SIXT Agentic Context Architecture

subgraph SOURCES["Enterprise Data & Systems"] DWH["Data Warehouse & Repos"] DOCS["SOPs, Confluence & ServiceNow"] APPS["App Catalog & Event Streams"] end

subgraph CONTEXT_LAYER["SIXT Agentic Context Layer"] L1["1. Semantic & Ontology Layer"] L2["2. Knowledge Layer"] L3["3. Tech Landscape Intelligence"] L4["4. Central Standards & Guardrails"] end

subgraph CONSUMERS["Downstream Execution (via MCP)"] ENG["Spec-Driven Engineering<br/>(Claude / Codex)"] VIBE["Vibe Coding Platform<br/>(Non-Engineers)"] AUTO["Autonomous Process Agents"] end

SOURCES --> CONTEXT_LAYER CONTEXT_LAYER --> CONSUMERS ```

---

[03:59](https://www.youtube.com/watch?v=odPx2okPVDE&t=239s) Layer 1: Tackling KPI Fragmentation with the Semantic and Ontology Layer

SIXT's first structural pillar is the semantic and ontology layer, initiated in late 2024 to solve enterprise naming fragmentation. In large enterprises, seemingly straightforward terms rarely mean the same thing across departments. A metric as universal as "revenue" carries wildly divergent definitions depending on who is asked: to the booking team, revenue means total booked reservations; to the finance team, revenue strictly represents invoiced amounts; and group controlling applies an entirely separate methodology. Across thousands of enterprise KPIs, an organization can easily maintain 20 to 25 competing definitions for the exact same term, while some global enterprises juggle hundreds.

When autonomous agents are deployed across an unstandardized landscape, they either hallucinate calculations or spend excessive cycles attempting to determine which metric variant applies. This ambiguity introduces two critical failure modes: blind spots caused by querying the wrong underlying systems, and invalid numerical outputs that invalidate downstream automation because "numbers drive everything." SIXT tackled this by cataloging all source systems into a unified semantic layer enriched with domain-specific metadata, exact mathematical formulas, and business logic. Directly above this, SIXT introduced ontologies defining core business entities—such as what constitutes a "country," a "branch," or a "customer" within SIXT—and mapped their relationships across hierarchical KPI trees. This structure equips agents to reason about business questions accurately and navigate enterprise metrics without getting derailed by linguistic nuances.

- KPI ambiguity: A single metric like "revenue" often has 20 to 25 conflicting definitions across booking, invoicing, and controlling teams. - Core risks mitigated: Enterprise blind spots (pulling from the wrong database) and hallucinated financial figures. - Semantic foundation: Complete business logic catalogs paired with domain ontologies (e.g., country, branch, customer) and hierarchical KPI trees.

---

[07:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=468s) Layer 2: Unifying SOPs and Ground Truth with the Knowledge Layer

The second foundational pillar is the knowledge layer, built to reconcile fragmented operational documentation across Confluence, ServiceNow, and disconnected Word documents. Over years of organizational turnover, internal documentation inevitably fractures into conflicting versions of the truth managed by disparate owners. To solve this, SIXT instituted a semi-automated ingestion engine that continuously inspects inbound operational knowledge. The system programmatically flags duplicate information, identifies gaps, and detects logical contradictions, while preserving a strict human-in-the-loop governance model where designated department owners certify that all ingested SOPs represent current business reality.

The absolute necessity of a unified knowledge layer becomes painfully apparent in customer service architectures. Many organizations deploy customer-facing self-service agents alongside internal co-pilots designed to assist human support agents with escalations. If these two agentic systems pull from separate, unaligned knowledge repositories, the entire customer journey degrades into chaos—the customer receives one answer from the automated bot, while the human agent's co-pilot generates a conflicting resolution. By grounding both interfaces in a single, vetted knowledge layer, SIXT guarantees consistent policy execution across the organization.

- Documentation landscape: Replaced sprawling, conflicting Confluence spaces, ServiceNow records, and Word documents with a single agent-accessible knowledge repository. - Ingestion pipeline: Employs a semi-automated verification pipeline to catch inconsistencies, duplicate guidance, and procedural gaps before ingestion. - Governance: Human-in-the-loop review retains departmental ownership over procedural accuracy and policy updates.

---

[09:42](https://www.youtube.com/watch?v=odPx2okPVDE&t=582s) Layers 3 & 4: Tech Landscape Intelligence and Centralized Engineering Standards

The third layer—the tech landscape intelligence layer—serves as an automated, real-time map of SIXT's software ecosystem. Instead of forcing AI coding agents to brute-force their way through sprawling codebases, burning through context windows and token budgets only to draw flawed architectural conclusions, this layer maintains a dynamically updated catalog of all enterprise applications. It details how systems interface, their direct runtime and architectural dependencies, underlying infrastructure, event stream integrations, assigned data sources, repository locations, and official engineering team ownership. The catalog updates continuously alongside code and infrastructure changes, giving agents immediate situational awareness of blast radiuses and system boundaries.

The fourth layer centralizes company-wide engineering standards and non-functional requirements (NFRs). Whether an agent is running locally inside an engineer's IDE (such as Claude or Codex) or operating as an autonomous cloud agent executing automated refactoring or quality verification, it accesses a single repository of corporate best practices. Crucially, this global framework is balanced by application-specific context files embedded directly within individual code repositories. These local definitions provide agents with explicit domain models, edge-case handling rules, and repository-specific patterns, which is critical given that shipping a single feature at SIXT frequently requires coordinated changes across multiple interconnected services.

- Dynamic tech mapping: Live metadata detailing service-to-service connections, infrastructure dependencies, event streams, data stores, code locations, and system owners. - Token and compute efficiency: Eliminates the need for models to ingest massive repositories just to discover system interfaces and dependencies. - Standardized governance: Universal coding standards and NFRs exposed to both developer-local agents (Claude/Codex) and autonomous cloud validation agents.

---

[11:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=708s) Architecture Overview and Enterprise Use Cases

These four unified context layers—the semantic ontology, the knowledge layer, the tech landscape intelligence layer, and centralized standards—coalesce into SIXT's enterprise context layer. Rather than building tailored pipelines for distinct departments, this single architecture underpins three core enterprise workloads: agentic software engineering, a citizen-developer vibe coding platform, and dedicated autonomous process agents that own business workflows end-to-end.

| Layer | Primary Data Assets | Core Role in Agentic Execution | |:--- |:--- |:--- | | **1. Semantic & Ontology** | KPI business logic, domain definitions (branch, vehicle, country), KPI trees | Eliminates hallucinated metrics and aligns agent reasoning with official financial definitions. | | **2. Knowledge Layer** | Verified SOPs, operational policies, cross-department documentation | Supplies a synchronized ground truth for customer-facing agents and internal co-pilots. | | **3. Tech Landscape Intelligence** | Dependency graphs, event streams, data sources, repo paths, system owners | Prevents token-heavy codebase brute-forcing by giving agents pre-computed architectural maps. | | **4. Central Standards & NFRs** | Coding guidelines, security rules, repo-level domain models, architecture specs | Enforces corporate code quality and security consistently across local and cloud environments. |

---

[12:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=768s) Spec-Driven Engineering and Acceleration Metrics

SIXT restructured its core software delivery by introducing spec-driven development across all engineering teams approximately six months prior. By exposing the enterprise context layers to local and autonomous cloud agents via the Model Context Protocol (MCP), SIXT automated nearly every stage of the software development life cycle (SDLC). The context infrastructure informs project discovery, formal specification authoring, system design, architectural modeling, and code generation against pre-indexed repositories—leaving only the final deterministic deployment pipeline outside the direct domain of LLM reasoning.

The operational velocity unlocked by this infrastructure has fundamentally shifted software delivery metrics. Year-to-date, over 85% of all code written internally at SIXT is authored by AI, compared to just 25% the previous year. Concrete production rollouts highlight the dramatic cycle-time compression across varying project scopes: - **New Product Launch**: Shipped a brand-new, greenfield product in early August "three times faster" than the timeline projected during late-2023 scoping. - **Complex Feature Delivery**: The booking team delivered a major core booking capability "five times faster" than an equivalent feature implemented the previous year. - **Legacy Migration**: Completely re-engineered a legacy application from scratch, completing the project "17 times faster" than historical engineering estimates had budgeted.

---

[15:11](https://www.youtube.com/watch?v=odPx2okPVDE&t=911s) The Vibe Coding Platform for Non-Engineers and Compounding Returns

Beyond accelerating professional developers, SIXT leveraged its context infrastructure to deploy an internal "vibe coding platform" that empowers non-technical business personnel to build production-grade automations. Non-engineers interact with flexible generative front-ends, Claude, or Codex to articulate operational problems and generate functional applications. Because citizen developers lack formal software engineering training, the platform introduces a fully automated governance harness: autonomous policy and guardrail agents intercept generated code, validating that the underlying architecture is sound, corporate security policies are respected, and enterprise data access rules are enforced before packaging and deploying the solution automatically.

The platform relies directly on the enterprise context layers to formulate problems correctly, steer policy validation agents, and manage runtime data authorization. Rolled out in March, internal adoption far outpaced leadership's initial expectations: while executive forecasts anticipated a few hundred apps over the first quarter, non-technical employees built and currently maintain more than 1,200 production solutions across the enterprise. Dimitrov concludes that the foundational lesson from SIXT's two-year journey is clear: "investing in foundations really has compounding results," transforming enterprise AI from fragmented, isolated experiments into a scaled operational reality.

- Enterprise footprint: Over 1,200 custom solutions built, deployed, and owned entirely by non-engineers between March and August. - Autonomous guardrails: Automated validation agents audit generated code for enterprise compliance, data access policies, and architectural standards prior to production packaging. - Strategic takeaway: Building shared contextual infrastructure rather than chasing model selection creates compounding productivity gains across both technical and business organizations.

## Notable quotes > [00:00](https://www.youtube.com/watch?v=odPx2okPVDE&t=0s) The bottleneck for AI productivity in the enterprise isn't the models - it's context. — Boyan Dimitrov

> [00:00](https://www.youtube.com/watch?v=odPx2okPVDE&t=0s) Who has access to what data, when, and in what form determines whether AI becomes a genuine productivity multiplier or stays a collection of isolated experiments. — Boyan Dimitrov

> [00:00](https://www.youtube.com/watch?v=odPx2okPVDE&t=0s) This is not a talk about choosing models or managing GPU costs. It's about the connective tissue that makes an AI-native enterprise actually function at scale. — Boyan Dimitrov

> [03:59](https://www.youtube.com/watch?v=odPx2okPVDE&t=239s) numbers drive everything — Boyan Dimitrov

> [12:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=768s) three times faster — Boyan Dimitrov

> [12:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=768s) five times faster — Boyan Dimitrov

> [12:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=768s) 17 times faster — Boyan Dimitrov

> [15:11](https://www.youtube.com/watch?v=odPx2okPVDE&t=911s) investing in foundations really has compounding results — Boyan Dimitrov

## Mentioned Boyan Dimitrov, SIXT SE, Ai4, Confluence, ServiceNow, Model Context Protocol (MCP), Claude, Codex, Microsoft Word

## Video description Boyan Dimitrov - CTO, SIXT SE

The bottleneck for AI productivity in the enterprise isn't the models - it's context. Who has access to what data, when, and in what form determines whether AI becomes a genuine productivity multiplier or stays a collection of isolated experiments.

At SIXT, we built a platform layer designed to solve exactly this: shared context and data access as first-class infrastructure, available to both engineering teams and business users. In this session, we will walk through the building blocks - how we made proprietary data accessible, how we created shared context that scales across teams, and what the platform capabilities look like that let non-engineers ship real solutions alongside engineers writing production code.

This is not a talk about choosing models or managing GPU costs. It's about the connective tissue that makes an AI-native enterprise actually function at scale.

[Source](https://www.youtube.com/watch?v=odPx2okPVDE)

中文简报

SIXT依托共享上下文基础设施实现85%代码由AI编写当模型缺乏领域上下文时，企业AI生产力往往停滞不前；但通过集中管理业务本体与系统架构图，SIXT不仅使非技术人员交付了超1200个生产级工具，更将软件交付速度提升了最高17倍。在发现早期生成式AI开发中有70%至75%的时间消耗在上下文收集与数据挖掘之后，SIXT构建了一个涵盖语义与本体、统一知识、动态技术全景智能及集中工程标准的四层集中式企业上下文平台。该基础设施通过模型上下文协议（MCP）集成，借助规范驱动开发（spec-driven development）改变了软件交付方式，使AI编写代码的比例提升至85%以上，软件交付速度最高提升达17倍。此外，该上下文层还支撑起一个配备自主护栏的内部“vibe coding”平台，赋能非技术员工构建并维护了1200多个生产级应用程序。 SIXT 在初期生成式 AI 探索中发现，团队 70% 至 75% 的项目时间都消耗在查找数据权限、确认 KPI 定义和梳理 SOP 等前置准备上，而非核心工程自动化。 (0:04) 为打破上下文孤岛，SIXT 建立了企业级 Agent 上下文基础设施，通过语义与本体层统一了如“收入”多达 20 余种冲突定义，有效杜绝模型幻觉与底层数据盲区。 (2:58) 通过 MCP 协议将上下文注入规范驱动开发流程后，SIXT 的 AI 代码生成率提升至 85% 以上，核心功能交付速度加快 5 倍，老旧系统重构提速达 17 倍。 (12:48) 结合上下文层与自动化合规护栏，SIXT 推出的 Vibe Coding 平台使非技术人员在数月内独立构建并维护了超过 1,200 个生产级业务应用。 (15:11)

Reading summary

When deploying generative AI across its global fleet operations, SIXT discovered that teams spent over 70% of project timelines hunting down definitions, systems, and documentation. To eliminate this preparation bottleneck, the company constructed a centralized four-layer enterprise context architecture that grounds AI agents in verified operational, semantic, and technical reality. The 70% Preparation Tax and Context Infrastructure (0:04) Managing approximately 300,000 vehicles across 2,000 locations in 105 countries generates significant operational complexity. When SIXT initiated enterprise generative AI pilots in late 2023 and early 2024, project retrospectives revealed that automation logic was not the primary constraint. Instead, teams spent 70% to 75% of project timelines conducting groundwork: locating data, deciphering unstandardized key performance indicators (KPIs), tracing standard operating procedures (SOPs), and mapping dependencies across legacy software systems. To end this recurring overhead, SIXT audited its data warehouses and application portfolio to build a centralized agentic context layer. Decoupling contextual data from individual application logic provides a unified foundation across the enterprise, enabling autonomous agents and software engineers to orient themselves immediately without rebuilding domain context for each new initiative. Resolving Semantic Fragmentation and Operational Knowledge (3:59) SIXT's context framework addresses business ambiguity through two foundational pillars: a semantic and ontology layer, and a verified knowledge layer. In late 2024, the company tackled metric inconsistency, where common terms like "revenue" maintained 20 to 25 competing definitions across booking, invoicing, and controlling departments. Unresolved ambiguity caused AI agents to either query incorrect systems or hallucinate figures. SIXT mapped source systems to unified business logic catalogs, exact mathematical formulas, hierarchical KPI trees, and core domain ontologies defining entities like branches, countries, and customers. Directly above this, a knowledge layer reconciles fragmented operational documentation dispersed across Confluence, ServiceNow, and text documents. A semi-automated ingestion engine identifies duplicates, coverage gaps, and policy contradictions, while departmental owners retain human-in-the-loop sign-off on current SOPs. This shared ground truth prevents discrepancies between customer-facing self-service bots and internal support co-pilots, ensuring consistent policy application across channels. Automating Architectural Mapping and Engineering Standards (9:42) To prevent autonomous coding agents from burning context windows and token budgets by brute-forcing enterprise repositories, SIXT introduced a tech landscape intelligence layer. This system maintains a continuously updated catalog detailing service-to-service interfaces, runtime dependencies, infrastructure, event streams, assigned data stores, repository locations, and engineering ownership. The mapping provides models with immediate visibility into system boundaries and operational blast radiuses. A complementary fourth layer centralizes corporate engineering standards and non-functional requirements. Accessible both to cloud-based verification agents and local integrated development environment (IDE) tools like Claude and Codex, these central guidelines are paired with repository-level context files. Local configuration files define domain models, error handling, and component boundaries, enabling multi-service feature coordination without sacrificing compliance. Spec-Driven Engineering and Citizen Developer Scaling (12:48) SIXT connected its context layers to downstream systems via the Model Context Protocol (MCP), adopting spec-driven engineering across all software teams. Context feeds directly into project discovery, specification authoring, system design, and AI code generation, leaving only final deployment pipelines deterministic. Consequently, year-to-date AI code generation rose to over 85%, up from 25% the prior year. Reported delivery accelerations include shipping a greenfield product three times faster than late-2023 projections, delivering a core booking feature five times faster, and completing a legacy re-engineering project 17 times faster than historical estimates. The same infrastructure powers an internal "vibe coding platform" launched in March, which allows non-technical staff to build applications using conversational front-ends. Autonomous guardrail agents inspect generated code against corporate architecture, security, and data-access policies before automated deployment. Non-engineers built and currently maintain more than 1,200 production solutions across SIXT, significantly outperforming initial leadership projections of a few hundred apps. SIXT's operational implementation demonstrates that treating organizational context as structured, platform infrastructure—rather than focusing strictly on model selection—yields compounding returns across professional engineering and citizen development. While core software generation has scaled rapidly, deterministic deployment pipelines and departmental human-in-the-loop verification remain mandatory safeguards.

精炼阅读摘要

全球出行服务商 SIXT 在推进生成式人工智能与智能体落地过程中发现，超过 70% 的研发周期耗费在厘清指标与业务流程等前置上下文中，为此构建了统一的企业智能体上下文层以实现规模化生产力跃升。突破准备瓶颈：集中式企业上下文层的提出 (0:04) SIXT 在全球 105 个国家和地区的 2,000 多个网点管理约 300,000 辆汽车，业务涵盖传统租车、汽车订阅、车辆共享、网约车及商用车等。在 2023 年底至 2024 年初启动企业级生成式 AI 试点时，公司发现工程编码与自动化实现本身并非瓶颈，项目总时间中高达 70% 至 75% 被用于前置准备工作。工程团队需要耗费大量时间进行“组织考古”，反复确认各项 KPI 的具体含义、数据存放位置与权限获取方式，并理清各底层软件系统、集成点与标准作业程序（SOP）。这种高昂的“准备税”直接制约了其向以自主智能体为核心的业务模式演进。为彻底根除各团队重复梳理上下文的资源浪费，SIXT 对其数据仓库、核心应用群落及分散数据源展开审查，设计出统一的企业智能体上下文层（Agentic Context Layer）。该平台将上下文数据与点对点应用逻辑解耦，作为基础设施向所有下游应用集中供给。这种解耦架构旨在通过模型上下文协议（MCP）向开发工具和自主智能体输出结构化信息，在降低模型推理 Token 消耗的同时，大幅提高智能体在企业复杂环境中的定向推理速度与系统集成可靠性。消除指标歧义与文档冲突：语义本体与知识治理 (3:59) SIXT 于 2024 年底启动了第一层“语义与本体层”建设，着力解决跨部门命名碎片化问题。在大型企业内部，通用商业术语往往缺乏统一标准，例如“收入”（Revenue）在预订部门代表总预订金额，在财务部门特指已开票金额，而集团控制部门又采用独立核算方法，同一指标在企业内可能存在 20 到 25 种不同定义。若直接部署自主智能体，极易因查询错误数据源产生业务盲区，或因指标歧义输出无效数值。SIXT 通过建立涵盖业务逻辑、精确数学公式与元数据的语义目录，并构建定义国家、分支网点和客户等核心实体的领域本体与层级化 KPI 树，使智能体能够准确理解指标层级关系。第二层“知识层”则聚焦于整合分散在 Confluence、ServiceNow 以及独立 Word 文档中的操作手册与流程记录。随着组织人员变动，内部文档常演化出相互冲突的“事实版本”。SIXT 引入半自动化摄取管道，自动检测入库知识中的重复内容、信息缺漏和逻辑矛盾，同时设立严格的人机协同（Human-in-the-loop）治理机制，要求业务部门负责人对 SOP 的现实有效性进行认证。该机制在客服场景中尤为关键，它确保了面向客户的自助服务智能体与协助人工客服的内部副驾驶（Co-pilot）依赖完全一致的基础规则，避免了对外输出相互矛盾的处置方案。动态技术全景与全局工程规范的解耦供给 (9:42) 第三层为“技术全景情报层”，其实质是 SIXT 软件生态系统的动态实时图谱。为避免 AI 编码智能体通过暴力解析庞大代码库而耗尽上下文窗口与 Token 预算，该层维护了一个随代码与基础设施变更而持续更新的应用目录，详细记录了各系统接口、运行时与架构依赖项、底层基础设施、事件流集成、挂接数据源、代码仓库路径以及归属工程团队。该图谱为智能体提供了清晰的系统边界与爆炸半径感知能力，使其在进入具体任务前即可获得预计算的架构全貌。第四层集中沉淀了全公司的工程标准与非功能性需求（NFRs）。无论是在工程师本地 IDE（如 Claude 或 Codex）中运行的辅助插件，还是在云端执行重构与质检的自主智能体，均遵循统一的企业级最佳实践、代码质量要求与安全规范。同时，各个具体代码仓库内嵌入了本地上下文文件，补充说明该仓库的领域模型与特定边界条件处理逻辑。这种“全局规范+局部模型”的双层架构，使智能体在面对需要跨多个微服务协同交付的复杂业务变更时，依然能够保持架构规范的一致性。规范驱动开发与无代码平台的工程效率跃迁 (12:48) 在完成上下文分层构建后，SIXT 于约半年前在全体工程团队推广规范驱动开发（Spec-Driven Development）。除最终的确定性部署流水线外，项目需求挖掘、规范编写、系统设计、架构建模和代码生成均依托上下文基础设施实现半自动化运作。根据 SIXT 披露的数据，年内公司内部由 AI 编写的代码比例已从上一年度的 25% 飙升至 85% 以上。具体落地项目显示出明显的周期压缩：8 月初上线的一款全新产品交付速度较 2023 年底的预估排期快了 3 倍；预订团队交付重大核心功能的速度比前一年类似功能快了 5 倍；一项重写遗留系统的迁移工程交付耗时则比传统历史预算快了 17 倍。此外，SIXT 将上下文基础设施赋能于 3 月推出的内部“氛围编程平台”（Vibe Coding Platform），允许非技术背景的业务人员利用 Claude 或 Codex 构建生产级自动化应用。针对非技术人员缺乏工程训练的风险，平台配备了自主策略与护栏智能体，在代码打包部署前对系统架构、安全规范与企业数据访问权限实施全自动拦截审计。截至 8 月，非技术员工已在企业内部自主构建并维护了超过 1,200 个生产级解决方案，大幅超出了管理层初期在第一季度仅达成数百个应用的预期。 SIXT 团队在两年的实践中总结认为，向共享上下文基础设施投资具有复合性收益，能将孤立的生成式 AI 试点转化为规模化的企业生产力引擎。不过，这一体系高度依赖跨部门对语义、知识与架构元数据的长期人工治理维护，如何在业务持续扩张中维持护栏有效性并防范权限穿透，仍是规模化落地过程中需要长期应对的挑战。

Detailed notes — zh

## Background 该内容由频道“Ai4”于 2026 年 8 月 18 日发布在 YouTube 平台，主讲人为 SIXT SE 首席技术官（CTO）Boyan Dimitrov。视频简介指出，企业 AI 生产力的真正瓶颈在于上下文而非模型本身，本场演讲详细解析了 SIXT 如何将共享上下文与数据访问构建为一等公民基础设施，从而让工程师与业务人员协同实现规模化生产力跃迁。 ## TL;DR 针对早期 AI 试点中 70% 至 75% 的时间浪费在数据口径梳理、SOP 考古与系统拓扑摸底的困境，SIXT 构建了涵盖本体语义、统一知识、技术全景与代码规范的四层企业级智能体上下文底座。依托该基础设施与规范驱动开发（Spec-Driven Development），全公司 AI 生成代码比例由 25% 飙升至 85%，老旧系统重构效率提升达 17 倍。同时，内置策略防护栏的 VIP/Vibe 编码平台已支持非技术员工自主构建超过 1,200 个企业级生产应用，充分验证了深耕底层基础设施带来的巨大复利效应。 ## Atmosphere & style 演讲展现出极为沉稳、专业且务实的技术领袖风格，完全摒弃了空洞的模型参数炒作与概念包装。叙事从一线工程团队面临的真实痛点与混乱现实切入，层层递进地展开严密的架构设计与落地策略，并在后半程以震撼的量化提效数据形成高潮。整场分享节奏明快、干货密集，传递出一种基于工程理性与基础设施复利带来的笃定与力量感。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=odPx2okPVDE&t=4s) SIXT 早期生成式 AI 试点的核心痛点在于“前期准备瓶颈”，团队超过 70% 至 75% 的时间耗费在梳理数据语义、SOP 流程与底层系统拓扑上，而非实际工程构建。 - [03:13](https://www.youtube.com/watch?v=odPx2okPVDE&t=193s) 为了从根本上消除重复摸底与割裂，SIXT 构建了企业级“智能体上下文层（Agentic Context Layer）”，将共享上下文作为一等公民的基础设施统一供给。 - [03:59](https://www.youtube.com/watch?v=odPx2okPVDE&t=239s) 本体与语义层（第一层）通过标准化建模、KPI 公式挂载与轻量级本体，消除了跨部门的命名碎片化与口径歧义（如“收入”存在 20 多种定义），杜绝了数据幻觉。 - [07:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=468s) 统一知识层（第二层）引入内省审查与人机协同校验，确保企业 SOP 与业务规则维持“单一真实来源”，避免客户侧与内部 Copilot 输出相互矛盾的政策解答。 - [09:44](https://www.youtube.com/watch?v=odPx2okPVDE&t=584s) 技术全景智能层（第三层）动态维护全公司系统依赖与事件流拓扑，使智能体接手任务时无需暴力遍历海量代码库即可精准定位影响范围。 - [09:44](https://www.youtube.com/watch?v=odPx2okPVDE&t=584s) 代码规范层（第四层）集中管理公司级编码标准与仓库特性，让本地 IDE、CLI 工具及云端工程智能体在统一的高质量标准下协同作业。 - [12:08](https://www.youtube.com/watch?v=odPx2okPVDE&t=728s) 在软件生命周期中全面推行“规范驱动开发”，通过 MCP 协议将上下文层与高速全局代码索引深度集成到需求定义、架构设计与编码执行全流程。 - [13:55](https://www.youtube.com/watch?v=odPx2okPVDE&t=835s) 上下文基础设施驱动研发效率爆发：内部 AI 生成代码占比从 25% 跃升至 85%，产品交付提速 3 至 5 倍，遗留系统重构速度提升了 17 倍。 - [15:11](https://www.youtube.com/watch?v=odPx2okPVDE&t=911s) 打造面向全员的 VIP 编码平台，结合自动化策略防护栏（Guardrails），让非技术业务人员通过自然语言独立构建并维护了超过 1,200 个企业级应用。 - [17:16](https://www.youtube.com/watch?v=odPx2okPVDE&t=1036s) 企业级 AI 的核心瓶颈不在于模型选择，而在于上下文连接；对底层共享上下文基础设施的投资能够产生持续且巨大的复利效应。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=odPx2okPVDE&t=4s) SIXT 的全球规模与早期生成式 AI 的“准备瓶颈” 作为全球出行服务巨头，SIXT 的核心业务是汽车租赁，同时还涵盖了汽车订阅（Car Subscriptions）、汽车共享（Car Sharing）、网约车（E-hailing）以及货车/卡车租赁等庞大的产品组合。在任何时间节点，SIXT 都在全球超过 105 个国家、2000 多个网点运营管理着大约 30 万辆汽车。这种庞大的跨国运营网络带来了极其复杂的业务逻辑与系统交互。为了应对这一挑战，SIXT 在技术与 AI 领域进行了重金投入。 SIXT 的生成式 AI（GenAI）探索始于 2023 年底至 2024 年初。然而，团队在各个业务线落地首批试点项目时，很快遭遇了一个出人意料的痛点：团队投入的大部分时间根本不是花在工程构建或自动化实现上，而是被耗费在所谓的“前期准备”环节。事实上，这些早期项目中超过 70% 甚至 75% 的时间都停留在摸清底层上下文的阶段。团队进一步深挖后发现，消耗大量时间的阻碍主要集中在三大方面： - **数据与 KPI 的语义歧义**：不同的数据和 KPI 到底代表什么业务含义？它们在系统里是如何绘制和计算的？如何正确获取？ - **业务流程与 SOP 的模糊性**：端到端的真实流程究竟如何运转？若要实现自动化，就必须找到最新、最权威的标准作业程序（SOP）。 - **底层系统的连接拓扑**：支撑这些流程的系统有哪些？它们之间如何集成？最佳实践是什么？对于一家立志成为前沿 AI 企业（AI Frontier Company）的公司而言，如果每个项目都要把四分之三的时间浪费在前期摸底上，规模化落地 AI 就无从谈起。因此，SIXT 决定彻底重构这一流程。 ```mermaid flowchart TD accTitle: SIXT 早期 AI 项目落地瓶颈与时间分配 subgraph Bottleneck["早期 AI 项目时间分配痛点"] direction TB A["前期准备耗时 (>70%-75%)"] --> B["数据语义与 KPI 口径梳理"] A --> C["端到端流程与 SOP 考古"] A --> D["底层系统架构与集成探索"] E["实际工程与自动化开发 (<25%-30%)"] end ``` --- ### [03:13](https://www.youtube.com/watch?v=odPx2okPVDE&t=193s) 破局之道：构建集中的“智能体上下文层” 为了从根源上打破准备阶段的瓶颈，SIXT 决定不再让各个团队各自为战、在局部项目中重复造轮子，而是自顶向下构建一个企业级的**智能体上下文层（Agentic Context Layer）**。这一层向下连接统一的数据仓库、全套应用程序架构和各类数据源，向上以中心化的方式为全公司所有智能体应用提供统一的上下文支持。通过将上下文作为一等公民的基础设施来建设，不论公司的哪个部门要解决什么业务问题，都能直接调用这一上下文底座迅速进入实质开发阶段。这种架构不仅带来了极高的规模经济效应，大幅提升了 Token 使用效率，还从根本上保证了系统集成质量与智能体推理的准确性。 --- ### [03:59](https://www.youtube.com/watch?v=odPx2okPVDE&t=239s) 第一层：本体与语义层（解决“命名碎片化”与数据幻觉）企业构建智能体时面临的首要难题是普遍存在的“命名碎片化问题”（Naming Fragmentation Problem）。以最基础的指标“收入（Revenue）”为例： - 预订团队（Booking Team）眼中的收入是**预订总额（Booked Revenue）**，即系统里所有预约订单的累计金额； - 财务团队（Finance Team）眼中的收入则是**已开票收入（Invoiced Revenue）**，即真正向客户开具发票的金额； - 集团控制团队（Group Controlling Team）又有其特定的核算口径。在 SIXT 内部，仅“收入”这一个概念在不同团队和语境下就可能存在 20 到 25 种不同定义；放眼全公司数千个 KPI，这种语义歧义呈指数级放大。如果直接让 AI 智能体在未经治理的数据层上运行，智能体极易产生混淆，不得不耗费大量算力进行“数据考古”，最终导致两类严重后果：一是产生**数据盲区**，找错底层系统；二是产生**虚假数字（Hallucinated Numbers）**，进而使基于错误数据的自动化决策全盘皆错。为了解决这一问题，SIXT 历时数月构建了**本体与语义层（Ontology and Semantic Layer）**： 1. **语义建模与数据编目**：从源系统提取全部数据，进行标准化建模与编目，附加上所属业务域、语义标签、KPI 计算公式及其背后的业务逻辑代码。 2. **企业级本体（Ontology）**：在语义层之上构建轻量级本体，明确定义核心业务概念（例如：在 SIXT 的世界里什么是“国家”、什么是“网点/门店 Branch”、什么是“客户”），并将所有 KPI 树与核心实体关联映射。这让智能体能够清晰理解业务层级关系，从而进行正确的逻辑推理。 --- ### [07:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=468s) 第二层：知识层（统一“单一真实来源”，消除冲突）企业内部的知识资产往往处于高度碎片化的状态，SOP、流程规范和团队运作机制散落在 Confluence、ServiceNow 或各类 Word 文档中，不仅存在多个互相矛盾的版本，且多年来责任人频繁更替。 SIXT 构建了半自动化的**知识层（Knowledge Layer）**接入机制。每当有新知识输入时，系统会自动进行内省审查：检查该信息是否已经存在、是否与现有规则冲突、是否存在知识缺口需要补充。同时，流程中设置了部门数据资产负责人作为“人机协同（Human-in-the-loop）”的关键校验节点，确保沉淀到上下文层中的每一项流程都是最新、最权威的“单一真实来源（Single Source of Truth）”。 > “如果你的客户服务智能体与辅助人工客服的 Copilot 由不同的数据源驱动，那么你的客户服务流程体验最终会非常糟糕，同一个问题会得到两种完全不同的解答。” 通过将所有面向客户的智能体与面向内部员工的 Copilot 接入统一的知识层，彻底杜绝了不同渠道对外输出矛盾政策的问题。 --- ### [09:44](https://www.youtube.com/watch?v=odPx2okPVDE&t=584s) 第三与第四层：技术架构智能层与代码规范层除了业务语义与知识规范，智能体在执行软件工程与系统变更任务时，还需要对整个技术生态拥有全局认知： ```mermaid flowchart LR accTitle: SIXT 企业级上下文架构的四层模型 subgraph ContextLayer["SIXT 企业级上下文层 (Enterprise Context Layer)"] direction TB L1["1. 本体与语义层 (Ontology & Semantic)"] L2["2. 统一知识层 (Knowledge & SOPs)"] L3["3. 技术全景智能层 (Tech Landscape Intelligence)"] L4["4. 代码规范与仓库层 (Standards & Repositories)"] end subgraph Agents["智能体消费生态"] direction TB A1["本地 IDE / CLI 开发者智能体"] A2["云端自主工程与质量智能体"] A3["客服智能体与员工 Copilot"] end ContextLayer --> Agents ``` - **技术全景智能层（Tech Landscape Intelligence Layer）**：整合了全公司所有应用系统的依赖拓扑、网络连接方式、基础设施运行环境、所消费的数据源与事件流（Event Streams）、代码仓库位置以及系统负责人元数据。该拓扑图会根据实际架构的变动实现按日甚至按分钟级的动态更新。智能体在接手任务时，无需暴力遍历海量代码库（Brute Force）消耗天量 Token，而是能直接精准定位受影响的上下游范围。 - **代码标准与仓库特定层（Coding Standards & Specifics）**：将全公司统一的编码标准、非功能性需求（NFRs）集中管理，开放给所有智能体消费——无论是开发者本地机器运行的 CLI/Codex 工具，还是云端执行自主开发与质量校验的工程智能体，都遵循同一种质量标准。同时，每个代码仓库自身的特定领域模型与业务特性也会被格式化就绪，便于智能体在处理跨多仓库、跨多应用的复杂功能时，能够准确将特定上下文全部纳入考量。这四层统一构成了 SIXT 的**企业上下文层（Enterprise Context Layer）**，成为了驱动全公司各类异构 AI 项目与智能体高效运转的核心底座。 ### [12:08](https://www.youtube.com/watch?v=odPx2okPVDE&t=728s) 统一上下文层驱动的规范驱动开发（Spec-Driven Development） SIXT 构建的统一上下文层并非仅用于特定单一场景，而是作为底层支撑，同时赋能智能体工程（Agentic Engineering）、非技术团队自建方案的低代码平台，以及端到端接管特定业务流程的独立自治智能体（Autonomous Agents）。大约半年前，SIXT 在全公司工程团队中全面推行了“规范驱动开发”（Spec-Driven Development）。虽然软件生命周期的每个环节各有分工，但贯穿始终的核心就是这个统一上下文层——它深度参与了项目定义、需求规范编写以及架构与设计决策的全过程。 ```mermaid flowchart TD accTitle: SIXT 统一上下文层与开发生命周期集成架构 subgraph ContextPlatform["统一上下文基础设施 (Context Infrastructure)"] CL["企业统一上下文层\n(Shared Context Layer)"] CodeIndex["高速索引代码库\n(Fast Searchable Code Index)"] end subgraph SDLC["智能体赋能软件生命周期 (SDLC)"] S1["1. 项目与规范定义\n(Project & Spec Definition)"] S2["2. 架构与方案设计\n(Architecture & Design)"] S3["3. 编码与功能落地\n(Code Execution)"] S4["4. 确定性部署系统\n(Deterministic Deployment)"] end CL -->|"通过 MCP 协议暴露上下文"| S1 CL -->|"通过 MCP 协议暴露上下文"| S2 CodeIndex -->|"检索关联依赖与落地点"| S3 S3 --> S4 ``` 在实际执行编码阶段，由于所有代码库都被建立为可高速检索的全局索引，AI 智能体能够精准知晓新功能应该规划在何处、落地到哪个代码模块以及需要遵循哪些既有逻辑。除了最终的确定性部署系统属于规则化流水线外，软件开发生命周期的每一个前置环节，都通过 MCP（Model Context Protocol）与运行在本地或云端的智能体深度互联，实现了工程全流程的自动化。 --- ### [13:55](https://www.youtube.com/watch?v=odPx2okPVDE&t=835s) 研发提效成果：85% AI生成代码与17倍重构提速在上下文基础设施与规范驱动开发的加持下，SIXT 的研发效率呈现出爆发式增长。年初至今的统计数据显示，SIXT 内部编写的代码中已有超过 85% 由 AI 直接生成，而在去年这一数字仅为 25%。这种跃升不仅体现在代码行数上，更直接反映在日常业务交付的速度与质量上。演讲中列举了三个极具代表性的落地案例以展现上下文赋能带来的显著收益： - **全新产品极速交付**：团队在上周刚上线了一款全新的产品，其实际完成速度比去年底规划该产品时的预估周期整整快了 3 倍。 - **核心预订功能迭代**：预订团队近期上线了一个大型预订功能，交付速度比去年构建同类功能时快了 5 倍。 - **遗留系统全面重构**：近期团队从零开始完全重构了一套历史遗留应用（Legacy Application），实际用时比去年评估该任务所需时间快了 17 倍。 --- ### [15:11](https://www.youtube.com/watch?v=odPx2okPVDE&t=911s) VIP/Vibe 编码平台：非技术人员构建 1200+ 企业级应用为了让非技术业务团队也能直接释放生产力，SIXT 打造了一套面向全员的 VIP/Vibe 编码平台。该平台允许非技术团队调用各类编程智能体（如 OpenAI Codex、Claude 或更偏向前端交互生成的智能体），通过自然语言自主构建应用程序并自动化日常工作流程。 ```mermaid flowchart LR accTitle: SIXT 非技术团队应用构建与治理流水线 subgraph Input["业务端发起"] User["非技术员工 / 业务团队"] -->|"自然语言 / Agent 交互"| Agents["Coding Agents\n(Claude / Codex / 前端 Agent)"] end subgraph Guardrails["平台治理与防护层 (VIP Platform)"] Agents -->|"生成原型与代码"| Engine["策略与防护栏引擎\n(Policy & Guardrails Agents)"] Engine -->|"架构/安全合规检查"| Packaging["自动打包与部署\n(Auto-Packaging & Deploy)"] end subgraph Runtime["企业运行时 (Enterprise Runtime)"] Packaging --> App["企业生产应用 / 流程自动化"] end ``` 针对非工程师“不懂代码底层逻辑”的现实，平台内部构建了多重智能体审查机制与企业级防护栏（Guardrails）： - **策略与合规审查**：自动化策略智能体实时介入，检查生成代码的质量、系统架构合理性，以及是否严格遵守企业级数据访问规范和业务使用准则。 - **全自动打包与部署**：通过合规校验后，平台会自动完成打包、发布与共享分发，让非技术人员一键将方案部署给其他用户使用。 - **全生命周期上下文贯穿**：底层统一上下文层在问题定义阶段为智能体提供企业领域知识，在平台中间层驱动策略引擎规范架构，在运行时严格把控数据访问边界。该平台自 3 月份正式上线以来，增长势头远超预期。最初管理层预计 3 个月内可能诞生两三百个应用，但截至目前，全企业范围内由非工程师独立构建并负责维护的解决方案已突破 1,200 个。 --- ### [17:16](https://www.youtube.com/watch?v=odPx2okPVDE&t=1036s) 核心启示：底层基础设施投资带来的复利效应在演讲的结尾，Boyan Dimitrov 总结了 SIXT 在过去两年深耕企业级 AI 过程中获得的最核心经验与认知： > “如果说今天能让大家带走一条核心建议，那就是：**对底层基础设施（Foundations）的投资，真正会带来巨大的复利效应（Compounding Results）。**” 企业 AI 的瓶颈不在于模型本身，而在于连接数据、业务规范与智能体的共享上下文基础设施。只有把上下文作为第一类基础设施（First-Class Infrastructure）进行全局建设，AI 才能真正从分散的单点实验演变为贯穿技术与业务全链路的规模化生产力倍增器。 ## Notable quotes > 企业级 AI 生产力的瓶颈不在于模型，而在于上下文。谁能在何时以何种形式访问什么数据，决定了 AI 是成为真正的生产力倍增器，还是仅仅停留在孤立的实验集合。 — Boyan Dimitrov > [00:04](https://www.youtube.com/watch?v=odPx2okPVDE&t=4s) 事实上，这些早期项目中超过 70% 甚至 75% 的时间都停留在摸清底层上下文的阶段。 — Boyan Dimitrov > [03:13](https://www.youtube.com/watch?v=odPx2okPVDE&t=193s) 将上下文作为一等公民的基础设施来建设，不论公司的哪个部门要解决什么业务问题，都能直接调用这一上下文底座迅速进入实质开发阶段。 — Boyan Dimitrov > [03:59](https://www.youtube.com/watch?v=odPx2okPVDE&t=239s) 在 SIXT 内部，仅‘收入’这一个概念在不同团队和语境下就可能存在 20 到 25 种不同定义；放眼全公司数千个 KPI，这种语义歧义呈指数级放大。 — Boyan Dimitrov > [07:48](https://www.youtube.com/watch?v=odPx2okPVDE&t=468s) 如果你的客户服务智能体与辅助人工客服的 Copilot 由不同的数据源驱动，那么你的客户服务流程体验最终会非常糟糕，同一个问题会得到两种完全不同的解答。 — Boyan Dimitrov > [09:44](https://www.youtube.com/watch?v=odPx2okPVDE&t=584s) 智能体在接手任务时，无需暴力遍历海量代码库消耗天量 Token，而是能直接精准定位受影响的上下游范围。 — Boyan Dimitrov > [12:08](https://www.youtube.com/watch?v=odPx2okPVDE&t=728s) 虽然软件生命周期的每个环节各有分工，但贯穿始终的核心就是这个统一上下文层——它深度参与了项目定义、需求规范编写以及架构与设计决策的全过程。 — Boyan Dimitrov > [13:55](https://www.youtube.com/watch?v=odPx2okPVDE&t=835s) 年初至今的统计数据显示，SIXT 内部编写的代码中已有超过 85% 由 AI 直接生成，而在去年这一数字仅为 25%。 — Boyan Dimitrov > [13:55](https://www.youtube.com/watch?v=odPx2okPVDE&t=835s) 近期团队从零开始完全重构了一套历史遗留应用，实际用时比去年评估该任务所需时间快了 17 倍。 — Boyan Dimitrov > [15:11](https://www.youtube.com/watch?v=odPx2okPVDE&t=911s) 最初管理层预计 3 个月内可能诞生两三百个应用，但截至目前，全企业范围内由非工程师独立构建并负责维护的解决方案已突破 1,200 个。 — Boyan Dimitrov > [17:16](https://www.youtube.com/watch?v=odPx2okPVDE&t=1036s) 如果说今天能让大家带走一条核心建议，那就是：对底层基础设施的投资，真正会带来巨大的复利效应。 — Boyan Dimitrov ## Mentioned Boyan Dimitrov, SIXT SE, Ai4, OpenAI Codex, Claude, MCP (Model Context Protocol), Confluence, ServiceNow, VIP / Vibe 编码平台 ## Video description Boyan Dimitrov - CTO, SIXT SE The bottleneck for AI productivity in the enterprise isn't the models - it's context. Who has access to what data, when, and in what form determines whether AI becomes a genuine productivity multiplier or stays a collection of isolated experiments. At SIXT, we built a platform layer designed to solve exactly this: shared context and data access as first-class infrastructure, available to both engineering teams and business users. In this session, we will walk through the building blocks - how we made proprietary data accessible, how we created shared context that scales across teams, and what the platform capabilities look like that let non-engineers ship real solutions alongside engineers writing production code. This is not a talk about choosing models or managing GPU costs. It's about the connective tissue that makes an AI-native enterprise actually function at scale. [Source](https://www.youtube.com/watch?v=odPx2okPVDE)

Source quotes

Boyan Dimitrov: 企业级 AI 生产力的瓶颈不在于模型，而在于上下文。谁能在何时以何种形式访问什么数据，决定了 AI 是成为真正的生产力倍增器，还是仅仅停留在孤立的实验集合。 [0:04] Boyan Dimitrov: 事实上，这些早期项目中超过 70% 甚至 75% 的时间都停留在摸清底层上下文的阶段。 [3:13] Boyan Dimitrov: 将上下文作为一等公民的基础设施来建设，不论公司的哪个部门要解决什么业务问题，都能直接调用这一上下文底座迅速进入实质开发阶段。 [3:59] Boyan Dimitrov: 在 SIXT 内部，仅‘收入’这一个概念在不同团队和语境下就可能存在 20 到 25 种不同定义；放眼全公司数千个 KPI，这种语义歧义呈指数级放大。 [7:48] Boyan Dimitrov: 如果你的客户服务智能体与辅助人工客服的 Copilot 由不同的数据源驱动，那么你的客户服务流程体验最终会非常糟糕，同一个问题会得到两种完全不同的解答。 [9:44] Boyan Dimitrov: 智能体在接手任务时，无需暴力遍历海量代码库消耗天量 Token，而是能直接精准定位受影响的上下游范围。 [12:08] Boyan Dimitrov: 虽然软件生命周期的每个环节各有分工，但贯穿始终的核心就是这个统一上下文层——它深度参与了项目定义、需求规范编写以及架构与设计决策的全过程。 [13:55] Boyan Dimitrov: 年初至今的统计数据显示，SIXT 内部编写的代码中已有超过 85% 由 AI 直接生成，而在去年这一数字仅为 25%。 [13:55] Boyan Dimitrov: 近期团队从零开始完全重构了一套历史遗留应用，实际用时比去年评估该任务所需时间快了 17 倍。 [15:11] Boyan Dimitrov: 最初管理层预计 3 个月内可能诞生两三百个应用，但截至目前，全企业范围内由非工程师独立构建并负责维护的解决方案已突破 1,200 个。 [17:16] Boyan Dimitrov: 如果说今天能让大家带走一条核心建议，那就是：对底层基础设施的投资，真正会带来巨大的复利效应。

Source quotes

[0:00] Boyan Dimitrov: The bottleneck for AI productivity in the enterprise isn't the models - it's context. [0:00] Boyan Dimitrov: Who has access to what data, when, and in what form determines whether AI becomes a genuine productivity multiplier or stays a collection of isolated experiments. [0:00] Boyan Dimitrov: This is not a talk about choosing models or managing GPU costs. It's about the connective tissue that makes an AI-native enterprise actually function at scale. [3:59] Boyan Dimitrov: numbers drive everything [12:48] Boyan Dimitrov: three times faster [12:48] Boyan Dimitrov: five times faster [12:48] Boyan Dimitrov: 17 times faster [15:11] Boyan Dimitrov: investing in foundations really has compounding results

Original transcript

[0:04] Nice to be with you. Um today I want to share some [0:08] of uh our insights about eventing context when it comes to uh agentic engineering and [0:14] some of the benefit benefits that we have seen over the past couple of years. Um before we get [0:21] into the topic maybe a few words about six so that you understand so to speak our context and some of [0:26] the challenges that we are uh solving. Sixth is a global mobility uh provider. Uh car rental is [0:34] our core business. Uh but we also offer a large portfolio of other products for our customers. [0:41] Car subscriptions, car sharing, e-haling, van trucks, a lot of other products as well. [0:48] At any point of time, we managed about 300,000 cars across the world in over 105 countries [0:56] across 2,000 locations. So it is a pretty large uh uh setup and uh you know it comes with a lot of [1:05] complexity to battle that complexity we obviously invest heavily in technology and heavily in AI. [1:12] Our journey started when it comes to Genai at least uh late 23 beginning of 24 and as we started [1:20] with our first projects across different areas of six um the first finding was actually that [1:30] a lot of the time that we spent goes not that much in automation not that much in engineering [1:35] but in so to speak preparation. uh most of those projects basically over 70% of the time went into [1:45] setting them up and when we zoomed in to see uh what takes so so long [1:52] basically uh those were some of the buckets that came out pretty quickly um starting with data [2:00] what does different datas or KPI mean where are they plotted how do we access them [2:06] how do processes actually work end to end I we we have to automate them. So we should find out [2:11] the latest and greatest when it comes to SOPs and how those processes run. How do systems connect? [2:17] So all the systems underpinning those processes, which are those, how do we integrate to them? What [2:22] are the best practices there? So this is basically where most of the time of those early projects [2:28] in uh 24 went into and as we were introspecting we decided that um this is one big bucket of time we [2:38] have to attack because we have large ambitions as a company we want to be AI frontier company and uh [2:45] if we want to basically integrate AI into most of our processes [2:49] and we spent over 75% of each of those projects just in prep uh is going to take some time. So [2:58] we started investing in those layers and basically what we did was looking at our [3:05] data warehouse looking at all our application landscape sources of data. We decided to build [3:13] a aentic context layer which is able to fit all our uh uh agentic undertaking from a central place [3:23] so that regardless of which problem we are solving in different parts of our company [3:28] we can always rely on this layer to get us going as fast as possible. Obviously, a lot [3:33] to be said also when it comes to uh economies of scale, token efficiency as well as the quality [3:39] of the integrations and uh uh so to speak the AI projects and agents that we're building. [3:46] In the remainder of this talk, I'm going to showcase some of those layers, [3:51] how we build them, and what purpose they serve and some of the results that we got out of it. [3:59] Starting with the ontology layer and when we speak about ontologies and when we speak about [4:06] semantic layers I mean uh in uh late 24 when we started working heavily on this topic it was I [4:12] would say pretty early but nowadays I'm pretty sure especially with the bus in the last few [4:16] months about this that most of you are familiar with the topic for those of you that might be new [4:22] to explain you the problem think of it like this every large company including ours [4:28] um has a naming problem if you like a naming fragmentation problem. Take a KPI like revenue. [4:35] It's if if when you hear revenue for a company, right? It's a pretty simple term to think about. [4:41] When we zoom in into a larger uh setup like ours, uh it turns out every department, [4:48] every domain, in some cases different teams within the same domain may think about something [4:53] as simple as revenue in very different terms depending on their own semantics. If I ask our [4:59] booking team, they would tell me that revenue for them would be basically booked revenue. [5:06] So whatever the reservations that we got in our systems total to that's their revenue. [5:11] If you ask the same question of some of our finance teams they may say well it's more about [5:16] the invoiced revenue or the revenue that we invoiced our customers. That's actually what [5:21] the the the the the ground for us is but ask our group controlling team they'll have a slightly [5:27] different definition of revenue and so forth it goes right I've put couple of examples on [5:32] this slide. Reality is there might be at any point of time 20 25 different definitions of framework [5:37] depending on the teams and the context. Some companies might have several hundred [5:41] and we're talking about thousands of KPIs that may have the same problem. So when you deploy agents [5:48] on top of uh uh such a landscape, they obviously get easily confused. they may grab the wrong data [5:56] or it takes a while until they basically try to uh uh do some archaeology and figure out [6:01] what is the exactly right revenue number that we should be looking when we analyze a process or [6:06] we're building certain automations. So um this creates two main problems. One is blind spots. [6:13] We are lucky that everything at least in our world is in one data warehouse. to spend years to get [6:18] to that but in many companies all those KPIs would also live in completely different systems [6:22] which means that you might be working of the wrong system to begin with. [6:26] Um and the second piece obviously is hallucinated numbers and numbers drive everything. So if the [6:30] numbers are wrong then obviously everything else that took to took place is also wrong. [6:36] To offset this, we've spent quite some months to basically produce a uh uh [6:45] meaningful layer for our agents to find where the data is and how they can reason about it. [6:52] We took all the data from our source systems. We modeled and cataloged it. We put a lot [6:58] of metadata when it comes to which domain it belongs to, what are the semantics against it. [7:02] KPI definitions, the business logic behind those KPI definitions that becomes our semantic layer. [7:10] On top, we layer this with a small ontology or couple of ontologies [7:16] which basically define terms like what a what what what a country is in the world of six, [7:21] what a branch is in the world of six, how do different KPIs relate to that [7:26] or customer for example, right? How do how are all the different KPI trees modeled and how do [7:32] they relate to the basically biggest uh domains and terms uh in the company which allows an agents [7:40] to figure out much easier how to reason about certain problems or how to answer them. [7:48] The second layer is what we call internally our knowledge layer. Again every company including [7:54] ours we would have a lot of different sources of uh truth so to speak for different teams [7:58] being uh SOPs being process definitions being how things work in a certain team [8:05] and they will be scattered across I don't know in our world it would be confluence or service now or [8:09] word documents right it's a fragment it's it's a very fragmented or was a very fragmented landscape [8:14] in many cases with multiple versions of the truth and uh many owners over the years [8:20] so we spend a lot time and built a process how we get all that knowledge in a agent that we can [8:28] expose for everybody else. It's a semi-automated process which allows us to introspect always our [8:35] knowledge layer and check is this information that is supposed to come in already present. [8:39] Are there any conflicts? Maybe we have a gap and we want to definitely incorporate it. And also [8:43] there is a human in the loop of course which is the owner of the data in the different departments [8:48] that we have at six to make sure that everything that we put in there is the latest and greatest [8:52] when it comes to how certain things work. And to illustrate why this layer is important, think of [8:59] customer service. Many of you probably have already built customer service agents that [9:04] uh help your customers solve their problem. Some of you have also built c- pilots for our customer [9:10] service team so that it assist they assist them with the more complex tasks. If those two are fed [9:18] by different data sources, well, your customer service process ends up being pretty poor. [9:24] The same the same question gets answered in two different ways. To avoid that, it's obviously [9:28] essential that you have one place to fit that. And that's exactly what we did here. making sure that [9:33] all the different agents in a very large scale process are always fed by the same [9:39] source of truth. Moving on, our um tech landscape intelligence layer, we took all the information [9:50] when it comes to applications, how they connect to other applications, what are their dependencies, [9:55] not only on the application side, but also when it comes to how they connect to each other, [10:00] infrastructure dependencies, where they run, what data sources do they use, [10:05] what event streams do they use, metadata in terms of who owns that applications, [10:10] and Where are the code repositories? All of that so that agents when they start solving a problem [10:16] they don't have to brute force through code basis and again put in certain amount of tokens and get [10:20] the wrong conclusions but always have a source of truth which is dynamically update itself as our [10:26] landscape changes on a daily or minute based and know um you know what is the scope and the context [10:34] of certain applications and as we ask agents to do changes for us how to navigate that landscape. [10:42] Last but not least, all our standards, coding standards, non-functional requirements that we [10:47] have companywide centralized made again available to agents regardless of where those agents run. [10:52] Might be your local CL or Codex that runs on the developer machine or could be also our [10:57] cloud agents that do autonomous uh uh engineering work or quality verification work. They have all [11:03] access and they're all basically sourcing the best practice from a single place. uh making sure that [11:11] uh in the end we have one word when it where one standard when it comes to quality but also [11:17] when it comes to individual repositories we can put all the specifics in the repository already [11:23] ready to be ingested by agents making sure that if there any specifics for this application that [11:27] have to be considered anything to do with domain models etc it can always be referenced by agents [11:33] as they work on a particular problem because at least in our world a problem a feature often spans [11:39] multiple repositories, multiple applications and therefore it's important that all specifics are [11:44] also taken into account. All those four layers is so to speak our enterprise context layer [11:52] and they fit pretty much any use case we have. Now I've put a couple of those use cases on those [11:57] slides. Uh but in fact there are many those three use cases however I hope illustrates [12:03] the diversity of the different projects that we power with the same context layer [12:08] could be our agentic engineering approach could be our viing platform for example that we are [12:14] going to zoom into in a in a second. This is the platform that our non-technical teams use [12:19] to produce solutions themselves to optimize their productivity their team's productivity. etc. [12:25] Or it could be dedicated autonomous agents that basically take care of certain processes and their [12:32] job at that point is to make sure that they own a process end to end. All of those different use [12:37] cases would basically get fed by the same context layer that we've built across uh the organization. [12:48] Zooming into engineering, few words on that. We've adopted uh half a year ago specdriven [12:55] development for pretty much all our engineering teams. Uh we don't have time to dive into it but [13:01] what's important for this context here is that it is the same layers that I just mentioned [13:07] that are pretty much uh on the enabling side on automating every single step of the software [13:13] developer life cycle that you have here. They're present pretty much when it comes to how we define [13:19] projects, how we define specs, how we define basically the design and architecture piece. [13:24] They're present when it comes to execution, having access to uh or having access to basically all the [13:31] code indexed in a fast searchable way so that they know exactly when a feature needs to be planned, [13:37] where it lands and what they need to consider. Every single step on the way apart from step [13:43] five which is more to do with our deterministic deployment system are heavily interconnected [13:48] with those context layers that we basically expose over MCP to local and cloud agents. [13:55] Some results as we have been going on this approach if I look year to date the statistics [14:02] over 85% of the code you write internally has been written by AI in contrast to 25% last year. So [14:09] things have sped up a lot. Couple of examples just to illustrate basically dayto-day wins. [14:17] We recently launched a completely new product uh actually last week [14:22] which we managed to finish three times faster and then we basically speced out [14:26] end of last year. So you know the diff is not that big. Um looking at features, we launched [14:33] recently a large uh uh booking feature as part of our booking uh team world and that was delivered [14:40] five times faster than a similar feature that we built last year or recently we also rebuilt [14:47] a uh legacy application from scratch and that took 17 times faster than again what we estimated [14:55] uh it could take last year. So things are evolving quickly and we're happy to see some of the returns [15:02] of those layers that we underpin uh basically our whole AI journey on uh uh already taking place. [15:11] Our VIP coding platform again it's a talk on its own but uh for for for the scope of this session [15:17] this is a platform we built for enabling our non-technical teams to use any agents could be [15:25] the codex or the or clo similar to our engineering teams or it could be also some more frontend first [15:32] agents to basically build applications and automate tasks and topics that they [15:38] have on a daily basis. The platform itself takes everything they've built, runs a lot of different [15:45] policy and guardrails agents on top of it, making sure that the code is, you know, because they're [15:50] not a genius, they don't understand code. The code is okay, the architecture is okay. [15:54] It follows our enterprise policies, when it comes to data access, when it comes to use cases, etc., [15:58] etc., etc. It packages everything automatically and allows them to get it deployed and share with [16:04] uh other users. This is basically the platform we built for them. And again the same context layer [16:11] that I just described is pretty much participating in every step of the process. It infuses obviously [16:19] uh uh the context for the coding agents at the very beginning when it comes to [16:24] uh basically problem definition and how this problem should be solved architecture etc. [16:30] It defines the behavior of our policy engines of our [16:34] as part of our platform to make sure that again everything is governed at an enterprise scale [16:40] and when it comes to runtime it ensures the data access and everything else again follows the [16:45] best practices that we have defined for our business. Um so end to end across the board [16:52] few results here as well we've launched that platform in March [16:56] by now we have over 1,200 solutions across the entire enterprise built and owned by non-engineers [17:04] which is pretty crazy if you would ask me beginning of March I was betting more of [17:08] couple of hundred uh for three months but you know uh things have accelerated. All right. If I have [17:16] one message for you that you can leave uh this room with, it is that investing in foundations [17:23] really has compounding results. And this has been our takeaway and our lesson from the last [17:30] two years in working on this topic. Uh and I hope it helps you as well. [17:36] Thank you very much for listening. It's been a pleasure being with you today.