Buy the Hands, Own the Conscience: Governing AI Agents That Ship Enterprise Software

Ai4

AI-assisted summary of Buy the Hands, Own the Conscience: Governing AI Agents That Ship Enterprise Software — original source. Check the original for full context.

Source published: 2026-08-18

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 18, 2026, this conference presentation features Vishak Mallya, Founder of Synthetix Labs. According to the video description, Mallya addresses the gap between AI agent speed and enterprise trust, presenting a deterministic-first architecture to govern full-lifecycle agentic software delivery across regulated, mission-critical production environments.

## TL;DR Mallya asserts that while AI agents can generate code rapidly, enterprise adoption is bottlenecked by the absence of deterministic governance and verifiable accountability. To bridge this divide, enterprises must follow the principle of 'buying the hands and owning the conscience,' letting agents perform mechanical, reversible engineering tasks while named human owners retain ultimate release authority. Drawing on real-world migrations of multi-million-line legacy systems, he presents concrete governance mechanisms, including behavioral equivalence ledgers, dynamically synthesized specifications, and strict tiers of verification evidence. The presentation culminates in a practical framework instructing engineering organizations to establish automated verification loops and auditor-grade proof before deploying agents into production.

## Atmosphere & style Pragmatic, authoritative, and grounded in hard-earned industry experience, the presentation cuts through vendor hype with the perspective of a veteran enterprise practitioner. Mallya delivers his talk with sober realism punctuated by candid humor, memorably reframing the passive 'human in the loop' into an accountable 'human on the hook.' Listening to the talk feels like a masterclass in risk management and systems architecture, balancing sobering war stories of agent failure modes with a structured, reassuring blueprint for enterprise leaders.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=4s) Agent generation has become table stakes across enterprises, shifting the primary operational bottleneck from code production to identity tracking, authority verification, and governance. - [01:50](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=110s) The trust bottleneck prevents agent-written software from reaching production, as enterprise auditors require deterministic proof rather than unverified model assertions. - [01:50](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=110s) Deploying agentic systems requires defining an 'oracle'—a frozen, immutable baseline of truth capturing legacy system behavior before modernization begins. - [06:01](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=361s) Agentic delivery has triggered an economic convergence where the cost of modernizing legacy systems has finally fallen below the ongoing carrying cost of legacy technical debt. - [07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) Under the principle 'buy the hands, own the conscience,' mechanical coding tasks are delegated to agents, but consequential decisions and final sign-offs require an accountable 'human on the hook.' - [08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) Modernization verification requires a Behavioral Equivalence Ledger that compares legacy and target inputs and outputs, mandating cryptographically signed human justification for any behavioral differences. - [08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) Reliable specifications cannot rely on outdated documentation and must instead be synthesized from codebase analysis, live UI workflow captures, and SME interviews. - [12:11](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=731s) Verification evidence must be tiered by rigor, with Tier 1 behavioral parity against legacy baselines taking precedence over isolated test executions or static code analysis. - [12:11](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=731s) Last-mile production controls require unsuppressible quality gates, dedicated kill switches, anti-stubbing guardrails, and cryptographic identity tracking for every agent action. - [15:21](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=921s) Prompt and context tuning cannot solve underlying orchestration failures, and complex agentic bug fixing requires persistent architectural memory to prevent cyclic regressions. - [15:21](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=921s) Agents excel at mechanical execution and test scaffolding but remain incapable of qualitative business reasoning, assessing cross-system operational risks, or self-certifying their own outputs. - [17:37](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=1057s) Regulated agent delivery must follow an 'Automate, Verify, Prove' blueprint, prioritizing mechanical and reversible tasks while designing audit trails specifically for external CISOs and auditors.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=4s) Industrializing Agent Creation vs. The Vacuum of Governance

Vishak Mallya opens by reflecting on his thirty-year career delivering mission-critical software across highly regulated sectors, including banking, financial services, healthcare, and insurance. In the pre-AI era, rigorous processes governed every deployment; today, engineering teams are learning how to achieve that same mission-critical reliability using agentic delivery pipelines. Walking the conference floor, one reality is inescapable: building agents has become table stakes over the past eighteen months, with many enterprises running dozens of agents in production. However, a profound vacuum appears when asking the critical second question: "Who governs them? Which agent made a change? On whose authority? What evidence did it leave behind?"

```mermaid flowchart TD accTitle: Agentic Engineering vs Platform Governance Framework subgraph Agents["Intelligent Agent Layer (The Hands)"] A1["Codebase & Estate Reading"] A2["Spec & Test Pack Generation"] A3["Scaffolding & Refactoring"] end subgraph Platform["Deterministic Governance Platform (The Conscience)"] P1["Touchpoint Authorization & Identity"] P2["Verifiable Evidence Generation"] P3["Strict Behavioral Gate Enforcement"] end Agents --> Platform Platform --> H["Human on the Hook (Ship Decision)"] ```

Enterprises have industrialized the generation of software agents while delegating their governance to informal Slack threads or the isolated judgment of a single senior project manager. At Synthetix Labs, the objective is to build a platform that directly resolves this governance dilemma from the ground up. While intelligent agents handle the mechanical engineering tasks—reading the existing application estate, parsing legacy code, drafting specifications, and generating test cases—the surrounding platform governs what each agent is permitted to touch, enforces identity, and tracks the exact evidence produced before anything enters production.

- Delivering mission-critical software in regulated industries requires deterministic governance rather than informal sign-offs in chat channels. - Building agents is no longer the primary hurdle; proving authority, change origin, and verifiable evidence is the actual challenge. - The platform's role is to constrain agent scope, track agent identities, and capture tamper-proof operational evidence.

---

[01:50](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=110s) The Trust Bottleneck and Moving from Capability to Accountability

Over the last 18 months, agents have grown exceptionally fast, but organizational trust has failed to keep pace. While an agent can refactor a 1990s legacy codebase into a modern language in mere minutes, navigating that refactored code through an enterprise risk and audit review still takes months. Zero enterprise auditors will accept the justification that software is production-ready simply "because the model or the agent said so." Consequently, the engineering bottleneck has shifted from raw code execution to building the trust layer required to satisfy stringent risk reviews.

```mermaid flowchart LR accTitle: Legacy Modernization Failure Modes subgraph FailureModes["Agentic Failure Points in Enterprise Deployments"] direction TB F1["Missing 'Oracle' (No Frozen Baseline Truth)"] F2["Assertion-Only Claims (Lacking Hard Artifacts)"] F3["Suppressible Gates (Bypassed Under Pressure)"] F4["Truncated Lifecycles (Ignored Day-2 Operations)"] end subgraph Solution["Accountability Paradigm"] direction TB S1["Establish Behavioral Equivalence"] S2["Auditable Evidence Artifacts"] S3["Immutable Kill-Switch Gates"] S4["Long-Term Architectural Traceability"] end FailureModes ==> Solution ```

Coding agents frequently excel in isolated pilots and vendor demos but stumble when confronted with enterprise production realities. Mallya introduces the concept of "the oracle"—a frozen, immutable source of truth establishing exactly how a system must behave before any agentic task begins. When systems fail in production, it is typically because teams rely on unverified assertions instead of tangible artifacts, build suppressible governance gates that buckle under deadline pressure, or ignore the upstream lifecycle needed to explain architectural decisions months after deployment. The fundamental industry question has permanently inverted: capability is table stakes, while accountability is the true product.

- Refactoring legacy code takes minutes with agents, but risk reviews take months without deterministic proof. - **The Oracle:** A mandatory frozen truth defining exact legacy system behavior prior to running migrations or greenfield tasks. - The core question in 2024 was *"How much can the agent write?"*; today the question is *"How much of this can be proven?"*

---

[06:01](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=361s) The Economic Convergence Driving Legacy Modernization

Legacy systems built across the 1970s, 1980s, 1990s, and early 2000s have historically been kept on operational life support. CIOs and enterprise leaders routinely avoided modernization projects because these "keep-the-lights-on" systems carried astronomical risks and costs compared to their immediate business utility. Over decades, this reluctance allowed vast amounts of technical debt to accumulate across core transactional backbones in banking, insurance, and healthcare.

That equation has shifted drastically due to agentic workflows. The cost and operational risk of modernizing legacy software have collapsed, reaching an economic convergence point where the cost of modernization is finally lower than the carrying cost of legacy technical debt. While the governance principles outlined apply equally to greenfield projects, this economic turning point makes legacy modernization the most urgent and active testing ground for enterprise-grade agent governance.

- Decades of accumulated technical debt in core transactional systems are reaching a critical tipping point. - Agentic delivery dramatically lowers the cost and risk curve of large-scale refactoring and modernization. - This convergence makes modernization financially viable for CIOs who previously deferred modernization due to cost.

---

[07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) Principle 1: Buy the Hands, Own the Conscience

The foundational principle of governed agentic delivery is establishing an absolute boundary between agent execution and human accountability: "Buy the hands, own the conscience." Consequential responsibilities must remain exclusively with humans. This includes making the final decision to ship, scrutinizing all generated evidence, establishing the canonical definition of "done," and setting functional expectations. While future AI models may gain broader capabilities, current enterprise risk models mandate that human judgment remains the ultimate authority.

```mermaid flowchart TD accTitle: Separation of Agent Mechanics and Human Conscience subgraph AgentHands["Agent Mechanics ('The Hands')"] M1["Read Legacy Repositories"] M2["Generate Scaffolding"] M3["Draft Test Packs & Docs"] end subgraph HumanConscience["Human Authority ('The Conscience')"] C1["Define Acceptance & 'Done'"] C2["Audit Underlying Evidence"] C3["Enact Final Ship Decision"] end AgentHands -->|Submits Evidence Artifacts| HumanConscience HumanConscience -->|Signs Off| Production["Production Deployment"] ```

Conversely, mechanical and repetitive engineering tasks should be delegated entirely to agents. Agents excel at ingesting large codebases, generating unit test scaffolding, creating technical documentation, and translating syntax. However, human oversight cannot be reduced to a cosmetic dashboard filled with passive green checkmarks; it requires an explicit, named individual signing off on the change. Mallya humorously notes that enterprises do not just need a "human in the loop"—they need a "human on the hook" who bears direct organizational responsibility if an issue reaches production.

- **Human Responsibilities:** Acceptance criteria, evidence scrutiny, definition of "done", and the final ship authorization. - **Agent Responsibilities:** Code parsing, scaffolding, test generation, and documentation drafting. - Governance dashboards must enforce named personal accountability rather than automated, aggregate approvals.

---

[08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) Principle 2 & 3: Behavioral Equivalence Ledgers and Multi-Source Specs

To modernize mission-critical systems without introducing regressions, teams must implement a "behavioral equivalence ledger." Migrations cannot rely on assumptions or surface-level code reviews; teams must capture a deterministic baseline of the legacy application by feeding it exact inputs and recording its outputs. When the agent builds the modern target system, identical inputs are executed through both the legacy and modern implementations to surface any differential behavior. If behavioral divergences occur intentionally—such as adding new functional capabilities or modifying legacy workflows—they must be formally documented with a rationale, a timestamp, and a cryptographic human signature in the ledger as a first-class artifact.

```mermaid flowchart LR accTitle: Multi-Source Spec Synthesis and Behavioral Ledger Validation subgraph SpecSynthesis["Multi-Source Spec Synthesis"] S1["Codebase Analysis"] S2["UI/Workflow Capture"] S3["SME Interviews"] end subgraph Validation["Behavioral Equivalence Ledger"] V1["Legacy Input/Output Baseline"] V2["Target Execution Run"] V3["Differential & Divergence Analysis"] V4["Signed Human Sign-off"] end SpecSynthesis -->|Compiles Verified Spec| Validation ```

This strict verification relies heavily on spec-driven development, but Mallya warns that one cannot verify against an outdated document. In one engagement, an engineering team attempted to validate an agent's modernized system against a formal specification document, only to discover the document was ten years old and completely out of sync with production reality. True specifications must be dynamically synthesized from multiple operational data points: static codebase analysis, captured UI interactions, and structured subject-matter expert (SME) interviews. Freezing this synthesized baseline prevents silent architectural drift and ensures the modernized system reflects true business logic.

- **Behavioral Equivalence Ledger:** A class-one audit artifact recording legacy vs. target outputs against identical inputs. - **Signed Divergence:** Any intentional behavioral difference must carry an explicit rationale, timestamp, and human sign-off. - **Triangulated Specifications:** Specs must synthesize code analysis, live UI flows, and SME interviews rather than trusting static documentation.

---

[12:11](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=731s) Principle 4 & 5: Evidence Tiers and Uncompromising Last-Mile Governance

Not all verification evidence carries equal weight in enterprise risk assessments. Synthetix Labs categorizes governance evidence into three strict tiers:

When teams report engineering metrics such as "87% code coverage," the claim is meaningless unless paired with the specific tier of evidence collected.

```mermaid flowchart TD accTitle: Last-Mile Governance Controls G1["Single Ship Decision Gate / Kill Switch"] G2["Unsuppressible Quality Gates"] G3["Cryptographic Agent Identity Tracking"] G4["Anti-Stubbing Guardrails (Preventing False Green Builds)"] G5["Policy as Code (Executable Rule Packs)"]

G1 --> G2 --> G3 --> G4 --> G5 ```

The final mile of agentic governance is where systems most frequently collapse under operational stress. To maintain integrity, teams must enforce five non-negotiable architectural controls: 1. **A Single Ship Decision Gate:** A unified, unambiguous kill button prior to production release. 2. **Unsuppressible Gates:** Quality and security gates that cannot be bypassed or overridden when delivery deadlines approach. 3. **Agent Identity:** Distinct cryptographic tracking for every agent action to maintain fine-grained auditability. 4. **Anti-Stubbing Guardrails:** Guardrails preventing LLMs from fabricating stubbed methods or dummy functions simply to force compiler passes. 5. **Policy as Code:** Hardcoded programmatic policy enforcement engines rather than passive compliance PDF documents.

---

[15:21](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=921s) Battle Scars: Million-Line Modernizations and Agent Failure Modes

The validity of this deterministic governance model is proven across large-scale legacy modernizations, including migrating a 1.5-million-line COBOL system dating back to the 1970s, as well as complex platforms written in VB6, PHP, and legacy ASP. These real-world engagements revealed critical operational lessons. Initially, teams wasted weeks fine-tuning model prompts and context windows to resolve bad outputs, only to discover that the root failure was poor agent orchestration and inadequate governance architecture.

```mermaid flowchart TD accTitle: Cyclic Defect Remediation in Agentic Loops D1["Agent Generates Patch"] --> D2["Automated Review Loop"] D2 --> D3{"Defects Present?"} D3 -- "Yes (Whack-a-Mole Defect Shift)" --> D4["Store Failure in Persistent Memory"] D4 --> D1 D3 -- "No (Zero Defects After up to 30 Loops)" --> D5["Promote to Tier 1 Validation"] ```

Another major operational challenge is the "whack-a-mole" dynamic inherent to agentic review loops. When an agent patches a specific bug, it frequently introduces secondary regressions elsewhere in the codebase; in the most severe engagement, driving defects entirely to zero required thirty consecutive agentic review loops. Overcoming this requires treating agent memory as a core architectural component rather than an ad-hoc feature, allowing agents to retain context across runs and avoid repeating past errors.

Ultimately, agents are exceptionally reliable at mechanical execution, syntax translation, and deterministic test creation, but remain highly unreliable at qualitative reasoning, assessing cross-system operational boundaries, understanding whether a change will break downstream processes (such as month-end financial closings), and self-certifying their own output.

- Successfully migrated a 1.5-million-line 1970s COBOL application to modern architecture under strict regulatory governance. - Model and prompt tuning cannot compensate for deficiencies in orchestration and governance guardrails. - Resolving interconnected defects in complex codebases can require up to 30 automated review loops. - Memory must be an explicit architectural pillar to prevent agents from cycling through the same failure modes. - Agents must never be allowed to self-certify or assess high-level operational impacts like month-end closing risks.

[17:37](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=1057s) The Delivery Blueprint: Automate, Verify, and Prove

To successfully deploy autonomous agents in regulated, mission-critical environments, teams must ground their approach in a three-part delivery framework: "Automate, verify, and prove." When deciding what to automate, organizations should target tasks that are fundamentally "mechanical, reversible, and undoable." If an agent executes a change, the system must have the built-in capability to rollback and undo that work cleanly if something goes wrong. High-volume, repetitive engineering tasks should be tackled first, leaving high-judgment, ambiguous decisions for later stages once the operational baseline is established.

Before setting agents loose on code generation or migrations, teams must prioritize building the verification loop. Determining how to prove that the executed work actually functions as intended is the crucial prerequisite. Crucially, proving correctness requires designing the audit trail from the perspective of external reviewers—such as an auditor, a CISO, or an architectural review board. The system must produce unambiguous, traceable evidence that allows stakeholders to inspect and validate the agent's work independently without requiring engineers to manually explain every step. Vishak concludes by inviting attendees to visit booth 1214 to discuss real-world agent governance before thanking the audience.

```mermaid flowchart LR accTitle: The Agent Governance Framework subgraph Framework["Agent Governance Framework"] direction LR A["1. Automate • Mechanical tasks • Reversible & undoable • High volume first"] --> B["2. Verify • Establish loops first • Execution validation • Behavioral checks"] B --> C["3. Prove • CISO & auditor ready • Independent inspection • Traceable audit trail"] end ```

- **Scope Criteria for Automation**: Prioritize tasks that can be completely reverted over irreversible workflows; handle volume before tackling nuanced human judgment. - **Verification-First Mindset**: Establish and test the automated verification loop prior to rolling out broad agent autonomy. - **Stakeholder-Centric Proof**: Structure logs and audit artifacts so CISOs, compliance officers, and review boards can inspect and approve deployments asynchronously. - **Follow-up**: Attendees with further technical questions are directed to connect at booth 1214.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=4s) Who governs them? Which agent made a change? On whose authority? What evidence did it leave behind? — Vishak Mallya

> [01:50](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=110s) because the model or the agent said so — Vishak Mallya

> [01:50](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=110s) How much can the agent write? — Vishak Mallya

> [01:50](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=110s) How much of this can be proven? — Vishak Mallya

> [07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) Buy the hands, own the conscience. — Vishak Mallya

> [07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) human on the hook — Vishak Mallya

> [08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) behavioral equivalence ledger — Vishak Mallya

> [17:37](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=1057s) Automate, verify, and prove. — Vishak Mallya

> [17:37](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=1057s) mechanical, reversible, and undoable — Vishak Mallya

## Mentioned Vishak Mallya, Synthetix Labs, Ai4, COBOL, VB6, PHP, ASP, Slack

## Video description Vishak Mallya - Founder, Synthetix Labs

What happens when AI agents can write enterprise software faster than your team can trust it? That gap between speed and accountability is exactly where most coding-agent demos collapse on contact with regulated, mission-critical systems. In this talk, I'll show how to move past the copilot demo to governed, full-lifecycle agentic delivery — building, migrating, modernizing, and supporting real production code. Using real engagements that modernized decades-old systems across financial services, healthcare, and insurance, I'll walk through a deterministic-first architecture where intelligent agents do the engineering while automated verification and human oversight keep every change accountable and traceable. You'll leave with a practical framework for what to automate, what to verify, and how to prove correctness — plus an honest look at where agents excel and where they fail. If you're working to get agent-built software into production you can actually trust, this is your blueprint.

[Source](https://www.youtube.com/watch?v=3j8SqeGj-lI)

中文简报

“购买双手，掌控良知”：交付企业软件的 AI Agent 治理之道 Mallya 指出，尽管 AI Agent 能够迅速生成代码，但缺乏确定性治理和可验证问责制成为了制约企业落地的瓶颈。为了弥合这一差距，企业必须遵循“购买双手，掌控良知”的原则，让 Agent 执行机械化、可逆的工程任务，同时由实名的人类负责人保留最终发布权限。结合数百万行遗留系统迁移的实际案例，他提出了具体的治理机制，包括行为等价性账本、动态合成规格说明以及严格的验证证据分级。该演讲最终提出了一个实用框架，指导工程团队在将 Agent 部署至生产环境之前，建立自动化验证闭环与审计级别的证明体系。 Agent 生成代码已成为企业的普遍标配，主要的运营瓶颈已从代码编写转向身份追踪、权限验证和合规治理。 (0:04) 信任瓶颈阻碍了 Agent 编写的软件投入生产，因为企业审计人员需要确定性的证明，而非未经核实的模型断言。 (1:50) 部署 Agent 系统需要定义一个“真值源”（oracle）——即在系统现代化改造启动前捕获旧系统行为的、冻结且不可篡改的事实基准。 (1:50) 基于 Agent 的交付引发了经济效益的交汇拐点，改造遗留系统的成本终于低于维系既有技术债务的持续持有成本。 (6:01) 在“购买双手，掌控良知”的原则下，机械性的编码任务被委派给 Agent，但重大决策与最终审批仍需由承担责任的“具体负责人”把关。 (7:12)

Reading summary

Vishak Mallya argues that while autonomous agents make legacy software modernization economically viable, raw generation speed creates an acute organizational trust bottleneck. Deploying agents in regulated industries requires isolating mechanical execution to machines while retaining deterministic verification, behavioral evidence, and final shipping authority with accountable humans. The Modernization Tipping Point and Trust Deficit (1:50) Decades of accumulated technical debt in core transactional systems across banking, healthcare, and insurance were historically deferred because modernization carried prohibitive operational risks and costs. Mallya explains that agentic delivery pipelines have inverted this equation: the cost of modernizing legacy software has collapsed below the ongoing carrying cost of legacy technical debt. However, while agents can refactor decades-old codebases in minutes, risk and compliance audits still require months because enterprise reviewers cannot accept code based merely on model assertions. To overcome this bottleneck, engineering organizations must move away from evaluating models by output volume and instead establish an "oracle"—an immutable, frozen baseline of legacy system behavior. In Mallya's assessment, production failures occur when teams rely on unverified claims, suppressible governance gates, or truncated lifecycles that fail to account for long-term architectural traceability. Separating Agent Hands from Human Conscience (7:12) The foundational principle of governed agentic delivery is "buy the hands, own the conscience." Mallya argues that mechanical, high-volume engineering tasks—such as parsing legacy repositories, translating syntax, generating boilerplate scaffolding, and drafting documentation—should be delegated entirely to agents. Conversely, consequential judgment must remain exclusively human, including defining functional specifications, establishing the criteria for "done," and scrutinizing the underlying evidence before authorizing release. Human governance cannot be reduced to automated dashboards with passive approvals. Regulated delivery requires a designated "human on the hook" who bears explicit organizational liability for production changes. Platforms must enforce this boundary by restricting agent permissions, tracking agent identities cryptographically, and capturing tamper-proof audit trails rather than relying on informal sign-offs in chat channels. Behavioral Equivalence Ledgers and Dynamic Specifications (8:57) To modernize mission-critical systems without introducing regressions, teams must maintain a "behavioral equivalence ledger." This audit artifact is compiled by feeding legacy applications exact inputs, recording the outputs, and running identical inputs through the modernized target system. Any differential behavior is flagged; if divergences are intentional, such as modified business workflows, they must be formally documented with an explicit rationale, timestamp, and cryptographic human signature. This verification model depends on reliable specifications, yet static enterprise documentation is frequently out of sync with production systems. Mallya notes that engineering teams must dynamically triangulate specifications from three operational sources: static analysis of legacy codebases, live user interface workflows, and structured subject-matter expert interviews. Freezing this synthesized baseline prevents architectural drift and ensures the new system reflects true operational logic. Rigorous Evidence Tiers and Architectural Guardrails (12:11) Synthetix Labs categorizes governance verification into three distinct tiers: Tier 3 static code inspections without real runtime variables, Tier 2 isolated execution lacking legacy differential baselines, and Tier 1 behavioral verification demonstrating parity against the equivalence ledger. Mallya warns that standard engineering metrics like code coverage remain uninformative unless tied to the specific tier of evidence gathered. Last-mile governance also demands programmatic architectural controls: a unified release kill switch, unsuppressible quality gates, anti-stubbing guardrails to prevent agents from fabricating dummy methods, and policy-as-code engines. Drawing on deployments such as migrating a 1.5-million-line 1970s COBOL platform, Mallya notes that agents frequently introduce secondary regressions when patching bugs. Resolving these interconnected defects required persistent architectural memory and up to thirty review loops to prevent cyclical errors. Mallya concludes that autonomous workflows should prioritize mechanical, reversible tasks where verification loops are pre-established and audit trails permit independent inspection by compliance officers. Because agents cannot reliably self-certify or assess complex cross-system impacts, such as month-end financial closings, mission-critical delivery remains contingent on strict human-enforced boundaries.

精炼阅读摘要

Synthetix Labs 的 Vishak Mallya 指出，随着 AI 智能体生成软件成为工程常态，系统交付的核心瓶颈已从代码编写能力转向可验证的信任体系；在受监管的关键任务系统中，企业必须贯彻“买手艺，定良知”（Buy the hands, own the conscience）的原则，由智能体承担机械执行，而将不可规避的问责权与最终上线裁决牢固保留在人类手中。遗留现代化的经济拐点与信任瓶颈 (1:50) Mallya 指出，银行、保险与医疗等行业在 20 世纪 70 年代至 2000 年代初期构建的核心交易系统长期依靠高成本维护维持运转，企业决策层过去因顾虑高昂费用和操作风险而屡屡推迟现代化。而在过去 18 个月内，AI 智能体的工作流显著拉低了重构成本与风险，现代化成本已低于继续背负技术债务的持有成本，形成了关键的经济拐点。然而，智能体可以在数分钟内重构数十年历史的旧代码，企业风险与审计审查却仍需耗费数月，没有任何企业审计师会单纯接受“模型或智能体说没问题”的上线依据。在生产部署中，工程失败的根源往往在于缺乏“先知”（Oracle）——即在智能体执行任务前确立的不可变系统基准真相。许多团队过度依赖模型未经证实的断言，设立容易在交付压力下被跳过的治理关卡，且忽视了数月后解释架构决策所需的生命周期追踪。当前行业的核心焦点已从 2024 年探讨的“智能体能写多少代码”，彻底转向“写出的代码有多少能被确定性证明”，合规与问责已成为真正的核心交付物。核心权责分离：“买手艺，定良知” (7:12) 受治理智能体交付的首要基石，是在智能体执行与人类问责之间划定绝对界限，即“买手艺，定良知”。具有重大影响的决策必须完全由人类掌控，包括界定“已完成”（Done）的规范、确立功能预期、严格审查底层证据以及做出最终发布决定。相比之下，机械且重复的工程任务应全面委派给智能体处理，如解析庞大代码库、构建架构脚手架、生成测试用例以及起草技术文档。 Mallya 强调，企业治理不能止步于显示绿色对勾的表面仪表板，而必须推行具名个人的终极追责。企业需要的不仅是形式上的“人在回路”（Human in the loop），更是真正承担组织责任的“挂钩责任人”（Human on the hook），确保在生产环境出现缺陷时有明确的人类主体负责。治理平台的核心作用在于约束智能体的触碰权限、跟踪智能体身份，并在变更进入生产环境前捕获防篡改的运行证据。确定性验证：行为等价账本与证据分级 (8:57) 为避免任务关键型系统在重构中出现逻辑退化，工程团队必须建立“行为等价账本”（Behavioral Equivalence Ledger）。该机制通过记录遗留系统在特定输入下的确切输出来建立确定性基准，并将相同输入注入智能体构建的目标系统以比对行为差异。一旦出现预期内的行为偏离（如新增功能或重构流程），该差异必须作为一等审计实体记录在账本中，并附带明确理由、时间戳与人类专家的加密签名。同时，用于验证的规范不能依赖可能过时的静态文档，而必须结合静态代码分析、动态 UI 工作流捕获以及领域专家（SME）访谈进行多源三角合成。在风险审查中，Synthetix Labs 将治理证据严格划分为三级：第 3 级（最弱）为未在真实运行环境中执行的静态代码检查；第 2 级（中等）为代码在隔离环境中通过测试或人工审查，但缺乏与遗留基准的差异比对；第 1 级（最高）则是通过行为等价账本验证其与原系统具有逐项功能对等性。最后的一公里治理必须落实五项刚性控制：单一发布终止开关、不可人为绕过的质量闸门、加密智能体身份追踪、防止大模型捏造桩函数以强行通过编译的防线（Anti-Stubbing），以及代码化策略执行引擎。实战教训与“自动化、验证、证明”蓝图 (15:21) 这套治理体系在涵盖 150 万行代码的 1970 年代 COBOL 核心系统迁移，以及 VB6、PHP、旧版 ASP 系统重构中得到了检验。实战表明，反复微调模型提示词和上下文窗口无法解决代码产出质量的根源问题，真正的瓶颈在于智能体编排与治理架构。此外，智能体在修复特定缺陷时极易引发次生回归，在复杂工程中曾需要历经多达 30 轮自动审查循环才能彻底消除缺陷，因此必须将智能体持久化记忆作为核心架构支持。同时，智能体在定性推理、跨系统业务边界评估（如月末财务结账风险）以及自我认证上高度不可靠。团队落地应遵循“自动化、验证、证明”三步交付蓝图：首先，优先自动化高频、可机械执行且具备完全可逆和回滚能力的任务，暂缓高歧义的人类判断环节；其次，在赋予智能体自主编码权限前，先行构建端到端执行与行为验证闭环；最后，审计追踪必须以 CISO、合规官与架构委员会等外部审查者的视角进行设计，确保证据链清晰独立可查，使相关方无需开发团队手动解释即可自主完成审批。 Mallya 强调，代码生成技术的平民化反衬出治理能力的稀缺性；在高度监管的工业级场景中，缺乏独立事实基准（Oracle）与抗篡改证据链的智能体无法跨越审计门槛，将治理逻辑转化为代码化策略并落实人类法律与组织层面的最终责任，是确保智能体能够安全发布企业软件的关键前提。

Detailed notes — zh

## Background 本视频由 Ai4 频道于 2026 年 8 月 18 日发布在 YouTube 平台，主讲人为 Synthetix Labs 创始人 Vishak Mallya。内容聚焦于强监管与关键业务系统场景，旨在探讨如何跨越 AI 编程从 Copilot 演示到全生命周期治理型 Agent 交付的鸿沟，提供一套兼顾确定性架构、合规审计与可追责性的落地蓝图。 ## TL;DR 演讲指出当前 Agent 代码生成速度与企业合规信任之间存在严重脱节，核心瓶颈已从“代码能力”转向“可追责性与证明能力”。主讲人系统性地提出了核心治理原则：“买其双手，主其良知”（让 Agent 承担机械执行，让人类背负最终签字问责）、利用“行为等价账本”建立确定性基准、采用分级可信证据体系以及设立不可绕过的刚性发布门禁。结合将 150 万行 1970 年代 COBOL 核心系统成功重写迁移的实战踩坑经验，演讲提炼出以“自动化可逆任务、预设闭环验证、提供外部审计证明”为核心的企业级 Agent 落地方法论。 ## Atmosphere & style 整场演讲风格极为硬核、务实且充满实战锋芒，毫无浮夸的 AI 概念炒作。主讲人凭借三十年深耕强监管关键系统的老牌工程底蕴，以从容而直言不讳的语调剖析行业痛点；他用“Human on the hook（把责任人挂在钩子上背锅）”等辛辣幽默的洞察直击盲盒审批的尴尬现实，给观众带来了一种清醒、严谨且极具说服力的“战壕老兵”式工程复盘体验。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=4s) 行业已将 AI Agent 的构建工业化，但在强监管企业级交付中，缺乏严密的治理机制、授权追踪与可审计证据。 - [02:29](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=149s) 代码生成的效率瓶颈已经转移：日常任务生成极快，但缺乏信任层和硬性工件证据导致代码无法通过审计并安全推入生产环境。 - [02:29](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=149s) 当前核心议题已从“Agent 具备多少代码编写能力”转变为“其生成的系统改动中有多少能被完全证明并追责”。 - [07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) 原则一“买其双手，主其良知”：将机械化执行交由 Agent 处理，人类必须对系统审计、完成标准及发布决策承担终极问责（Human on the hook）。 - [08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) 原则二“行为等价账本”：通过在同一输入下比对新老系统输出，以确定性证据记录并由负责人签名归档所有设计偏离，实现系统行为的数学证明而非口头断言。 - [10:44](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=644s) 原则三“以多维数据锚定动态规范”：规范不能依赖过时的静态文档，必须综合代码库逻辑、UI 交互流与专家访谈固化为可验证的基准线。 - [12:11](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=731s) 原则四“分层可信证据体系”：将证据划分为静态检查（三级）、主观验收（二级）和行为账本全量回放（一级），只有一级证据才具备生产发布价值。 - [13:22](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=802s) 原则五“最后一公里防护栏”：设立不可绕过的单一发布决策门禁，赋予 Agent 独立身份标识，并通过策略即代码与严密检查杜绝空函数或桩代码上线。 - [15:21](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=921s) 提升 Agent 交付质量的核心突破点在于外围调度编排与治理框架，而非单纯微调提示词或调整模型参数。 - [15:21](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=921s) 多 Agent 审查反馈循环容易陷入引发连锁缺陷的“打地鼠”困境，必须将记忆机制（Memory）升格为核心架构组件以避免重复犯错。 - [17:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=1032s) Agent 在定性评估、跨系统边界影响分析及自我证明方面极不可靠，绝不能允许其对生成结果进行盲目自我背书。 - [17:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=1032s) 企业推进 Agent 落地的三步框架：优先自动化机械可逆任务（Automate）、预设闭环确定性核验（Verify）、面向外部审计提供无可辩驳的证据链（Prove）。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=4s) 工业化构建与治理真空：从代码生成到责任追踪 Vishak Mallya（Synthetix Labs 创始人）首先介绍了自己的背景：他在进入 AI 领域之前，已在银行业、金融服务业、医疗保健和保险等强监管行业中，深耕了近三十年关键业务软件（mission-critical software）的交付。如今迈入 AI 时代，整个软件工程正在重构，大家都在摸索如何将智能体交付（agentic delivery）机制内化到这些核心关键业务系统的交付中。Vishak 坦言，参加会议的同仁在展区逛了三天后，一定会发现一个显而易见的事实：“每个人都在造 Agent”。过去 18 个月内，构建 Agent 早已不再是技术难点，很多企业甚至已经有几十个 Agent 在生产环境中运行，构建 Agent 几乎变成了“准入门槛”（table stakes）。然而，当抛出第二个至关重要的问题时，全场往往陷入沉默：“谁在治理它们？哪一个 Agent 进行了变更？这是基于谁的授权？它留下了什么审计证据？”当前行业的现实是：业界已经成功把 Agent 的**构建**工业化了，却把**治理**留给了凌乱的 Slack 讨论串，或是依赖某一位资深项目经理的主观判断。Synthetix Labs 从底层重新搭建架构时，不仅要求 Agent 去完成工程实现（如扫描整个系统资产、阅读代码、撰写技术规范、生成测试用例等它们非常擅长的事），更要求平台牢牢包揽 Agent 周围的一切管控：明确每个 Agent 允许触碰哪些代码与边界、必须输出什么形式的审计证据，以及这些证据具体出自哪个 Agent 之手。 ```mermaid flowchart TD accTitle: Agentic Engineering vs Platform Governance accDescription: Separation between what intelligent agents handle and what the governance platform oversees. subgraph AGENTS["智能体职责：负责工程执行 (The Hands)"] direction TB A1["扫描系统资产与读取代码"] A2["撰写系统规范与技术文档"] A3["构建脚手架与生成测试用例"] end subgraph PLATFORM["治理平台职责：负责约束与取证 (The Boundary)"] direction TB P1["访问权限与变更边界控制"] P2["要求生成严格证据工件"] P3["追踪变更主体与授权链条"] end AGENTS -->|"受到严格约束与记录"| PLATFORM ``` - Vishak 强调，这套治理框架并非闭门造车的产物或纸上谈兵的理论构想，而是团队在为企业客户以及自身内部落地 Agent 交付流程时，真刀真枪踩坑换来的“实战伤疤”（battle scars）。 - 他直言不讳地指出当前工程审批的痛点：在场的许多管理者与技术负责人，上个季度、上个月甚至今天早上，都一定批准过自己无法完全解释清楚的代码或系统变更，而这套框架正是为了终结这种盲盒审批。 --- ### [02:29](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=149s) 速度与信任的脱节：从能力竞赛转向责任证明过去 18 个月里行业最大的割裂在于：“Agent 变快了，但信任并没有随之建立”。举例来说，要将一段写于 20 世纪 90 年代的陈旧代码重构成一门现代语言，现在的 Agent 几分钟之内就能完成；然而，如果要让重构后的代码通过严格的风险审查、接受审计并真正部署上线，往往依然需要耗费数月之久。试问如果走到审计员面前说：“这个可以直接上线，因为大模型或 Agent 说它没问题”，世界上“没有任何一个审计员会点头同意”。代码生成的瓶颈早已发生位移——日常任务的执行已经极其高效，真正的瓶颈卡在如何将软件安全推入生产环境，这正是必须构建“信任层”（trust layer）的原因。为什么会出现 Agent 在 Demo 和概念验证（PoC/Pilot）中表现惊艳，一旦进入真实的复杂企业环境就立刻“哑火”、无法像演示时那样稳定交付的现象？Vishak 剖析了其中的深层原因： 1. **真实事实没有冻结（Lack of the "Article"）**：在启动任何智能体工作前，必须先确定并冻结一套不可动摇的基准事实——系统究竟应该实现什么行为？如果要迁移一套老旧遗留系统，旧系统的精确行为究竟是什么？这个被冻结的行为真理就是所谓的“法典/事实基准”（the article）。 2. **缺乏硬性工件证据（No True Evidence）**：系统的证据不能停留在模型单方面的声明或断言（assertion），必须是在全生命周期过程中沉淀下来、能够经受住外部严苛审查的“真实工件”（true artifacts）。 3. **治理卡点形同虚设（Suppressible Gates）**：很多团队虽然设立了所谓的防线和卡点，但“任何可以被随意跳过或压制的卡点，根本就不是卡点”。 4. **生命周期认知错位（Truncated Lifecycle）**：传统的智能体开发视角往往在 Agent 完成代码变更的一刻就宣告结束，却忽略了庞大的下游与上游生产集成体系。一个今天由 Agent 生成并上线的系统，在 3 个月、6 个月甚至 1 年后，团队是否还能复盘证明为什么系统在特定情况下会做出某种决策？因此，行业在面对 Agent 时提出的核心问题必须发生根本性转变：在 2024 年，大家都在问“Agent 能写多少代码？能力边界在哪里？”；而到了今天，Agent 具备代码能力已是公认的事实，核心提问必须转变为“这里面有多少改动是能够被完全证明的？”——能力已经成为基础标配，而**可追责性（Accountability）**本身才是真正的产品。 - **遗留系统现代化的交汇点**：在金融、医疗等强监管领域，运行着大量 80 年代、90 年代乃至 2000 年代初构建的系统。这些系统长期作为“维持运转”（keep-the-lights-on）的核心资产被保留，积累了巨额技术债务。过去 CIO 们迟迟不敢重构，是因为改造成本与业务中断风险极高；如今 Agent 的介入让改造成本出现断崖式下跌，重构成本与累积的技术债风险迎来了关键的“历史交汇点”，从而掀起了遗留系统现代化的高潮（但此治理逻辑同样适用于全新构建的 Greenfield 项目）。 --- ### [07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) 原则一：买其双手，主其良知（让负责人真正“背锅”）演讲的核心原则第一条即是：“买下它的双手，守住你的良知”（Buy the Hands, Own the Conscience）。在人机协同工程中，必须建立一条极其清晰刚性的边界，明确 Agent 的能力范围与人类的核心职责： ```mermaid flowchart LR accTitle: Buy the Hands Own the Conscience accDescription: Division of responsibilities between automated AI agents and accountable human engineers. subgraph HANDS["双手：Agent 自动化执行"] H1["阅读分析代码"] H2["自动生成测试套件"] H3["搭建工程脚手架"] H4["编写配套文档"] end subgraph CONSCIENCE["良知：人类终极问责"] C1["定义 Done 完成标准"] C2["实质性审查验证证据"] C3["拍板最终发布裁决"] C4["承担线上后果签字画押"] end HANDS -->|"产出物与证据支撑"| CONSCIENCE ``` 人类必须牢牢掌控那些具有深远后果的关键决策：评估并掌握系统的真实审计证据、深刻理解系统究竟应当达成何种业务目标、制定“完成”（Definition of Done）的标准，以及做出最终是否发布上线的决策（Ship Decision）。这些至关重要的裁量权在现阶段必须属于人类。相比之下，机械化的脏活累活——读取代码库、生成测试套件、搭建工程脚手架（scaffolding）、补全技术文档等，完全可以放手交给 Agent。 Vishak 特别告诫道，这种人类掌控绝不能沦为形式主义——绝不能只是在监控仪表盘上扫一眼满屏的绿色对勾，然后草草点击通过，而是必须有具体的责任人进行具有法律和业务效力的签字审批（sign-off）。他幽默地调侃道：“大家总爱提 Human-in-the-loop（人机协同闭环），但在我们看来，这不仅是人在环路中，更得是 **Human on the hook（把责任人挂在钩子上 / 让人背锅）**！”线上系统一旦出现重大故障需要紧急回滚，企业必须立刻知道找谁负责，而不是面对一堆匿名的 Agent 变更两眼一抹黑。 --- ### [08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) 原则二：行为等价账本（从口头断言到数学证明）第二条原则是团队在实战中历经阵痛总结出来的核心概念——**行为等价账本（Behavioral Equivalence Ledger）**。在遗留系统迁移重构场景中，系统行为必须是“被证明的”，而不能仅仅是“被断言的”（prove the behavior and not just assert it）。想要在老系统与新系统之间证明行为一致，绝不能仅靠翻阅过去的业务文档，而必须基于真实的运行表现建立基线（baselining）： 1. **实证行为基线**：针对同一批已知的实际输入数据，真实运行老系统，捕获并记录老系统的确切运行行为与输出作为基准。 2. **同等输入差异比对**：当 Agent 自动开发生成了目标新系统后，将完全相同的测试输入灌入老系统与新系统，以确定性的方式捕获并比对两者之间的输出差异（differential）。 3. **显式记录设计偏离（Divergences by Design）**：新老系统之间存在差异并不一定是缺陷。现代化改造往往不仅是单纯的代码直译，还包含业务重构、算法优化或新增功能特性。如果某种差异是设计使然，就必须在账本中明确记录“为何产生该偏离”。 4. **负责人数字签名归档**：回到“Human on the hook”的逻辑，账本中每一处业务偏离都必须绑定明确的责任人：究竟是谁批准了这项偏离？偏离的业务合理性何在？附带精准的时间戳和责任人电子签名。整个“行为等价账本”被 Synthetix 作为**一级工件（Class-One Artifact）**来持久化保管。通过这套机制，团队把软件交付的底气从虚妄的“我们相信它能跑通”（we believe it works），彻底转变为坚实的“我们能证明它跑得通”（we can prove that it works）。随后，Vishak 顺势引出了驱动这一严密流程的技术支柱——基于规范驱动的开发（Spec-driven development）。 ### [10:44](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=644s) 原则三：以多维数据锚定动态系统规范开发新系统前必须具备清晰坚实的规格说明（Spec），但单纯依赖传统文档往往会带来巨大隐患。演讲者指出，规范绝不仅仅是一份静态文件，其核心在于能够基于测试“预言机”（Oracle）原则对系统的实际行为进行精准验证。现实中，仅凭现有文档往往难以还原真实逻辑。为此，构建规范时必须综合多维数据：不仅要穿透代码库本身的逻辑，还要完整捕获用户界面（UI）交互流，并通过深入的领域专家（SME）访谈萃取隐性业务规则，最终将这些要素固化为一个可验证的基准线（Frozen Baseline）。 ```mermaid flowchart TD accTitle: Multi-Source Spec Baseline Architecture subgraph Inputs["规范数据来源"] A["代码库逻辑\n(Codebase)"] B["UI/交互行为\n(User Interfaces)"] C["领域专家访谈\n(SME Interviews)"] end subgraph SpecCore["基准固化与验证"] D["冻结行为基准\n(Frozen Baseline Spec)"] E["新系统行为验证\n(Behavioral Validation)"] end Inputs --> D D --> E ``` 演讲者分享了一个切肤之痛的亲身案例：团队在验证一套新系统时，曾对照现存的一份设计文档进行比对，后来却发现那份文档是十年前编写的且多年未曾更新。在这十年间，老系统的实际逻辑早已严重漂移，导致基于旧文档生成的新系统完全无法通过真实业务验证。这一教训表明，规范的建立必须依赖代码、界面与专家经验的三维对齐，杜绝单一静态文档引发的系统行为分歧。 --- ### [12:11](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=731s) 原则四：构建分层的可信证据体系在评估系统交付质量时，单纯声明测试覆盖率（如“新系统覆盖率达到 87%”）是远远不够的，因为并非所有证据都具备同等效力。为了让交付物的可信度能够经受住监管与审计的检验，必须引入分级证据模型： * **三级证据（Tier 3，可信度最低）**：仅静态检查新生成的代码和系统，未在真实目标环境及对应运行时变量下实际执行。 * **二级证据（Tier 2，中等可信度）**：在目标环境中运行并通过测试，但仅依赖测试人员或领域专家的主观验收，未与老系统的历史真实行为建立直接比对。 * **一级证据（Tier 1，最高可信度与黄金标准）**：将新系统置于行为账本（Behavioral Ledger）中全面回放，逐项比对并证明老系统的每一项特性与边界行为在新系统上均能完全对齐。演讲者强调，在向业务方与管理层汇报时，必须将覆盖率数字与对应的证据层级绑定呈现，唯有具备一级证据支撑的覆盖率才具备真正的生产发布价值。 --- ### [13:22](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=802s) 原则五：严守最后一公里的治理关卡与防护栏治理体系最容易在“最后一公里”彻底崩塌，必须设置不容妥协的强硬约束机制。首先是设立单一且明确的发布决策门禁（Ship Decision Gate），它相当于生产交付前的唯一“紧急终止按钮”（Kill Button），必须拥有清晰的判定标准与执行权力。其次，绝不允许存在“可被绕过的门禁”（No Suppressible Gates）；一旦系统允许人为跳过门禁，在紧张的项目截止日期压力下，绕过门禁就会成为必然。此外，必须为智能体赋予独立的身份标识（Agent Identity），以确保系统内发生的每一次修改与决策都能精确追溯到具体执行的 Agent。在代码生成层面，大语言模型（LLM）具有极强的“走捷径”倾向——为了迅速让编译变绿（Compile Green），它们往往会生成空函数或桩代码（Stubs）来假装实现功能。治理防护栏必须具备深度静态与动态检查能力，严禁任何未完全实现的桩代码混入生产环境。最后，所有合规与安全策略必须转化为可执行的“策略即代码”（Policy as Code），而非停留在纸面规范中。 --- ### [15:21](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=921s) 生产实践经验与踩坑教训：从 150 万行 COBOL 迁移到治理闭环在强监管行业的真实交付中，严密的治理体系展现出了巨大威力。演讲者团队曾在一个单期项目中，成功将一套编写于 1970 年代、规模达 150 万行代码的 COBOL 核心业务应用完整现代化重写，并在 VB6、PHP、老旧 ASP 等多种遗留系统迁移中复用了同一套治理模型。 ```mermaid flowchart LR accTitle: Defect Elimination Loop A["Agent 生成/修改代码"] --> B["自动化审查与门禁"] B -- "发现衍生缺陷" --> C["记录上下文与架构内存"] C --> A B -- "缺陷清零" --> D["一级证据验证与发布"] ``` 在取得这些成果的过程中，团队也经历了一系列关键认知转变： * **从微调提示词转向优化编排治理**：团队初期花费数周反复调整模型参数、提示词（Prompts）与上下文窗口，但生成的默认质量始终不尽如人意。最终发现核心症结在于外围的调度编排与治理框架，重构治理机制后才彻底突破瓶颈。 * **Agent 审查循环的高昂代价与“打地鼠”陷阱**：多 Agent 审查反馈循环并非免费。Agent 在修复一个缺陷时，极易因局部改动引发新的连锁缺陷，导致陷入“打地鼠”（Whack-a-Mole）困境。在最极端的情况下，团队连续运行了多达 30 轮审查修复循环，才将系统缺陷彻底清零。 * **将内存（Memory）升格为核心架构组件**：Agent 必须具备跨运行周期的记忆能力，将历史执行经验与踩坑记录沉淀为共享资产，确保在后续流程中不再重复犯错。 --- ### [17:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=1032s) 智能体的能力边界与落地框架：自动化、验证与证明演讲者提醒，当前智能体在特定领域表现出色，但在全局判断上依然存在明显缺陷。Agent 极度不可靠的领域包括：定性评估、跨系统边界影响分析（例如无法准确评估“本次改动是否会导致月末结账流程崩溃”），以及对其自身生成结果的自证明与影响范围判定。因此，企业绝不能允许 Agent 进行盲目自我背书。 ```mermaid flowchart TD accTitle: Automate Verify Prove Blueprint subgraph Step1["1. 自动化 (Automate)"] A1["优先机械性、可逆任务"] A2["大批量、低主观判断流程"] end subgraph Step2["2. 验证 (Verify)"] B1["执行前预设闭环验证手段"] B2["行为账本对齐"] end subgraph Step3["3. 证明 (Prove)"] C1["面向审计员/CISO/评审委员会"] C2["提供全链路可解释审计追踪"] end Step1 --> Step2 --> Step3 ``` 企业推进 Agent 落地生产的核心框架可以总结为三步： 1. **自动化（Automate）**：严格限制自动化范围，首选机械性强、完全可逆（Reversible and Undoable）、产生海量工作量的任务；暂缓引入强主观判断的复杂业务流程。 2. **验证（Verify）**：在开始执行任务之前，必须先设计好验证闭环，明确如何通过确定性手段核验运行结果。 3. **证明（Prove）**：跳出开发者视角，从外部审计员、首席信息安全官（CISO）及架构评审委员会的角度审视系统——确保无需人工逐行讲解，系统也能自动呈现无可辩驳的证据链与执行追踪记录。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=4s) 每个人都在造 Agent — Vishak Mallya > [00:04](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=4s) 谁在治理它们？哪一个 Agent 进行了变更？这是基于谁的授权？它留下了什么审计证据？ — Vishak Mallya > [02:29](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=149s) 这个可以直接上线，因为大模型或 Agent 说它没问题 — Vishak Mallya > [02:29](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=149s) 任何可以被随意跳过或压制的卡点，根本就不是卡点 — Vishak Mallya > [07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) 买下它的双手，守住你的良知 — Vishak Mallya > [07:12](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=432s) 大家总爱提 Human-in-the-loop（人机协同闭环），但在我们看来，这不仅是人在环路中，更得是 Human on the hook（把责任人挂在钩子上 / 让人背锅）！ — Vishak Mallya > [08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) 我们相信它能跑通 — Vishak Mallya > [08:57](https://www.youtube.com/watch?v=3j8SqeGj-lI&t=537s) 我们能证明它跑得通 — Vishak Mallya ## Mentioned Vishak Mallya, Synthetix Labs, Ai4, Slack, COBOL, VB6, PHP, ASP ## Video description Vishak Mallya - Founder, Synthetix Labs What happens when AI agents can write enterprise software faster than your team can trust it? That gap between speed and accountability is exactly where most coding-agent demos collapse on contact with regulated, mission-critical systems. In this talk, I'll show how to move past the copilot demo to governed, full-lifecycle agentic delivery — building, migrating, modernizing, and supporting real production code. Using real engagements that modernized decades-old systems across financial services, healthcare, and insurance, I'll walk through a deterministic-first architecture where intelligent agents do the engineering while automated verification and human oversight keep every change accountable and traceable. You'll leave with a practical framework for what to automate, what to verify, and how to prove correctness — plus an honest look at where agents excel and where they fail. If you're working to get agent-built software into production you can actually trust, this is your blueprint. [Source](https://www.youtube.com/watch?v=3j8SqeGj-lI)

Source quotes

[0:04] Vishak Mallya: 每个人都在造 Agent [0:04] Vishak Mallya: 谁在治理它们？哪一个 Agent 进行了变更？这是基于谁的授权？它留下了什么审计证据？ [2:29] Vishak Mallya: 这个可以直接上线，因为大模型或 Agent 说它没问题 [2:29] Vishak Mallya: 任何可以被随意跳过或压制的卡点，根本就不是卡点 [7:12] Vishak Mallya: 买下它的双手，守住你的良知 [7:12] Vishak Mallya: 大家总爱提 Human-in-the-loop（人机协同闭环），但在我们看来，这不仅是人在环路中，更得是 Human on the hook（把责任人挂在钩子上 / 让人背锅）！ [8:57] Vishak Mallya: 我们相信它能跑通 [8:57] Vishak Mallya: 我们能证明它跑得通

Source quotes

[0:04] Vishak Mallya: Who governs them? Which agent made a change? On whose authority? What evidence did it leave behind? [1:50] Vishak Mallya: because the model or the agent said so [1:50] Vishak Mallya: How much can the agent write? [1:50] Vishak Mallya: How much of this can be proven? [7:12] Vishak Mallya: Buy the hands, own the conscience. [7:12] Vishak Mallya: human on the hook [8:57] Vishak Mallya: behavioral equivalence ledger [17:37] Vishak Mallya: Automate, verify, and prove. [17:37] Vishak Mallya: mechanical, reversible, and undoable

Original transcript

[0:04] Good morning, everyone. And thank you for attending this session. My name is Vishakh Malia, [0:09] and as Austin introduced, I run Synthetics Labs. My background is that I spent about three decades [0:16] delivering mission-critical software to regulated industry, banking and financial services, [0:22] health care, and insurance. This was the pre-AI era, and now with AI coming in, [0:27] we're learning things all over again and learning how to deliver the same mission-critical software [0:32] with with agentic delivery built in, right? Uh you guys have been here at the conference for [0:37] 3 days now. You walked the floor, and one thing is obvious, right? Everybody is building agents. [0:42] I'm sure people in this room have dozens of them in production already. Building them stopped being [0:48] the hard part over the last 18 months, right? Building agents have become almost table stakes. [0:54] But ask the second question, who governs them? Which agent made a change? On whose authority? [1:03] What evidence did it leave behind? And it gets quiet, right? So we industrialized the building of [1:10] the agents, but left the governing to Slack threads or one senior project manager's judgment, [1:16] right? So Synthetics, when we built from grounds up, we're using agents to actually [1:21] create software, but we wanted to also have a strong answer to the second question, [1:26] not just the first, right? Agents do the engineering, reading the estate, [1:31] reading code, writing specs, creating test cases. They do it very well. The platform's job [1:38] is everything around them. What each agent is allowed to touch, what evidence it has to produce, [1:45] and what agent produced it, that's what we're trying to cover using our platform. [1:50] So this isn't a talk about what agents can build. I think you heard that over the last 2 days. [1:55] It's really about how we govern them. I'm going to talk about five principles here. These are [2:00] principles that are not just brainstormed visions or a framework that we've just come up with. [2:06] It is through the battle scars that we've taken actually implementing agentic processes for [2:11] clients and internally. And because the reason that we've built this is because I'm sure a lot of [2:17] people in this room have approved something that they could not fully explain. Maybe last quarter, [2:23] maybe last month, even this morning, right? So, we're trying to give some guidance towards that. [2:29] Just see if it works. So. So, something that I already mentioned about what did we see over [2:35] the last 18 months? Agents got fast, but trust didn't, right? Taking a piece of code that was [2:42] written in the '90s and refactoring it into a new language, agents can do it in a matter of minutes. [2:49] But, if you want to pass that through a risk review, have it audited, and really be able to [2:54] put into the into production, it takes months to get that passed through. You talk to the auditors, [3:01] an auditor who would stand up and say, "Hey, just because the model or the agent said so, [3:06] it's ready to go." You'll have zero auditors ready to agree to that, right? That's why this [3:11] creation of trust is is very important. So, what we did was the bottleneck moved, [3:16] right? We became very good at doing the practical tasks, but the bottleneck is now moved to being [3:22] able to actually put this into production, and that's why we need to build that trust layer. [3:27] And why did this happen? Again, this is the hypothesis and what we've seen, right? [3:31] Coding code generation has become table stakes. Coding agents, demos, and products do very well [3:37] in in in a demo or even in a pilot. But, when you put that into an actual enterprise, [3:43] they are not capable enough of putting things out as much as you would have seen them during the [3:48] demo or the pilot. Why does this happen? I want to introduce a concept of the article, right? [3:54] So, what we learned very soon is that we have to understand to freeze a certain truth even before [4:01] starting any agentic work, right? That frozen truth is, hey, what is the system supposed to do? [4:08] If you are going to go from one system to another, if you're migrating a legacy system to a new one, [4:13] what is the exact behavior of the legacy system? This has to be the frozen truth and that's what [4:17] we call the article. I'll be visiting this concept in the in the future slides as well. [4:22] There is there is no evidence, right? Evidence again has to be a true artifact. The evidence [4:29] cannot be just assertion. Evidence has to be artifacts that are stored throughout the process [4:34] and be able to stand up to scrutiny. Gates, we all create great gates when it comes to [4:40] agentic development, but any gate that can be suppressed is not a gate at all, right? So, [4:47] we need to have strong gates that actually enable us to kind of really ensure that we're really [4:52] putting it to scrutiny. And last, the the whole the whole life cycle. The life cycle has changed, [4:57] right? The agentic life cycle ends when the agent finishes the change, but then comes the whole [5:03] upstream. How do you put this into production? How is the system that was created agentically today [5:08] and put into production 3 months down the line, 6 months down the line, a year down the line? How [5:13] do you How are you able to still prove why some of the decisions that are being taken [5:17] being taken in the system are because of a certain reason. So, all this are some of the reasons why [5:23] we are seeing some of the failure modes when we put agents into into production. So, what we [5:28] need to change is we need to change the question that we're asking today of agents, right? In 2024, [5:34] the question was, how much of this can the agent write? What is the capability of the agent? [5:40] I think 2 years hence, all of us here can be very confident that agent can do it, right? It's [5:45] no longer a capability question, but the question more of this is that how much more or how much of [5:51] this can be proven. So, the question is changed from a capability ask to an accountability ask. [5:56] Capability has become table stakes. Accountability has become the product. Now, before I go into [6:01] the principles, I do need to mention that one of the key elements of uh agentic work that we have [6:07] focused on and especially what we see out there in the industry is legacy modernization. Especially [6:13] in these regulated industries, you have systems that are built in the '80s, '90s, even early 2000s [6:19] that have accumulated a lot of technical debt, right? There's a reason that these have been [6:24] kept because these are keep-the-lights-on kind of systems, and CIOs and leaders have not seen [6:31] the need to actually modernize them, but what has happened is that technical debt has [6:35] kept creeping up. And today, the cost of actually modernizing these systems with the help of agentic [6:41] uh workflows is coming down by very drastically, right? So, we are seeing a point of convergence [6:47] where the cost of modernization and the risk of modernization is overcoming the actual is [6:52] actually converging with the technical debt that's creeped up, and that's why it's become [6:56] a key intent for a lot of CIOs to undertake uh legacy modernization during this phase. And [7:01] that's why many of the examples that I talk to you after this slide will cover legacy modernization, [7:06] but the truth is that it it actually applies for greenfield development as well, right? [7:12] So, let's let's move on to the first principle, the principle number one, and that's kind of [7:15] the highlight of the talk, by the hands on the conscience, right? What do we really mean by this? [7:20] Be able to really derive a strong boundary on what agents can do and what humans should be [7:27] doing in the system, right? When you when you look at humans, what should I let me cover the [7:32] human part first because it's more consequential, right? Having the having the decision to ship, [7:39] owning the evidence, owning the owning the looking at the evidence, making sure that we have a good [7:44] understanding of what the system is supposed to do. The right definition of what is done. [7:50] All of this should rest with humans. Right? Cuz these are very consequential steps. [7:55] Again, I I will caveat it by saying that it is it is as of today. 2 years down the line we might [8:00] have models that are much more powerful, but today this is what humans should own. [8:05] At the same time, things that are mechanical and I've referred to it previously, reading the code, [8:10] creating test packs, creating scaffolding, creating documentation, [8:14] all of this you can have agents owning. Right? But you have to define that the ship decision the [8:21] items of consequence is owned by a human and this is not in the form of a dashboard in which you [8:28] have multiple green checks. It actually needs to have a person who's signing off on that. So, I I [8:34] call it jokingly, it's not just human in the loop, it's human on the hook. Right? You need to have [8:39] somebody who's actually responsible and owns the consequence of that system system shipping. [8:44] So, that's principle number one and we've seen that in production too, right? If if if if you [8:48] don't have ownership of something that's gone into production, at the end of it, [8:51] you don't know who to who to basically target to actually revert something that's been done. [8:57] Principle number two and here is something again that we've learned the hard way, right? Uh we have [9:03] a concept known as behavioral equivalence ledger, right? Again, this is very important when it comes [9:07] to legacy modernization. We have to be able to prove the behavior and not just assert it. How do [9:13] you prove behavior when you migrate a system from legacy to new? You have to first of all be able to [9:19] baseline what that behavior is and this baselining cannot occur just through documentation. [9:24] You have to be able to actually demonstrate that a a legacy system performed in a certain way for a [9:31] certain input. And after that, once the agent has developed the the new system or the target system, [9:38] you have to be able to run the same inputs in the legacy system and the new system and show the [9:45] differential if there are any. And there might be differences. There might be differences by design, [9:51] right? There might be divergences because that's the way you've designed. You're not just migrating [9:55] a new system, you're not just translating the system, but you're also enhancing it and giving it [9:59] new capabilities. So, if that is part of design, then we have to be able to document the divergence [10:05] and keep it keep it documented saying why did this divergence occur? And lastly, [10:10] we have to be able to actually have a signature on top. Again, going back on the human on the hook, [10:15] we need to be able to say, "Hey, who signed off on this divergence? Why was this divergence there? [10:20] What's the timestamp? What is the signature of the person who did that, right?" All of this [10:24] forms a concept known as behavioral equivalence ledger. We keep that as a class one artifact, [10:28] something that people need to actually have it so that it moves from we believe it works to we can [10:33] prove that it works. Spec driven development. I'm sure a lot of folks who are experimenting [10:39] with agentic tools are looking at this. Again, our platform relies a lot on spec driven development, [10:44] which is basically that you have a very strong spec before you go out and develop something. [10:48] Now, again, you cannot verify a spec that doesn't exist, right? How does the spec even get created? [10:54] A spec is not just a document. You have to be able to, going back to the principle of the oracle, [11:00] you have to be able to actually validate the behavior of a a particular system. [11:07] Bring in various data points. Not just the not just the validation through the code base, [11:14] but capturing user interfaces, capturing any SME documents through SME interviews. Find all of [11:21] that and then freeze the baseline and that really becomes the spec that you're validating your new [11:25] system against or the development against and not necessarily just documentation other things. I can [11:31] give an anecdote here. We were We were actually testing out a system and we were verifying it [11:36] against a spec that was a document, but we later figured out that that spec was about 10 years old, [11:41] written by somebody and never updated. The system had drifted from there quite a bit. So, when the [11:46] new system was created, it was not validated It was not getting validated against the spec at all. [11:51] And the reason for that is because of divergence. So, that is when we learned that we cannot [11:55] trust on just a spec that has been created. We need to have these various data points of checking [12:00] hey, how is this big spec being put together? Combination of code base, combination of UI, and [12:05] combination of SME interviews that actually make up the spec. So, that's principle number three. [12:11] Evidence. I spoke about evidence. Now, all evidence is not equal, right? In reality, what we [12:16] saw is that there are there are different tiers of evidence. We We've actually break break it up into [12:20] three tiers. The tier three evidence, which is the least credible one, is where you're inspecting a [12:26] newly created system, but you have not run it in the in the environment and according to the [12:31] same variables as you actually expect it to run. Right? This is the weakest part of the evidence. [12:36] Tier two is where you're running it and it passes, but you have not actually verified it against [12:42] the behavior of the old application. You are taking it on on face value of somebody who [12:48] has tested it and SME who has reviewed it and and that is that is accepted as a evidence. [12:53] And tier one of the evidence, which is most important or most acceptable, [12:56] is where you have run it against that behavioral ledger. You've shown each and every feature [13:00] that was there in the previous application is now working on the new application. So, when you go [13:06] out there and you talk about coverage, when you talk about saying hey, this 87% coverage in in my [13:11] newly built system, make sure that the coverage is not just a number, but you're also enhancing [13:16] that with the tier of evidence that you've collected so that it can be much more presentable. [13:22] Principle number five, and this is the toughest one, and this is actually where this is the last [13:27] mile where governance actually fails, right? So, everything that's put out here is is something [13:31] that we have seen happening, right? One, you need to have one ship decision gate at the end of it. [13:39] It cannot be It cannot be multiple. You need to have absolutely a one It's almost a kill button [13:46] before something is put out there. There needs to be a ship decision that is that is clearly defined [13:51] and able to be enacted. Right? No suppress gates. I've covered this already. You cannot If a gate is [13:57] allowed to be suppressed, it will be suppressed due to deadline pressure. So, we have to ensure [14:01] that we don't have suppressible gates. We need to make sure that there is agent identity. And again, [14:07] that's a whole concept and talk by itself. So, I'm not going to go deep there, but we need to [14:11] have ability to give identity to agents so that we are sure that whenever any decision is taken, [14:19] we are exactly able to track what agent did it. Uh we need to be uh sure that uh [14:27] AI LLMs especially, I'm sure people who have experimented this would have seen, [14:31] have the tendency to conflate things and pass it quickly to compile green. In In Well, doing that, [14:38] what they do is they create stubs. They create stubs of functionalities that are not fully [14:42] available and just build it so that it can it can actually go through the process and get get [14:48] promoted. That's how LLMs are built to behave. So, we need to make sure that in our safety mechanism [14:53] and our guardrails, we ensure that stubbed stubbed features are never put out there into production. [14:59] And last but not the least, we need to make sure that policy is policy is available as code, [15:04] right? Too often policy is put as a document. It is not a pack. Now, in our platform and [15:10] what I advise everybody doing there is that you need to have this policy built as a control and [15:16] policy as code that needs to be there during this agentic development. Right? What is the reality? [15:21] What it looks on real estate? What we've done, some of the things that we are really proud of, [15:26] migrated a 1.5 million line code COBOL application written in the '70s to modern [15:33] code. This is only possible because it was it is one single engagement, but because we [15:37] followed these tight governances, we were able to produce that. Again, as I mentioned, we work [15:42] mostly in regulated industry, so we need to have these kind of things there. So, as you can see, [15:46] examples of various various legacy codes like VB6, PHP, legacy ASP, all of these, but it is basically [15:56] one governance model that covers all of these, very important. Places where we've gone wrong [16:01] and we corrected, right? Things like hey, we spent a lot of times tweaking models, tweaking prompts, [16:06] tweaking contexts, but the default was always bad. We could never achieve that. Then we figured out [16:11] the problem was in the orchestration and the governance, and we had to fix [16:15] that after weeks and weeks of trying. The review loop. We talk about agentic loops. [16:21] Those agentic loops don't come cheap, right? You have to ensure that you have agentic review loops [16:27] till the time that you can drive the defects down to zero. Cuz many times with agentic developed [16:32] code, it's like a game of whack-a-mole. You run it through a review, you fix one defect, [16:36] another creeps up because it has done something to fix just that defect. So, in our worst case, [16:41] we ran about 30 review loops before we were able to get the defects down to zero. And lastly, [16:45] memory. Again, something very important for everybody adopting agentic development, keeping [16:50] that memory as an architecture component and not just a feature, right? Agents have to learn [16:55] through every run and not repeat that mistake. So, ability to understand the memory of a run [17:00] and keep it for other processes to run is actually very important. These are some of the things that [17:05] we we saw wrong and we we corrected them. So, I'll rush through this since I'm running out of time. [17:12] Probably things that we already know. What are agents really good at today? Where we are sure, [17:16] right? They're reliably good in things here marked in green, but where they're not reliable, [17:21] some of the things that we touched. The qualitative aspects, the cross-system boundaries, [17:25] able to tell you, "Hey, is my month end going to break because of this thing?" Right? Able to kind [17:31] of gauge the impact of what they have done and sort of self-certify. Agents are really unreliable [17:37] when it comes to that. So, you have to make sure that you are applying them the right way. So, [17:41] as a takeaway, what can you take away from this whole session that I would like to leave you with, [17:46] right? Take this framework. Automate, verify, and prove, right? What do you automate? You automate [17:53] things that are mechanical, reversible, and and undoable, right? So, basically, [17:59] you have to take up processes where a work done by an agent can be undone and brought back. Do [18:05] not take up processes that are not matching that. Take up volume work first. Take judgment-related [18:11] work later because that's the tough part. So, decide on what processes you're going to automate. [18:16] Figure out how you are going to verify first, right? How do you make sure that what you have [18:21] executed is actually working? How are you able to verify that? Figure out that loop first [18:25] and then be able to prove. Think of it at Think of it from the point of someone who's reviewing the [18:30] system, an auditor, a CISO, review board. How will they actually be able to review the system without [18:36] you actually walking through those and be able to see see what you have done out here? So, uh [18:43] I'll just skip the next slide because I won't I covered this. If you have any questions at [18:46] this point, I can take or you can come to our booth at 1214 and I'll be happy to take them. [18:52] Thank you. Thank you for paying attention to the session. Welcome. [applause]