Agentic Code Generation as Compilation

Sources#

How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes

Summary#

Santi Weight, technical lead on Bridgewater's Pocket Analyst Tool and a compiler-theory and programming-language-design background, offers the talk's closing thought exercise as its actual thesis: think of agentic coding as a compiler problem, not an agentic problem. The stated analogy is structural — a compiler takes user code and lowers it to a target like JavaScript; a coding agent takes a user prompt or plan and lowers it to Python — and the requirements profile is the pull: compilers are expected to be deterministic, correct, and reliable, which is exactly the profile a hedge fund needs before it will let generated analysis sit underneath billions of dollars of trading. "We can't have just vibe-coded analysis be the underpinning of how these analyses go."

The claim is not that a compiler is a good metaphor. It is that four decades of compiler technique — a typed intermediate representation, dependency-graph scheduling, parallel lowering, mandatory validation passes, static analysis, and caching — are directly transplantable, and that transplanting them buys properties that prompting for the same behavior does not. Each of the four moves below is a compiler technique doing recognizable compiler work.

The plan is a typed IR, not a to-do list#

The chat agent produces an analysis plan; the coding agent consumes it. The plan is decomposed into tasks, each mapping approximately to one Python function computing one data frame. A task's schema carries a name, a description of what to calculate, and — the load-bearing part — structural and semantic information about the data frame that should come out.

Weight draws the contrast explicitly: "our analysis plan isn't just a to-do list like you'd see in Claude Code. Instead, we think of it as a natural language Python project." A to-do list names intentions; this names interfaces. The distinction is the same one that separates a build script from a linker: once every task declares the shape of what it emits, every other task can be compiled against that declaration instead of against the artifact.

This is also where the planning cost is deliberately incurred. Michael Ran describes the planning phase — enumerating every data frame in the analysis, its schema, and how all those data frames connect — as "relatively expensive from a time perspective, but it's a cost we pay deliberately because of what it lets us do during execution." The investment-side framing of the same decision, that "the plan is the analysis", is treated on Planning / Execution Division of Labor; this page is about what a sufficiently typed plan buys the compiler downstream.

Parallel lowering, and why it is not merely fan-out#

Because each task declares its output schema and its dependencies' schemas, code for every task can be generated at once: "a visualization task at the end of the plan already knows everything it needs to consume from code generation that hasn't yet been completed for loading data." The consumer is compiled against a declaration, not against a produced artifact — the separate-compilation property that lets a C project build every translation unit in parallel from headers alone.

Two self-reported numbers attach to this. Against Claude Code, for the same context and the same plan, PAT generates code about 4x faster. And the scaling shape: a 20-task plan takes roughly the same wall clock as a 3-task plan, which Weight calls "hyper-scaling."

Both numbers should be read narrowly. Constant-time-in-task-count is what any embarrassingly-parallel fan-out gives you up to a concurrency limit, and it is the unsurprising half; the claim that carries weight is that fanning out this way does not cost quality, because each sub-agent is compiling against a complete interface rather than guessing. That half is not measured in the talk. The 4x figure compares a domain-specialized pipeline against a general-purpose agent that was never given the typed plan as an input format, and — as with the corpus's other determinism-beats-autonomy results — no ablation isolates which ingredient carries it: plan typing, parallelism, and the execution layer below are all varying at once. Deterministic Engineering for Agent Code Review has the same missing arm, and Deterministic Pre-Execution Gates names it as the corpus's standing unrun experiment.

Validation enforced in the architecture, not requested in the prompt#

After generation, the pipeline runs static analysis over the emitted code, derives the DAG, and dispatches validation agents in parallel across dependency layers — "a five-task plan comes down to three layers, and a 20-task plan might be four or five layers of validation." Each validation compares the generated code against the task that produced it, edits the code when it does not match, and iterates.

The architectural claim is the point Weight most wants taken home:

"We enforce correctness in the architecture. Again, no agentic orchestration. This is regular Python code, so the guardrails are really hard, and the agents cannot forget to validate. They are forced to validate."

The high-level architecture diagram, he notes, is "actually just Python code. It's influenced by LangGraph, but there's no agentic orchestration." The distinction being drawn is between a validation step an agent is instructed to perform — which it can skip, forget, or declare unnecessary — and one that is a statement in the enclosing program, which it cannot reach. This is the same lever as a fail-closed runtime gate (Deterministic Pre-Execution Gates), a rule-driven dispatcher (Deterministic Engineering for Agent Code Review), and the promotion of validated behavior into zero-token deterministic paths (Crystallizing Agent Work into Workflows) — moved one level up, to the orchestration of the agents themselves rather than to their tool calls.

The execution layer: run the code for the model, then cache it#

Weight's second architectural inversion: coding agents normally invoke their own generated code through a terminal tool call. He names two costs — the latency of the tool-call round trip, and that agents "will sometimes get lost along the way." PAT instead executes the code on the model's behalf, through a custom framework fed by a classical static-analysis pipeline that injects caching annotations into the Python to avoid re-execution.

The first-run win is modest and mechanically explained: PAT never double-loads data or double-executes intermediates. The real claim is about the second run. Their benchmark takes a finished plan and changes only the name of its last chart. Claude Code re-runs everything — "basically the same amount of time, though it is faster at editing the code" — while PAT's execution is "basically instantaneous." The product consequence is the one that matters to the user: an investor can make small tweaks to an analysis without paying a full iteration each time.

Note the honest concession inside the comparison: Claude Code is faster at the edit itself. The win is not generation speed, it is that a memoized dependency graph makes the blast radius of a small edit small, where an agent re-invoking its own script has no representation of what did not change.

What the 95% determinism number means, and what it does not#

The headline reliability claim: "when we run our test suite on any plan, 95% of the time, the code that comes out is exactly the same for two different agents. So it's essentially a deterministic coding agent." The design intent underneath it is stated separately, as an expectation imposed on the task spec rather than a property of any model — "we expect every task to deterministically compile via LLM to a piece of code. So two LLMs operating on the same task should produce code that, when run, is semantically equivalent — the same output values, exactly the same."

Three readings are worth separating, because the talk runs them together:

The design expectation is semantic equivalence (same output values). The measurement reported is textual identity (the code "is exactly the same"). Textual identity is the stronger property and the easier one to measure; it is also achievable by a tight enough spec collapsing the output space, independent of whether the semantics were ever checked.
The 95% is measured downstream of the repair loop. Generation, validation, and code-editing all run before anything is compared, so the figure conflates how tightly the typed plan constrains the first emission with how reliably the validation layers converge two different runs onto the same fixed point. Those are different engineering achievements with different failure modes, and the talk credits the first while measuring after the second.
Determinism is being purchased as an eval substrate, not as an end. Weight's stated payoff: "because we have such a reproducible agent, as we're scaling and hill climbing and evaluating, we have something much more dependable than vibes-based or LLM-as-judge evals." A reproducible pipeline makes a benchmark delta attributable to the change you made rather than to sampling noise — the complaint against LLM-judge variance that Production-Sourced Evaluation and Measuring Beyond Accuracy Saturation both circle. This is the most transferable claim on the page and the one with no number attached at all.

Specialize, then compound — the direction is one-way#

The talk's first takeaway is a strategic corollary of the architecture. Bridgewater explicitly does not believe in generic, powerful agents: "They make really cool demos... But it's really hard to make that a daily workflow that you can depend on." The prescribed order is narrow workflow → heavy benchmarking → hill climbing → composition, with a directionality claim attached: "You can then compound the agents after the fact, but it's harder to go back the other way."

The asymmetry is the interesting half, and it is asserted rather than demonstrated. It says a specialized agent can be generalized by composition more cheaply than a generalist can be specialized by constraint — which, if true, is an argument about where in a product's life the typed-plan discipline has to be adopted, not merely which architecture is better. Nothing in the talk tests it.

Connections#

Planning / Execution Division of Labor — the same plan/execute split seen from the other side. That page's telemetry finding is descriptive (humans make ~70% of planning decisions, agents ~80% of execution decisions in observed Claude Code sessions); PAT's architecture is the prescriptive version, deliberately paying for an expensive planning phase to make execution parallel and checkable. Ran's "the plan is the analysis" is the product-side statement of this page's compiler-side claim that the IR is where the correctness budget should be spent
Deterministic Engineering for Agent Code Review — the corpus's other "constrain the agent, beat the general-purpose baseline" result, and the closest methodological sibling: both compare a purpose-built pipeline against Claude Code, both report large multiples, and neither runs an ablation, so in both cases the credit assignment across deterministic injections is untested. The differences are instructive — OpenCodeReview's determinism sits in dispatch and output bounding and its headline is a precision/recall swap; PAT's sits in the IR and the execution layer, and its headline is latency plus reproducibility, with no quality metric reported at all
Deterministic Pre-Execution Gates — the same enforce-in-the-runtime lever one level down. A gate is a pure predicate over a proposed tool call; PAT's validation layers are mandatory passes over a proposed program, scheduled by a DAG the runtime derived rather than by anything the agent decided. Both pages rest on the identical unproven premise — that architecture beats instruction — and both lack the instruction-only control arm that would establish it
Crystallizing Agent Work into Workflows — the lifecycle counterpart. Malik promotes repeatedly-validated agent behavior down a spectrum toward zero-token deterministic code on accumulated evidence; PAT starts at the deterministic end by construction, deriving its structure from the domain rather than earning it from a track record. The two describe opposite entry points to the same destination, and PAT's is only available because the domain's shape (analyses are data-frame DAGs) was known up front
Intra-Trace Parallel Planning (SPRINT) — the same DAG-recovery insight applied inside a reasoning trace instead of across a plan: SPRINT finds that a chain of thought is secretly a dependency graph and repacks independent steps to run together. PAT never has to recover the graph, because the typed plan declares it — the difference between inferring an IR and being handed one
Dynamic Workflows: An Algebra for Agents — the nearest first-party analogue and the sharpest contrast. Claude Code's dynamic workflows also compose agents from ordinary program code in a sandbox, but the model writes the program; PAT's orchestration program is written by humans and fixed, which is what makes "the agents cannot forget to validate" a guarantee rather than a tendency
Harness Shrinkage as Models Improve — a genuine counter-current worth naming. The shrinkage thesis holds that scaffolding is deleted as models improve; PAT's harness is elaborate and growing (typed IR, validation DAG, static-analysis caching layer, custom execution framework) and its authors expect that to remain load-bearing. The reconciliation the two pages suggest is that shrinkage applies to scaffolding that substitutes for model capability, while enforcement machinery that supplies a guarantee the model cannot supply at any capability level does not shrink — the same split the shrinkage page already concedes for mechanical verification
Verification as the New Bottleneck — verification relocated into the compiler's pass structure, where it costs no separate human step and cannot be skipped, plus a second-order form specific to this design: PAT self-checks its finished analysis for sensible numbers and clean charts before returning, the "junior analyst double-checks their work" step
Bridgewater Associates — the organization, the 50 years of written-down investment logic that made a machine-readable domain context available, and the multi-archetype team structure that built PAT

Open Questions#

Does the plan-as-typed-IR discipline transfer to a domain whose work does not decompose into a schema-declarable DAG? Every property on this page — parallel lowering, layered validation, memoized re-execution — descends from the fact that a Bridgewater analysis is a data-frame dependency graph. Falsifiable by anyone reporting the same architecture on an open-ended coding domain (refactoring, incident response) with a latency or reproducibility number.
Is the 95% two-agent code identity a property of the typed plan or of the validation repair loop? The obvious ablation — measure identity on the pre-validation emission — separates them and is cheap for anyone running this architecture. Until it is run, "essentially a deterministic coding agent" credits the IR for work the repair loop may be doing.
Does the specialize-then-compound directionality claim hold — that narrow benchmarked agents compose upward more cheaply than generalists specialize downward? It is the talk's most load-bearing strategic assertion and carries no evidence.

Sources#

How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes — Brendan McManus, Michael Ran & Santi Weight (Bridgewater Associates applied AI team), How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes, LangChain channel, 2026-07-24, 25:44 conference talk, case-study. This page draws on Weight's technical segment (18:08–25:29) plus Ran's planning and execution narration (11:14–14:27). Evidence handling: every number here is first-party, self-reported, and unmethodologized — the 4x codegen figure, the 20-task/3-task equivalence, the 95% two-agent code identity, and both execution-layer benchmarks are stated from slides with no published task set, sample size, model, or date, and the comparison baseline (Claude Code) is a general-purpose agent evaluated outside the format PAT's pipeline is built around. Treat all of them as directional claims by an interested party, not as measurements. Slide visuals, including the architecture diagram and both benchmark charts, are not captured in the transcript