Software wird künftig nicht mehr geschrieben, sie wird beschrieben. Das verändert Softwarefirmen, jede andere Firma und jede Due Diligence.
Jede grosse Softwarefirma ist ein Gedächtnis. Viele Jahre Kundengespräche, Beschwerden, Sonderfälle, gescheiterte Releases und mühsam gelernte Branchenregeln stecken in ihrem Code. Dort lagen sie sicher, weil niemand ausser dem Hersteller sie lesen konnte. Genau das war der Burggraben: nicht der Code selbst, sondern das darin eingefrorene Prozesswissen, das sich ohne den Hersteller nicht wieder auftauen liess.
Seit diesem Herbst lässt es sich auftauen. Coding-Agenten bedienen inzwischen die Werkzeuge der Reverse Engineers, untersuchen laufende Programme und deren Netzwerkverkehr und tragen zusammen, was eine Anwendung tatsächlich tut. Ein einzelner Entwickler tritt mit KI-gebauten Alternativen gegen sieben Adobe-Anwendungen an und prüft seinen Photoshop-Nachbau gegen Dateien, die Photoshop selbst erzeugt hat. Das Original, Adobes Photoshop, liefert die Prüfkriterien für seinen eigenen Ersatz.
Bevor jetzt alle ihre Adobe-Aktien verkaufen: Wer Photoshop entschlüsselt, hat Photoshop vom Oktober 2026. Er hat nicht die Firma, die Photoshop 2027 baut. Genau dort beginnt die eigentliche Geschichte.
Codieren hat keinen Wert mehr
Die These ist simpel und für viele Geschäftsmodelle unangenehm: Die Herstellung von Software kostet bald nur noch ein paar Token. Wer mir dann noch Programmierarbeit verkauft, verkauft mir etwas, das ich mir selbst für Centbeträge erzeugen kann.
Wert behält genau eine Fähigkeit: zu wissen, was gebaut werden muss. Das eigene Geschäft so präzise zu beschreiben, Widersprüche so klar zu entscheiden und diese Beschreibung so konsequent weiterzuentwickeln, dass daraus jederzeit die richtige Software entstehen kann. Requirements, ein Wort, bei dem die meisten Manager bisher innerlich abschalten, werden zum wichtigsten Vermögenswert eines Unternehmens.
Das gilt für Softwarefirmen. Und es gilt mit derselben Härte für jede andere Firma.
Die neue Welt hat neue Regeln, und sie gelten ab heute. Wer sie nicht versteht, macht morgen keine Geschäfte mehr. Es sind vier Paradigmenwechsel.
Paradigmenwechsel 1: Vom Produkt zum Schnappschuss
Für die Incumbents heisst das zunächst: Ihr Code schützt sie nicht mehr. Das Urheberrecht bleibt bestehen, aber es schützt den Code, nicht die Funktion. Das Adobe-Beispiel zeigt, wer das Verhalten eines Produkts erschliessen und mit eigenem Code neu herstellen kann, braucht den geschützten Code nicht. Das Monopol steht weiter im Gesetz. Die Zahlungsströme daraus stehen nur noch in der alten Excel-Planung.
Noch ist der Nachbau nicht so weit. PhotoCraft schätzt selbst, dass es erst rund 45 Prozent dessen abdeckt, was professionelle User verlangen. Wer sich darauf ausruht, sieht den Stand und übersieht die Steigung.
Interessanter ist allerdings, was der Angreifer nicht bekommt. Er hält eine Momentaufnahme in der Hand: alle Entscheidungen bis gestern, keine einzige für morgen. Er weiss nicht, warum eine Regel so ist, welcher Kunde sie verlangt hat und was dieser Kunde als Nächstes verlangen wird. Ein Nachbau ist ein Foto des Produkts. Das Produkt selbst ist ein Film.
Damit stehen Angreifer und Angegriffener im selben Rennen, und keiner von beiden gewinnt es mit Code. Gewinnen wird, wer schneller herausfindet, was als Nächstes gebaut werden muss.
Paradigmenwechsel 2: Altsoftware, vom Risiko zur Quelle
Der zweite Wechsel ist für viele Unternehmen der wichtigere. Alte Software war bisher vor allem ein Risiko. Niemand wusste mehr genau, welche Regeln in ihr stecken, und jede Ablösung war ein Projekt, bei dem die Hälfte des Budgets in die Frage floss, was das alte System eigentlich tut. Also liess man es laufen und zahlte.
Wenn sich die Requirements aus altem Code zurückgewinnen lassen, kippt diese Rechnung. Bei Nokia haben zwei Ingenieure mehr als 50 Millionen Codezeilen in zwei Wochen analysiert. Thought Machine und AWS kündigen für Banken eine Lösung an, die Geschäftsregeln aus Altsystemen gewinnt, konsolidiert und daraus neue Implementierungen samt Tests erzeugt. Der Altbestand ist auf einmal nicht mehr der Klotz am Bein. Er ist die Spezifikation für seinen Nachfolger.
Das trifft ein Geschäftsmodell, über das selten jemand offen spricht: Die Angst vor der Migration war so ein Geschäftsmodell. Anbieter haben davon gelebt, dass niemand herauskam. Dienstleister haben davon gelebt, dass jeder Ausstieg Jahre dauerte. Ab jetzt ist diese Angst nur noch eine Ausrede. Und der Kunde muss nicht einmal wechseln. Es reicht, dass er es könnte, um die nächste Preiserhöhung zu beerdigen.
Paradigmenwechsel 3: Vom Code zur Spezifikation
Die ersten beiden Wechsel laufen auf denselben Punkt zu. Wenn Code beliebig herstellbar ist, wird die Beschreibung dessen, was er tun soll, zum eigentlichen Produkt. Die Spezifikation ist das Produkt. Der Code ist ihr Nebenprodukt.
Das grosse Missverständnis der aktuellen Debatte heisst Vibe-Coding. Jemand tippt einen Wunsch ins Chatfenster, bekommt eine hübsche App und hält das für die Zukunft der Softwareentwicklung. Das ist ungefähr so, als würde man aus einer Skizze auf dem Flipchart auf die Zukunft des Maschinenbaus schliessen. Professionelle Softwareherstellung sieht anders aus, und sie wird gerade erst erfunden.
Ihr Kern ist ein lebendes Modell des eigenen Geschäfts. Kein Pflichtenheft, das ein Berater zum Projektende abliefert und das mit dem ersten Änderungswunsch veraltet, sondern eine dauerhaft gepflegte Beschreibung: Was bedeuten unsere Begriffe? Welche Regeln gelten, und warum? Wo widersprechen sich Vertrieb, Produktion und Controlling, und wer hat den Widerspruch wie entschieden? Woran erkennen wir, dass ein Ergebnis richtig ist?
Aus diesem Modell werden Prüfkriterien abgeleitet, und erst gegen diese Kriterien wird Code erzeugt, den keine Maschine an ihren eigenen Massstäben vorbei durchwinken darf. Was im Betrieb schiefgeht, landet nicht im Ticketfriedhof, sondern fliesst als neue Frage zurück ins Modell. Jede Schleife macht die Beschreibung präziser und die nächste Software besser. Die Entscheidung bleibt beim Menschen. Die Fleissarbeit dazwischen nicht mehr.
Der Engpass liegt dann nicht mehr bei den Entwicklern. Er zeigt sich in jeder Firma, die nicht sagen kann, wie ihr eigenes Geschäft funktioniert. Eine Warnung gehört allerdings dazu: Wer seinen schlechtesten Prozess perfekt beschreibt, bekommt ihn künftig perfekt automatisiert. Requirements-Kompetenz heisst deshalb auch, Anforderungen zu hinterfragen, bevor man sie in Software giesst.
Paradigmenwechsel 4: Vom Standard zur Massanfertigung
Standardsoftware war immer ein Kompromiss. Wir haben unsere Prozesse an fremde Produkte angepasst, weil Massanfertigung zu teuer war. Ganze Beratungsindustrien leben davon, Unternehmen beizubringen, wie sie in die Masken eines ERP-Systems passen. Wenn die Herstellung nichts mehr kostet, verschwindet der Grund für diesen Kompromiss. Individualsoftware, jahrzehntelang als teurer Luxus betrachtet, wird überall dort zur naheliegenden Wahl, wo die eigene Arbeitsweise einen Unterschied macht.
Damit stellt sich jedem Unternehmen eine unbequeme, aber logische Frage: Brauche ich überhaupt noch eine Softwarefirma, die für mich programmiert? In vielen Fällen lautet die ehrliche Antwort: nein. Was ich brauche, ist die Fähigkeit, präzise zu sagen, was ich will, und diese Beschreibung im Takt meines Geschäfts weiterzuentwickeln. Aus „make or buy“ wird „beschreiben oder abhängig bleiben“.
Wer diese Fähigkeit auslagert, lagert das Verständnis seines eigenen Geschäfts aus. Das war schon immer ein schlechter Deal. Bisher war er nur alternativlos.
Was von Softwarefirmen übrig bleibt
Softwarefirmen verschwinden nicht, aber sie werden sich ändern. Die Softwarefirma der Zukunft ist eine Requirements-Firma mit tiefem Domänenwissen. Ihr Produkt ist nicht der Code, sondern ihr Vorsprung im Verstehen und Lernen: Sie sieht bei hundert Kunden, was einer allein nicht sieht, erkennt früher als alle anderen, welche Regel sich ändert, und liefert die Antwort aus, bevor der Kunde die Frage formuliert hat.
Das ist ein gutes Geschäft, nur ein anderes. Die alte Rechnung lautete vereinfacht: einmal bauen, millionenfach verkaufen, jedes Jahr die Preise erhöhen. Die neue lautet: jeden Monat beweisen, dass man das Geschäft des Kunden besser versteht als er selbst und besser als jeder, der den Code von gestern nachgebaut hat. Auch damit lassen sich ordentliche Margen verdienen. Sie müssen nur jeden Monat neu erarbeitet werden, statt mit dem nächsten Lizenzbrief verlängert zu werden.
Für die Bewertung heisst das: Es zählt nicht mehr, was eine Softwarefirma gebaut hat, sondern wie schnell sie weiss, was sie als Nächstes bauen muss. Ein grosser Codebestand ist kein Vermögenswert mehr, eher eine Erinnerung an vergangene Umsätze und Gewinne. Wer ein Software-Roll-up auf der Annahme jährlicher Preiserhöhungen gerechnet hat, sollte sein Modell einmal ohne diese Excel-Zeile laufen lassen.
Warum das eine gute Nachricht ist
Für Unternehmer ist das die beste Nachricht seit Jahrzehnten. Zum ersten Mal passt sich die Software an das Geschäft an und nicht das Geschäft an die Software. Differenzierung, bisher ein Privileg von Konzernen mit eigenen Entwicklungsabteilungen, wird für jeden bezahlbar. Wer seine Prozesse wirklich versteht, kann sie jetzt in Software verwandeln, ohne sich an einen Anbieter und dessen Roadmap zu ketten.
Für Investoren entsteht eine neue Landkarte mit Gewinnern auf beiden Seiten: erstens, die Softwarefirmen, die sich zur Requirements-Maschine ihrer Domänen umbauen, und zweitens, alle anderen Unternehmen, deren Requirements-Kompetenz noch in keiner Bewertung auftaucht. Die zweite Gruppe ist heute systematisch unterbewertet, weil niemand sie auf dem Schirm hat.
Deshalb gehören zwei Fragen in jede Due Diligence, nicht nur an Softwarefirmen: Wie wird in der Breite der Teams das Anforderungs-Management organisiert? Wie schnell lernen Sie, und wie viel Ihrer Kundenbindung ist echte Leistung und wie viel nur Ausstiegsangst? An jede andere Firma, auch wenn im Branchenfeld Maschinenbau steht: Können Sie Ihr eigenes Geschäft so beschreiben, dass daraus Software entsteht? Oder kaufen Sie weiter Beraterfolien und Lizenzen, die ein anderer für Sie ausgesucht hat?
Software wird künftig nicht mehr geschrieben. Sie wird beschrieben. Die Firmen, die das zuerst verstehen, werden die Softwarefirmen der nächsten Dekade sein, ganz gleich, was heute in ihrem Handelsregisterauszug steht.
