Die Mutter von Van, unser Grosi, ist jedes Jahr fast ein halbes Jahr in Vietnam. Hier lebt sie ausgesprochen sparsam und enthaltsam. So gibt es zwei Duschräume. Der einte ist mit WC und Duschschlauch versehen, der andere Raum mit Wasseranschluss Hahnen und einem Loch im Ecken. Van duscht immer in diesem Raum, denn das liegt neben unserem Zimmer im 1. Stock. Ich dusche immer unten.

Um heraufzukommen in den ersten Stock ist ein Teil der schmalen Treppe (mit Mauern auf beiden Seiten) mit so grossen Stufen versehen die doppelt so hoch sind, wie unsere gewohnten.

Vor den zwei Zimmern im oberen Stock ist ein Platz wo ein grosser Tisch steht. Darauf steht das Laptop und einen der 4 harten Stühle habe ich mit Kissen ausgestattet.

Für die zwei Schlafzimmer hat es eine Klimaanlage. Für den Raum davor hat es keine Klimaanlage und auch nur ein defekte Lüfter der schwach ist und keine Oszillation bietet. Ich darf auch keinen guten Lüfter kaufen, weil sie den dann, wenn ich zurück bin, nicht mehr brauchen würden. Unten ist eine gute Klimaanlage und ein sehr grosser Deckenlüfter wie ich sie aus alten Hotels in Italien/Rom kenne. Also können sie den Lüfter/Ventilator wirklich nicht gebrauchen, wenn ich zurück in der Schweiz bin.

In der letzte Wochen war es immer zwischen 32-34° warm, was auch für hier aussergewöhnlich warm war. Zum Glück sind wir fast jeden Tag(bei einer so grossen Familie kein Wunder) in irgendeiner familiären Gedenkfeier eingeladen, so dass ich gar nicht zum AUOJI kommen würde. Und am Abend bin ich schnell müde und am frühen Morgen kann ich etwas machen. Nun freue ichmich auf die Woche, denn ab morgen sind ein paar Tage ohne Feste vorgesehen und es wird nur 27° warum, was mich gutam AUOJI werkeln lässt. 

Ja, das AUOJI treibt mich nun stetig weiter. Ich freue mich darauf wieder zu Hause in meiner perfekten PC-Umgebung weiter machen zu können.

Juan schrieb mir sinngemäß:

Beim Vibe Coding kommt es vermutlich zu keinem Paradigmenwechsel, weil weder der Programmierer noch die dadurch erzeugten Programme sich das Paradigma strukturell aneignen.

Der Gedanke dahinter ist bemerkenswert. Er führt direkt zu einer Frage, die für die ontologisch orientierte Programmierung entscheidend ist:

Wann verändert eine neue Technik tatsächlich die Art, wie wir Programme denken, und wann verändert sie lediglich die Art, wie wir Programme erzeugen?

Der Ausdruck „Vibe Coding“ wurde Anfang 2025 durch Andrej Karpathy bekannt. Gemeint war ursprünglich eine sehr lockere Form der KI-gestützten Programmierung: Man beschreibt der KI, was man haben möchte, lässt den erzeugten Code laufen, meldet Fehler zurück und arbeitet so lange weiter, bis das Ergebnis ungefähr den eigenen Vorstellungen entspricht. Der Entwickler beschäftigt sich dabei kaum noch mit dem konkreten Quellcode. Karpathy beschrieb das bewusst überspitzt als eine Arbeitsweise, bei der man gewissermaßen vergisst, dass der Code überhaupt existiert.

Ein typischer Ablauf könnte so aussehen:

1. „Erstelle mir eine kleine Webseite zur Verwaltung meiner Aufgaben.“
2. Die KI erzeugt mehrere Dateien.
3. Die Webseite startet nicht.
4. Die Fehlermeldung wird vollständig an die KI zurückgegeben.
5. Die KI ändert einige Dateien.
6. Nun startet die Webseite.
7. „Mach die Schaltfläche etwas kleiner.“
8. „Die Liste soll nach Datum sortiert sein.“
9. „Jetzt funktioniert das Löschen nicht mehr.“
10. Die KI nimmt weitere Änderungen vor.

Am Ende existiert möglicherweise eine funktionierende Anwendung, obwohl der Benutzer weder ihre Klassenstruktur noch die Datenhaltung noch die Fehlerbehandlung vollständig verstanden hat.

Das kann für einen Prototyp hervorragend sein. Eine Idee wird innerhalb kurzer Zeit sichtbar. Jemand, der selbst keine Programmiersprache beherrscht, kann etwas ausprobieren, das früher bereits an der technischen Einstiegshürde gescheitert wäre.

Aber genau hier liegt auch die Grenze.

Diese Unterscheidung ist wichtig.

Wenn eine KI große Teile eines Programms schreibt, der Entwickler den erzeugten Code jedoch prüft, versteht, testet und bewusst in eine vorhandene Architektur einordnet, ist das nicht zwingend Vibe Coding.

Simon Willison grenzt diese beiden Arbeitsweisen ausdrücklich voneinander ab. Für ihn liegt Vibe Coding gerade dort vor, wo der Entwickler die Verantwortung für das Verständnis des Codes weitgehend aufgibt. Wer KI-generierten Code vollständig überprüft und versteht, verwendet die KI eher als sehr leistungsfähige Schreibhilfe.

Der entscheidende Gegensatz lautet deshalb nicht:

Menschlicher Code gegen KI-Code.

Er lautet:

Verstandener und verantworteter Code gegen lediglich akzeptierten Code.

Eine KI kann hervorragend innerhalb einer klaren Architektur arbeiten. Sie kann auch Tests ergänzen, Abhängigkeiten analysieren, Fehler suchen und vorhandene Regeln konsequent anwenden.

Sie kann aber ebenso überzeugend Code erzeugen, der lokal funktioniert und zugleich die innere Ordnung eines Systems beschädigt.

Hier wird es interessant.

Vibe Coding verändert zweifellos die Schnittstelle zwischen Mensch und Computer.

Früher formulierte der Entwickler seine Absicht hauptsächlich in einer formalen Programmiersprache. Heute kann er diese Absicht zunächst in Alltagssprache ausdrücken. Die KI übersetzt dann eine ungenaue menschliche Beschreibung in konkreten Code.

Das ist eine erhebliche Veränderung der Arbeitsweise.

Einige wissenschaftliche Autoren bezeichnen Vibe Coding deshalb selbst als neues Paradigma. Ihre Begründung lautet, dass die menschliche Absicht nicht mehr ausschließlich durch exakt formulierte Anweisungen vermittelt wird, sondern durch eine probabilistische Interpretation der KI. Der Mensch beschreibt ungefähr, was er erreichen möchte, und das Modell schätzt, welche technische Umsetzung wahrscheinlich gemeint ist.

In diesem Sinn kann man tatsächlich von einem Paradigmenwechsel sprechen:

Die Vermittlung zwischen menschlicher Absicht und ausführbarem Programm verändert sich grundlegend.

Aber das ist noch nicht dieselbe Art von Paradigmenwechsel, die beispielsweise mit der objektorientierten Programmierung verbunden war.

Die Objektorientierung veränderte nicht nur, wie Code eingegeben wurde. Sie veränderte, wie ein System gedanklich zerlegt wurde:

• Daten und Verhalten wurden in Objekten zusammengeführt.
• Klassen beschrieben gemeinsame Strukturen.
• Vererbung und Komposition ordneten Beziehungen.
• Polymorphie ermöglichte ein gemeinsames Verhalten unterschiedlicher Typen.
• Zuständigkeiten wurden auf miteinander kooperierende Objekte verteilt.

Das veränderte die innere Bauweise der Programme.

Vibe Coding verändert dagegen zunächst vor allem den Weg zum Code. Der erzeugte Code kann weiterhin vollkommen gewöhnlich objektorientiert, prozedural, funktional oder schlicht ungeordnet sein.

Deshalb muss man zwei Ebenen auseinanderhalten:

Wer formuliert den Code?

Wie wird eine menschliche Absicht in ein Programm übersetzt?

Wie stark arbeitet der Entwickler unmittelbar mit der Programmiersprache?

Auf dieser Ebene ist Vibe Coding tatsächlich etwas Neues.

Welche Einheiten bilden das System?

Wo befindet sich Bedeutung?

Wer trägt Verantwortung?

Welche Beziehungen sind erlaubt?

Welche Regeln bleiben über sämtliche technischen Schichten hinweg gültig?

Auf dieser Ebene liefert Vibe Coding allein noch keine neue Antwort.

Ich sage einer KI:

Erstelle mir ein Programm, in dem ein Baum Wasser aufnimmt, wächst und bei Wassermangel abstirbt.

Die KI könnte folgende Lösung erzeugen:

public class TreeService {
  public void UpdateTree(TreeData tree) {
    if (tree.Water > 0) {
      tree.Size++;
      tree.Water--;
    } else {
      tree.IsDead = true;
    }
  }
}

Dieser Code kann funktionieren.

Aber was ist ein Baum in diesem System?

Ist er selbst ein handelndes Objekt oder nur ein Datensatz?

Besitzt er eigene Bedürfnisse?

Nimmt er seine Umwelt wahr?

Entscheidet er selbst, ob und wie er reagiert?

Oder wird er von einem zentralen Dienst bearbeitet, der alle Entscheidungen außerhalb des Baumes trifft?

Die sichtbare Funktion ist dieselbe: Der Baum wächst oder stirbt.

Die innere Bedeutung ist jedoch vollkommen unterschiedlich.

Im ersten Fall ist der Baum ein passiver Datenbehälter. Ein fremder Dienst bestimmt sein Verhalten.

Im zweiten Fall ist der Baum ein autonomes Objekt, das einen eigenen Zustand, eigene Bedürfnisse, eigene Wahrnehmungen und daraus entstehende Handlungen besitzt.

Ein Funktionstest könnte in beiden Fällen grün werden:

Wasser vorhanden → Baum wächst.
Kein Wasser vorhanden → Baum stirbt.

Der Test beweist jedoch nur das beobachtete Ergebnis. Er beweist nicht, dass die beabsichtigte ontologische Ordnung eingehalten wurde.

Genau darin liegt ein wesentliches Problem des Vibe Codings: Der Entwickler beschreibt häufig die gewünschte Wirkung, aber nicht zwingend die beabsichtigte innere Bedeutung.

Die KI optimiert dann auf ein sichtbares Ergebnis.

Sie beantwortet:

Wie kann ich erreichen, dass dieser Test grün wird?

Sie beantwortet nicht automatisch:

Welche Art von Welt soll dieses Programm darstellen?

In klassischer Softwareentwicklung wird häufig geprüft, ob ein Programm korrekt funktioniert:

• Gibt eine Methode den erwarteten Wert zurück?
• Wird eine Nachricht gesendet?
• Wird ein Datensatz gespeichert?
• Wird eine Benutzeroberfläche korrekt aktualisiert?
• Bleibt die Antwortzeit innerhalb eines bestimmten Bereichs?

Diese Prüfungen sind notwendig.

Sie beantworten aber nicht alle architektonischen Fragen.

Ein Programm kann sämtliche funktionalen Tests bestehen und trotzdem seine eigene begriffliche Ordnung verletzen.

Beispielsweise könnte eine Spielfigur durch eine zentrale Methode bewegt werden:

world.MoveCharacter(characterId, target);

Oder die Figur könnte selbst eine Handlung auswählen und ausführen:

character.SelectAction();
character.ExecuteSelectedAction();

Auf dem Bildschirm kann in beiden Fällen dieselbe Bewegung erscheinen.

Ontologisch sind es zwei unterschiedliche Welten.

Im ersten System wird die Figur bewegt.

Im zweiten System handelt die Figur.

Dieser Unterschied ist für AUOJI nicht sprachliche Dekoration. Er bestimmt, wo Wahrnehmung, Entscheidung, Verantwortung und Verhalten liegen.

Damit ein Programm ein Paradigma strukturell übernimmt, darf dieses Paradigma nicht nur in Kommentaren, Dokumentationen oder Prompts vorkommen.

Es muss in der Architektur des Programms sichtbar werden.

Bei einer ontologisch orientierten Programmierung betrifft das beispielsweise folgende Fragen:

• Besitzt ein Objekt die Eigenschaften, die zu seinem dargestellten Wesen gehören?
• Befindet sich sein Verhalten beim Objekt oder in einem externen Verwaltungsdienst?
• Darf eine technische Schicht die fachliche Bedeutung eines Objekts verändern?
• Bleibt ein Objekt über Speicherung, Transport und Darstellung hinweg dasselbe fachliche Wesen?
• Sind Wahrnehmung, Bedürfnis, Entscheidung und Handlung voneinander unterscheidbar?
• Können ungültige Beziehungen überhaupt entstehen?
• Wird ein Verstoß gegen die Weltordnung automatisch erkannt?

In AUOJI ist diese Richtung bereits erkennbar.

Eine Pflanze ist nicht lediglich ein Datensatz mit beliebigen Feldern. Sie ist als Spezialisierung einer Ressource modelliert und besitzt fachliche Eigenschaften wie Wasser, Alter, Bestand und Erntbarkeit.
Auch bei der Erzeugung der Welt werden Nachbarschaften nicht vollständig beliebig zusammengesetzt. Der WorldCreator verwendet Regeln dafür, welche Bodentypen in welcher Ausrichtung nebeneinanderliegen dürfen. Die Welt besitzt damit zumindest in diesem Bereich eine überprüfbare innere Ordnung.

Die Datenbankverwaltung zeigt gleichzeitig, weshalb die Bewahrung dieser Bedeutung über technische Schichten hinweg schwierig ist. Ein fachliches AUOJI wird serialisiert, in ein Item überführt, Tabellenfeldern zugeordnet und später wieder rekonstruiert. Jede dieser Übergangsstufen kann Bedeutung verlieren oder versehentlich verändern.

Ontologisch orientierte Programmierung bedeutet deshalb nicht bloß, passende Klassennamen zu verwenden.

Sie verlangt, dass die Bedeutung eines Objekts den gesamten Weg überlebt:

Fachliches Objekt
→ Laufzeit
→ Aktion
→ Zustandsänderung
→ Snapshot
→ Transport
→ Client
→ Speicherung
→ Wiederherstellung

Ein Objekt darf auf diesem Weg technisch anders dargestellt werden. Es darf aber nicht unbemerkt zu etwas fachlich anderem werden.

Jeder erzeugte Code besitzt irgendeine Struktur.

Deshalb wäre es zu hart zu sagen, Vibe-Code enthalte überhaupt kein Paradigma.

Häufig enthält er sogar mehrere gleichzeitig:

• etwas Objektorientierung,
• einige prozedurale Hilfsmethoden,
• globale Zustände,
• Framework-Konventionen,
• Datenbankmodelle,
• Ereignisse,
• statische Manager,
• Services und
• zufällig entstandene Abhängigkeiten.

Das Problem ist nicht die völlige Abwesenheit eines Paradigmas.

Das Problem ist seine Zufälligkeit.

Das Programm besitzt dann eine Struktur, aber niemand hat diese Struktur als zusammenhängende Ordnung gewählt. Sie ist aus vielen lokalen Entscheidungen entstanden:

• Die KI hat eine bekannte Lösungsschablone verwendet.
• Ein Fehler wurde durch einen zusätzlichen Sonderfall behoben.
• Eine neue Funktion wurde an der bequemsten Stelle ergänzt.
• Ein bestehendes Objekt erhielt eine weitere Verantwortung.
• Eine Abhängigkeit wurde eingebaut, weil sie das aktuelle Problem schnell löste.
• Eine zweite Datenstruktur entstand, weil die erste nicht verstanden wurde.

Jede einzelne Änderung kann vernünftig aussehen.

In ihrer Summe entsteht ein System, dessen innere Landkarte langsam zerfließt.

Technische Schulden sind ein bekannter Begriff. Gemeint sind kurzfristig günstige Entscheidungen, die spätere Änderungen verteuern.

Durch unkontrolliertes Vibe Coding entsteht zusätzlich eine andere Form von Schuld:

Verständnisschuld.

Der Code existiert, aber das Wissen darüber, warum er so aufgebaut ist, wächst nicht im gleichen Maß mit.

Das zeigt sich spätestens bei Fragen wie:

• Warum gibt es diese Klasse?
• Welche Methode darf diesen Zustand verändern?
• Welche Nebenwirkungen hat diese Änderung?
• Welche Regeln müssen bei einer Erweiterung erhalten bleiben?
• Ist dieses Verhalten Absicht oder nur ein Nebeneffekt?
• Wer kann entscheiden, ob eine Vereinfachung fachlich zulässig ist?

Dass diese Sorge nicht nur theoretisch ist, zeigt auch die vorsichtige Haltung vieler Entwickler gegenüber KI-Ausgaben. In der Stack-Overflow-Umfrage von 2025 misstrauten mehr Entwickler der Genauigkeit von KI-Werkzeugen, als ihr vertrauten. Besonders erfahrene Entwickler äußerten hohe Vorsicht.

Das bedeutet nicht, dass KI ungeeignet für Softwareentwicklung wäre.

Es bedeutet, dass Geschwindigkeit bei der Erzeugung von Code nicht automatisch Geschwindigkeit bei der Erzeugung eines verstandenen Systems ist.

Ontologisch orientierte Programmierung beginnt nicht mit der Frage:

Welche Klassen brauche ich, damit die gewünschte Funktion läuft?

Sie beginnt früher:

Welche Dinge existieren in dieser Welt?

Danach folgen weitere Fragen:

Was macht jedes dieser Dinge zu dem, was es ist?

Welche Eigenschaften gehören zu ihm?

Was kann es wahrnehmen?

Welche Bedürfnisse besitzt es?

Welche Entscheidungen darf es treffen?

Welche Handlungen kann es ausführen?

Welche Beziehungen zu anderen Dingen sind möglich?

Welche Veränderungen würden seine Identität oder Bedeutung verletzen?

Erst danach wird entschieden, wie diese Ordnung technisch dargestellt wird.

Das ist mehr als eine Benennungsübung.

Eine Klasse namens Wolf macht ein Objekt noch nicht zu einem Wolf.

Wenn sämtliche Entscheidungen durch einen zentralen WolfManager getroffen werden, während das Objekt selbst nur Koordinaten und Lebenspunkte enthält, ist der Wolf möglicherweise lediglich ein Datensatz mit zoologischem Etikett.

Für AUOJI ist deshalb ein anderer Grundsatz wichtig:

Ein Objekt wird nicht danach beurteilt, wie es heißt, sondern danach, welche innere Struktur und welches beobachtbare Verhalten es tatsächlich besitzt.

Damit verbindet sich AUOJI auch mit dem Gedanken des Homo Conscientius: Systeme, Gruppen und handelnde Einheiten sollen nicht nach ihrer Selbstbeschreibung oder ihrer Bezeichnung beurteilt werden, sondern nach ihrer wirklichen Struktur und ihrem wirklichen Verhalten.

Ja.

Die entscheidende Trennlinie verläuft nicht zwischen menschlicher und künstlicher Programmerzeugung.

Eine KI kann sehr wohl Code innerhalb eines neuen Paradigmas erzeugen. Sie benötigt dafür jedoch mehr als einen Funktionswunsch.

Sie braucht eine überprüfbare Ordnung.

Beispielsweise könnte ein Auftrag lauten:

Ergänze eine Handlung, mit der eine Pflanze Wasser aus ihrem Boden aufnehmen kann.

Eine reine Vibe-Coding-Antwort könnte irgendwo eine Methode ergänzen, die Wasserwerte verändert, bis der sichtbare Test funktioniert.

Eine ontologisch gebundene Umsetzung müsste zusätzlich beachten:

• Die Pflanze besitzt das Bedürfnis nach Wasser.
• Die Wahrnehmung des verfügbaren Wassers erfolgt in der Sensorphase.
• Die Bewertung des Bedürfnisses erfolgt in der Denkphase.
• Die Auswahl der Handlung geschieht beim handelnden AUOJI.
• Die Zustandsänderung erfolgt in der Aktionsphase.
• Fremde Objekte werden nicht unkontrolliert verändert.
• Die Änderung wird im Snapshot korrekt sichtbar.
• Die fachliche Bedeutung bleibt beim Transport erhalten.
• Bestehende Invarianten dürfen nicht verletzt werden.

Die KI kann diese Regeln anwenden.

Aber sie muss gegen sie geprüft werden.

In diesem Moment verlassen wir das reine Vibe Coding. Aus dem „Es läuft, also akzeptiere ich es“ wird:

Es läuft, und seine Struktur entspricht weiterhin der beabsichtigten Welt.

Damit ein Paradigma nicht nur vom guten Willen des Entwicklers abhängt, braucht es technische Wächter.

Ein Ontologie-Wächter prüft nicht nur einzelne Ergebnisse. Er prüft, ob eine Änderung innerhalb der erlaubten Weltordnung liegt.

Solche Prüfungen könnten beispielsweise erkennen:

• Ein Client leitet den fachlichen Typ eines Objekts aus zufälligen Property-Typen ab.
• Eine Transportschicht verändert die Bedeutung eines Objekts.
• Eine Aktion verändert ein fremdes Objekt unmittelbar, obwohl dafür ein Wirkungsereignis vorgeschrieben ist.
• Eine Klasse besitzt eine Verantwortung, die ontologisch zu einem anderen Objekt gehört.
• Ein Objekt wird gespeichert, ohne dass seine identitätsbestimmenden Eigenschaften erhalten bleiben.
• Eine Handlung findet statt, obwohl keine passende Wahrnehmung oder Entscheidung vorausging.
• Ein technisches DTO beginnt selbst fachliche Entscheidungen zu treffen.

Der Ontologie-Wächter fragt also nicht nur:

Funktioniert der Code?

Er fragt zusätzlich:

Darf diese Art von Code in dieser Welt überhaupt existieren?

Damit wird ein Paradigma vom Stilwunsch zum überprüfbaren Bestandteil des Systems.

Vibe Coding und ontologisch orientierte Programmierung sind nicht zwingend Gegner.

Sie liegen zunächst auf unterschiedlichen Ebenen.

Vibe Coding beschreibt, wie Software erzeugt werden kann.

Ontologisch orientierte Programmierung beschreibt, welche innere Ordnung die erzeugte Software besitzen soll.

Problematisch wird Vibe Coding dort, wo die schnelle Erzeugung sichtbarer Funktionen die Prüfung dieser inneren Ordnung ersetzt.

Dann entsteht Code, der lokal richtig und im Ganzen falsch sein kann.

Der entscheidende Unterschied lautet deshalb:

Vibe Coding fragt, ob das gewünschte Ergebnis erscheint. Ontologisch orientierte Programmierung fragt zusätzlich, ob es auf die richtige Weise zustande kommt.

Oder noch kürzer:

Vibe Coding kann Code erzeugen. Ein Paradigma bestimmt, was dieser Code bedeuten darf.

Juan hat deshalb einen wichtigen Punkt getroffen.

Vibe Coding allein führt nicht automatisch dazu, dass ein Entwickler ein neues Programmierparadigma versteht. Es führt auch nicht automatisch dazu, dass das erzeugte Programm ein neues Paradigma strukturell verkörpert.

Es kann die Art der Programmerzeugung grundlegend verändern. Darin liegt durchaus ein eigener Paradigmenwechsel.

Aber eine neue Eingabemethode schafft noch keine neue innere Ordnung.

Damit ontologisch orientierte Programmierung tatsächlich zu einem Paradigma wird, muss sie mehr leisten:

• Sie muss Bedeutung explizit machen.
• Sie muss Zuständigkeiten aus dieser Bedeutung ableiten.
• Sie muss die Bedeutung über technische Schichten hinweg erhalten.
• Sie muss Verstöße erkennbar machen.
• Und sie muss auch KI-generierten Code denselben Regeln unterwerfen.

Dann wird KI nicht zum Ersatz für das Paradigma.

Sie wird zu einem Werkzeug innerhalb des Paradigmas.

Vibe Coding sagt:

„Beschreibe, was du sehen möchtest, und lass die KI etwas Passendes erzeugen.“

Ontologisch orientierte Programmierung ergänzt:

„Beschreibe zuerst, welche Welt existieren soll, welche Dinge in ihr leben und welche Ordnung für sie gilt. Erst dann darf Code entstehen.“

Genau dort beginnt der eigentliche Paradigmenwechsel.

Die drei KIs sind alles andere als perfekt. Im Zusammenspiel und durch ihre gegenseitige Kontrolle steigern sie sich jedoch deutlich. Den mit ihrer Hilfe erzeugten Code muss ich weiterhin selbst prüfen. Ich formuliere Regeln und formale Muster, fördere eine hohe Testaffinität und treffe die grundlegenden Richtungsentscheidungen.

Trotzdem kommt es gelegentlich zu einem von mir ausgelösten Rewrite. Die Rentabilität steigt dennoch weiterhin klar an.

Gleichzeitig wachsen die Anforderungen an mich als einzigen Menschen im System. Sie liegen inzwischen deutlich über dem, was von einem durchschnittlichen Programmierer normalerweise verlangt wird. Auch in dieser Hinsicht geht das aktuelle Projekt über den heutigen allgemeinen Stand hinaus.