Trading system development with AI: cost moves from writing code to trusting itThis is the first in our blog series on the challenges of building trading systems today. The anchor post, Capital markets infrastructure: The end of the trade-off between performance and resilience, sets out the challenges at a high level.
This post looks at the challenge of using AI to accelerate your time to market while maintaining core concerns of safety, availability, and performance.
Every firm scoping a new trading system now asks the same early question: Can we use AI to build this faster and cheaper? On the narrow question of writing code, the answer is yes. Well-scoped business logic that took weeks to implement now takes days.
But writing code is not the expensive part of a trading system.
The real cost of trading software is defining it, proving it correct before it goes live, and supporting it in production for the ten years it stays there. AI-assisted development does not shrink that work the way it shrinks code generation. If anything, it inflates them: more code, produced faster, with less deliberate human reasoning behind each line.
Specification now has to be precise enough to constrain a model, not just brief a colleague who shares your context. Verification bites too: a green test is weaker evidence than it used to be, because a model can shape code to pass exactly the tests it is given without the result doing what you intended. The bottleneck has moved from generation to specification, verification and lifetime ownership.
The data points in the same direction. The DevOps Research and Assessment programme (DORA), run by Google, has surveyed tens of thousands of software professionals over more than a decade. Its 2024 report estimated that a 25% increase in AI adoption was associated with a 7.2% drop in software stability. Its 2025 report finds that AI acts primarily as an amplifier of an organisation’s existing strengths and weaknesses: AI makes it easy to produce more code per change. The conventional approaches to specifying, verifying and supporting that change over many years have not kept pace.
Let’s take this amplified burden and apply it to the architecture most trading firms run today: services arranged around a message bus, state held in caches and databases, each service running its own threads, doing its own failover, and reconciling its own view of the world with everyone else’s.
In that world, business logic and distributed machinery are interleaved everywhere. The pricing service carries its retry logic; the order manager carries its cache invalidation; the risk engine carries its recovery-on-restart behaviour.
The fundamental problem is that there is no clear separation of concerns. The application logic and the machinery that ensures fault tolerance, availability and data consistency are woven through the same services. That leaves no clear boundary between the code the model touches and the code that must not break; they are the same code. Your most senior engineers have invested years delicately composing a system you’d never be comfortable handing to an AI assistant to add a new set of instruments, let alone an entire new business line. Add in AI-assisted code generation, producing more, faster, and the problem amplifies. This is where the promise of faster delivery dies.
And when something goes wrong in production, the answers you most need are obscured by race conditions, data mismatches and non-determinism: the interleaving of threads and messages does not recur consistently, so reproducing an incident takes hours or days of retries and cul-de-sacs. When your post-incident review, and your regulator, asks which input drove which decision, the answer has to be stitched together from partial logs written by services that each saw events in a different order.
Behind this amplification burden sits a choice: what should AI be working on? The hard distributed system problems or the application logic?
The hard problems should not be the target. Getting consensus across nodes and services, failover, and recovery right has taken the industry decades of skilled engineering and hardening. Correctness there depends on how the whole system behaves under load and during failure, not on how any single function reads: exactly what an AI model, and a reviewer working function by function, cannot see. The specification and verification lift is enormous, and a defect is not a bug ticket but a potentially existential event for a trading firm.
And all of that effort is non-differentiating. Clients do not choose you for your fault tolerance or consensus implementation; they choose you for what your system does for them, and every hour of scarce senior engineering spent specifying and verifying distributed machinery is an hour not spent on the logic that wins business. Hard, complex, and invisible when it works: this is the last place to spend the speed AI gives you.
Application logic is the best target: bounded, testable, reviewable, and the place where your business actually differentiates. It is also where the speed genuinely compounds, because pricing rules, workflows, and risk checks are the code that changes every quarter, for the simple reason that the market does.
Many firms have written this into their AI usage conventions, but in a conventional stack the interleaving overrules them: every service still hands the model some concurrency, some failover, some reconciliation. Creating a separation of concerns that is architectural is the best way to allow safe AI-assisted code development at pace on your application.
State Machine Replication (SMR) is the architecture that provides exactly that separation, as a property of the system rather than a convention that survives only as long as discipline maintains it. The application runs as a single-threaded, deterministic state machine: it consumes an ordered log of input events, applies business logic within a single threaded context, and emits an ordered log of outputs.
If you are used to thinking in terms of a message bus and a database, the ordered log plays both roles at once. It is the message stream and the system of record, and because multiple State Machine replicas process the same events in the same order through the same deterministic logic, replicas cannot drift apart. Keeping them in step, surviving the loss of a replica, and recovering after a crash all live below a platform boundary, and are never the application’s concern.
For AI-assisted development, this separation works across the three dimensions we’ve been discussing, and it is what turns the answer to the opening question into a genuine yes: the speed of generation survives, because specification, verification and support no longer consume it.
Specification: Before any code exists, the platform hands the developer and AI-agent a bounded contract rather than a distributed system to reason about: these are the input events you will receive, these are the outputs you are permitted to emit, these are the business invariants, such as the sum of money in the system, that the state must always satisfy. However capable the AI model, an unconstrained problem space gives you something harrowing to build and support. A bounded contract makes the work tractable, though it still demands engineering judgment to specify, review, and own what is produced.
Verification: After the code is generated, it is verifiable. Deterministic logic over an ordered log means a failure in that logic reproduces exactly by replaying the log: an engineer can watch the precise decision path and confirm the invariants held at every step. A human can genuinely own AI-assisted code because the architecture can always show them what that code did and why.
Long-term support: Once the system is live, the decade of ownership falls to people who mostly did not write the code. Deterministic logic keeps that inheritance understandable: behaviour is fully described by ordered inputs and outputs, so an unfamiliar state machine can be learned without archaeology. Incidents stay diagnosable years later, because replaying the log reproduces the exact events that led to a failure. And the estate your team supports stays small, because the machinery with the heaviest support burden is the platform’s to patch, harden, and evolve.
The play that falls out of this is the oldest principle in business strategy: concentrate your scarce engineering attention on the things that make customers choose you, don’t own the machinery that does not. Capital markets firms are settling on exactly this hybrid position on the buy-versus-build spectrum, buying the hardened platform machinery and building the differentiating logic on top, as we set out in our Markets Media piece on buy and build.
AI strengthens both halves of that position. The more code AI-assisted generation adds, the more the separation between application and platform matters, because the platform bounds what AI-assisted code can touch: amplification lands on the logic that differentiates you, while the machinery whose defects are existential sits outside AI’s scope, where risks are managed, not amplified.
Aeron Sequencer is Adaptive’s enterprise SMR platform, built on the open-source Aeron Cluster, a consensus implementation proven over years of mission-critical production. It owns the layer this post has argued you should not own: consensus, replication, and recovery, plus the operational properties that make a trading system safe to run and fast to build on.
A message is processed only once a majority of cluster nodes have stored it, so losing a node loses no data. Replicated snapshots keep recovery time bounded too: a recovering node replays from the latest snapshot rather than from the beginning, however long the system has been running.
Availability is a configuration choice, active-passive or fully active-active per group of applications. Application upgrades need no downtime either: versioned protocols let two versions of a service run side by side and cut over cleanly during trading hours. And the audit trail reads off the same single ordered log, one that a regulator can follow without forensic investigation. The full architecture is set out in the white paper, Aeron Sequencer: A Reference Overview.
Your team, and the AI assistant working alongside it, builds the deterministic state machine above that boundary, with the governance and review that code always requires. The platform is what makes that ownership practical; a firm that builds like this inherits decades of distributed-systems correctness research instead of paying to rediscover it one incident at a time.
And none of this costs you performance. Production trading systems built on Aeron Sequencer run at microsecond latency, and because every replica already holds identical state, a standby can take over without a reconciliation step, which is how well-operated deployments keep downtime to minutes a year.
Eric Bowden, a senior engineer in our platform team, recently used AI-assisted development on this stack to build, in two weeks, a proof-of-concept replacement for etcd, a strongly consistent distributed store. Eric wrote a small deterministic core, verified against etcd’s existing client test suites (with significant performance gains), which is what made two weeks possible. The consensus, replicated log, and crash recovery came from the platform: Aeron Sequencer. It is a demonstration of how fast AI-assisted development can be. The full account is in a forthcoming companion post, seqcd: a drop-in etcd replacement, built on Aeron Sequencer.
The question that decides your next build is not whether AI-assisted development can write it. The question is whether you can trust what it built, at 3 am, in four years’ time. Trust of that kind comes from architecture and the engineering discipline it makes possible, not from the AI model. In our forthcoming AI posts, we’ll look at the engineering discipline, governance and toolchains that make AI development possible on Aeron Sequencer.
So, can you use AI to build a trading system faster and cheaper? Yes, when the architecture lets you.
If you are considering a new build now, the conversation worth having is where the platform boundary should fall for your system, so that AI accelerates the logic that makes you different and never touches the layer that should not be yours to own. Please get in touch to have that conversation.
Ralph is a Strategy Executive at Adaptive with 20+ years in capital markets tech, driving exchange, matching engine, and Aeron-based product strategy for global trading venues and fintech leaders.
Explore how Aeron Sequencer applies state machine replication and consensus-based design to deliver always-on, scalable capital markets systems.
Capital markets firms no longer need to trade performance for resilience—learn how modern platform design delivers both.
Learn how state machine replication with Aeron Cluster simplifies mission-critical trading systems while delivering fault tolerance and microsecond-level latency.
Explore how 50 capital markets firms are shifting to hybrid and cloud models—benchmark your trading technology strategy against industry peers.
LinkedIn profile