Checksum Builds Code World Model to Halt AI-Driven Outages

The Missing Half of AI Coding With Checksum — Ai4

Ai4

Autonomous software engineering requires deterministic production simulation rather than AI-generated unit tests because large language models fail to anticipate real-world runtime states.

AI-assisted summary of The Missing Half of AI Coding With Checksum — original source. Check the original for full context.

Source published: 2026-08-16

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 16, 2026, this presentation features Gal Vered, Co-Founder and CEO of Checksum. According to the video description, Vered explores why verification remains the broken half of AI software development and introduces the 'Code World Model'—a simulation layer modeled after autonomous vehicle engineering that validates code before shipping.

## TL;DR Gal Vered explains that while AI coding agents have dramatically increased code generation velocity, they have also triggered a surge in production outages and manual review bottlenecks due to a 'context void' around runtime states. To achieve truly autonomous engineering, probabilistic LLMs must be paired with deterministic verification engines rather than more LLM-based reviewers. Checksum introduces a Code World Model that acts as a production digital twin, compressing a week's worth of complex distributed traffic, database mutations, and failure conditions into a five-minute simulation. Empirical benchmarks demonstrate that providing autonomous agents with deterministic replay tools elevates mergeable task success rates from 30% to 90%, shifting the industry focus away from brittle unit tests toward comprehensive behavioral validation.

## Atmosphere & style The presentation carries a pragmatic, sharp, and industry-insider tone that balances relatable engineering pain points with high-conviction technical vision. Vered speaks conversationally and candidly, blending dry humor about 'vibe coding' and early computer bugs with rigorous architectural diagrams and benchmark data. It feels like an authoritative technical pitch and strategy session, transforming the anxiety around brittle AI code into an organized, deterministic blueprint for the future of software development.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=4s) Developer trust in AI coding tools has surged, but the resulting flood of AI-generated pull requests has driven a parallel increase in production incidents and rollbacks. - [00:04](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=4s) Manual code review of AI output has become the primary bottleneck constraining the full productivity potential of autonomous software engineering. - [02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) LLMs fail in production due to a 'context void': while models master isolated syntax, production systems depend on dynamic runtime state, database concurrency, and environmental quirks that cannot fit in a prompt. - [02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) Major production outages like Cloudflare or CrowdStrike stem from subtle interaction failures across interconnected systems rather than simple syntax errors. - [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) Software engineering is shifting from writing code to observing and verifying behavior via realistic execution paths and runtime telemetry. - [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) Relying on non-deterministic LLMs to check LLM-written code is insufficient; autonomous software delivery requires a deterministic verification layer to achieve 99.999% confidence. - [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) Much like Waymo simulates millions of driving miles before road deployment, software requires a 'Code World Model' that compresses a week of production traffic and failures into a five-minute simulation. - [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) Once high-fidelity simulation exists, source code becomes an implementation detail akin to assembly language, freeing developers from managing low-level plumbing. - [11:50](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=710s) Internal benchmarks showed that giving agents production replays and deterministic checks raised task completion rates from 30% to 90%, whereas LLM-only review provided minimal improvement. - [14:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=859s) Checksum delivers tests purely as standard open-source code (Playwright, pytest) to remain native to the agent's context and workflow without proprietary overhead. - [14:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=859s) Deterministic flakiness filtering and a centralized knowledge base of user traffic and past outages ensure reported test failures reflect genuine regressions. - [16:30](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=990s) Traditional unit tests are becoming less effective because AI models tend to write tests that mirror the exact flawed assumptions embedded in their buggy code.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=4s) The Paradox of AI Productivity and the Incident Bottleneck

Gal Vered, co-founder and CEO of Checksum, introduces the core mission of his company: building an agentic verification platform powered by continuous quality agents. By orchestrating end-to-end and API testing, Checksum aims to provide a safety net that lets software engineers fully embrace autonomous AI development with the certainty that every shipped commit is bug-free. Reflecting on the state of the industry over the past twelve months, Vered notes that developer trust in AI coding tools has skyrocketed alongside improvements in model capabilities and agent harnesses. Teams are shipping unprecedented volumes of code, pull requests, and tickets, driving visible productivity gains across engineering organizations.

However, this explosion in AI-generated output has triggered an equally direct surge in production incidents. Invoking a simple "vibe check," Vered points out that everyday consumer and enterprise software feels noticeably more brittle and prone to blocking defects. Industry statistics confirm this intuition: the vast majority of engineering teams have shipped outages caused directly by AI-authored code and have been forced into emergency rollbacks. As a result, developers are spending the bulk of their working hours manually reviewing large volumes of AI pull requests. This verification drag has emerged as the true bottleneck holding back the promise of autonomous software engineering.

- Developer trust in AI coding assistance has risen dramatically over the last twelve months alongside measurable increases in PR and ticket velocity. - The surge in AI-generated code correlates directly with an uptick in production incidents and rollbacks. - Manual code review of AI output has become the primary bottleneck in the software development lifecycle.

---

[02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) The Context Void: Why Syntax Solvers Struggle with Production Runtime

To understand why sophisticated models produce buggy software, Vered highlights what Checksum calls the "context void." Large language models excel at syntax and isolated code generation for two reasons: they are trained on massive corpuses of open- and closed-source software, and coding against small, self-contained codebases represents the ideal LLM task—a relatively small volume of token data requiring deep reasoning. The failure occurs because production software is fundamentally not just code. It is an intricate web of runtime state, fluctuating user inputs, database records, race conditions, undocumented third-party API quirks, and disparate environmental configurations.

```mermaid flowchart TD accTitle: The Context Void in AI Code Generation

subgraph LLMStrengths ["What LLMs Master (Syntax Domain)"] A["Training Data Corpora"] --> C["Code Syntax & Logic"] B["High-Reasoning Small Datasets"] --> C end

subgraph ProductionReality ["What LLMs Miss (Runtime Domain)"] D["User Traffic & Dynamic Inputs"] E["Database States & Race Conditions"] F["Undocumented 3rd-Party APIs"] G["Multi-Tenant Local Regulations"] end

C -.->|"Fails across the Context Void"| H["Production Outages & Breakages"] ProductionReality --> H ```

This runtime layer involves terabytes of messy, distributed state that LLMs cannot readily ingest or reason over in a prompt window. Vered shares the example of an enterprise customer running identical software across thousands of instances, where every single deployment behaves differently due to local city, state, and national regulatory requirements. When AI agents attempt to ship changes into such environments, unit tests and syntax linters pass, but the application breaks in the real world. Pointing to historic outages at Cloudflare and CrowdStrike, Vered emphasizes that catastrophic system failures are almost never simple syntax mistakes like an LLM typing `a + b` instead of `a - b`. Instead, they occur in the void between hundreds of thousands of interacting components under real runtime conditions.

- LLMs excel at syntax and high-reasoning tasks over small, discrete code contexts. - Production failures stem from runtime complexity: database states, asynchronous queues, third-party integrations, and environment-specific behaviors. - Major internet outages (e.g., Cloudflare, CrowdStrike) result from subtle interaction failures across interconnected systems rather than simple syntax or logic typos.

---

[05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) The Shift Toward Behavior: Why Coding Agents Need Deterministic Counterparts

Tracing the rapid evolution of software engineering, Vered observes that two years ago the core job was writing code. Today, outside of high-level architecture and planning, an engineer's primary job is reviewing AI-generated code. The next evolutionary leap required to reach the "singularity point of software development"—an autonomous software factory capable of handling complex enterprise systems—is shifting focus entirely to observing and verifying behavior. Observing behavior requires two distinct capabilities: triggering the software through realistic execution paths and analyzing the resulting runtime exhaust (logs, metrics, and state mutations) to diagnose failures.

Vered argues that while modern vibe coding works for hobbyist applications through quick feedback loops (prompting, running, and reprompting), enterprise development requires an industrial-grade verification counterpart. Today's ecosystem suffers from an over-reliance on non-deterministic LLMs for every stage: LLMs write the code, LLM sub-agents review it, and LLM orchestrators deploy it. To ship autonomously without human intervention, probabilistic coding agents must be paired with an uncompromising, deterministic verification engine that can prove software works to a 99.999% degree of confidence.

> "To reach to a point where we're shipping software autonomously, you have to have a deterministic counterpart... If you build this deterministic verification layer, I believe that software development becomes a solved problem."

---

[08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) The Waymo Analogy and the Code World Model

To illustrate the necessity of pre-deployment validation, Vered presents a thought experiment: the absolute fastest way to ship software is to deploy directly to production, leave it for a week, observe what breaks, and fix the issues. While optimal for raw velocity, it is also "the fastest way to piss off your customers." The solution is to replicate the simulation playbook developed by the autonomous vehicle industry. When Waymo prepares to release a new driving model in San Francisco, the system drives millions of simulated miles in a lab environment before it ever touches a physical vehicle or real-world sensor, achieving near-total verification prior to road testing.

Checksum applies this principle to software engineering via the "Code World Model"—a high-fidelity digital twin of an enterprise production environment. Rather than testing isolated functions, the Code World Model simulates the entire production ecosystem: real and synthetic user behaviors, distributed queues, database mutations, third-party latency, and simulated infrastructure outages. It compresses a week's worth of live production traffic into a five-minute simulation run, surfacing edge-case breakages before code is merged. Once this simulation capability exists, source code becomes analogous to assembly language: an implementation detail that humans no longer need to read, write, or manually optimize for technical debt.

```mermaid flowchart LR accTitle: The Code World Model Simulation Loop

subgraph AgentSpace ["Agentic Workspace"] A["Coding Agent Generates Code"] end

subgraph SimulationSpace ["Code World Model (Digital Twin)"] B["Simulate Week of Production (5 Min)"] C["User Traffic, DB State, Outages, APIs"] B --- C end

subgraph VerificationEngine ["Deterministic Verification"] D{"99.999% Confidence?"} E["Autonomous Production Release"] F["Deterministic Failure Traces"] end

A --> B B --> D D -- "Yes" --> E D -- "No" --> F F --> A ```

- Waymo validates autonomous driving models across millions of simulated lab miles before deploying them to physical streets. - The Code World Model acts as a digital twin that simulates an entire production week (users, queues, databases, API outages) in five minutes. - Comprehensive simulation abstracts source code into low-level plumbing (like assembly code), allowing developers to focus solely on high-level intent and behavior.

---

[11:50](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=710s) From the First Bug to the Last Bug & Empirical Benchmarks

Displaying an archival photo of the famous first documented computer bug—a moth taped into a Harvard Mark II relay logbook by Grace Hopper's team—Vered jokes about the physical origin of the term when code was punched into paper tape. Checksum's overarching north star is to build an environment that uncovers the "last documented bug," creating verification infrastructure so comprehensive that production software defects become historical relics.

To validate the impact of deterministic testing on AI agents, Checksum ran an internal benchmark using ten multi-day, highly complex tasks taken directly from their engineering backlog. The tasks were assigned to autonomous coding agents under three experimental conditions:

The benchmark demonstrates that stacking probabilistic tools (such as having LLMs review LLM-written code) yields marginal improvements. In contrast, providing agents with deterministic execution tools and production-like feedback loops dramatically elevates their ability to produce merge-ready enterprise software.

---

[14:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=859s) Checksum’s Architecture: Dual Loops and Code-Native Verification

Vered walks through Checksum’s current architecture, presenting what he jokingly calls his "mandatory loop slide." The platform operates around two interlocking operational cycles: the Generate and Maintain Loop, and the Run, Report, and Fix Loop. A core architectural principle is that all generated tests are delivered purely as native, open-source code (utilizing frameworks like Playwright, pytest, and standard API testing suites). This ensures the tests live directly within the agent’s existing context surface, removing the need for coding agents to learn proprietary APIs or external test runners.

```mermaid flowchart TD accTitle: Checksum Dual-Loop Verification Architecture

subgraph Loop1 ["Loop 1: Generate & Maintain"] G1["Monitor Application & PR Changes"] --> G2["Synthesize Full-System Tests"] G2 --> G3["Maintain & Update Existing Suites"] end

subgraph Loop2 ["Loop 2: Run, Report & Fix"] R1["Execute Open-Source Tests (Playwright / PyTest)"] --> R2["Deterministic Flakiness Filter"] R2 --> R3["Triaged Real Bugs & Automated Fix Traces"] end

subgraph KnowledgeCore ["Enterprise Knowledge Base"] K1["Developer Intent"] K2["User Traffic Patterns"] K3["Production Incident Data"] end

KnowledgeCore <--> Loop1 KnowledgeCore <--> Loop2 R3 -->|"Actionable Feedback"| G1 ```

Checksum's agents continuously analyze codebase modifications, generate full-system test suites that mimic real user journeys, and maintain them as the application evolves. When tests run, an integrated verification layer deterministically weeds out test flakiness, guaranteeing that reported failures represent genuine software regressions rather than environmental noise. Everything feeds into a shared enterprise knowledge base that synthesizes insights from user telemetry, developer intent, and past production outages. This infrastructure lowers the engineering cost of generating and maintaining tests while unlocking vastly higher reliability for autonomous coding workflows.

- Tests are delivered as code using standard open-source tooling (Playwright, pytest, API tests) to stay native to the AI agent's environment. - The platform incorporates a flakiness filter so that flagged failures represent verified defects rather than transient false positives. - A centralized knowledge base continuously ingests developer feedback, real user traffic, and historical incidents to refine the testing model.

---

[16:30](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=990s) Q&A: The Declining Role of Unit Tests

During the audience question-and-answer period, an attendee asks whether the shift toward full-system behavioral observability renders traditional unit tests obsolete or turns them into technical debt. Vered responds that unit tests are indeed becoming significantly less important in the age of generative development. Because engineers no longer write every line of code by hand, they also delegate unit test creation to AI models. However, models possess an inherent bias when evaluating their own output: they generate passing unit tests that conform to the exact flawed assumptions embedded in their buggy code.

Consequently, Checksum has observed a measurable decline in the percentage of real-world bugs caught by standard AI-generated unit and integration tests. While there remains distinct value in human engineers deliberately architecting high-level validation frameworks—or utilizing specialized platforms designed to enforce deep verification—simply asking coding assistants to generate basic unit tests offers diminishing returns. True deployment confidence requires moving past code-level unit checks toward comprehensive, production-grade behavioral simulation.

## Notable quotes > AI coding agents have solved the easy problem. The hard part, Verification, remains broken. — Gal Vered

> The Code World Model: the infrastructure layer that lets AI agents simulate production before a single line ships, closing the gap between what an agent can see and what actually determines whether software works. — Gal Vered

> [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) To reach to a point where we're shipping software autonomously, you have to have a deterministic counterpart... If you build this deterministic verification layer, I believe that software development becomes a solved problem. — Gal Vered

> [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) the fastest way to piss off your customers — Gal Vered

## Mentioned Gal Vered, Checksum, Ai4, Cloudflare, CrowdStrike, Waymo, Grace Hopper, Harvard Mark II, Playwright, pytest, Code World Model

## Video description Gal Vered - Co-Founder and CEO, Checksum

AI coding agents have solved the easy problem. The hard part, Verification, remains broken. In this talk I'll introduce the Code World Model: the infrastructure layer that lets AI agents simulate production before a single line ships, closing the gap between what an agent can see and what actually determines whether software works. I'll explain why coding agents need the same world model solution autonomous vehicles found. Attend if you're building or betting on autonomous software engineering.

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

中文简报

Checksum构建代码世界模型以遏制AI引发的生产故障自主软件工程需要确定性的生产环境模拟，而非AI生成的单元测试，因为大语言模型无法预见真实的运行时状态。 Gal Vered解释称，尽管AI编码智能体大幅提高了代码生成速度，但由于运行时状态方面的“上下文真空”，它们也引发了生产故障的激增和人工审查瓶颈。为了实现真正的自主工程，概率性LLM必须与确定性验证引擎相结合，而非引入更多基于LLM的审查工具。Checksum推出了充当生产环境数字孪生的代码世界模型，可将一周内复杂的分布式流量、数据库变更和故障条件压缩为5分钟的模拟。实证基准测试表明，为自主智能体提供确定性重放工具能将可合并任务的成功率从30%提升至90%，从而推动行业重心从脆弱的单元测试转向全面的行为验证。开发者对AI编码工具的信任度大幅上升，但由此带来的海量AI生成Pull Request也导致生产事故和版本回滚同步增加。 (0:04) 对AI输出进行人工代码审查已成为制约自主软件工程充分释放生产力潜力的主要瓶颈。 (0:04) LLM在生产环境中失效是由于存在“上下文真空”：尽管模型精通孤立的语法，但生产系统依赖动态运行时状态、数据库并发和无法容纳在提示词中的环境特异性。 (2:10) 像Cloudflare或CrowdStrike发生的重大生产中断，均源于互联系统之间细微的交互失效，而非单纯的语法错误。 (2:10) 软件工程正在从编写代码转向通过逼真的执行路径和运行时遥测来观察并验证系统行为。 (5:19)

Reading summary

Gal Vered, CEO of Checksum, argues that the critical bottleneck in software development has shifted from code generation to code verification, as AI-generated output triggers frequent production incidents. He contends that autonomous software delivery requires pairing probabilistic coding models with deterministic runtime simulation rather than relying on manual code reviews or AI-generated unit tests. The Productivity Paradox and the Context Void (0:04) Over the past twelve months, developer trust in AI coding tools has increased alongside measurable gains in pull request and ticket throughput. However, Vered observes that this rapid output has created a direct surge in production failures and emergency rollbacks across engineering organizations. Software engineers now spend the majority of their time manually auditing AI-authored pull requests, transforming verification into the primary bottleneck of modern software delivery. Vered attributes this instability to a fundamental "context void." Large language models excel at reasoning through syntax and discrete, localized logic, but production software operates as a messy network of runtime states, race conditions, fluctuating traffic, and third-party dependencies. Highlighting outages at Cloudflare and CrowdStrike, Vered notes that catastrophic failures stem from subtle interactions across distributed environments rather than basic syntax errors, making prompt-window reasoning insufficient for real-world reliability. Limits of Probabilistic Reviews and Unit Tests (5:19) Vered cautions against the common practice of stacking non-deterministic models—using LLM agents to write code, review pull requests, and orchestrate deployments. In Checksum's internal benchmark evaluating ten multi-day backlog tasks, an autonomous agent relying on LLM sub-agents for review produced mergeable code only 30% of the time (3 of 10 tasks). Providing the agent with unit and integration test suites increased the success rate to 60%, while validating against deterministic failure replays and deep runtime checks yielded a 90% mergeable rate. Addressing audience questions, Vered states that standard unit tests are suffering from diminishing returns in generative workflows. When engineers delegate unit test creation to AI, the models frequently write passing tests that replicate the same flawed assumptions embedded in their generated code. As a result, AI-authored unit tests catch a declining share of genuine defects, underscoring the need for deterministic behavioral testing rather than isolated code-level checks. Simulating Runtime with the Code World Model (8:46) Drawing an analogy to autonomous vehicle testing, Vered notes that Waymo evaluates driving models across millions of simulated lab miles before deploying them to physical streets. Checksum applies this concept through what it terms a "Code World Model"—a digital twin of an enterprise environment designed to compress a full week of production traffic, distributed queues, database mutations, and synthetic outages into a five-minute simulation. According to Vered, achieving high-confidence behavioral simulation allows engineering teams to treat source code as an implementation detail similar to assembly language. Once deterministic systems can verify software behavior to a 99.999% confidence level prior to release, developers can focus on high-level architecture and intent rather than manually reading lines of code or managing technical debt. Code-Native Architecture and Flakiness Mitigation (14:19) Checksum's platform runs on two interconnected operational cycles: a Generate and Maintain Loop, alongside a Run, Report, and Fix Loop. To prevent AI agents from needing to learn proprietary test harnesses, test suites are generated purely as native, open-source code using established frameworks like Playwright and pytest, ensuring tests reside directly within the agent's code repository. The architecture incorporates a deterministic flakiness filter to eliminate environmental false positives, ensuring that reported failures represent genuine regressions. Both execution loops continuously exchange data with a centralized enterprise knowledge base that aggregates user telemetry, developer intent, and historical incident records to keep dynamic test coverage aligned with evolving production behavior. Checksum aims to construct verification infrastructure robust enough to make production software bugs historical relics, yet the approach fundamentally relies on whether digital-twin simulations can accurately reflect complex, live enterprise environments without prohibitive operational overhead.

精炼阅读摘要

Checksum 联合创始人兼首席执行官 Gal Vered 指出，AI 编码工具的大规模应用虽大幅提升了代码交付速度，但由于模型缺乏对生产运行环境复杂交互的认知，导致线上故障激增并使人工代码审查沦为核心瓶颈。他认为，要实现完全自主的软件工程，必须用确定性的行为验证层与高保真运行模拟来替代脆弱的概率性审查。 AI生产力悖论与运行时的上下文真空 (0:04) Vered 观察到，过去 12 个月内开发者对 AI 编程工具的信任度显著上升，Pull Request 和工单处理速度大幅加快，但伴随而来的却是生产环境故障与紧急回滚的同步激增。由于大量工程团队都遭遇过由 AI 编写代码直接导致的线上停机，开发者不得不将大部分工时转用于人工审查 AI 生成的代码，导致验证环节成为自主软件开发生命周期中的首要阻碍。 Vered 将此问题归结为“上下文真空”。大语言模型擅长处理语法规则和小型独立代码库中的高推理任务，但真实的生产系统涉及动态用户流量、数据库复杂状态、并发竞争条件、未公开的第三方 API 以及各地法规配置等数以 TB 计的分布式运行时状态。像 Cloudflare 或 CrowdStrike 的历史性宕机事故，均源自系统互联组件间的交互失效而非简单的语法错误。大语言模型无法在提示词窗口内推理此类环境，导致代码即便通过单元测试与语法检查，在实际部署中仍会发生崩溃。行为观测与确定性验证引擎的必要性 (5:19) 软件工程的工作重点在过去两年中已从手动编写代码转向审查 AI 代码。Vered 认为，软件工程迈向企业级自主化的下一个飞跃，是将重心彻底转向观测与验证软件的运行时“行为”，这包括通过真实执行路径运行软件，并分析日志、指标与状态突变等运行时痕迹来定位故障。 Vered 强调，业余项目的“感觉编码”（vibe coding）可以通过快速试错完成迭代，但企业级交付需要工业级的验证工具。当前行业过度依赖非确定性的大语言模型进行代码编写、子代理审查及部署编排，这种概率性工具的层层叠加无法满足企业级可靠性要求。他断言，若要实现无需人工介入的自主软件发布，必须引入能提供 99.999% 置信度的确定性验证引擎作为对应保障。代码世界模型与自动驾驶级仿真模拟 (8:46) 为了在保障系统稳定的同时维持极高的交付速度，Vered 借鉴了自动驾驶汽车行业的验证思路。正如 Waymo 在旧金山实地部署前必须在实验室内模拟数百万英里的虚拟行驶一样，软件部署也应在上线前完成深度模拟，以避免直接在生产环境中试错而损害客户信任。 Checksum 据此提出了“代码世界模型”，该模型充当企业生产环境的高保真数字孪生体，能在 5 分钟内压缩模拟一整周的真实生产状态，涵盖合成与真实用户流量、分布式消息队列、数据库突变、第三方 API 延迟及基础设施故障。Vered 设想，当全真模拟能够前置暴露边缘缺陷时，源代码将退化为类似汇编语言的底层细节，开发者将无需再手动阅读代码或处理技术债务。经验基准测试与传统单元测试的局限 (11:50) Checksum 针对其工程待办列表中的 10 个多日复杂任务进行了内部基准测试。数据显示，仅配备基础代码库及自我审查子代理的 AI，任务合并成功率仅为 30%；当加入标准单元测试和集成测试后，成功率提升至 60%；而当为代理配备生产故障重放与深度确定性检查时，任务成功率跃升至 90%。测试表明，叠加概率性审查模型的收益有限，确定性的真实执行反馈才是关键突破口。在问答环节中，Vered 进一步指出，传统单元测试在生成式开发时代的有效性正持续下降。当工程师把编写测试的任务也委托给 AI 时，模型在评估自身产出时存在固有偏见，往往会基于其代码中的错误假设生成表面通过的单元测试。Checksum 观察到标准测试拦截真实漏洞的比例正在降低，因此仅依靠提示词生成单元测试已无法提供充分的发布信心，必须转向全系统行为验证。 Checksum 正在通过双循环架构生成原生开源代码测试并过滤偶发性测试假阳性，致力于将生产故障彻底变为历史。然而，在架构高度异构且动态复杂的现实企业环境中，数字孪生模拟器能否低成本且高保真地还原千差万别的运行状态，仍是该模式面临的核心现实考验。

Detailed notes — zh

## Background 该视频由 YouTube 频道 Ai4 于 2026 年 8 月 16 日发布，内容为 Checksum 联合创始人兼 CEO Gal Vered 的主题演讲。演讲探讨了当前 AI 编程智能体虽解决了代码生成但缺乏有效验证的行业困境，并介绍了借鉴自动驾驶仿真机制构建的“代码世界模型（Code World Model）”，旨在帮助开发者在代码上线前模拟生产环境以确保软件可靠性。 ## TL;DR 演讲指出 AI 编程虽大幅提升了代码产出效率，但因大模型无法理解数 TB 级的动态生产运行时上下文，导致线上事故频发且代码审查成为新瓶颈。借鉴 Waymo 自动驾驶仿真测试的思路，Checksum 提出了作为数字孪生的“代码世界模型”，将开发重心从审查代码转向观察与验证行为。实测基准表明，生产级确定性验证能将 AI 智能体的代码成功合并率从 30% 提升至 90%。同时，针对 AI 自编自测导致单元测试价值下降的现状，演讲强调了自顶向下构建端到端确定性验证闭环的必要性。 ## Atmosphere & style 演讲风格务实沉稳且极具技术洞察力，直击当下开发者对 AI 代码“既依赖又担忧事故”的现实焦虑。主讲人通过引入计算机历史上“第一只真实 Bug 飞蛾”的趣闻活跃现场气氛，并巧妙借助自动驾驶的成熟经验进行类比，使复杂的架构概念通俗易懂。整体叙事由浅入深，严谨的实验数据与清晰的行业愿景相结合，给听众带来了关于自主软件工程未来演进方向的深刻启发与信念感。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=4s) 开发者对 AI 编程的信任度显著上升，但代码产出的激增导致生产事故和版本回滚率同步攀升，人工代码审查已成为研发交付的核心瓶颈。 - [02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) AI 频繁引入事故的根源在于“上下文缺口”：大模型精通静态语法和小数据域逻辑推理，但无法理解包含海量状态组合与未记录 API 的多 TB 级生产运行时数据。 - [02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) 灾难性故障极少源于单元测试能捕捉的单行语法错误，往往是在成千上万组件相互作用的“上下文真空”中爆发的系统级崩溃。 - [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) 软件工程正在经历范式转移：从两年前的“编写代码”、当下的“审查代码”，全面迈向下一代的“观察软件运行行为”。 - [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) 实现自主软件工程无需依赖基础大模型的持续跃升；只要构建具备 99.999% 置信度的确定性验证层，自主交付本质上已是可解决的问题。 - [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) 借鉴自动驾驶（如 Waymo）在虚拟仿真中跑完数百万英里的经验，软件工程需要建立“代码世界模型”，在 5 分钟内完整模拟上一周的生产环境全貌。 - [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) 当生产级数字孪生仿真成熟后，源代码将演变为类似“汇编语言”的底层实现，技术债务对工程吞吐量的阻碍将被大幅钝化。 - [12:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=739s) Checksum 的愿景是从计算机历史上“第一个 Bug”（物理飞蛾）迈向“最后一个被记录的 Bug”，在代码交付前彻底拦截所有缺陷。 - [12:56](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=776s) 基准测试表明：仅靠多 Agent 互相审查，高难任务合并率仅 30%；加入单元与集成测试后提升至 60%；而接入生产级仿真与边缘故障回放后，成功率跃升至 90%。 - [12:56](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=776s) 纯粹依赖“LLM 审查 LLM”会陷入无效死循环，编码 Agent 真正需要的是能切实运行软件、检验真实行为的确定性工具。 - [14:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=859s) Checksum 采用“测试即代码”理念，生成开源标准格式（如 Playwright、pytest）的测试用例，并通过专有验证层过滤不稳定测试（Flakiness），确保告警必定对应真实 Bug。 - [16:30](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=990s) 传统单元测试的重要性正在显著下降并有演变为技术债的趋势，因为 AI 会顺着自身预设的错误逻辑生成“完美通过”的单元测试，极难捕获深层缺陷。 - [16:30](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=990s) AI 时代的核心质保底线必须来自自顶向下架构的真实生产级验证链路，而非简单要求大模型自动生成孤立的单元测试套件。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=4s) AI 编程的信任度上升与生产事故的激增 Checksum 的联合创始人兼 CEO Gal Vered 开门见山地介绍了公司的定位：Checksum 是一个智能体验与端到端验证（agentic verification）平台。通过部署持续质量代理（Continuous Quality Agents），利用 API 与端到端（E2E）测试，确保开发者交付的每一行代码都能正常运行且无 Bug，从而让开发者能够全力投入 AI 驱动的软件开发。回顾过去 12 个月的发展历程，Gal 指出开发者对 AI 的信任度正在呈爆发式增长。随着基础大模型（LLM）能力的跃升和 Harness 架构的演进，团队借助 AI 交付了海量代码，拉取请求（PRs）、工单处理量等各项生产力指标均大幅提升。然而，信任度的提升伴随着一个残酷的现实——生产环境中的故障与事故（incidents）也呈现出直接的正相关。从直观感受（vibe check）来看，日常使用的软件不仅没有变得更可靠，反而变得更加脆弱、Bug 频发。统计数据同样证实了这一点：绝大多数开发者都曾因 AI 编写的代码而引入线上事故，甚至被迫紧急回滚版本。 - **开发者行为变迁**：相比 12 个月前，开发者对 AI 产出代码的依赖与信任度显著提高。 - **生产力与事故正相关**：代码交付速度加快的同时，因 AI 代码引发的生产事故与版本回滚率同步攀升。 - **新的效率瓶颈**：人类工程师花费大量时间审查 AI 编写的代码（Code Review），代码审查已成为阻碍研发吞吐量的核心瓶颈。 --- ### [02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) 上下文缺口：为什么 AI 精通语法却不理解“运行时”？面对“为什么 AI 看起来写代码极其聪明，现实中却频繁引发事故”这一疑问，Gal 提出了“上下文缺口（context exploit / context void）”的概念。LLM 之所以极度擅长编写代码语法，主要得益于两点：第一是海量的开源与闭源训练数据支撑；第二是代码任务本身的特性——即在相对较小的数据体量上进行超高密度的逻辑推理，这恰好命中了 LLM 的核心优势区。 ```mermaid flowchart TD accTitle: AI coding vs production reality subgraph AIStrengths["AI 擅长领域：代码与语法"] A["静态源码与抽象逻辑"] --> B["高推理密度 / 较小数据域"] end subgraph RuntimeReality["真实生产环境：运行时复杂度"] C["数 TB 级生产运行时数据"] D["复杂状态组合与未记录的第三方 API"] E["多租户/跨地域法规分支差异"] end AIStrengths -.->|"上下文缺失 (Context Void)"| F["生产事故与系统级崩溃"] RuntimeReality --> F ``` 然而，软件绝不仅仅是静态代码，它的本质是复杂的生产运行时（runtime）：包括实际使用软件的用户、数据库中的动态数据、海量状态组合，以及缺乏完整文档的第三方服务集成。此类运行时数据往往达到数 TB 规模，碎片化且难以直接在上下文窗口中推理。例如，某些企业客户将同一套系统部署到数千个实例中，每个实例因应对不同城市、州或国家的合规与监管要求而存在微妙的运行时差异。 - **语法 vs 运行时**：AI 极度擅长语法和静态代码逻辑，但在庞大、未结构化的动态生产运行时数据面前表现极差。 - **系统级故障的本质**：正如导致全球大范围宕机的 Cloudflare 或 CrowdStrike 事件，灾难性故障极少是因为简单的单行语法错误（如将加号误写为减号，此类问题会被单元测试轻松拦截），而是成千上万个组件相互作用时，在组件间的“上下文真空”中爆发的系统性崩溃。 --- ### [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) 软件开发的范式演进：从编写、审查到“观察行为” Gal 展望了软件工程通往“奇点（Singularity）”以及在复杂企业级架构下实现“自主软件工厂（Autonomous Software Factory）”的路径。如今开发者在构建轻量级项目时的“氛围式编程（vibe coding）”遵循一个直观闭环：输入 Prompt $\rightarrow$ 模型生成 $\rightarrow$ 验证结果 $\rightarrow$ 发现问题则带错重新提示 $\rightarrow$ 成功则进入下一步。企业级软件的自主开发也将走向同样的循环，关键区别在于：企业环境需要一层极度严密、精准度极高的企业级确定性验证层。从软件开发角色的历史演进来看： 1. **两年前**：核心工作是**编写代码（Writing Code）**。 2. **当下阶段**：核心工作转移为**审查代码（Reviewing Code）**，大部分代码由 LLM 生成，人类工程师负责把关和部署。 3. **下一代范式**：核心工作将全面转向**观察行为（Observing Behavior）**。观察行为包含两大核心动作：一是**触发行为**（即真实模拟使用软件），二是**分析海量运行时数据**（理解多 TB 级的运行状态并精准定位/修复缺陷）。 - **对确定性验证的刚需**：目前行业过度依赖 LLM 做全栈闭环（LLM 写代码、LLM 审代码、LLM 做编排），但要实现完全自主交付，必须引入基于真实生产环境的“确定性对应层（deterministic counterpart）”，提供 99.999% 的运行置信度。 - **即使模型停滞依然可行**：Gal 强调，即使底层大模型能力不再提升、Agent 框架维持现状，只要补齐了这一确定性验证层，企业级软件工程的自主化在本质上就将成为一个“已解决的问题”。 --- ### [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) 借鉴自动驾驶：构建代码世界模型（Code World Model） Gal 用一个思想实验阐述了交付逻辑：理论上最快的交付方式是直接部署到生产环境，放任其运行一周并观察线上事故，然后再去修复；但这种做法会彻底激怒客户。正确的路径应当参考自动驾驶领域的经验：Waymo 在旧金山街道上线新模型之前，模型从未直接接触真车或物理传感器，而是在实验室的仿真环境中完成了数百万英里的高逼真度模拟测试，达到了 99.999% 的确定性验证。 ```mermaid flowchart LR accTitle: Autonomous vehicle simulation vs Code World Model subgraph AV["自动驾驶验证模式"] A["新算法模型"] --> B["高保真物理世界模拟器 (数百万英里模拟)"] B --> C["99.999% 验证后实车部署"] end subgraph CodeWM["软件工程：代码世界模型"] D["AI 生成代码"] --> E["代码世界模型 (Digital Twin 生产模拟)"] E --> F["5 分钟模拟一周运行 / 自主上线"] end ``` Checksum 将这种机制引入软件领域，构建了**代码世界模型（Code World Model）**——即生产环境的数字孪生（Digital Twin）。该模型能在一台机器中，于 5 分钟内完整模拟包含用户请求、系统负载、任务队列、数据库读写、第三方 API 响应甚至宕机故障在内的“上一周生产环境全貌”，从而提前捕获所有潜在行为异常。 - **源代码沦为汇编语言**：当代码世界模型建立后，源代码将变得像底层的汇编语言一样，人类不再需要逐行阅读或关心其实现细节。 - **技术债（Tech Debt）的消解**：在足够强大的仿真与验证层支持下，AI Agent 能够在结构混乱的遗留代码库中自由修补并确保行为正确，技术债对工程吞吐量的阻碍将被大幅钝化。 - **历史趣闻与互动的引出**：Gal 在演讲尾声展示了一张历史照片并与观众互动——那是计算机历史上第一起被记录在案的真实“Bug”（一只卡在纸带继电器里的飞蛾），以此引出从早期穿孔纸带时代至今代码抽象层次的演进历程。 ### [12:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=739s) 从“第一个 Bug”到 Checksum 的愿景：消灭生产环境中的 Bug 演讲展示了一张历史上著名的照片——计算机先驱记录在日志本上的第一只物理蛾子。历史上记录的第一个“Bug”其实是一只真正卡在机器纸带里的飞蛾，这也是后世将软件缺陷称为“Bug”的由来。Checksum 的终极愿景正是走向“最后一个被记录的 Bug”，构建一个极其强大的验证层，在代码运行的第一时间捕获所有缺陷，从而让生产环境中的 Bug 彻底成为“过去的遗迹”（relic of the past）。无论这一目标需要一年、两年、十年还是三十年才能实现，它始终是 Checksum 的北极星指标。 ### [12:56](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=776s) 10 个高难度任务基准测试：确定性运行工具对 AI Agent 的决定性影响为了验证真实环境下的代码验证能力，团队在 Checksum 内部的研发积压（backlog）中挑选了 10 个极其复杂的硬核任务。这些任务在正常情况下需要人类工程师花费数天才能完成。团队将这些任务交给 AI 编码 Agent 进行端到端处理，并在不同的验证能力配置下测试其输出代码的可合并率（mergeable state）： ```mermaid flowchart LR accTitle: AI Agent 任务完成度随验证能力升级的变化 subgraph S1["仅靠 Agent 与代码库"] A["Agent 生成代码<br/>+ 子 Agent 审查"] --> B["3 / 10 成功合并"] end subgraph S2["引入传统测试"] C["Agent 编写代码<br/>+ 单元与集成测试"] --> D["6 / 10 成功合并"] end subgraph S3["引入生产级验证"] E["Checksum 生产级仿真<br/>+ 真实故障与边缘场景回放"] --> F["9 / 10 成功合并"] end ``` - **第一阶段（仅 Agent + 代码库）**：仅提供代码库，即便允许 Agent 启动多个子 Agent 进行互相审查（Code Review），最终也仅有 3/10 的任务在经过人工严格审查和测试后达到可直接合并的标准。 - **第二阶段（引入单元与集成测试）**：为 Agent 提供现有的单元测试和集成测试套件，并允许其自行编写新测试，任务的可合并率跃升至 60%（6/10）。 - **第三阶段（引入生产级环境与确定性检查）**：让 Agent 接入类似生产环境的验证系统，回放真实的生产故障日志与各种极端边缘用例（Edge Cases），任务成功率直接攀升至 90%（9/10）。这一实验清晰地表明：单纯依赖大模型互相阅读代码——即陷入所谓“LLM 审查 LLM 的产出，另一个 LLM 再来审查 LLM 的审查”的死循环——效果非常有限。AI 编码 Agent 真正需要的是确定性的工具（deterministic tools），即能够切实运行软件、在真实执行环境中检验行为的验证层。 ### [14:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=859s) Checksum 代码世界模型：双循环闭环架构与测试即代码在探讨 Checksum 当下的产品实现时，Gal Vered 幽默地展示了 AI 行业大会“必不可少的闭环架构图”（mandatory loop slide）。Checksum 目前主要运行着两个核心闭环：一个是“生成与维护闭环”（Generate and Maintain Loop），另一个是“运行、报告与修复闭环”（Run, Report, Fix Loop）。 ```mermaid flowchart TD accTitle: Checksum 核心双循环系统架构 subgraph KB["统一知识库 (Knowledge Base)"] K1["开发者行为与意图"] K2["真实用户操作轨迹"] K3["线上真实故障与事件 (Incidents)"] end subgraph L1["闭环一：生成与维护"] G1["感知代码库变更"] --> G2["生成全系统测试用例"] G2 --> G3["自动维护与更新测试代码"] end subgraph L2["闭环二：运行、报告与修复"] R1["执行自动化测试<br/>(Playwright / pytest / API)"] --> R2["验证层过滤不稳定测试 (Flakiness)"] R2 --> R3["准确定位真实 Bug 并报告修复"] end KB --> L1 L1 --> L2 L2 --> KB ``` - **测试即代码（Tests as Code）**：所有生成的测试均以开源的标准代码格式交付（如 Playwright、pytest 和标准 API 测试等）。这样做的关键在于将所有上下文保留在 Agent 熟悉的编程界面中，绝不强迫外部 Agent 学习 Checksum 的专有 API 或平台。 - **全系统测试与真实度模拟**：Agent 会持续监听代码变更，基于实际代码库和真实用户行为生成用例，尽可能逼近全系统级端到端测试。 - **剔除不稳定测试（Flakiness Removal）**：UI/端到端测试历来饱受测试不稳定的困扰。Checksum 在上层加装了专有验证层进行过滤；一旦 Checksum 报告测试失败，开发者可以百分之百确信这是真实存在的 Bug。 - **统一知识库驱动仿真**：底层连接着汇聚了开发者习惯、真实用户行为以及线上真实 Incident 的知识库。其长期演进目标是实现组件级的一键全量生产仿真，让代码在合并前就如同已经在生产环境运行过一样。 - **效率与成本优势**：由 AI 驱动测试的生成、维护与自动修复，其综合成本和速度均显著优于传统纯人工编写维护测试的模式。 ### [16:30](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=990s) 现场问答：单元测试已沦为技术债？AI 时代的验证范式转移在演讲后的问答环节，现场观众提出了一个敏锐的问题：“随着我们越来越依赖可观测性（Observability）和全系统仿真，传统的单元测试（Unit Tests）是否正在变得无足轻重，甚至演变为纯粹的技术债务？” 对此，Gal Vered 给出了明确的判断：单元测试的重要性确实在显著下降。其核心根源在于软件开发范式的根本变化——人类已经越来越少手写业务代码，更不再亲自编写单元测试。当让 AI 去给自身生成的代码编写单元测试时，AI 非常擅长验证自己刚写出的逻辑，但这些逻辑本身可能就是存在缺陷的；AI 会顺着错误的假设写出“完美通过”的单元测试。因此在实际工程中，由 AI 自动生成的单元测试捕获真实 Bug 的概率正在持续走低。但这并不意味着测试设计失去价值。真正有价值的是由资深工程师或专门的平台（如 Checksum）自顶向下架构核心验证体系，而不是简单地对 Claude Code 等工具说一句“帮我生成单元测试和集成测试”。只有经过深思熟虑、以真实环境和置信度为核心构建的验证链路，才能在 AI 编码时代真正兜住软件质量的底线。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=4s) 生产环境中的故障与事故也呈现出直接的正相关。从直观感受来看，日常使用的软件不仅没有变得更可靠，反而变得更加脆弱、Bug 频发。 — Gal Vered > [02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) LLM 之所以极度擅长编写代码语法，主要得益于两点：第一是海量的开源与闭源训练数据支撑；第二是代码任务本身的特性——即在相对较小的数据体量上进行超高密度的逻辑推理，这恰好命中了 LLM 的核心优势区。 — Gal Vered > [02:10](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=130s) 灾难性故障极少是因为简单的单行语法错误……而是成千上万个组件相互作用时，在组件间的“上下文真空”中爆发的系统性崩溃。 — Gal Vered > [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) 两年前：核心工作是编写代码。当下阶段：核心工作转移为审查代码。下一代范式：核心工作将全面转向观察行为。 — Gal Vered > [05:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=319s) 即使底层大模型能力不再提升、Agent 框架维持现状，只要补齐了这一确定性验证层，企业级软件工程的自主化在本质上就将成为一个“已解决的问题”。 — Gal Vered > [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) Waymo 在旧金山街道上线新模型之前，模型从未直接接触真车或物理传感器，而是在实验室的仿真环境中完成了数百万英里的高逼真度模拟测试，达到了 99.999% 的确定性验证。 — Gal Vered > [08:46](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=526s) 当代码世界模型建立后，源代码将变得像底层的汇编语言一样，人类不再需要逐行阅读或关心其实现细节。 — Gal Vered > [12:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=739s) 构建一个极其强大的验证层，在代码运行的第一时间捕获所有缺陷，从而让生产环境中的 Bug 彻底成为“过去的遗迹”。 — Gal Vered > [12:56](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=776s) 单纯依赖大模型互相阅读代码——即陷入所谓“LLM 审查 LLM 的产出，另一个 LLM 再来审查 LLM 的审查”的死循环——效果非常有限。AI 编码 Agent 真正需要的是确定性的工具。 — Gal Vered > [14:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=859s) 所有生成的测试均以开源的标准代码格式交付……绝不强迫外部 Agent 学习 Checksum 的专有 API 或平台。 — Gal Vered > [14:19](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=859s) 一旦 Checksum 报告测试失败，开发者可以百分之百确信这是真实存在的 Bug。 — Gal Vered > [16:30](https://www.youtube.com/watch?v=4ywGlu4JKa4&t=990s) 当让 AI 去给自身生成的代码编写单元测试时，AI 非常擅长验证自己刚写出的逻辑，但这些逻辑本身可能就是存在缺陷的；AI 会顺着错误的假设写出“完美通过”的单元测试。 — Gal Vered ## Mentioned Gal Vered, Checksum, Ai4, Cloudflare, CrowdStrike, Waymo, Playwright, pytest, Claude Code ## Video description Gal Vered - Co-Founder and CEO, Checksum AI coding agents have solved the easy problem. The hard part, Verification, remains broken. In this talk I'll introduce the Code World Model: the infrastructure layer that lets AI agents simulate production before a single line ships, closing the gap between what an agent can see and what actually determines whether software works. I'll explain why coding agents need the same world model solution autonomous vehicles found. Attend if you're building or betting on autonomous software engineering. [Source](https://www.youtube.com/watch?v=4ywGlu4JKa4)

Source quotes

[0:04] Gal Vered: 生产环境中的故障与事故也呈现出直接的正相关。从直观感受来看，日常使用的软件不仅没有变得更可靠，反而变得更加脆弱、Bug 频发。 [2:10] Gal Vered: LLM 之所以极度擅长编写代码语法，主要得益于两点：第一是海量的开源与闭源训练数据支撑；第二是代码任务本身的特性——即在相对较小的数据体量上进行超高密度的逻辑推理，这恰好命中了 LLM 的核心优势区。 [2:10] Gal Vered: 灾难性故障极少是因为简单的单行语法错误……而是成千上万个组件相互作用时，在组件间的“上下文真空”中爆发的系统性崩溃。 [5:19] Gal Vered: 两年前：核心工作是编写代码。当下阶段：核心工作转移为审查代码。下一代范式：核心工作将全面转向观察行为。 [5:19] Gal Vered: 即使底层大模型能力不再提升、Agent 框架维持现状，只要补齐了这一确定性验证层，企业级软件工程的自主化在本质上就将成为一个“已解决的问题”。 [8:46] Gal Vered: Waymo 在旧金山街道上线新模型之前，模型从未直接接触真车或物理传感器，而是在实验室的仿真环境中完成了数百万英里的高逼真度模拟测试，达到了 99.999% 的确定性验证。 [8:46] Gal Vered: 当代码世界模型建立后，源代码将变得像底层的汇编语言一样，人类不再需要逐行阅读或关心其实现细节。 [12:19] Gal Vered: 构建一个极其强大的验证层，在代码运行的第一时间捕获所有缺陷，从而让生产环境中的 Bug 彻底成为“过去的遗迹”。 [12:56] Gal Vered: 单纯依赖大模型互相阅读代码——即陷入所谓“LLM 审查 LLM 的产出，另一个 LLM 再来审查 LLM 的审查”的死循环——效果非常有限。AI 编码 Agent 真正需要的是确定性的工具。 [14:19] Gal Vered: 所有生成的测试均以开源的标准代码格式交付……绝不强迫外部 Agent 学习 Checksum 的专有 API 或平台。 [14:19] Gal Vered: 一旦 Checksum 报告测试失败，开发者可以百分之百确信这是真实存在的 Bug。 [16:30] Gal Vered: 当让 AI 去给自身生成的代码编写单元测试时，AI 非常擅长验证自己刚写出的逻辑，但这些逻辑本身可能就是存在缺陷的；AI 会顺着错误的假设写出“完美通过”的单元测试。

Source quotes

Gal Vered: AI coding agents have solved the easy problem. The hard part, Verification, remains broken. Gal Vered: The Code World Model: the infrastructure layer that lets AI agents simulate production before a single line ships, closing the gap between what an agent can see and what actually determines whether software works. [5:19] Gal Vered: To reach to a point where we're shipping software autonomously, you have to have a deterministic counterpart... If you build this deterministic verification layer, I believe that software development becomes a solved problem. [8:46] Gal Vered: the fastest way to piss off your customers

Original transcript

[0:04] Perfect. So my name is Gal, co-founder and CEO of Checkexamai. In a sentence, what we do, we are [0:12] an agentic UN verification platform. We deploy continuous quality agents that through API and [0:18] end to end tests allow developers to fully lean into AI development because we make sure that the [0:24] code they ship is always working and bug free. So let's start by talking about the state of [0:32] AI development. I am sure that I'm not surprising anyone in this room when I say that developers [0:38] today trust AI significantly more than they trusted it 12 months ago. As AI models become [0:46] better, as harnesses become better, people do more with AI, people trust more the output. [0:52] At the same time, I'm sure that I'm not saying anything surprising when I say that we see [1:00] significantly more code being shipped into production. Code, PRs, tickets, whatever metric [1:08] you choose to use, productivity of developers has increased significantly in the last 12 months. [1:17] The problem is that together with trust there's a very direct correlation also to incidents. [1:26] I think the strongest thing is just the vibe check. We all use software daily and it just [1:32] feels like software becomes more buggy, more problematic. Every day I encounter a blocking [1:39] issue that prevents me from using a software that you know I depend on on the dayto-day. Um, [1:46] and also the stats back it up. Most developers ships shipped incidents because of AI. [1:51] Most developers needed to roll back versions because of AI related incidents. [1:57] And especially important, a lot of developers spend significant amount of time reviewing AI [2:03] code. And that starts to become the bottleneck. That's the missing part of AI development. [2:10] Why does it happen? Why does AI feel so smart at writing code but there's still so many incidents [2:16] occur daily? We like a check to call it the context exploit. So AI is very good at syntax. [2:23] It's very good at code for two main reasons. One, the training data. LLMs are trained on a lot of [2:30] code, open source code, closed source code. A lot of code is going into the training process. [2:38] The other thing that makes AI very good at coding is that it's exactly the task that LLMs [2:44] are very well suited for. Small amount of data, relatively even large code bases in the world of [2:51] data is small amount of data that requires very very high reasoning. That's exactly the kind of [2:58] task that LLMs are great for. What they're not good at is your runtime, is your production. [3:04] The problem is that software is not just code. Software is also the users that use the software, [3:10] the data in the database and the data that the users feed into the system. All of the state [3:15] combinations, all of the third party integrations, all of the behavior on the third party side [3:21] that is just undocumented, especially at the age of AI where people move fast. Your software [3:27] is everything together. It's not just the code. And what we call the runtime data is exactly the [3:35] thing that LLMs are really bad at. Vast amount of data, terabytes of data, the details are in [3:42] the small are are across a lot of places and it's very hard to reason on. We have a customer [3:49] that the same software is deployed across thousands of instance in instances. Every instance [3:55] is very different than the other one because of regulation. Each city, each stage, each country [4:01] gets a special treatment. That kind of deployment makes it very hard for AI to actually ship code. [4:09] And this is not just theoretical. As we said, we see in incidents daily. I think a good example is [4:16] two incidents that literally took down the entire internet. The Cloudflare incident, [4:21] the Cloud Strike incident. None of those incidents were syntax issues alone. None of them was oh an [4:28] LLM did a plus b instead of a minus b and therefore the entire internet is dumb. No [4:34] those things are being caught by unit tests, integration test, deployments. [4:41] The both of those incidents and many more are just set of circumstances that all come [4:46] together. Those are hundreds, thousands, hundreds of thousands of components all working together. [4:53] And in the void between two components, in the context void, something happened that broke down [5:01] the entire system altogether and it only got caught once it was deployed into production and [5:08] was run on real use cases. So with all of those problems, what's next for software development? [5:19] And I think when when we look at it at checkum, we're thinking about what brings us into the [5:23] singularity point of software development. What essentially allows us to have an autonomous [5:29] software factory on complex enterprise software and allows us to essentially move forward, [5:36] essentially deploy code to production autonomously again in an enterprise setting. [5:41] And the way to look at it is just look how people vibe code apps today. Today when you v code an [5:46] app, you go, you prompt, you let the model do its thing and then you verify the results, [5:51] right? It's very simple. If it works, you move on to the next thing. If there's an issue, you prompt [5:56] the model again with the issue. I think the same exact loop will happen with enterprise software. [6:02] The main difference would be that the verification layer will be a very robust enterprise level [6:08] verification that gets you to very high accuracy of whether your code is working or not. [6:15] So essentially software development is shifting constantly. Two years ago software development [6:20] was all about writing code. That was the main job of a software developer. I think today [6:27] the main job is reviewing code. Beyond architecting and planning, I'm talking about the [6:32] actual stage of deploying to production, writing and deploying. The main job is reviewing code. [6:37] Most of the code written is done by LLMs and the software engineer still needs to review the code, [6:42] make sure it works and deploy it in enterprise setting. Again, vibe coding definitely people are [6:47] not there yet are not even there. They moved on to the next thing. I think the next evolution is [6:52] observing behavior. I think that's the thing that unlocks the next jump in software development. [7:00] That's the thing that brings us into singularity in software development into an autonomous [7:05] software factory. Observing behavior and observing behavior has two parts to it. [7:10] One is actually triggering the behavior. So actually using the software and the second one is [7:15] taking the data that the software produces which could be terabytes of data on complex enterprise [7:21] deployments and analyzing it understanding what's going on and fixing the issues that occur. [7:28] So essentially every coding agents need a deterministic counterpart. [7:33] Why deterministic? I think today we're at the stage where everything is LLM, right? LLMs write [7:37] the code and then we have LLM's code reviewers and we have LLM's orchestration and we have LLM [7:42] deployments. LLM is this exciting new technology and we use it across the board to push [7:48] things forward. It makes a lot of sense because of the leverage. But the reality is to reach to a [7:55] point where we're shipping software autonomously, you have to have a deterministic counterpart. And [8:02] this deterministic counterpart needs to be based on production. Needs to be able to get to a point [8:08] where you can say software is verified to 99.999%. When you can say, hey, this software is working [8:15] and because I have this verification layer, I'm 99.999% sure it's going to work. Then you reach to [8:22] a point that you can deploy software autonomously with existing models. By the way, even if there's [8:28] no existing improvement in models today with Fable and Soul and there's no improvements in RNSS, [8:34] everything stays the same. If you build this deterministic verification there, I believe [8:39] that software development is a solved problem. Becomes a solved problem once you build that. [8:46] The best way to exemplifies it is a thought experiment. What's the fastest way to [8:51] ship software? The fastest way to ship software is simply deploy to production, [8:58] let it sit there for a week, see all of the incidents, go back and fix them. [9:03] If you're only optimizing for speed and then developers time, that's the fastest way. [9:09] The problem is that it's also the fastest way to piss off your customers. [9:14] That's why um we are trying to get to a state where you can ship your software into a simulation [9:21] actually trying to see everything that's working. Shipping your software to production [9:25] without shipping it to production. The best example is just autonomous cars. When Whimo [9:31] deploys a new model to production to cars driving around San Francisco, [9:38] before this model even touches a car, before this model even touches a real sensor, [9:43] it already driven millions of miles in the lab. No real cars, no sensor, millions of miles. [9:48] This model is 99.999% verified just by simulation. Now obviously because you're talking about cars [9:57] and because talking about human life there's still a long process until this model gets production. [10:03] But when you're talking about lower stake environments which most enterprise softwares [10:08] are compared to to autonomous cars then this simulation essentially means that you're solving [10:15] the full problem. So we call this the code world model. It's a digital twin of your [10:20] production environment. We're abusing the term cold world model a bit or world model a bit, [10:24] but we're basically saying what if you can build and simulate your production environment, [10:29] the world in which your software is living, users, environments, machines, cues, databases, um, [10:38] API responses, outages. What if we can simulate all of that your last week of production [10:44] within five minutes and observe the behavior and essentially tell you yes this software is working [10:51] 99.999% of the time or here are the failures that we identified and now you can go ahead and fix [10:57] them and then if we connect it to a coding agent again software development is for the most part [11:03] solved I believe and when you get that source code becomes like assembly nobody looks at assembly [11:09] code Today people used to write it by hand. Today it's trivial. Nobody cares about it. It's not [11:14] trivial to write, but it's trivial in the sense that you don't care what's there. And I think [11:18] that's where it gets us. I think once you have the simulation, once you have this verification, [11:22] source code doesn't matter. I also think tech that is for the most part sold because when you have [11:28] a very robust simulation basically will allow models to work in even very messy code bases. [11:35] So as models become better I think that even you don't care about tech debt and you only care about [11:39] behavior only care about observing what your software is doing out there in the wild in the [11:43] simulation in production with real users with fake users and that's it. So you're planning and you're [11:50] observing everything in the middle becomes a black box who knows what this image is. I'm curious. [12:00] Yeah. You want to go for it? Exactly. So first of all that's the first documented bug [12:08] and the reason a bug is called a bug is that when back when source code used to become [12:14] was film was basically punching holes on a paper that's how you called it the zeros and ones [12:19] and the first documented bug was an actual bug getting stuck on the machine or on the paper [12:25] therefore we call it bugs the reason why I have this image is this is the first documented bug [12:32] our vision in checksum is to get to the less documented bug to have such a strong verification [12:37] layer that when you run it, it basically catches all of the bugs you have and bugs [12:43] at least in production will become a relic of the past. I don't know if we'll get there one year, [12:49] two years ago from now, 10 years or 30 years from now, but that's the guiding star for checks. [12:56] And look, when you do experiments, I I'm sure people who who use coding agents daily wouldn't [13:01] be surprised about this. So we took 10 really hard tasks from our backlog. We chose tasks [13:07] that we think will take a few days, really complex tasks and we gave it to AI agent to fully verify [13:12] and then observe the results. And when we only had the agent and the codebase, three out of [13:18] 10 uh tasks were mergeable by us as is after we reviewed the code and we tested it. When [13:24] the agent had our regular unit and integration tests, we stripped it in the first version. When [13:29] we gave it a unit and integration test and also the ability to add more tests, 60% of the tasks [13:35] were completed to a merible state. When we talk about production like checks, actually taking [13:41] um failures from production, replying them all of the edge cases, the systems we have building, [13:47] then nine out of 10 of those tasks were completed successfully or or in a mergeable state. [13:53] So obviously the more tools you give the agent to verify it work the better [13:59] and in by the way in the in the first part the agent could launch sub agents to review the code. [14:05] So it's not just the more tools it's also tools that are deterministic tools that are [14:09] actually running your software and make sure it's working versus just reading code and [14:13] LLM reading LLM's work reading LLM's work. I think that deterministic part is important. [14:19] So how does it look today? Check some the code word model. This is our vision and we're working [14:23] towards it. What we have today and I don't think I think it wouldn't be an AI for presentation [14:28] probably if you don't have a loop slide. So this is my mandatory loop slide. So I can say we talked [14:33] about loops as well. Um we have two main loops. One is the generate and maintain loop. The other [14:38] one is the run report fix. All of the tests are delivered as code. That's important. We [14:42] want to keep the context within the agent uh surface. We don't want to force the agent to [14:48] learn how to use checksum. We just deliver it as code. open source code, playrights, pi test, [14:52] API testing, the entire thing. And essentially our agents are constantly running, seeing changes [14:58] you make to your application. Generate test, run the tests, maintain tests, and triage. [15:04] So we do two things. One, we make sure you always your app is always fully tested based [15:09] on your code base, based on real usage, trying to mimic as much as possible full system tests. [15:14] And the other part when we run the tests, there's a lot of flakiness. Obviously, [15:20] we without a flakiness. So when you see a test, check some tests fails, you know it's a real bug [15:26] because we we run a verification layer on top of it. And the goal is to take and all of it [15:30] is connected into a knowledge base. Basically trying to create as much information as possible [15:35] and from your developers, from your users, from actual incidents. And the goal is taking that [15:42] and moving more and more towards simulation and testing your entire components in one go as if [15:49] you deployed it into production. And this isn't theoretical like we see across the board. Again, [15:55] much easier to repair tests and significantly better performance for AI agents. [16:02] lower cost to fix test, maintain test, generate test by AI agents versus [16:08] by check versus AI agents versus humans, which at this point seem pretty obvious that AI is more [16:14] efficient than than humans. So, yeah, that's the vision. That's where we are today. And that's how [16:22] I think we're going to revolutionize how code is being built and deployed. [16:30] That's it. Thank you very much. So my question would be on the great great presentation. So [16:38] as we lean towards observability then are we really kind of negating like are unit tests [16:46] for example still important or they just mostly technical debt? I think what I I see [16:52] is that unit test has become less important. To me the reason is because we don't we no longer write [16:58] code. We definitely no longer write unit tests and AI is excellent at testing its own work and [17:04] making sure the unit test the code that is written but often this code is buggy. So what we see is [17:09] actually a decrease in the number of bugs that unit and integration tests are catching because [17:13] AI generating those tests. I think there's still value in humans architecting the the key tests or [17:20] a platform that architect the key test is what we do at checksum and making sure your app is fully [17:25] verified. But it can be just oh I'm just going to tell cloud code create tests unit test integation [17:30] test. I think the value there is go down. But if you think through the things you need to test and [17:34] you purposely build them in a way that gives you confidence I think there's a lot of value in that.