Software stirbt nicht – es entwickelt sich weiter

• Durch AI wird Code-Generierung günstiger, wodurch der Burggraben „wir haben die Funktionen zuerst gebaut“ zusammenbricht, und Software, die vor allem immer mehr Funktionen aufgetürmt hat, wird in Echtzeit neu bepreist (repriced)
• Verteidigungsfähigkeit entsteht nun nicht mehr durch Funktionsgeschwindigkeit, sondern durch hochpräzise Workflows, proprietäre Daten und tief verankerte Systems of Record, und auch die Messlatte dafür, als „echtes Unternehmen“ zu gelten, steigt
• Behauptungen wie „Ich habe am Wochenende mit Claude ein CRM per Vibe Coding gebaut“ übersehen den Unterschied zwischen Code-Generierung und dem Betrieb mission-kritischer Services; Unternehmen kaufen keinen Code, sondern Vertrauen (trust)
• Agenten ersetzen Apps nicht, sondern werden innerhalb vertikaler Anwendungen eingebettet; Anwendungen, die Datenmodell, Berechtigungen und Audit-Trail besitzen, bleiben die Instanz für Verkauf und Verlängerung
• Zuletzt sind aus der Marktkapitalisierung von Legacy-Software 285 Milliarden US-Dollar verdampft, wodurch Untergangserzählungen über SaaS aufkamen; doch der AI-Markt basiert weiterhin auf realen Umsätzen, in dem die Nachfrage das Angebot übersteigt

---

Die Blasen-Debatte stellt die falsche Frage

• Betrachtet man AI insgesamt, ist es keine Blase. Die Nachfrage übersteigt weiterhin das Angebot, und einige Portfoliounternehmen können wegen fehlender Rechenkapazität nicht einmal alle Kunden bedienen
  • Mit dieser Nachfrage sind nicht bloß Nutzerzahlen verbunden, sondern reale Umsätze in Höhe von zig Milliarden Dollar; so sieht eine Blase nicht aus
• Es gibt allerdings einen Bereich, in dem ein Blasenverdacht naheliegt: humanoide Robotik, in die Kapital in späte Bewertungen strömt
  • Man sieht Backflips und Tanzbewegungen, aber es gibt noch keine Roboter, die wirtschaftlich wertvolle Arbeit verrichten
  • LLMs funktionieren dank des offenen Internets als Trainingskorpus, aber in der Robotik fehlt ein gleichwertiger Datenkorpus,
    weshalb die Herkunft der Trainingsdaten ein ungelöstes Forschungsproblem bleibt (und Forschungszeitpläne passen nicht zu Venture-Zeitplänen)
• Die Antwort auf die Frage nach einer „AI-Blase“ fällt also je nach Bereich unterschiedlich aus, und auch bei Software (SaaS) sollte man nicht sofort zum Schluss kommen, sie sei „tot“, sondern die einzelnen Behauptungen prüfen

Vier Thesen zum Tod von Software (geordnet von der schlechtesten zur besten)

• #4: Jeder wird seine eigene Software per Vibe Coding bauen

  • Die These lautet: „Warum für Salesforce zahlen, wenn man am Wochenende mit Claude selbst ein CRM per Vibe Coding bauen kann?“
  • Das Erzeugen einer Codebasis und der Betrieb mission-kritischer Services sind völlig verschiedene Dinge
    • Wenn die Person, die per Vibe Coding gebaut hat, geht, entsteht sofort ein Problem bei der Pflege der Codebasis
    • Code-Generierung löst weder SOC2-Compliance noch die Kontrolle von Halluzinationen (hallucination)
    • Auch Integrationen mit einer SQL-Datenbank von 1998 oder die Verantwortung für Uptime bei einem Dashboard-Ausfall um 4 Uhr morgens werden dadurch nicht gelöst
  • Unternehmen kaufen keinen Code, sondern Vertrauen; mit AI ist Code-Parität leichter geworden, Vertrauens-Parität aber weiterhin schwer

• #3: Agenten wie Claude oder ChatGPT werden Enterprise-Apps verschlingen

  • Das ist eine bessere These als Vibe Coding, aber bei Workflows mit hohen Fehlerkosten bleibt Skepsis angebracht
  • LLM-Systeme sind nicht deterministisch (non-deterministic) und anfällig für Halluzinationen
    • Gewöhnliche Software-Bugs sind reproduzierbar, Agentenfehler ähneln dagegen instabilen Tests, die zu 98 % durchlaufen und im entscheidenden Moment scheitern
  • Für risikoarme Aufgaben wie E-Mail-Entwürfe, Dokumentzusammenfassungen oder Marketing-Copy sind sie geeignet
    • Wenn ein Agent jedoch Pflichtfelder auslässt oder den Vertragswert falsch einträgt und dadurch ein sechsstelliger Deal verloren geht, braucht man wieder ein System, das Regeln erzwingt
  • Teams mit rein agentischen Workflows bauen am Ende doch wieder Validierungsschichten, Freigabeschritte, Rollbacks und Audit-Logs auf
    • Addiert man all das, hat man im Grunde wieder eine SaaS-App rund um den Agenten aufgebaut
    • Das Ergebnis ist also nicht der Ersatz der App, sondern die Einbettung von Agenten in vertikale Anwendungen
    • Datenmodell, Berechtigungen, Audit-Trail und Kundenbeziehung verbleiben bei der Anwendung, und verkauft, unterstützt und verlängert wird genau diese Hülle
  • Wenn die Modellzuverlässigkeit steigt, wird das spannender, aber so weit ist es noch nicht

• #2: Das Ende der sitzbasierten Preisgestaltung wird das SaaS-Modell zum Einsturz bringen

  • Klassisches SaaS besteht aus drei Schichten: Daten, Business-Logik und UI; darauf wird nun eine vierte agentische Schicht (agentic layer) aufgebaut
    • Wenn man früher 50 Seats an Menschen verkauft hat und nun zwei Agenten alles ohne UI erledigen, entsteht ein Problem bei der Preisdurchsetzung
  • Wenn Agenten mehr Arbeit übernehmen und Kunden mehr Wert erhalten, ist das kein existenzielles Problem, sondern ein Pricing- und Packaging-Problem
    • Anbieter, die über Token, Ergebnisse oder hybride Nutzungsmodelle wertbasiertes Pricing (price to value) gestalten, werden überleben
    • Anbieter, die am Preis pro Seat festhalten, brechen ein, sobald Kunden Seats automatisieren
  • Rein erfolgsbasiertes Pricing lässt sich nicht sauber auf alle Kategorien anwenden; deshalb werden in den nächsten Jahren wohl hybride Modelle (Nutzung + Ergebnis) dominieren (explizit so im Original)

• #1: Günstiger Code zerstört den Funktions-Burggraben

  • Diese These wird am ernstesten genommen
  • Der Burggraben von SAP, ServiceNow und Salesforce bestand über Jahrzehnte aus angesammelter Engineering-Kapazität
    • Jede Funktion, Integration und jedes Reporting war in Codebasen aufgegangen, die für Startups kaum einzuholen waren; AI komprimiert diese Zeitleiste jedoch drastisch
  • Wenn ein Produkt im Kern nur eine Workflow-Schicht ist und die Verteidigung lautete „wir haben es zuerst gebaut“, dann ist das eine Krisensituation
    • Business Intelligence und kreative Content-Erzeugung sind derzeit die Bereiche mit dem flachsten Burggraben, weil LLMs genau diese Arbeit sehr gut beherrschen

Wo liegt der Burggraben jetzt?

• Drei Verteidigungselemente

  • Hochpräzise Workflows mit nahezu null Fehlertoleranz: Finanzinfrastruktur, Gesundheitswesen, regulatorische Compliance usw.
    • Vibe Coding hält weder HIPAA-Audits noch Abrechnungsdifferenzen stand; die Fehlerkosten selbst werden zum Burggraben
  • Proprietäre Daten-Feedback-Loops: Sie verbessern sich durch Kundennutzung substanziell und können von Wettbewerbern mit demselben Foundation Model nicht kopiert werden
    • Nicht das Modell, sondern die Daten sind das Asset
  • Tief verankerte Systems of Record: Sie sind in Legacy-Abläufe eingebettet, besitzen die Source of Truth und erzeugen hohe Wechselkosten
    • Diese Unternehmen sollten AI nicht meiden, sondern offensiv annehmen; die agentische Schicht steigert den Wert ihrer Daten sogar noch

Der aktuelle Stand des AI-Stacks: Wo investiert wird – und wo nicht

• „In AI investieren“ ist inzwischen ungefähr so wenig differenzierend wie 2012 die Aussage „in Software investieren“
• Es gibt vier Schichten, und sie sind keine identischen Ziele für Kapitalallokation

• 1. Hardware

  • Rechenkapazität bleibt in diesem Zyklus der bindende Engpass (binding constraint)
  • Unternehmen wie Neolabs warten auf Bestellungen (POs), die eigentlich schon vor Monaten hätten verarbeitet werden sollen
  • Die Nachfrage ist real, aber das Angebot ist blockiert, und die Gewinner sind meist börsennotiert oder bereits skaliert – Seed-Investments ändern daran wenig

• 2. Modelle

  • Frontier-Modelle sind kein Venture-Business, sondern ein kapitalintensives (capex) Geschäft
  • Das ordentliche Training kostet so viel wie das BIP eines kleinen Landes, und OpenAI, Anthropic und Google spielen dieses Spiel bereits
  • Modell-Startups, die frontal angreifen wollen, wählen den falschen Kampf
  • Investiert wird nur in wenige Unternehmen wie Sciforium, die mit neuen Architekturen, Trainings-/Inference-Ansätzen oder Problem-Framing eine andere Form anstreben
    • Wenn es ein Outflanking-Ansatz ist, den etablierte Akteure nur durch Kannibalisierung ihres Kerns kopieren könnten, ist das interessant

• 3. Infrastruktur

  • Hier bricht AI bestehende SaaS-Annahmen auf interessante Weise auf
  • Traditionelles SaaS war read-heavy: eine Zeile speichern und millionenfach abfragen
    • AI-Workloads drehen das um: Trainingspipelines, Agent-Memory, Vector Stores und Evaluierungs-Harnesses sind write- und update-heavy und arbeiten mit Datenformen, für die Legacy-Systeme nie entworfen wurden
  • In beide Richtungen wird aktiv investiert
    • Die Datenschicht selbst: PlanetScale, Greybeam – sie bauen OLTP- und OLAP-Datenbankprimitive für diese Workload-Form neu auf
    • Die Datenentstehungsschicht: Preference Model, Moody Pines, Terac – sie adressieren nach gelöster Compute-Frage den eigentlichen Engpass, nämlich die Versorgung mit bereinigten, strukturierten und gelabelten Daten

• 4. Anwendungen

  • Hier fließt derzeit der Großteil des Kapitals hin, denn auf dieser Schicht erreicht der Wert echte Käufer
  • AI erschließt enorme neue Oberfläche (surface area) in zuvor kaum angreifbaren Workflows wie Medical Coding, Frachtoptimierung, Legal Review, Sales Motion oder klinischen Abläufen
  • Der Wettbewerb ist intensiv und der Preisdruck hoch, aber genau das ist typisch für eine Schicht mit großer Nachfrage
  • Gewinner werden jene sein, die AI-native Workflows mit hochpräzisen Umgebungen, proprietären Daten-Loops oder tiefen Systems of Record kombinieren

Für Gründerinnen und Gründer in diesem Markt

• Hardware und Modelle sind für Neueinsteiger ohne strukturellen Vorteil nahezu verschlossen
• Infrastruktur steht weit offen, wenn man verinnerlicht hat, dass „AI-Workloads keine SaaS-Workloads sind, an die man einfach einen Chatbot klebt“
• Anwendungen sind der Bereich mit dem größten Volumen und der am schnellsten steigenden Messlatte

• Empfehlungen für Seed- und Series-A-Phase

  • Hört auf, „schnell launchen“ als Burggraben zu behaupten – das ist jetzt Grundvoraussetzung
  • Zeigt die Daten, die nur ihr aufbauen konntet und sonst niemand bekommen kann
  • Betont den Workflow, den nur ihr so tief absorbiert habt, dass Kunden ihn nicht beliebig herauslösen können
  • Pitcht die Genauigkeit eures Systems in Umgebungen, in denen Fehler zu großen Verlusten führen
  • Wenn eure Funktion zwischen zwei großen Anwendungen eingeklemmt ist, solltet ihr erkennen, dass ihr euch in einer Dead Zone befindet
• Software stirbt nicht, aber aufgeblähte Utility-Software wird in Echtzeit neu bepreist (repriced);
  sie zu ersetzen ist sehr viel schwieriger als ein Wochenendprojekt mit Model-APIs – die Messlatte für ein echtes Unternehmen steigt