Schema Evolution as a Graph Rewrite

Every team has a field name that's wrong. Someone typed population when they meant population_total, four years ago, and it is now in a hundred and forty places. And given everything that can go wrong, nobody would ever contemplate changing it. So it stays wrong, and everyone works around it.

It's a common problem, because schemas evolve — you can't expect to get every field right on the first try. It's a hard one because the first thing anyone reaches for is search, and the usual tools don't work here. Grep finds strings that might be entirely unrelated. An AI assistant finds 47 of the 50 references and calls it a day.

Using a graph built with an open-source parser, we can quickly find every occurrence of a field, along with every location in the codebase that references it. From there we perform a series of small operations, composed into a sequence, each one arriving with a generated test.

The easiest way to demonstrate is by building a database schema from scratch. We'll pick a random Wikipedia page, or take an idea from the audience, or both in quick succession. Then, step by step, we add and remix our way into a custom schema you can use immediately — either through an automatically built user interface, or through a chat with one of the AI agents you already use.

The broader implication is that we can modify schemas inside existing code. That's harder; there is a great deal more in a codebase than the schema. But there are exciting ways to enhance the databases you already have, in a way that makes them suitable for combining with evolved ones.

Audiences leave able to use the approach with whatever they already have: how to treat a schema and the code around it as one connected graph, why parsing finds what searching misses, and how to break a change nobody wants to make into steps small enough to prove. They will have watched a working system appear from nothing in a few minutes, which tends to reset what a small team believes it can take on. And they leave with a sharper sense of which parts of their own stack are worth owning outright, and which are better left exactly where they are.