01.01 — Flipping the problem#

The observation#

Every modern e2e testing framework was built on one implicit assumption: there’s a barrier between people who code and people who define tests. That barrier gets taken for granted — methodologically, organizationally, sometimes contractually.

Most testing frameworks were built in a world where the barrier between “those who code” and “those who define tests” was real and structural.

The two historic answers to that assumption show up in the Holy Book:

Robot Framework#

Robot Framework tried to work around it with a DSL (Domain Specific Language), complete with its own format and its own plugin ecosystem. In doing so, RF de facto imposes its own standards: that’s the immediate cost of its promise.

The mechanic: swap the complexity of code for the complexity of a different code. The entry ticket isn’t waived — it’s relocated. Now you’ve got to learn the RF syntax, its ecosystem of libraries and resources, and its orchestration model.

Cucumber#

Cucumber tried the same with Gherkin: a “natural” language that, in practice, constrains everyone without truly freeing anyone. Cost: a permanent translation layer, Gherkin/code desynchronization.

The mechanic: build an illusion of natural language that actually has a strict grammar and limited semantics. The cost isn’t the language — it’s the permanent translation layer between Gherkin and Step Definitions code, which drifts the moment nobody’s watching.

The opposite bet#

Instead of dressing up the barrier, Ocarina bets that it’s going away:

Ocarina bets on the opposite: this barrier will disappear. This is a non-debate around which everyone has tied a noose with needlessly complicated tools, mistaking them for solutions. Impact: operational disaster the moment a need arises that can’t be expressed within a “framework” that is NOT truly generic.

And:

And the worst part: all these technologies will keep evolving in the same direction. NONE of them will make this shift, because it would require a paradigm change, a return to fundamentals that directly contradicts their entire value proposition.

AI is the bridge, not the DSL#

The Holy Book’s rhetorical lock on this point:

With AI, and tools like Claude Code, this bet grows stronger every day. The bridge between technical and non-technical people is no longer an abstraction layer.

It’s AI itself. AI that works on raw data.

Observable design consequences in the code:

The practical embodiment is the ocarina-with-ai-example repo: a real e2e suite 99% written by Claude Code, with intelligence split 50/50 between the author and the AI.

The cost of other people’s “creativity”#

The Holy Book spells out why DSL leveling isn’t neutral:

The biggest cost is a race to the bottom: fewer options, and a “flexibility” that can only be achieved by fighting your tools rather than using solutions.

Yet what remains is the need for test code that is readable, traceable and flexible in its most raw form.

The word raw matters. It comes back elsewhere (“raw data”, “the raw data”), and it’s the axis Ocarina extends along toward AI. See 05-political-stance.md, “Anti No-Code” section.

What it means for Ocarina’s architecture#