A dollar today is worth more than a dollar tomorrow — and that single sentence, made precise, is the foundation beneath every price in finance. Discounting future cash flows back to their value today is the operation you perform, explicitly or implicitly, every time you value anything: a bond, a stock, an option, a company, a mortgage. Master this one idea and most of finance becomes arithmetic on top of it.
A dollar today is worth more than a dollar tomorrow — and that single fact, made precise, is how everything in finance gets valued. Present value, future value, discounting, and the discounted-cash-flow method that prices anything with a future payoff. (Educational, not financial advice.)
Post 1 argued an LLM application is never "done." This post gives that idea a shape: the LLMOps lifecycle, the repeating loop of develop → evaluate → deploy → observe → improve that a production LLM system lives inside. Seeing the whole loop at once is what turns a pile of practices — prompt management, evals, guardrails, monitoring — into a coherent operating model, and it's the map for the rest of the series.
The LLMOps lifecycle — develop, evaluate, deploy, observe, improve — as a loop an LLM app lives inside, not a line it runs once. Why evaluation is a first-class stage appearing twice, why production feedback flows backward, and why the loop turns whether you act or not.
Machine learning promises to find patterns humans miss, and finance is drowning in data — so surely ML should mint money? The reality is humbling: finance is the hardest domain to apply ML to, because the data is noisy, non-stationary, and adversarial, and the ways to fool yourself are endless. This post is an honest guide to where ML genuinely works in finance, where it reliably fails, and why the discipline here is mostly about not deceiving yourself.
Finance is the hardest domain to apply ML to — noisy, non-stationary, adversarial — and the ways to fool yourself are endless. An honest guide: where ML genuinely works (information, structure, credit, computation), where it reliably fails (market prediction), and why the discipline is mostly not deceiving yourself. (Educational, not financial advice.)
Forward deployment that isn't run as a disciplined function becomes an unscalable custom-dev shop. The Forward Deployed Leader owns the motion as a business — the team, the scoping, the economics, and the decision of what becomes product.
Forward deployment that isn't run as a disciplined function becomes an unscalable custom-dev shop. The Forward Deployed Leader owns the motion as a business — team design, scoping discipline, unit economics, and the decision of what becomes product — and names the invisible trap: it feels like success right up until the margins invert.
Financial engineering is what happens when you point the tools of mathematics, computer science, and engineering at money. It is the discipline behind pricing a derivative, measuring the risk of a portfolio, and deciding what a future cash flow is worth today. For engineers, it is a surprisingly familiar world — models, assumptions, edge cases, and a relentless question of what a thing is really worth. This series builds it from first principles.
Financial engineering applies math, statistics, and computation to money — and under the jargon it rests on three ideas an engineer will recognize: the time value of money, the trade-off between risk and return, and no-arbitrage. This series builds quant finance from those foundations. (Educational, not financial advice.)
Getting an LLM feature to work in a demo is easy; keeping it working, safe, and affordable in production for a year is a different discipline entirely. That discipline is LLMOps — the operational practices for running LLM-powered applications in production. It inherits a lot from MLOps, but the differences are sharp enough that treating an LLM app like a traditional ML model is one of the most common and expensive mistakes teams make. This series is about the operational layer that the demo never shows you.
Getting an LLM to work in a demo is easy; keeping it working, safe, and affordable for a year is a discipline. What LLMOps is, how it differs from MLOps, and the five properties of LLMs — opaque external models, prompt-defined behavior, fuzzy correctness, non-determinism, new failures/costs — that force a different playbook.
If the valuation engine answers "what is this worth?", the risk engine answers the question that actually keeps institutions solvent: "what could go wrong, and how badly?" Risk engines turn the theory of VaR, stress testing, and scenario analysis into production systems that run across whole portfolios — and AI both accelerates them and extends them into risks that were previously too unstructured to quantify. This post is about building the risk core.
The risk engine answers what keeps institutions solvent: what could go wrong, and how badly? Building VaR, stress testing, and scenario analysis in production, how AI accelerates (surrogate-powered scenarios) and extends (unstructured risks) — and the danger it carries: AI can make risk engines more confident and more wrong at once. (Educational, not financial advice.)
The forward deployed engineer builds a win inside one customer. The Forward Deployed Architect makes that win survive the next ten — turning bespoke builds into reference architecture, passing security review, and deciding what's reusable. It's the missing layer between heroics and product.
The forward deployed engineer builds a win inside one customer; the Forward Deployed Architect makes it survive the next ten — reference architecture, security and governance that passes review, and the reuse decision that separates product from one-off. The missing layer between heroics and product.
Everything in this series converges on one discipline: you cannot optimize what you haven't measured. GPU performance is unintuitive — the bottleneck is rarely where you'd guess — so the engineers who make inference fast are the ones who profile first, identify the actual limit, apply the one lever that moves it, and measure again. This closing post ties the series into a workflow you can actually run, and looks at where inference engineering is heading.
You can't optimize what you haven't measured. The optimization loop — baseline, profile, find the dominant limit, apply the matching lever, repeat — plus knowing when to stop, leaning on the ecosystem, and the durable mental model behind it all.
At the heart of most financial systems is an engine that answers one question: what is this worth? Pricing and valuation engines turn the mathematics of the [first-principles series](/blog/series/financial-engineering-from-first-principles/) into production software — and AI is reshaping them, both by accelerating expensive computations and by valuing the illiquid instruments that have no market price. This post is about building the valuation core and where AI fits into it.
At the heart of most financial systems is an engine answering 'what is this worth?'. Building valuation engines in production, and where AI fits: accelerating expensive computations (ML surrogates for Monte Carlo) and extending valuation into illiquid, document-driven instruments. Engineered to be validated, auditable, and reproducible. (Educational, not financial advice.)
The forward deployed engineer gets all the attention, but forward deployment is bigger than one role. It's a go-to-market operating model with three layers — build, scale, run — and seeing the whole stack is how AI companies turn embedded engineering from a heroic cost center into a repeatable engine.
The forward deployed engineer gets all the attention, but forward deployment is bigger than one role — it's a go-to-market operating model with three layers: build (engineer), scale (architect), run (leader). Seeing the whole stack is how AI companies turn embedded engineering from a heroic cost center into a repeatable engine.
The single largest consumer of GPU memory during inference often isn't the model — it's the KV cache, the growing store of attention state that lets a model generate text without recomputing the past. Managing it well is the difference between serving a handful of users and serving thousands on the same hardware. This post explains what the KV cache is, why it's such a brutal memory problem, and how PagedAttention borrowed a 1960s operating-systems idea to solve it.
The KV cache often exceeds the model weights in HBM, and naive contiguous allocation wrecks concurrency with fragmentation. PagedAttention applies operating-system paging to fix it — a core inference bottleneck solved by borrowing a classic systems idea.