We Don’t Use AI-Generated Code in Live Production Environments
Growth used to be linear. You added clients, you pushed volume, and the business got bigger in a fairly predictable way. In 2026, with the advent of AI, it is now far more demanding. Brokers are often expanding across products, asset classes and markets simultaneously, while working on much shorter timelines than even a few years ago. Growth cycles are shorter, and the room for error is smaller.
So the question is no longer just how to grow. It is what you are willing to build that growth on. And this year, there is more temptation than usual to cut corners to get there.
Every year, the industry finds its next big thing. A few years ago, it was prop trading. Then, prediction markets. Now all the attention is on AI, moving so fast that keeping up week by week is a job in itself. And for good reason. The pace at which teams can turn an idea into something working is remarkable. What took weeks of specification can now be prototyped in days, and everyone, from the dealing desk to the boardroom, can react to something real instead of a document.
That is a genuine shift, and it’s worth being excited about. But excitement and discipline are not the same thing, and 2026 is the year a lot of firms will learn the difference.
Read more: “You Can’t Grow Just by Cutting,” Huy Nguyen Trieu on AI in Finance Jobs
Where AI Helps, and Where It Doesn’t Yet
There’s a temptation, under pressure to move, to take what AI produces and push it straight into production. It works in the demo, the logic looks right, so why wait? But prototyping and running critical infrastructure at scale are two different tests. Code that looks correct is not the same as code that holds up under real load, in the middle of a major news event when volatility spikes and every position is exposed at once.
That is the real test, and it’s why, internally, we don’t use AI-generated code in our live production environments. I have no doubt AI will get there. But it is not there yet, and in 2026, that gap still exists.
Perf win of the day: Claude Code CLI now uses 2x less CPU at p99.
Bun’s garbage collector was running on a fixed timer, so it would kick in mid-turn and steal CPU right when Claude Code was busiest. Now it waits until the process is idle. pic.twitter.com/icGc35LDQs
— ClaudeDevs (@ClaudeDevs) August 18, 2026
AI is an extraordinary tool. It can accelerate almost every part of how software gets built. But it cannot yet be your senior developer, the one who has spent twenty years learning, often the hard way, what breaks when systems scale and how to build so they don’t. That judgement isn’t something you prompt your way to. It’s earned. AI can support experienced engineers, but it does not replace architectural judgement, production testing or accountability for the final system.
The Foundations You Have to Live With
The AI question is really a version of a much older one: when you’re scaling, what are you willing to build on? Growth has a way of exposing whatever you didn’t get right early. A broker today is often doing far more than it was a few years ago, and all of it runs on infrastructure decisions made when the business was half the size.
Those decisions were often made quickly, under pressure, and you don’t find out whether they were right until the business has grown enough to test them.
I remember a case from a few years back that makes the point well. A prospect was convinced our hosting fees were three times higher than what he could find elsewhere. He wasn’t comparing infrastructure built for the financial industry; he was comparing it against general hosting providers, and he went with the cheaper option.
He was back three or four months later. Downtime had become unbearable, latency was too high, and the provider’s IOPS turned into a bottleneck that created lag. It made for a bad launch experience for both the broker and its clients, and by then, the only fix was to migrate everything across to us.
People assume a technology choice isn’t permanent, that if a provider becomes a bottleneck, you simply move to a better one. And you can, but how long that takes depends on a few things: what’s actually being migrated, since the product itself changes the timeline; whether it’s a full cutover completed over a weekend with all hands on deck or a staged migration done in steps with checkpoints along the way to confirm each stage before moving on; the size of the setup, since migrating 100 users is a very different job from migrating 500,000 accounts; and whether the provider has built native migration tooling or whether it’s being done by hand.
An interesting read: Getting to Know your (AI) Agent
Automation Must Not Run Independently
With the right provider, much of that work is automated. At cBridge, for example, migration scripts map the existing configuration across automatically, which removes most of the manual work, and from there it’s up to the client how much flow they want to start with and how fast they want to stage the rest. But even at its smoothest, it is still a real project, not a weekend job. It asks for planning and time from the same teams who should be focused on growth, which is exactly why the decision of who you build on in the first place is worth getting right.
Ease of use matters more as a brokerage scales. A tool your team can actually work with, clear rather than cluttered, is a scaling factor, not a nice-to-have. Every hour spent fighting the technology is an hour not spent on growth, and complexity turns small changes into slow ones. The systems that let a team move quickly and confidently are the ones that make scaling manageable rather than fragile.
That is why the choice of who you build on matters more than it first appears. The cost of getting it wrong isn’t paid at the moment you choose. It’s paid later, when you’re trying to grow, and the foundation won’t let you.
The brokers who scale cleanly, in my experience, are rarely the ones who move fastest. They’re the ones who treated their foundations as a strategic decision. They chose infrastructure and partners that had already proved they could scale, because they understood they’d live with that choice for years. They built for the business they were becoming, not just the one they had.
Growth used to be linear. You added clients, you pushed volume, and the business got bigger in a fairly predictable way. In 2026, with the advent of AI, it is now far more demanding. Brokers are often expanding across products, asset classes and markets simultaneously, while working on much shorter timelines than even a few years ago. Growth cycles are shorter, and the room for error is smaller.
So the question is no longer just how to grow. It is what you are willing to build that growth on. And this year, there is more temptation than usual to cut corners to get there.
Every year, the industry finds its next big thing. A few years ago, it was prop trading. Then, prediction markets. Now all the attention is on AI, moving so fast that keeping up week by week is a job in itself. And for good reason. The pace at which teams can turn an idea into something working is remarkable. What took weeks of specification can now be prototyped in days, and everyone, from the dealing desk to the boardroom, can react to something real instead of a document.
That is a genuine shift, and it’s worth being excited about. But excitement and discipline are not the same thing, and 2026 is the year a lot of firms will learn the difference.
Read more: “You Can’t Grow Just by Cutting,” Huy Nguyen Trieu on AI in Finance Jobs
Where AI Helps, and Where It Doesn’t Yet
There’s a temptation, under pressure to move, to take what AI produces and push it straight into production. It works in the demo, the logic looks right, so why wait? But prototyping and running critical infrastructure at scale are two different tests. Code that looks correct is not the same as code that holds up under real load, in the middle of a major news event when volatility spikes and every position is exposed at once.
That is the real test, and it’s why, internally, we don’t use AI-generated code in our live production environments. I have no doubt AI will get there. But it is not there yet, and in 2026, that gap still exists.
Perf win of the day: Claude Code CLI now uses 2x less CPU at p99.
Bun’s garbage collector was running on a fixed timer, so it would kick in mid-turn and steal CPU right when Claude Code was busiest. Now it waits until the process is idle. pic.twitter.com/icGc35LDQs
— ClaudeDevs (@ClaudeDevs) August 18, 2026
AI is an extraordinary tool. It can accelerate almost every part of how software gets built. But it cannot yet be your senior developer, the one who has spent twenty years learning, often the hard way, what breaks when systems scale and how to build so they don’t. That judgement isn’t something you prompt your way to. It’s earned. AI can support experienced engineers, but it does not replace architectural judgement, production testing or accountability for the final system.
The Foundations You Have to Live With
The AI question is really a version of a much older one: when you’re scaling, what are you willing to build on? Growth has a way of exposing whatever you didn’t get right early. A broker today is often doing far more than it was a few years ago, and all of it runs on infrastructure decisions made when the business was half the size.
Those decisions were often made quickly, under pressure, and you don’t find out whether they were right until the business has grown enough to test them.
I remember a case from a few years back that makes the point well. A prospect was convinced our hosting fees were three times higher than what he could find elsewhere. He wasn’t comparing infrastructure built for the financial industry; he was comparing it against general hosting providers, and he went with the cheaper option.
He was back three or four months later. Downtime had become unbearable, latency was too high, and the provider’s IOPS turned into a bottleneck that created lag. It made for a bad launch experience for both the broker and its clients, and by then, the only fix was to migrate everything across to us.
People assume a technology choice isn’t permanent, that if a provider becomes a bottleneck, you simply move to a better one. And you can, but how long that takes depends on a few things: what’s actually being migrated, since the product itself changes the timeline; whether it’s a full cutover completed over a weekend with all hands on deck or a staged migration done in steps with checkpoints along the way to confirm each stage before moving on; the size of the setup, since migrating 100 users is a very different job from migrating 500,000 accounts; and whether the provider has built native migration tooling or whether it’s being done by hand.
An interesting read: Getting to Know your (AI) Agent
Automation Must Not Run Independently
With the right provider, much of that work is automated. At cBridge, for example, migration scripts map the existing configuration across automatically, which removes most of the manual work, and from there it’s up to the client how much flow they want to start with and how fast they want to stage the rest. But even at its smoothest, it is still a real project, not a weekend job. It asks for planning and time from the same teams who should be focused on growth, which is exactly why the decision of who you build on in the first place is worth getting right.
Ease of use matters more as a brokerage scales. A tool your team can actually work with, clear rather than cluttered, is a scaling factor, not a nice-to-have. Every hour spent fighting the technology is an hour not spent on growth, and complexity turns small changes into slow ones. The systems that let a team move quickly and confidently are the ones that make scaling manageable rather than fragile.
That is why the choice of who you build on matters more than it first appears. The cost of getting it wrong isn’t paid at the moment you choose. It’s paid later, when you’re trying to grow, and the foundation won’t let you.
The brokers who scale cleanly, in my experience, are rarely the ones who move fastest. They’re the ones who treated their foundations as a strategic decision. They chose infrastructure and partners that had already proved they could scale, because they understood they’d live with that choice for years. They built for the business they were becoming, not just the one they had.
