Mikael Ronstrom

Tuesday, June 30, 2026

Experiences from the new wave of AI programming

Experiences from the new wave of AI programming

How we built RonSQL in RonDB with Claude and Codex

A false start

A few years ago at Hopsworks we made an early attempt at using ChatGPT for<br>coding. It turned out to be an expensive mistake: the generated code cost us<br>several months of rewriting. So when I came back to AI programming this year, I<br>did so with a fair amount of skepticism.

Trying again — the small wins

In January we tried again, and the first success came from an unexpected<br>place. Our marketing manager put together a simple RonDB client in about two<br>hours. That caught my interest. I took the code over and, in a few more hours,<br>had extended it significantly.

Encouraged, I tried something closer to real engineering: extending our REST<br>API server so that it could handle not only batched key reads, but also batched<br>key inserts, writes, and deletes. The original code had taken significant effort<br>to write; the extension took just two days. Clearly, extending existing code was<br>something Claude and Codex could do well.

The big bet: a ten-year TODO item

With those successful experiments behind me, I realised this new tooling might<br>be extremely useful for developing genuinely new features in RonDB.

Something our customers have wanted for a long time is more complex queries in<br>real-time AI inferencing. Supporting that requires CTEs and parallel join<br>aggregation — a capability that has sat on the RonDB TODO list for more than<br>ten years. It is very complex development work; with conventional coding I would<br>estimate it as a two-year project, at least.

What this really amounts to is adding subsets of complex SQL support to a<br>key-value store. RonDB sits in the same category as key-value stores such as<br>Redis and DynamoDB, which are traditionally used for exactly this kind of<br>real-time, low-latency serving — but which have no support for complex SQL<br>queries at all. Bringing CTEs and parallel join aggregation into that world is<br>what makes the effort both unusual and worthwhile.

Would it be feasible now, with AI programming? I decided to find out. This post<br>shares what I learned over the past five months.

The short version: today we released RonDB 26.04.1 , which<br>ships beta support for RonSQL with CTEs and pushdown join aggregation.

The development model

From the start it was clear that the proven development model still applied.<br>You begin with a high-level plan, move to a detailed implementation plan, and only<br>then implement it step by step.

We went through this loop several times. Each plan had at least 10–20<br>phases, and sometimes many more.

Claude vs. Codex

Working with both models, my conclusion is that their strengths are<br>complementary. Claude is better at keeping track of plans and remaining work.<br>Codex is often better at solving hard problems, but it is sloppier about<br>maintaining the plan and can lose track of what to do next. So for the most part<br>I let Claude own plan maintenance and the less complex tasks, and handed the hard<br>bugs to Codex.

Massive testing across four layers

One thing that struck me immediately is that AI programming makes it possible<br>to generate massive amounts of unit tests — even for the distributed cases<br>that are normally painful to test.

RonSQL query execution spans four layers in RonDB:

LDM (Local Data Manager) — the lowest layer, six<br>modules that handle local query execution, local recovery, and local<br>checkpointing.

TC (Transaction Coordinator) — coordinates join<br>execution for complex queries. Partial results flow from the first tables in<br>the join to the later ones. The TC drives execution from a Query Tree:<br>essentially a program that specifies how to run the query, including interpreted<br>code to be sent down to the LDMs.

NDB API — defines the Query Tree through an API.<br>Applications can use it directly, though that is uncommon because it is<br>low-level.

RonSQL — the top layer, which translates SQL into<br>NDB API calls. The NDB API builds a Query Tree and sends it to the TC; the TC<br>distributes execution across the RonDB nodes, and each part runs on the LDM in<br>every node.

Normally you write test programs in RonSQL, because writing and maintaining<br>programs against the LDM, TC, and NDB API layers by hand is very hard. AI<br>programming changes that. It became feasible to develop and test the LDM layer<br>first, before touching the TC layer, and the TC layer before touching the NDB API<br>layer. This made it much easier to reach a working implementation across all four<br>layers quickly.

The asynchronous challenge

AI programming works very well on the kind of sequential code the models have<br>seen in training. But RonDB uses an asynchronous programming model, and here the<br>models sometimes needed firm guidance to understand how things actually work.<br>Things that were obvious to me were sometimes completely invisible to the model<br>— but it was usually easy enough to teach it through the prompts....