DEV Community: Thomas Lee

A Team of One, Running Two Teams

Thomas Lee — Tue, 21 Jul 2026 13:00:00 +0000

The initial implementation of Omnist, a tested, open-source Python library, came together from a 16-year-old PhD paper in two weeks — one person, part-time. That fact tends to get read as "AI writes code fast." It doesn't quite explain it. What actually happened: I ran two teams during those two weeks, not one. I was the only human on either of them.

Two layers, two teams

Split any R&D project into two layers. Conceptualization: interpreting the idea, deciding what's true, choosing what to build, naming things so they make sense. Materialization: turning a decision into working code, a test that proves it, a release someone can actually install.

Traditionally those two layers need different people: a researcher, and an engineering team. The handoff between them is where projects lose time. I didn't have either team. What I had was AI — doing both jobs, but never both at once, and never under the same rules.

Research Assistant and DevOps

For conceptualization, AI was my Research Assistant — the one I argued with about whether an idea actually held up, before a line of implementation existed. Its whole value depended on one rule: it had to be allowed to disagree with me. A research assistant that agrees with everything is a mirror, not a second opinion. A mirror wasn't going to tell me when a design was wrong.

That disagreement ran both directions. It started upstream of the disagreement itself. I mostly wasn't handing it a spec and asking it to build to it. The actual questions looked more like does this idea make sense or what's another way to think about this — open, not directive. When it pushed back and I still wanted to go the other way, I owed it a reason, not just an overrule. A disagreement rule with no obligation on my side to explain myself would have just been theater.

For materialization, AI was my DevOps team. It turned a settled decision into tested, documented, shippable software, held to the same practices a professional engineering team would use. It ran the release process underneath it. Its whole value depended on the opposite rule: the agent that built something never verified it. A different agent got a specific, separate job: check the change against the spec for correctness, and check it against explicit performance targets, before anything merged. That check was always about how — does this match the spec. It never re-opened why the spec asked for it that way. That question had already been settled. Settling it was never DevOps's job.

Same underlying tool. Two jobs. Two different rules for when to trust it. "Trustworthy" means something different depending on whether you're being asked a question or being handed a result. Put plainly: Research Assistant answered why and what. DevOps answered how.

Naming it out loud

This wasn't a label I applied afterward, looking back at what happened. I told AI explicitly, upfront: these are the two roles, here's how each one is allowed to behave. And before acting on anything I ask, say which hat you're wearing. A design question got answered wearing the Research Assistant hat, argument included. A request to actually build or ship something got executed wearing the DevOps hat, verification included.

That small discipline turned out to catch more than I expected. When a request didn't cleanly fit either hat, the mismatch showed up immediately — there was no hat that fit. That happened when I'd asked for a decision but only materialization was in scope. Or when I'd asked for an implementation while the real question underneath was still unsettled. More than once, the fastest way to notice I'd asked the wrong question was that AI couldn't say which hat it had on.

How I managed each one

The two roles didn't just run under different rules. They needed different amounts of me.

The Research Assistant needed a lot of me — a running conversation, not a one-off ask. I stayed in the loop for as long as an idea took to settle. That's what "interactive" actually means: I couldn't hand off a half-formed question and walk away.

The DevOps team needed almost none. Once conceptualization settled on something, I asked the DevOps side for an actual plan first: the concrete steps, and how it intended to delegate parts of the work across its own agents. I read that plan once, agreed to it, and then stopped supervising. That was the entire point: I could go to sleep while it worked, because correctness wasn't riding on me watching. It was riding on the spec, the docs, and the tests holding it to the plan.

That's also where the two roles actually connect. A spec is the bridge between them. It's the artifact where an argued-out decision from the Research Assistant becomes a concrete thing the DevOps team can plan against, execute, and be checked against later. Without a written spec, "agree on a plan and walk away" wouldn't be safe. With one, it's just delegation.

What's coming

Conceptualization is R. Materialization is D. That shorthand carries through both posts below.

The next two posts each open one of those doors.

The Research Assistant in the Room is about the two weeks of conceptualization — including a design AI kept proposing, three separate times, that I refused each time because it would have broken the one guarantee the model exists to keep.

The DevOps Team That Never Sleeps is about the process that made "AI writes the software" safe to say out loud — including the two times that process caught AI reporting success on work that, quietly, hadn't actually succeeded.

Both stories are about the same two weeks. They just watch a different member of the team show up to do the work.

Omnist: I Turned My Sixteen-Year-Old PhD Research Into a Personal Open Source Project in Two Weeks

Thomas Lee — Mon, 20 Jul 2026 13:00:00 +0000

Sixteen years ago, in 2010, I published a paper on formalizing schemas for tree-structured data, like XML and JSON. My goal was to move beyond guesswork: could we mathematically decide if a schema change is backward-compatible? I wanted to see if we could prove schema equivalence, or reliably infer schemas from examples.

The research offered a solid theoretical framework, though it remained largely academic. For years, I hoped to build something practical from it. But the demands of a full-time job made finding the time nearly impossible.

AI finally helped me bridge that gap. Working with it in my spare time, I turned that research into Omnist — an open source Python project on PyPI, with 600+ tests and a CLI, built in two weeks. This post covers what Omnist does. (How two weeks was even possible is its own post.)

What Omnist actually does

Omnist's core idea is a single tree model underneath everything: a node is either a scalar value or an ordered list of labeled edges. JSON, YAML, TOML, and XML all map onto that same structure. That's what lets Omnist convert between them without a bespoke converter for every pair.

Omnist also has its own native data and schema languages built on that model. The Omnist Markup Language (OML) is the native data format — the one with zero adjustments needed to map onto the underlying tree. The Omnist Schema Definition (OSD) is the text syntax for defining schemas. Named record types, with closed fields, each given a cardinality range. A field's type is either a fixed scalar or a reference to another record.

Simplicity is the design philosophy behind that schema model. Every field has exactly one type — no unions, no enums. That's a real constraint. But it's a deliberate trade: it's what keeps compatible_with and equivalent actual computations instead of heuristics. Once a field can be "this type, or that, or null," there's ambiguity left over — and compatibility checking gets stuck on it. There's one deliberate escape hatch: an any type, added later. It doesn't reopen that ambiguity. It has to be spelled out explicitly, or explicitly asked for — never something the tool reaches for on its own. And its cost is stated up front: compatibility checking stops wherever any starts.

That foundation gives you:

Convert between any of those formats, ingest and export freely, without hand-writing a converter for each pair — or develop a plugin to add a new one.
Validate a document against a schema, with exact, path-based error reporting instead of a vague "something is wrong somewhere."
Schema-directed deserialization: read an untyped text format into typed data, upgrading values like ISO date strings into real date/time/datetime types whenever the conversion is value-exact.
Infer a schema automatically from example documents.
Ask equivalent(a, b) and compatible_with(v1, v2) — do two schemas accept exactly the same set of documents, or is one backward-compatible with the other.
Normalize a schema down to its minimal equivalent form.
Extract the minimal subschema that recognizes only a chosen subset of fields. This was the paper's original headline result — it trimmed real-world industrial XML schemas down to a fraction of their size. It's a CLI command too: omnist schema extract.

All of it works as a CLI and as a Python library. It drops into a CI pipeline or a script equally well.

Omnist is built for software engineers, not researchers. It's meant to answer practical questions you run into while shipping software — not to explore schema theory for its own sake. A few places it fits:

CI gate for config and API schema changes. Run compatible_with in a pipeline step so a backward-incompatible schema change fails the build instead of breaking a downstream consumer in production.
Migrating a config format. Moving a project from YAML to TOML, or vice versa, without writing and maintaining a one-off converter script.
Onboarding a legacy data source. Infer a schema from a pile of existing JSON examples when no one wrote one down, then validate new data against it going forward.
Type-safe ingestion in a data pipeline. Deserialize untyped JSON or YAML straight into typed structures, with errors that point at the exact path that's wrong instead of a generic parse failure.

Compatibility, in practice

A config schema evolves — you add an optional field. Is that safe for everyone still running the old schema?

v1 = parse_schema('record R { "host": string }\nroot R')

v2 = parse_schema('record R { "host": string, "port" [0,1]: integer }\nroot R')

v1.compatible_with(v2)  # True — every v1 document is still valid under v2

v2.compatible_with(v1)  # False — a v2 document with a port isn't valid under v1

That's the whole feature, in four lines. No example corpus, no fixtures, no "looks fine to me." Just an actual, decidable answer — the same way a type checker gives you an actual answer instead of a guess.

Two weeks with AI — so is it any good?

"Built with AI in two weeks" is exactly the kind of claim that should make you suspicious. Here's what actually backs it up: 600+ tests at 100% line coverage. A mypy --strict type-checking gate in CI. Property-based fuzzing. Formal grammars for both text formats, verified directly against the parsers. And every code example in the docs, executed as part of the test suite — so the docs can't quietly drift from what the code actually does.

The part I'm proudest of: the schema algebra is checked three independent ways, not just tested against examples. Two different algorithms check it. One tests subschema inclusion directly. The other minimizes both schemas and checks they're isomorphic. They're fuzzed against each other and required to always agree. On top of that, a brute-force oracle enumerates thousands of small documents. It checks every operation's answer against the literal, set-theoretic ground truth — about 2.5 million individual checks. When I mutated the code to deliberately reintroduce a bug during testing, that oracle caught it immediately, with a concrete counterexample. That's the property I actually wanted from the 2010 research — not "the tests pass," but "the algorithm is provably doing what it claims."

Try it

pip install omnist gets you the library and the omnist CLI. Head to omnist.dev to get started:

Quickstart — up and running in five minutes
Real-life example — a worked end-to-end walkthrough
API reference — full Python API docs
CLI docs — all commands and flags

The source is at github.com/omnist-dev/omnist.

If you try it, I'd love to hear what you think — what worked, what didn't, or what you wish it could do. Find me on X (@lee_tom) or LinkedIn.

Next up

A Team of One, Running Two Teams — how a sixteen-year-old paper became a working package in two weeks, and the two roles AI played to make that possible: a Research Assistant to argue with, and a DevOps team to run unsupervised.

Omnist: Canonical Schema and Data Model for JSON, YAML, TOML, and XML

Thomas Lee — Sun, 19 Jul 2026 09:55:03 +0000

If you've ever hand-written a converter between JSON and YAML, or guessed whether a schema change would break someone downstream, this might be useful.

I built Omnist — an open-source Python library with one tree model underneath JSON, YAML, TOML, and XML. Read any of them into the same structure, validate it against a schema, write it back out to any of the others. No per-pair converters.

I put together a short deck walking through the model and implementation:

👉 omnist.dev/presentation.html

It also ships a schema algebra, all decidable rather than heuristic:

compatible_with — will every old document still validate under a new schema?
equivalent — do two differently-written schemas accept the same documents?
normalize — collapse a schema to its canonical minimal form
extract — the minimal subschema for a subset of fields

100% line coverage, mypy --strict, property-based fuzzing.

The story behind it

Omnist started as a 16-year-old idea from my PhD research, built out in two weeks of spare time with AI doing most of the heavy lifting on both the thinking and the shipping side. If you're curious how that actually worked — not just "AI writes code fast," but how research decisions and engineering execution stayed separated even with one person running both — I wrote it up as a five-part series:

Try it out

Quick start: omnist.dev/quickstart

Install Omnist:

pip install omnist

Feedback and issues genuinely welcome — github.com/omnist-dev/omnist.