Gerade laufen die KI-SaaS-Wars an, und wer sie nur als neue Runde im üblichen Werkzeugrennen zwischen Claude Code, Codex und dem nächsten glänzenden Agenten missversteht, schaut auf die Oberfläche und verpasst die tektonische Verschiebung darunter. Denn es geht nicht primär darum, dass Maschinen inzwischen erstaunlich gut Code erzeugen können. Das ist nur das sichtbare Symptom. Der eigentliche Umbruch liegt tiefer, nämlich dort, wo bisher der Preis vieler Softwareprodukte stillschweigend durch Knappheit gestützt wurde, durch die Knappheit an Entwicklungszeit, an Umsetzungskapazität, an mühseliger Fleißarbeit und an Teams, die bekannte Muster zuverlässig in laufende Systeme übersetzen konnten. Genau diese Knappheit beginnt gerade zu verdampfen. Reuters beschreibt bereits sichtbar, dass KI traditionelle Softwaremodelle unter Druck setzt, besonders dort, wo Wachstum sinkt und seat-based pricing an Überzeugungskraft verliert.
Deshalb verschwindet auch nicht der Beruf des Softwareentwicklers, jedenfalls nicht für Menschen, die mehr können als Syntax an die Wand werfen. Was verschwindet, ist die bequeme Illusion, dass das bloße Herstellen von Software bereits ein belastbarer ökonomischer Burggraben sei. Wer diesen Unterschied nicht erkennt, wird in den kommenden Jahren sehr viel Marktwert verlieren und sich anschließend einreden, das Problem sei “die KI” gewesen. In Wahrheit war das Problem früher da, es wurde nur freundlich von teurer Implementierung kaschiert. Viele Produkte waren nämlich nie besonders tief, sie waren nur teuer genug im Bau, um wie Substanz zu wirken.
Genau deshalb halte ich die entscheidende Frage unserer Zeit nicht für “Kann KI Software bauen?”, sondern für etwas deutlich Unangenehmeres, nämlich: “Was an dieser Software ist noch wertvoll, wenn Code keine Knappheit mehr ist?” Und diese Frage ist brutal, weil sie den ganzen dekorativen Nebel aus Produktmarketing, Pitch-Folien und “AI-powered”-Buttonlack einfach wegwischt. Übrig bleibt dann oft erstaunlich wenig. Ein Rollenmodell, ein Dashboard, ein paar APIs, etwas Workflow, ein bisschen Suchfunktion, eine Handvoll Tabellen, darüber ein freundlicher Login, und plötzlich soll das ein unersetzbares SaaS-Produkt sein. Früher konnte man so etwas teuer verkaufen, weil der Bau langsam war. Heute muss man erklären, warum es mehr ist als ordentlich zusammengesteckte Commodity.
Das ist der Punkt, an dem Intellectual Property anfängt, wirklich wichtig zu werden. Nicht als juristische Floskel, nicht als PowerPoint-Wort mit Patentglanz, sondern als reale ökonomische Verteidigung. Echte IP liegt nicht darin, dass ein Team bekannte Standardmuster korrekt implementiert hat. Echte IP liegt dort, wo Nachbau trotz günstiger Implementierung schwierig bleibt, also in Domänenwissen, in tief verankerten Datenflüssen, in Integrationen, die an reale Prozesse angeschlossen sind, in regulatorischer Sicherheit, in Erfahrungswissen aus Randfällen, in Betriebsstabilität, in Vertrauen, in Haftung, in einem Systemverständnis, das nicht aus ein paar kopierten Tickets und einem Modellzugang entsteht. Andreessen Horowitz formuliert diese Marktverschiebung inzwischen bemerkenswert offen: “Every feature that can be built will be built.” Genau deshalb reicht Feature-Besitz als Schutz nicht mehr aus.
Anders gesagt, die Welt trennt sich gerade in zwei Klassen von Software. Auf der einen Seite steht echte Substanz, also Software, deren Wert über den Code hinausgeht und die auch dann schwer kopierbar bleibt, wenn Implementierung plötzlich billig geworden ist. Auf der anderen Seite steht Commodity Software, also das, was man erhält, wenn bekannte Patterns mit genügend Fleiß und hinreichend sauberer Technik in ein Produkt gegossen werden und anschließend so bepreist werden, als hätte man den Aggregatzustand der Informatik verändert. Genau diese zweite Klasse bekommt jetzt Probleme. Nicht weil sie niemand bauen könnte, sondern weil sie plötzlich sehr viele bauen könnten.
In den USA sieht man die Risse bereits. Das Interessante daran ist nicht einmal, dass einzelne Firmen scheitern, Firmen scheitern immer, das wirklich Relevante ist, warum sie scheitern und welche Nervosität dabei im Markt sichtbar wird. Reuters berichtet bereits über deutliche Verwerfungen an Software-Aktien, nachdem neue KI-Funktionen die Sorge verstärkt haben, dass bisher stabile Software- und Informationsmodelle von unten heraus angegriffen werden. Bloomberg berichtete 2025 über die Insolvenz von Builder.ai, einem hoch bewerteten Unternehmen, das sehr deutlich zeigt, wie schnell ein großes Narrativ kollabiert, wenn zwischen Behauptung, Substanz und belastbarer Differenzierung zu wenig echte Tragfähigkeit liegt. Das ist nicht der einzige Fall und auch kein mathematischer Beweis für die ganze These, aber es ist ein ziemlich brauchbares Menetekel.
Aus genau diesem Grund habe ich MegaRepo (https://bsnsoft.de/megarepo) gebaut. Nicht, weil die Menschheit morgens aufwacht und denkt: “Endlich, noch ein Artifact Repository Manager, jetzt kann die Zivilisation weitergehen.” So romantisch muss man wirklich nicht werden. Ich habe MegaRepo gebaut, weil ich ein Exempel zeigen wollte. Ich wollte sichtbar machen, dass ein erheblicher Teil des Marktes seine Preise nicht aus echter Tiefe bezieht, sondern aus historisch gewachsener Trägheit, aus Vertriebsmaschinerie, aus Gewohnheit, aus Installationsangst und aus dem alten Reflex, dass Software eben teuer sein müsse, weil Software zu bauen teuer sei. Genau dieser Reflex ist veraltet.
MegaRepo ist für mich deshalb nicht nur ein Produkt, sondern auch ein Argument. Es ist die praktische Demonstration der These, dass Commodity Software ihren Schutz verliert, sobald die Produktionsmittel demokratisiert werden. Wer heute ein solches System in sehr kurzer Zeit bauen kann, sauber, funktionsfähig und in sinnvoller Qualität, der entwertet nicht gute Produkte, sondern schlechte Preislogiken. Das ist ein wichtiger Unterschied. Ich zerstöre damit nicht die Idee von Wert, ich zerstöre nur die bequeme Ausrede, dass Implementierungsaufwand automatisch Wert bedeute. Das war noch nie philosophisch sauber, und ökonomisch ist es jetzt endgültig nicht mehr haltbar.
Dabei hilft es aus meiner Sicht auch nicht, Claude oder ähnliche Systeme bloß als “Tool” zu beschreiben. Diese Sprache hält das Denken zu klein. Wer von einem Tool spricht, stellt sich immer noch einen Entwickler vor, der im Wesentlichen dasselbe tut wie früher, nur ein wenig schneller. Das ist nicht falsch, aber es greift zu kurz. Ich nutze Claude nicht als Tool. Ich nutze Claude eher wie ein SE-Team, und meine eigentliche Arbeit besteht nicht darin, Zeichenketten in eine Datei zu tippen, sondern darin, fachliche Anforderungen sauber zu übersetzen, Grenzen zu schneiden, Qualitätsmaßstäbe zu definieren, Architekturentscheidungen zu treffen, Risiken zu erkennen und den Unterschied zwischen einem bloß funktionierenden System und einem wertvollen System herauszuarbeiten. Genau dort liegt heute die eigentliche Leistung.
Das verändert auch den Beruf des Softwareentwicklers, aber nicht in der infantilen Weise, in der manche Untergangspropheten oder Heilsverkäufer das beschreiben. Gute Entwickler werden nicht obsolet, sie werden entlarvt. Wer nur implementieren konnte, ohne zu verstehen, wird an Relevanz verlieren. Wer hingegen Probleme strukturieren, Abhängigkeiten erkennen, Anforderungen schärfen, Systeme führen und aus vagen fachlichen Spannungen tragfähige Lösungen formen kann, wird wichtiger. Aus dem reinen Produzenten von Code wird stärker ein Dirigent technischer Wertschöpfung. Und wie bei jedem Orchester gilt auch hier, dass die bloße Existenz vieler Instrumente noch keine Musik ergibt. Manchmal ergibt sie nur Lärm, und in manchen Firmen ist sogar der Lärm noch als Transformation budgetiert.
Deshalb glaube ich auch nicht, dass SaaS verschwindet. Das wäre zu grob und am Ende auch zu bequem formuliert. SaaS bleibt dort stark, wo nicht nur Software verkauft wird, sondern Verantwortung, Integration, Betrieb, Verlässlichkeit und Ergebnisnähe. SaaS stirbt nicht, aber ein bestimmter Typ SaaS verliert gerade seine metaphysische Aura. Die Zeit, in der man Standardsoftware mit ein paar differenzierenden Adjektiven versehen und anschließend so tun konnte, als sei das allein schon ein Burggraben, geht zu Ende. Künftig wird man genauer hinschauen müssen, und das ist gesund. Wer echte Datenvorteile besitzt, echte Integrationsmacht, echtes Domänenwissen oder echte operative Exzellenz, der hat weiterhin einen Platz. Wer dagegen nur Features zusammengesetzt hat, hat im Kern keinen dauerhaften Wert geschaffen, sondern nur eine Lücke zwischen Bedarf und Umsetzungsgeschwindigkeit monetarisiert. Diese Lücke wird nun kleiner.
Man kann es noch härter sagen, und vielleicht sollte man das auch: Eine 100.000-Euro-Software, die sich in kurzer Zeit nachbauen lässt, wird den KI-SaaS-War nicht überleben, sofern ihr Wert nicht in echter IP liegt. Nicht im Quelltext, nicht im Frontend, nicht in den fünf PowerPoint-Folien des Vertriebs, sondern in etwas, das auch dann noch schwer bleibt, wenn zehn gute Leute mit einem klaren fachlichen Ziel und einem KI-gestützten Entwicklungssetup antreten. Wenn dieser Restwert nicht vorhanden ist, dann war das Produkt nie besonders tief, sondern nur historisch gut geschützt. Das ist hart, aber Härte ist manchmal nur der unangenehme Name von Klarheit.
Genau deshalb sortiert KI den Markt nicht in “Firmen, die KI einsetzen” und “Firmen, die KI nicht einsetzen”. Das wäre zu simpel. Sie sortiert in Firmen mit echter Intellectual Property und Firmen mit teurer Commodity. Die einen werden ihre Hebel massiv vergrößern, weil sie schneller bauen können, ohne ihren Kern zu verlieren. Die anderen werden feststellen, dass ihr Kern leider der Bau selbst war. Und wer als Kern nur “wir können so etwas auch entwickeln” vorweisen kann, sollte langsam unruhig werden, denn das ist kein Burggraben mehr, das ist ein Praktikumszeugnis mit Preisetikett.
Am Ende bleibt deshalb für jede Softwarefirma nur eine wirklich ehrliche Frage, und sie ist so einfach, dass man sie kaum noch marketingtauglich verpacken kann: Was bleibt von unserem Wert übrig, wenn Code billig geworden ist? Wenn die Antwort lautet “unsere Features”, wird es unerquicklich. Wenn die Antwort lautet “unsere Integration, unsere Datenflüsse, unser Domänenwissen, unsere regulatorische Sicherheit, unser Betrieb, unser Vertrauen und unsere echte IP”, dann beginnt dort der Teil des Geschäfts, den man auch in zehn Jahren noch verteidigen kann.
Und genau das ist aus meiner Sicht die eigentliche Wahrheit der KI-SaaS-Wars. Sie zerstören nicht den Wert von Software. Sie zerstören die Selbsttäuschung rund um Software, die nie mehr war als ordentlich verpackte Commodity. Das ist für manche unbequem, für den Markt insgesamt aber heilsam. Denn Commodity darf billig werden. Sie sollte billig werden. Teuer bleiben darf, was wirklich schwer ist. Und schwer ist heute eben immer seltener das Schreiben von Code, schwer ist das Schaffen von Substanz.