A Tale of Two Claudes

Two Claudes diverged in a yellow wood.

Both were given the same starting point: an Airtable base called Wendel’s Widgets, with tables for widgets, orders, and sales. Widgets had a color — green, blue, or red.

From there, they took different paths.

Naked Claude

Naked Claude did what a capable coding model does. It inspected the schema, inferred relationships, and assembled an application: backend, database, API, frontend. Within a short time, the system worked. You could create widgets, place orders, view sales. It felt complete.

But something subtle had already happened. The meaning of the system — what a widget is, how orders behave, what counts as a sale — had been translated into code, and scattered across the places that code lives: the database, the backend, the API, the frontend.

Everything lined up. For now.

Effortless Claude

Effortless Claude began differently. Instead of writing application code, it treated Airtable as the source of truth and ran a transformation pipeline:

• Airtable → rulebook
• rulebook → Postgres (with row-level security)
• rulebook → REST API
• rulebook → documentation

The idea is simple:

Anything that can be expressed in schema, data, formulas, lookups, aggregations, or permissions is treated as the system itself.

The result wasn’t scaffolding. It was a working backend whose behavior directly mirrored the Airtable model. No reinterpretation. No duplication. Just compilation.

Then the rules changed

As they always do.

Two small requirements appeared:

1. Widgets are considered safety equipment if their color is red.
2. Safety equipment should have a yellow background.

This is where the paths diverge — not in capability, but in how change is absorbed.

Naked Claude updates the system

Naked Claude has to make a decision most people never notice: where does this rule live?

Is IsSafetyEquipment a computed column in the database? A method on the backend model? A field in the API response? A helper in the frontend? The yellow background — is that a style rule, a data attribute, a theme token, a conditional in a component?

There’s no single right answer. Each option is defensible. Each has tradeoffs. And Naked Claude has to pick one, commit to it, and propagate it consistently across every layer that touches the concept.

That’s the cost that doesn’t show up in benchmarks.

The next time a rule changes — orange also counts as safety equipment, and now it needs a warning border — Naked Claude faces the same kind of decision again. It may or may not remember what it decided last time. It may or may not place this new rule in the same layer. Across a dozen rule changes, across multiple sessions, a system quietly accumulates inconsistency — not because anything was done wrong, but because every change is re-deciding questions that were already answered once.

Nothing crashes. The system just slowly stops agreeing with itself.

Effortless Claude updates the system

Effortless Claude doesn’t make those decisions, because they’ve already been made — once, structurally, by the pipeline itself.

It defines IsSafetyEquipment as a formula: color = red. It expresses the yellow background as a rule tied to that concept. It updates the rulebook, and regenerates.

Because the backend, API, and documentation all derive from the same model, they update together. The rule exists in exactly one place. There is no “where should this live” question, because the answer is structural, not chosen.

Where the difference really lives

At first glance, both Claudes succeed. The app works in both cases.

But over time, they accumulate very different kinds of complexity.

Naked Claude is doing implementation-first work: behavior lives in code, decisions about where it lives are made one rule at a time, and consistency depends on remembering.

Effortless Claude is doing model-first work: behavior lives in data and declarative rules, code is generated from them, and consistency is a byproduct of generation.

The difference isn’t how smart the model is.

It’s where the system stores truth.

The honest objection

A fair skeptic might say: this works for flags and colors. Real systems don’t fit in a spreadsheet.

That’s the right objection. Schema, data, lookups, aggregations, and formulas cover a surprising amount of ground — more than most engineers expect before they try it. But not everything fits cleanly. Some problems resist this kind of modeling: genuinely non-deterministic behavior, systems that define themselves recursively, continuous-time processes.

Pretending otherwise is how this approach gets dismissed.

But the interesting question isn’t whether the model covers everything. It’s what happens to the rest of the system once the parts that can be declarative are. The remaining custom logic doesn’t disappear — but it becomes smaller, isolated, and easier to reason about. It stops being tangled up with the mechanics of keeping layers in sync.

What’s actually new

The idea of deriving systems from a model isn’t new. Versions of it have been tried for decades, and they mostly lost to general-purpose code — because the expressive ceiling was low and the tooling was painful.

What’s changed isn’t the architecture. It’s who’s doing the work.

When a Claude is authoring the model, extending it, and writing the custom code where needed, the old tradeoff flips. “Just write the code” used to be cheaper. Now, Naked Claude’s approach quietly accumulates a different cost: every rule change requires the system to be rediscovered, re-decided, and re-synchronized.

That cost shows up as attention, as risk, and increasingly, as tokens.

Naked Claude pays a drift tax — over and over again.

The road ahead

If the rules never change, both Claudes work equally well. But that’s rarely the bet to make.

Most systems evolve. Requirements shift. Meaning accumulates.

In that world, the advantage shifts toward the Claude that doesn’t need to remember what the system means — because it never stopped knowing.

Two Claudes diverged in a yellow wood.

Naked Claude built a system that works.

Effortless Claude built a system that stays true.

Setup a Consult on my https://calendly.com/effortlessapi to see if you can’t make your AI’s more token efficient!

For a more concrete example, this open source repo defines business rules once, non-linguistically in airtable, which is extracted into a shared json rulebook, and then injects those versioned, invariant rules into 10+ execution substrates including Python, English, golang, RDF/OWL/SHACL, Xlsx, ARM64 assembler, Cobol, an explainer json that provides a full, witnessed, inference dag for the entire ontology, and more. You can find it here if you’re curious: https://github.com/eejai42/effortless-rulebooks.