Seit vielen Jahren entwickeln wir Software – für Kunden, für eigene Projekte, und inzwischen auch gemeinsam mit KI.
Dabei fiel uns etwas auf: Der eigentliche Aufwand entsteht selten beim Schreiben des ersten Codes. Er beginnt später. Wenn Programme wachsen. Wenn neue Anforderungen dazukommen. Wenn aus einer guten Idee ein großes System wird.
Am Anfang ist immer alles übersichtlich. Man sieht jede Funktion, jede Verbindung, jeden Grund. Doch je größer ein System wird, desto mehr verschwindet dieser Überblick. Nicht plötzlich, sondern schleichend. Nach einem Jahr fragt man sich, warum Modul A eigentlich von Modul B abhängt. Nach zwei Jahren traut sich niemand mehr, diese Abhängigkeit anzufassen, aus Angst, etwas anderes kaputtzumachen.
Die Beobachtung
Wir hatten das Gefühl, Software wie eine Maschine zu behandeln. Jede neue Funktion wird eingebaut. Jede Abhängigkeit wird fest verdrahtet. Irgendwann weiß niemand mehr genau, warum bestimmte Teile überhaupt miteinander verbunden sind.
Das Programm funktioniert noch. Aber niemand versteht mehr wirklich, wie.
Eine Maschine übernimmt keine Verantwortung. Sie kennt nur Verbindungen. Ein Zahnrad greift in das nächste, ohne zu wissen, wofür. Fällt ein Zahnrad aus, steht oft die ganze Maschine still – selbst wenn neunzig Prozent der Teile noch einwandfrei arbeiten würden. Genau dieses Muster erkannten wir in immer mehr Softwareprojekten wieder, auch in unseren eigenen.
Und mit KI-Unterstützung verschärft sich das Problem eher, als dass es sich löst. Wenn ein Sprachmodell Code erzeugt, tut es das im Kontext dessen, was es sieht. Ist die Verantwortung eines Bausteins nicht klar erkennbar, verwischt sie mit jeder weiteren Änderung ein Stück mehr.
Irgendwann wurde uns klar, dass wir immer wieder dieselben Probleme lösten – aber nie die Ursache. Wir flickten Symptome und nannten es Refactoring. Wir waren diese Probleme leid.
Wir brauchten also nicht nur bessere Werkzeuge zum Schreiben von Code. Wir brauchten eine andere Vorstellung davon, was ein Softwarebaustein überhaupt ist.
Die Frage
Was wäre, wenn Software nicht wie eine klassisch verdrahtete Maschine aufgebaut wäre, sondern anders?
Was wäre, wenn Programme eher aus eigenständigen Einheiten bestehen würden – Einheiten, die Verantwortung für einen klar umrissenen Bereich übernehmen und Beziehungen zueinander eingehen, statt starr verdrahtet zu sein?
Eine Einheit, die weiß, wofür sie zuständig ist. Die weiß, was sie nicht kann, und die in diesem Fall fragt, statt zu raten. Die sich erklären kann, wenn man sie fragt, warum sie etwas getan hat. Das ist eine andere Grundhaltung als die einer klassischen Softwarearchitektur – näher an einem Lebewesen als an einem Getriebe.
Es gab keinen einzelnen Moment, an dem wir diese Frage zum ersten Mal gestellt haben. Aber es gab einen Moment, an dem sie sich zum ersten Mal richtig anfühlte – mitten in einem der Projekte, in denen wir wieder einmal dieselbe Art von Fehler reparierten wie Monate zuvor. Da war klar: So wollen wir Software eigentlich nicht mehr bauen.
Warum “Biocodie”?
Der Name kommt nicht daher, dass wir Biologie nachbauen wollen. Sondern weil uns die Natur seit Milliarden Jahren zeigt, wie aus vielen eigenständigen Einheiten stabile, anpassungsfähige Systeme entstehen. Eine Zelle kennt ihre Aufgabe. Sie kennt ihren Zustand. Sie kommuniziert über gemeinsame Sprachen, ohne die Funktionsweise ihrer Nachbarn zu kennen.
Fällt eine Zelle aus, bricht deswegen nicht gleich der ganze Organismus zusammen. Andere Einheiten übernehmen, kompensieren, oder der Organismus lernt, mit dem Verlust umzugehen. Diese Widerstandsfähigkeit entsteht nicht durch einen zentralen Plan, sondern durch die Art, wie die einzelnen Teile miteinander in Beziehung stehen.
Genau dieses Prinzip interessiert uns für Software. Nicht als Metapher, die man einmal erwähnt und dann vergisst, sondern als tatsächliche Bauform.
Was das praktisch bedeutet
Ein Programm muss nicht alles selbst können.
Es muss wissen, was es kann.
Es muss wissen, wobei es Hilfe braucht.
Und es muss lernen können, neue Beziehungen einzugehen.
Keine Einheit kennt die Implementierung einer anderen. Sie kennt nur die gemeinsame Sprache, über die sie sich verständigen. Wie diese Sprache konkret übersetzt wird, entscheidet die Umgebung, in der die Einheit lebt – nicht die Einheit selbst.
Das klingt zunächst abstrakt, hat aber eine sehr konkrete Konsequenz: Eine solche Einheit lässt sich austauschen, ohne dass die Einheiten um sie herum etwas davon merken. Sie lässt sich einzeln verstehen, ohne das gesamte System im Kopf haben zu müssen. Und sie lässt sich befragen – man kann sie fragen, was sie getan hat und warum. Das ist bei einer klassisch verdrahteten Funktion praktisch nie der Fall.
Was daraus entsteht
Aus dieser Idee entstehen bei uns gerade mehrere Werkzeuge. Kaupapi entsteht für unseren eigenen Verlag – ein Commerce-Backend für statische Shops, das ohne die üblichen schweren Shop-Systeme auskommt. Mainjan kümmert sich um Beziehungen zwischen Zellen. Anagild analysiert Software. Fragjan überprüft Regeln und hilft beim Entwickeln.
Das ist keine Theorie. Das sind Dinge, die wir bauen, während wir gleichzeitig lernen, was Biocodie eigentlich bedeutet. Die Reihenfolge ist bewusst nicht umgekehrt: Wir haben nicht erst ein vollständiges Modell entworfen und bauen jetzt danach. Das Modell entsteht mit jedem Werkzeug ein Stück weiter.
Der Stand der Dinge
Biocodie ist noch nicht fertig. Viele Ideen entstehen erst beim Bauen. Manche Annahmen, mit denen wir gestartet sind, haben sich bereits verändert, seit wir die ersten Zeilen dazu geschrieben haben. Das gehört dazu. Ein Denkraum, der behauptet, von Anfang an vollständig zu sein, wäre keiner mehr.
Deshalb werden wir hier regelmäßig über unsere Erfahrungen berichten – über Erfolge genauso wie über Irrtümer. Über Werkzeuge, die funktionieren, und über Annahmen, die sich als falsch herausgestellt haben.
Wir wissen nicht, wohin uns dieser Weg führen wird. Aber wir sind überzeugt, dass wir Software künftig anders bauen müssen, als wir es heute tun.
Wenn euch diese Fragen ebenfalls beschäftigen, begleitet uns auf diesem Weg. Wir kennen die Antworten noch nicht alle – aber wir werden offen zeigen, wie sie entstehen.
