The New Quant Desk — AI for Speed, Quants for Correctness

AlgoQuantHub Weekly Deep Dive

Author

Nicholas Burgess
July 31, 2026

Welcome to the Deep Dive!

Each week on The Deep Dive we explore cutting-edge ideas in algorithmic trading, quantitative research, and modern financial engineering, bridging theory and practice in how markets behave.

This week we explore: The New Quant Desk — AI for Speed, Quants for Correctness. AI made code, tests and backtests nearly free to produce. It didn't make them correct — that's still the quant's job, and it's why the new Quant desk needs both.

Table of Contents

Feature Article: The New Quant Desk — AI for Speed, Quants for Correctness

Starting with the part that isn't controversial: for a working quant, AI is a real accelerant. Point it at a mature library and you can generate unit tests around code that never had them, draft the documentation nobody found time to write, and refactor a procedural pricer into something maintainable — in a fraction of the time it takes by hand. The shift is that you spend less time writing code and more time reviewing it, and reviewing a solid first draft is faster and less error-prone than starting from a blank file. You begin every task with a running head start instead of a cold engine.

But faster production isn't the real story, and treating it as the whole story is where teams get hurt. When code, tests, docs and backtests become nearly free to generate, the bottleneck doesn't vanish — it moves, from production to verification. The scarce skill stops being "can you build it" and becomes "can you tell when it's wrong." An AI will happily hand you a pricer that compiles, runs, and is quietly off by a day-count convention, or a backtest that looks brilliant because it's peeking at future data (look-ahead bias). Last month Claude handed my team exactly that — a pricer that compiled, ran, even the tests passed (false positive), and was off by a day-count convention; it took a second pair of human eyes to catch it, not the machine. Those failures are plausible, not obvious — and plausible-wrong is far more expensive to catch than obviously-broken. The quant who can generate but can't verify simply produces mistakes faster.

So the edge is judgment, not output — and that carries a cost we should name out loud. If juniors learn to prompt before they learn to price, the profession hollows out from the bottom: people who can assemble a solution but can't defend it, debug it, or tell a real signal from an overfit one. When I interview juniors now, I care less about whether they can prompt a solution and more about whether they can tell me why it's wrong — because prompting is cheap and judgment isn't. The answer isn't to refuse the tools — that's just slower and no safer. It's to use AI to understand faster, not to understand less: generate the draft, then force yourself through the derivation, the edge cases, the assumptions. Automate the typing, never the thinking. Get that balance right and AI makes you a stronger quant; get it wrong and it quietly makes you a worse one who ships more.

Keywords: AI-Assisted Development, Model Risk, Verification, Quant Workflow

Bonus Article: Agentic Quant Development - How to Wire AI Into Your Quant Library Safely

Agentic AI is moving from autocomplete to teammate, and your setup decides whether that's an asset or a liability.

The step past copy-pasting from a chat window is agentic: you give the model direct access to the repository and let it work across the whole codebase — read the library, run the tests, propose changes, iterate.

This is fast becoming the norm rather than the novelty. What you're really building is a controlled loop: the model reads your existing pricer, you pin the current numbers with regression tests so nothing silently changes value, and only then do you let it refactor, extend, or document. The guardrail is the point — the single highest-value step is capturing known-good outputs before a line is touched: 

// Define & Pin known-good outputs BEFORE letting AI touch the pricer.
// Any refactor that changes a number now fails loudly.
TEST(CdsPricer, MatchesGoldenValues)
{
    CdsPricer p = makeStandardTestCds();
    EXPECT_NEAR(p.pv(),        -132540.18, 1e-2);
    EXPECT_NEAR(p.parSpread(),    0.008734, 1e-6);
}

With that harness in place, the benefits compound while the risks stay bounded: the AI can modernise a legacy library, add a Quanto extension, or write the missing docs, and any drift in a number fails a test immediately instead of surfacing in production three weeks later. The challenges are real and worth stating plainly — models hallucinate maths that looks right, lose track of context in large codebases, and will confidently "fix" something that was already correct. The discipline that makes agentic quant development safe is the same one from the feature: the machine produces, the human verifies, and your tests are what let you trust the loop instead of the vendor.

More detailed implementation frameworks and structured trading models are available in my AlgoQuant playbooks and trading toolkits.

Keywords: Agentic AI, Regression Testing, Library Modernisation

AlgoQuant Playbooks & Trading Toolkits

Explore my quantitative trading and financial markets toolkit store, featuring practical implementation frameworks for yield curve construction, derivatives pricing, risk modelling, and live market trading.

Feedback & Requests

I’d love your feedback to help shape future content to best serve your needs. You can reach me at [email protected]