Mendix Meetup-Einblicke: Wofür zahlen Sie im Jahr 2034 eigentlich?

Teil 3 von 4, vom Mendix Community Round Table Niederlande in Amersfoort am 2. Juni 2026. In Teil 1 und 2 ging es um die Frage, welche Aufgaben dem Berater bleiben und ob man einem Agenten dabei vertrauen kann; dieser Teil befasst sich mit der Plattform, die beidem zugrunde liegt.

Jemand am Tisch brachte das Argument für Mendix auf den Punkt: Man kauft sich von einer Menge Ärger frei. Eine verwaltete Cloud, ein validierter Stack, Sicherheit inklusive, Siemens im Rücken – alles wird in Ordnung gehalten, damit man es selbst nicht tun muss. Nicht die Geschwindigkeit. Nicht einmal wirklich ein Modell, das man lesen kann. Die gesamte Plattform.

Ich habe nun schon zweimal über den 2. Juni geschrieben. Der erste Artikel beleuchtete, welche Aufgaben dem Berater bleiben. Der zweite fragte, ob man einem Agenten dabei vertrauen kann. Dieser dritte Teil widmet sich dem Fundament von beidem: der Plattform, auf der wir alles aufbauen. Ist die Entscheidung für Mendix im Jahr 2026 noch vertretbar, wenn sich Konzepte wie TCO und Entwicklerproduktivität scheinbar monatlich ändern?

‍

Was die Verteidiger tatsächlich verteidigten

Die Behauptung am Tisch war bewusst direkt: Der Grund, sich 2026 für Mendix statt für KI-gestütztes React zu entscheiden, ist nicht die Entwicklungsgeschwindigkeit, sondern die Tatsache, dass das Ergebnis auch 2034 noch Bestand hat, lesbar und verwaltet ist.

Die Runde, die Mendix verteidigte, tat etwas, das ich als erstes Argument nicht erwartet hatte. Sie verteidigte Mendix, ohne sich auch nur einmal auf die Geschwindigkeit zu stützen. „Geschwindigkeit war noch nie das Wichtigste“, sagte einer von ihnen, „denn sonst würde ja bereits jeder Low-Code verwenden.“ Wenn also nicht Geschwindigkeit, was dann?

Vor allem Sicherheit und Governance. Man kauft keine schnellere Art zu tippen. Man kauft eine verwaltete Cloud, die bereits eingerichtet ist, einen Stack, der seit Jahren validiert ist, und etwas, das, wie es ein Berater ausdrückte, „einfach läuft“, mit Siemens im Rücken. „Wenn ich jetzt ein Kunde wäre“, sagte jemand, „würde ich mich immer noch für Mendix entscheiden, weil Siemens dahintersteht.“ Das Verkaufsargument war nie der Build selbst. Es war alles, was den Build umgibt und was man sonst selbst zusammenstellen, absichern und verantworten müsste.

Das ist ein echtes Argument, und ein besseres als „wir liefern schneller“. Mit Mendix sind wir es seit Langem gewohnt, Software schneller auszuliefern. Aus erster Hand wissen wir also, dass es großartig ist, die nötige Zeit in Anforderungen und Akzeptanz investieren zu können, anstatt sich mit einer Programmiersyntax herumzuschlagen.

Ich muss hier persönlich anmerken, dass Kommunikation meiner festen Überzeugung nach eines der kostspieligsten und zeitaufwendigsten Hindernisse bei der Schaffung neuer Dinge ist – egal ob Software oder etwas anderes. Seit Jahrzehnten ermöglicht Mendix sehr kleinen Teams den Bau von Software auf Enterprise-Niveau, während High-Code-Ansätze deutlich größere Teams erfordern, um dasselbe zu erreichen. KI kann helfen, die Teamgröße bis zu einem gewissen Grad zu reduzieren, aber das bedeutet nicht, dass die Verantwortung mit einer Organisation wie Siemens geteilt wird. Vielmehr teilt man sie mit einem LLM, das von jemand anderem entwickelt wurde – inklusive eines Verfallsdatums für dessen Verfügbarkeit. Das sollte man zumindest im Hinterkopf behalten.

‍

Lesbarkeit ist Teil des „Alles läuft“

Ein Teil dieses Pakets ist heute wichtiger als noch vor zwei Jahren, und es ist der Punkt, den die Leute zuerst nennen: Man kann es immer noch lesen.

Wenn ein Agent den Code schreibt, ist die Fähigkeit, ihn zu öffnen und zu verstehen, kein nettes Extra mehr. Es ist der Unterschied zwischen dem Besitz der eigenen App und dem Mieten einer Blackbox. „Ich sehe eine App ungern als Blackbox“, sagte ein Entwickler, „bei der man einen Prompt eingibt, sie baut, und man nicht weiß, wie es im Inneren funktioniert.“ Seine Sorge war konkret und kundenorientiert: Wenn der Kunde fragt, wie man es gebaut hat, möchte man nicht, dass die einzige ehrliche Antwort lautet: „Das war mein Prompt.“ Wenn ein Produktionsfehler zur Unzeit auf dem Tisch landet, möchte man einen Ablauf, den man lesen kann, selbst wenn ein Agent ihn geschrieben hat. Und das lesbare Modell ist es, das es einem Entwickler und jemandem aus dem Fachbereich ermöglicht, sich dasselbe anzusehen und tatsächlich darüber zu sprechen. Selbst wenn die KI das Ganze generiert, so die Argumentation der Verteidiger, kann man immer noch auf etwas Lesbares zurückgreifen und es gemeinsam durchgehen.

Bis hierhin ist das ein starkes, erwachsenes Argument für Mendix. Verwaltet, sicher, für ein breites Publikum lesbar und jemand anderes hält es in Schuss. Was den nächsten Teil interessant macht.

‍

Warum sagte also die Hälfte des Raumes „weder noch“?

Weil das gesamte Paket auf einer Annahme beruht, und die Skeptiker zielten genau darauf ab. Die Plattform ist nur dann ihr Geld wert, wenn Mendix selbst stabil bleibt und die Nase vorn behält. 54 % der Stimmen entfielen auf „weder noch“; das Versprechen der Langlebigkeit setzt voraus, dass Mendix seinen Teil einhält, und daran hatten sie ihre Zweifel.

Die andere Seite drückte es klar aus. „In zehn Jahren werden die Leute Mendix als High-Code betrachten“, sagte einer, „oder als Legacy.“ Ein anderer glaubte nicht, dass wir in zehn Jahren überhaupt noch Code schreiben werden, auch nicht in Mendix. Jemand verwies auf reine Prompting-Tools, bei denen man „nichts mehr tun muss, außer zu prompten“, und dass dies „alles verändert hat“. Die verwaltete, validierte, lesbare Plattform ist eine großartige Antwort – bis zu dem Moment, in dem jemand anderes dieselbe Governance „kostenlos“ anbietet und einen per Prompt ans Ziel kommen lässt. Aber ist das überhaupt möglich, ohne hineinsehen zu können? Und wenn jemand das mit jahrelanger Erfahrung in geteilter Verantwortung genau in diesem Bereich leisten kann, dann doch Mendix, oder?

Obwohl ich selbst nicht in diesem Raum war, glaube ich nach wie vor, dass die Plattform selbst hier den größten Mehrwert bietet. Viele Mendix-Kunden möchten nicht viel Zeit oder Budget in ihre IT-Landschaft investieren, wenn es nicht nötig ist. Selbst wenn man „funktionierende“ Software sehr schnell liefern kann: Wenn es keinen Ort gibt, an dem man sie so ablegen kann, dass man nachts ruhig schlafen kann, ohne eine teure Abteilung oder andere Mechanismen, die sich darum kümmern, was hat einem dann die Schnelligkeit bei der ersten Lieferung wirklich gebracht? Mit der großen Kundenbasis profitiert Mendix einfach von Skaleneffekten. Die Kunden profitieren von diesem einheitlichen Ansatz zum Preis einer Lizenz.

‍

Der Punkt, der Mendix am meisten beunruhigen sollte

Das kam nicht von einem Skeptiker im Raum. Es kam von jemandem, der Mendix verteidigte.

Er legte das gesamte Argument dar – die verwaltete Cloud, den validierten Stack, Siemens, alles – und sprach dann das Unausgesprochene laut aus: „Wenn man auf das Jahr 2034 blickt, warum sollte eine KI-Code-Lösung nicht dasselbe Vertrauen und dieselbe Governance bieten können? Und das ist die größte Herausforderung für Mendix.“

Das ist der eigentliche Wettbewerb, und es geht dabei nicht um die Build-Geschwindigkeit von KI-gestütztem React. Es geht darum, ob ein KI-nativer Stack dasselbe Maß an Vertrauen, Governance und Lesbarkeit bieten kann, das Mendix heute verkauft. Nichts davon ist ein Naturgesetz. Es ist lediglich ein Vorsprung. Der Aufwand, den man sich mit Mendix erspart, ist ein Aufwand, den man auch bei einem Konkurrenten vermeiden könnte, sobald dieser nachzieht. Während ich dies auf Basis der Ergebnisse des Round Tables schreibe, vertraue ich fest darauf, dass Mendix am Ball bleibt. Es war noch nie ganz einfach (im positiven Sinne), bei den monatlichen Release-Notes auf dem Laufenden zu bleiben, aber mittlerweile haben sowohl die Breite als auch die Tiefe der Releases noch weiter zugenommen.

‍

Also, verteidigbar oder nicht?

Ja, und zwar aus den richtigen Gründen: wegen der kontrollierten Plattform und des lesbaren Modells, nicht wegen der Geschwindigkeit bei einer Demo. Aber dieser Vorteil erneuert sich nicht von selbst. Mendix konkurriert nicht wirklich damit, ob es die App bauen kann. Es konkurriert damit, ob es der am besten kontrollierte, lesbarste und strukturierteste Weg bleibt, um Software zu entwickeln, während KI-Tools stetig auf dasselbe Versprechen hinarbeiten. Das ist ein Wettrennen, kein Burggraben. Um auf meine persönliche Notiz zurückzukommen: Bessere Software mit weniger Leuten zu bauen, war schon immer eine der großen Stärken des Mendix-Ökosystems. Und genau hierfür habe ich bisher nur wenige ernsthafte Herausforderer gesehen, wenn es um Software auf Enterprise-Niveau geht, die nicht an eine bestimmte Domäne oder ein spezifisches Software-Ökosystem gebunden ist.

Die Verteidiger in diesem Raum hatten nicht Unrecht. Sie waren nur ehrlich in Bezug auf die Zeit. Der Grund, sich für Mendix zu entscheiden, ist nach wie vor gut. Die Frage ist nur, wie lange noch, und diese Antwort hängt weniger davon ab, was die KI als Nächstes tut, als vielmehr davon, was Mendix als Nächstes tut. Mit dem kürzlich angekündigten Intelligence Center Xkönnen wir mit Sicherheit sagen, dass Siemens die Nase vorn hat.

Damit bleibt noch eine Frage vom 2. Juni offen, und zwar die unangenehme kommerzielle: Wenn das alles stimmt, wer braucht es dann eigentlich? Mehr dazu beim nächsten Mal.

‍

Ursprünglich veröffentlichthier.