Financial Quants and Forge: Writing Trading Algorithms Without Exposing the Alpha

For most software teams, a coding assistant is a productivity tool. For a quant desk, the calculus is different, because the codebase it would be reading is not incidental to the business — it is the business. The signal generation logic, the position sizing rules, the execution algorithm that decides how an order gets worked against the book: all of it lives in source code, and all of it is the specific, hard-won output of years of research that a firm has no intention of routing through infrastructure it doesn't control.

That puts quant engineering teams in an odd position relative to the rest of the industry. Everyone else is deciding whether to adopt AI-assisted coding. A quant desk has largely already decided the answer is yes, in principle. The productivity case for a repo-aware assistant is not in dispute. What it's instead stuck on is a narrower, harder question: how do you get the benefit of a model that has read your entire codebase without that codebase, or any trace of it, ever leaving the building.

Why trading code is a different category of secret

Most enterprise source code is valuable because it's expensive to reproduce: replacing it would cost engineering time. Trading strategy code is valuable because it's expensive to discover. The logic itself might be a few hundred lines. What those lines encode is the answer to a question, which signals matter, in what combination, at what threshold, executed in what sequence, that took a research team months or years of iteration against market data to arrive at. A competitor who saw the code wouldn't need to reverse-engineer the idea. The idea is right there, in the conditionals and the parameter values.

That changes what "the codebase" means as an asset to protect. It's not just the finished strategy files. It's the backtesting harnesses, which reveal what the firm tests for and, by omission, what it doesn't. It's the execution algorithms, which encode views on market microstructure and venue behavior that are themselves a form of edge. And it's the commit history, arguably as revealing as the current state of the code, since it shows the reasoning behind a strategy's evolution, not just where it ended up. A cloud coding assistant that indexes a repository to be useful is, by construction, building a representation of all of that on infrastructure the firm doesn't own.

The specific failure mode of cloud copilots on quant code

A cloud-based coding assistant earns its usefulness by building context: it reads the repository, indexes symbols and call graphs, and uses that index to make completions and answers relevant to the actual codebase rather than to code in general. That's exactly the mechanism that makes it unsuitable for a strategy codebase. The index has to exist somewhere, the prompts sent to generate it have to transit somewhere, and "somewhere" is a vendor's infrastructure with its own logging, its own retention posture, and its own attack surface, none of which the firm can fully audit no matter how carefully the contract is written.

Redacting or truncating what gets sent doesn't fully close the gap either. A strategy's logic isn't concentrated in one flagged file that can be excluded from indexing. It's distributed across the signal layer, the risk layer, and the execution layer. A codebase with the sensitive parts blacked out is a codebase the assistant can no longer reason about coherently, which defeats the purpose of using a repo-aware tool in the first place. The choice a cloud tool forces isn't between convenience and security. It's between a coding assistant that actually understands the repository and one that's been deliberately blinded to the parts that matter, which tends to be most of it.

What changes when the assistant runs inside the perimeter

Forge is built around the premise that a repo-aware coding assistant and a sealed, air-gapped deployment aren't in tension — that the index, the model, and the inference all need to live inside the same boundary as the code they're reasoning about. For a quant engineering team, that reframes the problem instead of trimming it.

The assistant can index the full repository — strategy code, backtest harnesses, execution logic, historical commits — because there's no external destination for that index to leak toward. Substrate, the platform underneath Forge, builds and maintains that context on the appliance itself, so the model's understanding of the codebase is as complete as the codebase, not a redacted subset of it.

Engineers get the workflow they'd expect from a modern coding copilot: inline completions, repo-aware chat, refactoring assistance across files that reference each other, without a corresponding decision about what's safe to expose, because nothing about using the tool routes code outward. The question a quant engineer would otherwise have to ask before every prompt, is this the kind of file I can paste into a cloud tool, doesn't need to be asked, because the tool never had an outbound path in the first place.

Governed connectivity, mediated by Substrate, means the appliance can still reach what it legitimately needs (internal package registries, an on-prem model updates channel, whatever the firm's own policy permits) without that connectivity defaulting to open. For a desk that has spent years building information barriers between teams and counterparties, an AI tool with an ungoverned network path back to a vendor would have been a strange exception to carve out. Forge is built so that exception doesn't need to exist.

Where this intersects compliance, not just security

Quant firms answer to regulators and to their own risk committees about where proprietary logic lives and who can see it, and that scrutiny has extended naturally to AI tooling as adoption has grown. A firm that can point to a sealed, on-premise deployment as the answer to "where does strategy code go when an engineer uses the AI assistant" has a materially simpler story to tell than one that has to describe a vendor's data handling policy, retention schedule, and the scope of a data processing agreement, then hope all three hold up under questioning. The former is an architectural fact. The latter is a set of promises about someone else's infrastructure.

That distinction also simplifies internal governance. Information barriers between desks, need-to-know restrictions on strategy code, and audit trails for who touched what are all controls a quant firm already runs. An AI coding assistant that lives inside the same perimeter as the code it's assisting with can be brought inside those existing controls, access governed the same way repository access already is, rather than introducing a parallel, less well-understood set of permissions tied to a separate vendor's account model.

What this doesn't solve

A sealed coding assistant protects the code while an engineer is writing, reading, or refactoring it with AI assistance. It does not, by itself, govern what happens to that code afterward: a developer copying logic into a personal note, a laptop leaving the building unencrypted, a contractor with broader repository access than their role warrants. Those remain personnel, endpoint, and access-control problems with their own existing solutions, and no coding tool, sealed or otherwise, substitutes for them. What a sealed deployment does remove is the specific exposure that comes from the tool itself: the possibility that the act of getting AI assistance on a trading algorithm is, incidentally, also the act of sending that algorithm somewhere outside the firm's control. For a codebase where the logic is the asset, closing that one path is not a marginal improvement. It's the difference between a tool the desk can actually use and one it has to work around.