Earlier this year, we did something unusual: we locked our system architects in a room for three months and let them rebuild the platform from the ground up. They came out with a new architecture and an engineering organization that looks nothing like the one that went in.

The result isn't a moderate improvement. Our oldest engineering constraint disappeared, and it changed who is allowed to build software at Casi. This is the first article in a series about that journey: from struggling to get real value out of AI, to making our platform AI-ready, to where we are now.

From 30+ repositories to one

The change at the core: migrating from more than 30 microservices spread across separate repositories to a single shared codebase, a monorepo. Not because the old architecture was broken, but because the way software gets built has fundamentally changed. An AI coding agent is only as good as the context it can see. Spread across 30+ repositories, no agent could hold the full picture of how our e-commerce layer, contracts, billing and fleet operations fit together. Frankly, no single human could either.

Monorepos aren't new. Google and Meta have run them for two decades. What's new is the reason. We didn't consolidate to simplify our build. We consolidated so that a machine could read the whole business in one pass.

Airbnb used an LLM pipeline to migrate roughly 3,500 test files in six weeks, work they had estimated at 1.5 years by hand. A different problem from ours, but the same lesson: when the machine can see the whole surface at once, the economics of large-scale change break in your favour.

The problem flipped

Before, our constraint was straightforward: we couldn't write code fast enough to keep pace with what the business needed. That constraint is gone. If anything, the opposite is now true. We write more code than we can humanly keep up with.

"Coding is no longer our problem. If anything, we code too much. We've already had to stop doing human code review the old way. We've introduced a new step in our delivery flow instead: robots write the code, robots review the code, and human input comes in right at the end."

Gunnar Birkenfeldt, Chief Product Officer

‍

That is a large claim, so it is worth one number. Output per person here was flat for three years running. This year it is 2.6 times that baseline. Our own estimates of the gain run considerably higher depending on what you choose to measure, but 2.6 is the figure we can reconstruct from the record, so that is the one we publish.

More gates, not fewer

The quote above tends to raise an eyebrow, so it's worth being precise about what replaced the old review. The new flow has more gates than the old one, not fewer. Architecture is decided by humans up front. Every change is covered by tests an agent cannot skip. Agents review against those tests and our architectural rules at machine speed. And nothing reaches production without a named human approving it.

Where that human sits in the flow depends on what the change touches. We are deliberately moving human intervention as late as we safely can, and for changes that touch critical core components we move it earlier and add to it. Security and criticality decide where the gate goes, not convenience. The audit trail is stronger than it was when a colleague clicked "approve" on a Friday afternoon. We didn't remove human judgment. We moved it to where it changes the outcome.

Today an agent writes the first version of essentially everything, and an agent performs the first review of it. Every change an agent contributes to is stamped as such in our commit history, so the provenance of a change is a matter of record rather than recollection.

Data is the oxygen

A shared codebase makes AI agents fast, but speed alone isn't the point. Coding is the easy problem. Understanding a business well enough to act on it is the hard one, and that takes clean, structured data, not just clean code.

"Data is the oxygen of our platform. AI is only as good as the domain data we feed it: clean, structured and in context. That combination, not coding speed, is where the real magic happens."

Gunnar Birkenfeldt, Chief Product Officer

There is a strategic point underneath that metaphor. If AI makes writing software cheap, then software stops being the moat. What's left is what a model cannot generate: years of structured, domain-specific data about how a vehicle earns and loses value across its life, and the people who know what it means. That is what we spent three months making machine-readable.

Everyone closest to the problem is now a builder

With one codebase, one data model and AI agents on top of both, building is no longer reserved for engineers. Our business and finance colleagues have the deepest domain knowledge of residual values, invoice flows and fleet economics. They are building prototypes themselves, and in many cases shipping new functionality straight into the platform.

Everyone here works against the same codebase, regardless of function or title, and contributes through their own agents.

The person who understands a problem best can now express the solution directly, with AI agents doing the translation into working software. Humans still have the final say. That is the last step in the new flow, and the distance from insight to shipped functionality has never been shorter.

AI native, not AI added

There is a difference between adding AI to a platform and building a platform that AI can operate. One is a feature. The other is an architecture. One codebase, one data model, structured domain data, and a delivery flow where agents are first class participants rather than bolted on: that is what AI first means in practice.

It also means the next set of capabilities will not require another three months in a locked room. The platform we run today is the one we intend to keep extending, not one we will have to rebuild when the tooling shifts again.

What this means for you

For the OEMs, FleetCos and finance companies running on our platform, the throughline is simple. New capability ships continuously rather than in quarterly batches, at around ten production releases a week. It is built by the people closest to your business. And it runs on data clean enough for an AI to actually reason over, which is what makes the insight layer on top of it worth anything.

What's next

This migration was phase one: making the platform AI-ready, in our architecture and in how our data is structured. The next phase is AI implementation, putting these superpowers to work across the business. The work in progress right now is letting agents carry more of the testing, so that human attention lands as late in the flow as it safely can.

In part two, our COO takes the harder question: if robots write the code and robots review it, how do you know the quality is there? She comes from testing, she is unsentimental about this, and she will explain which numbers we trust, which ones we refuse to publish, and why. After that we'll cover Casi Apex, which turns our data into insight for the customers who rely on us, and our new vehicle ledger, which will give transparent unit economics per vehicle.

Want to hear more about how we made our platform AI-ready? Reach out. We're happy to share what we learned along the way.

The numbers behind this article

Measured on 27 August 2026 from our own commit and pull request records, using the same window in every year, 1 January to 27 August.

Output per person. Our own estimates of the overall gain run higher, roughly 2.5 to 8 times depending on what you measure, but 2.6 is the lowest and the only one we can reconstruct from the record.

AI on delivered code. An agent writes the first version of essentially everything and performs the first review. What we can prove per change is narrower: in August, two thirds of what we delivered carried an explicit machine-readable AI co-author signature. Treat that as a floor, not a total. We only began stamping changes that way in May 2026.

Delivery. Around ten production releases a week, continuously rather than in batches.

Who builds. Four colleagues from outside engineering account for roughly a fifth of this year's merged changes. Neither had contributed code before 2026.

What we are not publishing. A change failure rate. The obvious candidate measures the reliability of our deploy step, not whether a change broke production. Part two takes that question seriously rather than quoting a number that would flatter us.

The per-person figures rest on our own estimate of how many people were producing platform code in each year, not on an extract from a system of record.