Writing · Architecture

The story behind Maiaen

Fifteen years of separate threads, a music composer, a language for testers, a year of philosophy, that turned out to be one idea.

Sep 2026 · 3 min read

The answer to why Maiaen exists lies deeper than a market. It is a story with several streams of thought that took years to merge.

A composer, 2009

In my final year of computer science engineering, the project was MusCom, a music composer. It gave people software instruments, the GarageBand kind, and let them play with devices like a game-pad. We also sketched its future: touch, and AI that could compose. Music has structure, and structure can be mapped to intent, so a machine should be able to compose with you. It didn't get there. The idea stayed.

Requirements as a language, 2012

A year and a half into my first job, I started exploring what I called system-based development. Whatever process a team follows, software is a mapping from requirements to a running system. So requirements, written in some formal structure, should compile into a system engine, and the rest is template-driven code generation. The closest names for it were model-driven development and domain-driven design. Modding Age of Empires 3 and, to some extent, UML told me the idea was not mad.

Machines and their languages, 2015

Studying for GATE, formal languages and automata theory finally clicked. A machine maps to an equivalent formal language. That fed straight into the line of thought.

A language for testers, 2016

Then came work on QA automation frameworks. QA engineers already write tests in structured natural language, and then someone translates them into Java, Python or JavaScript. Even Gherkin is only sentence-to-function mapping. So I built an Xtext-based language for testers, which generated the Selenium and Appium code underneath. Real testers used it. That working experiment pulled me into domain-specific languages and language engineering (ANTLR, Xtext, JetBrains MPS), specification languages like Alloy, model-driven development and model-based testing. It also changed one belief: instead of one system for everything, domain-specific systems seemed better.

Understanding, and its limits

When machine learning became fashionable, neural networks and linear algebra felt like an inefficient way to build software, and I leaned towards genetic algorithms: a domain language that behaves like genes, a model that runs, fitness functions that judge, and software that could evolve. Around then I spent a year reading philosophy, western and eastern, and kept returning to one question: what does it mean to understand something?

The hypothesis that came out of it: our understanding of any truth is bounded by the system that understands. We cannot understand what lies beyond our capabilities. Language is how we learnt to express that understanding, and it is bounded too. So every system has a domain language that maps to it. The same bound is also what lets us imagine, because within our own language we can express things we have never met. That mapped very well onto software, and onto AI.

Stories without studios

Alongside, two ideas from college would not leave: how small game teams and writers could express themselves without big studios, and how a writer could turn a story into an animated film without a film studio. Interactive virtual museums belonged to the same family.

LLMs, and then Mviaso

Then large language models arrived. They are machine-learning-driven development at its peak: they work remarkably well, and they pulled almost all attention towards themselves. They also made it possible, finally, to build at the scale these ideas needed.

In 2026 these threads became Mviaso. Old projects came back as Bizzento, Quto and Webu, and Maiaen became the way all of them are developed and kept alive. The thought behind it is simple. Software went from machine code to assembly to general-purpose languages to domain-specific languages. The next step is systems that think, which is as old an ambition as the Turing test. A Domain Language Model thinks in the language of its domain, and a system can be anything: an application, an IoT installation, an organisation, a household.

Maiaen is the tool that lets those systems be built and maintained without a struggle, so that the time saved can go back into being creative.

Drafted in September 2026
Updated for site in October 2026