Is AI eating Software? Ein neuer Krieg um Unternehmenssoftware hat begonnen

Dank KI wird es immer einfacher, Programme selbst zu entwickeln. Das verändert das Verhältnis zwischen Softwareunternehmen und ihren Kunden rapide – birgt aber auch Chancen.

2011 schrieb Marc Andreessen den Satz, der eine ganze Generation von Gründer:Innen geprägt hat: “Software is eating the world.”

Fünfzehn Jahre später stellt sich eine neue Frage: Is AI now eating software?

Die Kapitalmärkte scheinen genau das zu glauben. Unternehmens-Software wie Salesforce, Workday, Hubspot, Service Now, SAP, Atlassian und viele andere notieren teilweise über 60 Prozent unter ihrem Allzeithoch. Bewertungen werden korrigiert, Wachstumserwartungen relativiert, Investoren stellen das nutzerbasierte Preismodell der Firmen oder sogar das ganze Geschäftsmodell Software-as-a-Service (SaaS) offen infrage. Und über allem steht die Frage:

„Triggert Künstliche Intelligenz (KI) die SaaS-Apocalypse?“ Wird es bald so einfach und günstig, mit Hilfe von KI neue Software mal eben so, ohne große Vorbereitung  zu bauen, sodass Standardlösungen überflüssig werden? Es wirkt fast, als würden einige Analysten an den Kapitalmärkten diese These vertreten. Oder sehen wir die sukzessive Transition, wie bei früheren Transformationen? So wie bei dem Wechsel auf das Betriebssystem Unix oder von IT-Diensten, die lokal auf dem Computer installiert sind,  in Richtung Cloud-basierte SaaS? Sind die Muster und Regeln bei KI dieselben wie bei früheren Transitionen? Wie findet dieser Wechsel statt? Was bedeutet er für die IT in Unternehmen und für die Softwareanbieter?

Kaum ein Thema hat mich so beschäftigt. In Gesprächen mit meinen Beteiligungen, mit Gründer:Innen und Investor:Innen. Mit CTOs auf der McKinsey CTO-Konferenz in Kitzbühel (danke für die Einladung). Und ganz praktisch in eigenen Experimenten – erst mit den KI-Tools Lovable, dann mit Claude Cowork oder mit OpenClaw. Aus all diesen Eindrucken sind die sieben Thesen entstanden:

1. These: Die Zukunft ist (vorerst) kein Large-Language-Model–Monolith (LLM), sondern kleine Sprachmodell-basierte Agenten (SLM)

In den letzten zwölf Monaten hat sich das Angebot von KI-Herstellern zunehmend “Unternehmenstauglich” entwickelt. Viele CTOs sehen vor allem in Anthropics Claude und spezialisierten Agenten einen Weg, bestehende Jobs oder Aufgaben durch Agenten unterstützt umzusetzen. Dabei scheinen zumindest aktuell kleinere, spezialisierte Agenten gut konfiguriert zu sein und sich durchzusetzen gegen allgemeine LLM-Monolithen.

Sie funktionieren weniger als allwissendes System, sondern mehr wie Teammitglieder mit Jobprofil. Und ähnlich werden sie auch koordiniert, was uns zu These Zwei bringt.

2.   These: Koordination von Agenten wird Kernkompetenz im CTO Office

Der Umgang mit Agenten ähnelt eher dem Management von Menschen als einer Software-Implementierung. Wir versorgen diese mit Fähigkeiten und Basisinformationen, trainieren sie im Onboarding und koordinieren und verbessern sie während ihrer Arbeitszeit. Ertappt habe ich mich zum Beispiel dabei, wie ich auf einer längeren Autofahrt eine Art Mitarbeitergespräch via Gesprächsfunktion geführt habe, in der ich Feedback zu der Performance einzelner Projekte und Agenten gegeben habe.

Ähnlich wie menschliche Rollen und Rechte ermöglicht das SLM-basierte Aufsetzen von Agenten das „Permissioning“ – also die Zugriffsrechte von KI stärker zu steuern. All die oben genannten Prozesse muss das CTO Office beherrschen: Es ist eine Art Mischung aus Enterprise Architektur (eine IT Disziplin) und Personalwesen:

3.   These: Das richtige SDLC-Tooling befähigt 10x Builder

Ein guter Software Development Lifecycle (SDLC) war schon immer entscheidend. Aber KI verändert ihn grundlegend. Das beginnt bei den Anforderungen. Gefühlte 90 Prozent der Probleme in der Softwareentwicklung entstehen aus einer Lücke zwischen Erwartung und sauber formulierten Anforderungen. Um den Wert von KI hier zu verstehen, habe ich ein Feature in einem Dialogprozess via Sprachbefehle auf einem 10-minütigen Spaziergang mit einem vorkonfigurierten Claude-basierten Agenten spezialisiert auf die Anforderungsaufnahme – das so genannte Requirement Engineering – besprochen. Daraus habe ich ein so genanntes Product Requirement Document (PRD) erstellen und eine Aufwandsindikation anhand weniger als zehn Rückfragen durch die KI herleiten lassen. Das Ergebnis hat viele fertige PRDs/Estimations geschlagen, die ich in den Jiras vieler Unternehmen gesehen haben.

Und das ist nur der Anforderungsprozess. Dazu kommen spezialisierte Agenten für etwa die Begleitung des Coding selber durch die KI (analog zu früher, wenn ein erfahrener Entwickler mit einem jüngeren Entwickler bei der Code Entwicklung am laufenden Programmcode trainiert), Testautomatisierungen, die Verbesserung von bestehendem Code (auch als Refactoring bekannt) sowie die Dokumentation der Software und der Entwicklung selbst.

Entwickler:Innen, die diese Werkzeuge gut orchestrieren können, werden deutlich produktiver sein als andere. Ob diese Entwickler dann sogar die 20x produktiver werden, wie McKinsey es schätzt, muss sich zeigen

4.   These: Ag(ent)ile Programmierung: 3 Menschen + x Agenten

In den drei, an der Softwareentwicklung beteiligten Berufsgruppen, setzt sich gerade eine spannende Erkenntnis durch: Die Grenzen zwischen den Berufen verschwinden.

Der Product Owner erhält durch KI die Möglichkeit selber mehr Design und Code zu erstellen. Designer:Innen und Entwickler:Innen wiederum erhalten mehr Einblicke zu den Softwareanforderungen. Erstere kommen schneller ins Coding, für letztere ist es einfacher Designs zu erstellen. Die Grenzen, die alle drei Rollen früher in einem guten Sprint Team erforderlich gemacht haben, verschwimmen.

Da jede einzelne Rolle, abhängig von ihren Fähigkeiten und dem Verständnis, nun mehr Verantwortung übernehmen kann, können Teams deutlich kleiner werden. Sprint Planungen werden dadurch einfacher, Wartezeiten und Schleifen durch fehlende oder unzureichende Spezifikationen werden reduziert. Die Entwicklungsgeschwindigkeit nimmt zu.

Und während agile Entwicklung mit zweiwöchigen Releases für viele Unternehmen bereits ein Novum ist, werden wir evtl. bald schon auf nahezu tägliche Releases wechseln. Dass es in diese Richtung gehen kann, zeigen am eindrucksvollsten die KI-Unternehmen wie Antropic und OpenAI gerade selber.

In einfach: kleine Teams werden schnell und effizient. Ein mögliches Setup im eingeschwungenen Zustand: ein Product Owner, ein Lead Builder (kann UX/PO/Entwickler sein), ein Entwickler und eine handvoll gut-konfigurierter Agenten (mit den Fähigkeiten aus These 3) mit dem jeweiligen Kontext der Software und der Guidelines des Projekts und/oder Unternemens.

Also drei  Menschen und eine gewisse Anzahl  Agenten.  Zu der Zahl kursieren unterschiedliche Thesen. Persönlich glaube ich, es wird von dem jeweiligen Team abhängen. Die besten Software-Teams haben ihre Methoden immer etwas an ihren eigenen, besten Arbeitsmodus angepasst.

Was machen nun diese ersten vier Thesen mit der Softwarewelt in großen Unternehmen wie zum Beispiel Banken sowie den dazugehörigen Strategien der Software-Anbieter. Die folgenden drei Thesen sehen sich hier die möglichen Folgen näher an.

5.   These: Die IT-Architekturkriege werden intensiver

Die Softwarearchitektur eines Unternehmens ähnelt einem Schlachtfeld. Viele miteinander vernetzte Applikationen kooperieren über Anbindungen und ersetzen sich manchmal über Zeit. Funktionalität wandert von einer Software zur anderen. Mal wird eine selbst entwickelte Applikation zu Gunsten einer Cloud-SaaS abgeschaltet, mal wird eine Cloud-SaaS durch interne Entwicklung umgesetzt oder durch eine neue bessere Cloud-Alternative. Perfekt ist es nie.

Was macht der oben geschilderte Produktivitätssprung mit dieser Umgebung? Wenn Software 10 Mal günstiger wird (und die Schätzungen gehen hier weit auseinander), dann verändert dies die Fähigkeit, neue Software zu bauen, aber auch zu personalisieren, anzubinden und damit auch abzulösen.

Von CTOs höre ich immer öfter, dass sie beginnen, SaaS-Funktionalitäten systematisch einzugliedern. Ein Beispiel, das ich die Tage öfter höre, ist Salesforce. Salesforce ist längst kein reines Customer-Relationship-Management- (CRM)-System mehr. Es deckt in den Architekturen großer Kunden viele verschiedene verwandte Bereiche ab – wie zum Beispiel das Onboarding von Kunden, die Integration von Webfunnels, Reporting und Datenintegration. Durch jüngste Preiserhöhungen verstärkt, berichteten mir CTOs, dass sie anfangen, erste Funktionalitäten auf Salesforce auf einer neuen Architektur nachzubauen – und dabei unter anderem mit Hilfe von KI.

Die These: Wenn KI, eigene IT-Abteilungen und Softwareunternehmen ermöglichen, neue Systeme schneller zu bauen, zu integrieren und zu migrieren, wird die Drehgeschwindigkeit (die heute oft gering ist) von Software stark beschleunigt. Die Folge: IT-Architekturkriege: Der sukzessive Umbau einzelner Funktionen in den Unternehmenssoftware-Architekturen. Nicht in einem Big Bang, aber Feature um Feature, das auf proprietären Systemen nachgebaut wird.

Auslöser ist dabei der Wunsch nach Kontrolle. Dazu mehr in These Sechs.

6.   These Kontrolle zurückgewinnen! Das Hinterfragen des US-Cloud-Patchwork

Das Beispiel oben mit Salesforce ist nur eines von diversen Baustellen. Nahezu alle CTOs äußern eine ähnliche Frustration: In den letzten Jahren wurden zahlreiche SaaS-Lösungen gekauft – jede für sich sinnvoll, aber oft ohne ein tiefes Verständnis in der eigenen IT, wie die Software funktioniert und wie man die Softwaresysteme in einer konsistenten Zielarchitektur verknüpfen will.

Für die IT entstand so ein so genanntes „SaaS-Patchwork“. Damit verbunden ist eine hohe Abhängigkeit von den Softwareanbietern und damit auch zu US-Infrastruktur. Während letztere aus Risikogesichtspunkten (Stichwort: Souveränität) in der aktuellen geopolitischen Lage hinterfragt werden muss, hat das SaaS-Patchwork auch ein Kostenproblem.

Ursprünglich lautete das Versprechen von SaaS: Kosten atmen mit. In der Praxis steigen sie oft mit dem Umsatz – sinken aber kaum, wenn das Geschäft schwächelt. Viele Unternehmen sind jetzt, drei bis fünf Jahre nach den ersten Cloud-Einführungen, und sehen die jährlichen Kosten der Applikationslandschaft in den späteren Jahren oft bedeutend höher als geplant.

Der Wunsch nach mehr Kontrolle wächst. Gerade in Europa. Aber zwischen dem Wunsch und der Wirklichkeit besteht eine große Lücke: Auf der Anbieterseite im Bereich Software und vor allem im Bereich der Infrastruktur fehlt es oft an guten Alternativen. Aber der Unternehmensseite fehlen oft die kapazitiven und intellektuellen Fähigkeiten, mehr Kontrolle und Transparenz auf Anwendungs- und Infrastrukturebene zu erreichen.

Hier haben alle Seiten ihre Hausaufgaben zu machen. Dabei kann KI massiv helfen. Auf die Chancen und Risiken für die Softwareanbieter-Seite gehe ich in These Sieben ein.

7.   These: Auch SaaS-Anbieter haben ihren 10x Moment – in beide Richtungen

Haben wir also SaaS-mageddon? Die Frage stelle ich mir als Unternehmer, Gesellschafter diverser Beteiligungen aber auch als Aktieninvestor und neugieriger Beobachter. Je mehr ich darüber nachdenke, komme ich zu dem Schluss: Was für den einzelnen Entwickler in These Drei galt, gilt auch für Softwareanbieter. Die Lücke wird größer.

Im Folgenden ein erster Versuch die Erfolgsfaktoren für die Richtung zu strukturieren.

1. Angriffspotential Funktionserweiterung: Wo kann ich in den Architecture Wars angreifen? Welche Funktionen kann ich übernehmen, die vorher von meinem Wettbewerber oder meinen Kunden nicht gut gelöst waren? Wo kann ich Tasks, die bisher Menschen erfüllt haben, unterstützend mit Agenten umsetzen und das gegebenenfalls  sogar auf Basis von Einsparungen oder Ergebnissen bepreisen?

2. Angriffspotential Implementierung und Anpassung: Hier erwarte ich sehr spannende Entwicklungen. Werden Systemhäusern zu Agent(ur)en? Wird eine Implementierung, die früher eine Million Euro kostete, mit Agenten auf 100.000 Euro oder sogar 10.000 Euro reduziert werden? Erste Start-ups greifen zum Beispiel den Markt für SAP-Implementierungen an. Kann eine günstigere Softwareanpassung und -einführung neue Marktsegmente erschließen? Daran glaubt zum Beispiel meine Beteiligung Companyon – eine Controlling-Software, die über das KMU-Segment Agenten einsetzen möchte, um auch größere Kunden auf die Software zu bringen.

3. Kundenbeziehung: Dies wird gerade bei den anstehenden Architekturkriegen ein großer Punkt sein. Einzelkämpfe werden dabei durch die Entscheidungen von Fachbereichen bestimmt. Hier wird die Entscheidung oft anhand der besseren Beziehung fallen – und unliebsame, aber früher wegen einer hohen Integration oder fehlendem Verständnis als nicht austauschbar geltende, Anbieter müssen mehr fürchten.

4. System of Records: Ein Konsens bei CTOs scheint, dass die meisten CTOs KI nur außerhalb der so genannten “System of Records” anwenden. Sprich: Buchführende Systeme beziehungsweise Kernsysteme werden erstmal außen vor gelassen. Die Frage: Was gilt alles als System of Record ist dabei sicher eine spannende für CRM, Personalverwaltung oder Billingsysteme (um nur ein paar zu nennen).

5. Wechsel- und Migrationskosten Wie einfach kann die Software nachgebaut werden? Hier trifft es einige Softwareanbieter härter, die eher einfache Workflows hatten. Tiefe Intellectual Property ist ein Burggraben.

6. KI-Affinität der Kunden: Anbieter, die selbst technologiestarke Unternehmen bedienen, müssen mehr fürchten als zum Beispiel. Anbieter von Krankenhaussoftware.

7. Ökoystem-Angreifer: Gibt es um die Firma herum zum Beispiel fähige Implementierungspartner, die schon immer gerne ein eigenes Produkt gebaut hätten? Dies ist z.B. im Bereich CRM oder Business Intelligence der Fall: In diesen Sektoren erwarte ich mehr Angreifer aus den Reihen des “eigenen Ökosystems”.

Und das ist nur ein erster Auszug der Erfolgsfaktoren.

„Is AI eating Software“? Aus einer technischen Perspektive glaube ich, kann ich mir ein „Ja – zu großen Teilen“ vorstellen. Und das ist die Chance. Die Chance für Unternehmen und Softwareanbieter ihren Anspruch in der Softwarearchitektur zu erweitern, die Produktivität massiv zu steigern und neue Anwendungsfälle zu erschließen. Und das ist die vielleicht größte Chance, die ich in 20 Jahren als Softwareunternehmer gesehen habe.