For many years, we’ve been developing software—for clients, for our own projects, and now increasingly together with AI.
Along the way, we noticed something: the real effort rarely comes from writing the first lines of code. It begins later. When programs grow. When new requirements appear. When a good idea turns into a large system.
In the beginning, everything is easy to understand. You can see every function, every connection, every reason. But the larger a system becomes, the more that clarity begins to disappear. Not all at once, but gradually. After a year, you find yourself wondering why Module A depends on Module B in the first place. After two years, nobody wants to touch that dependency anymore for fear of breaking something else.
The Observation
We had the feeling that we were treating software like a machine. Every new feature gets bolted on. Every dependency gets hardwired. At some point, nobody really knows why certain parts are connected at all.
The program still works.
But nobody truly understands how anymore.
A machine doesn’t take responsibility. It only knows connections. One gear meshes with the next without knowing what it’s for. If one gear fails, the entire machine often comes to a stop—even if ninety percent of its parts would still work perfectly. We kept recognizing this same pattern in more and more software projects, including our own.
And AI assistance tends to make the problem worse rather than solve it. When a language model generates code, it does so in the context of what it can see. If the responsibility of a building block isn’t clearly recognizable, it becomes a little more blurred with every additional change.
Eventually, we realized that we were solving the same problems over and over again—but never addressing the cause. We were patching symptoms and calling it refactoring. We had grown tired of those problems.
So we didn’t just need better tools for writing code. We needed a different idea of what a software building block actually is.
The Question
What if software weren’t built like a classically hardwired machine, but differently?
What if programs were made up of autonomous units instead—units that take responsibility for a clearly defined area and form relationships with one another instead of being rigidly wired together?
A unit that knows what it’s responsible for. That knows what it can’t do, and asks instead of guessing. That can explain itself when asked why it did something. That’s a fundamentally different mindset from that of traditional software architecture—closer to a living organism than to a gear train.
There wasn’t a single moment when we first asked ourselves that question. But there was a moment when, for the first time, it felt right—in the middle of one of those projects where we were once again fixing the same kind of bug we had repaired months before. At that point, it became clear: this was no longer how we wanted to build software.
Why “Biocodie”?
The name doesn’t come from wanting to imitate biology. It comes from the fact that nature has been showing us for billions of years how stable, adaptable systems can emerge from many autonomous units. A cell knows its purpose. It knows its state. It communicates through shared languages without knowing how its neighboring cells work.
If one cell fails, the entire organism doesn’t immediately collapse. Other units take over, compensate, or the organism learns to live with the loss. That resilience doesn’t come from a central plan. It comes from the way the individual parts relate to one another.
That’s exactly the principle that interests us for software. Not as a metaphor that’s mentioned once and then forgotten, but as an actual way of building systems.
What This Means in Practice
A program doesn’t have to be able to do everything itself.
It has to know what it can do.
It has to know where it needs help.
And it has to be able to learn new relationships.
No unit knows another unit’s implementation. It only knows the shared language they use to communicate. How that language is actually translated is decided by the environment in which the unit lives—not by the unit itself.
At first, that may sound abstract, but it has a very concrete consequence: such a unit can be replaced without the surrounding units even noticing. It can be understood on its own, without having to keep the entire system in your head. And it can be questioned—you can ask it what it did and why. That’s something a classically hardwired function can practically never do.
What Is Emerging from This
Several tools are currently growing out of this idea. Kaupapi is being built for our own publishing house—a commerce backend for static shops that works without the usual heavyweight e-commerce systems. Mainjan manages relationships between cells. Anagild analyzes software. Fragjan verifies rules and helps with development.
This isn’t theory. These are things we’re building while we’re simultaneously learning what Biocodie actually means. That order is intentional, not the other way around: we didn’t first design a complete model and then start building from it. The model grows a little further with every tool we create.
Where We Are Today
Biocodie isn’t finished yet. Many ideas only emerge while we’re building. Some assumptions we started with have already changed since we wrote the first lines about them. That’s part of the process. A thinking space that claimed to be complete from the very beginning wouldn’t be one anymore.
That’s why we’ll regularly share our experiences here—our successes just as much as our mistakes. The tools that work, and the assumptions that turned out to be wrong.
We don’t know where this path will lead us. But we’re convinced that, in the future, we’ll have to build software differently than we do today.
If these questions matter to you as well, join us on this journey. We don’t have all the answers yet—but we’ll openly show how they come into being.
