Software-Unternehmen: Warum das Geschäftsmodell jetzt kippt

Eine Zahl, die auf dem Weg ihre Bedeutung verloren hat

Anfang Juli war der WeAreDevelopers World Congress in Berlin. 15.000 Teilnehmer, über 500 Vortragende, 40.000 Quadratmeter Ausstellung. Danach kursierte in einigen Zusammenfassungen die Zahl 93 als angeblicher Produktivitätsfaktor durch KI-gestützte Entwicklung.

Ich habe versucht, diese Zahl zu belegen. Sie existiert nicht. Was existiert, ist eine 93 in genau diesem Themenfeld, allerdings mit umgekehrter Aussage. Sie stammt aus Erhebungen zur Verbreitung von KI-Werkzeugen unter Entwicklern, gepaart mit einem einstelligen bis niedrig zweistelligen Produktivitätsgewinn. Aus „über neunzig Prozent nutzen es, und es bringt etwa zehn Prozent" wurde unterwegs „Faktor 93".

Ich finde das lehrreicher als jede Keynote. Es zeigt in einem einzigen Beispiel, wie in dieser Branche gerade Zahlen entstehen, und warum Geschäftsführer bei jeder Prozentangabe zur Produktivität misstrauisch sein sollten.

Der offizielle Nachbericht der Konferenz enthält übrigens gar keine Produktivitätsmultiplikatoren. Das Leitmotiv war ein anderes: Die Frage hat sich verschoben von „kann KI Software bauen" zu „wie bauen wir sie gut". Loredana Crisan, Chief Design Officer bei Figma, hat es auf der Bühne so formuliert: „AI can make something look finished in seconds. But finished-looking is not the same as good."

Was die Messungen tatsächlich hergeben

Die Spannbreite der seriösen Untersuchungen ist beachtlich, und sie erklärt, warum in dieser Debatte jeder eine Studie für seine Position findet.

• GitHub/Microsoft (Peng et al., 2023): 95 Entwickler im randomisierten Versuch, 55,8 % schneller mit Copilot. Konfidenzintervall 21 bis 89 %. Es ging um eine isolierte Aufgabe auf der grünen Wiese, einen HTTP-Server in JavaScript.
• Cui et al., Management Science 2025: drei Feldexperimente bei Microsoft, Accenture und einem Fortune-100-Unternehmen, 4.867 Entwickler. Ergebnis +26,08 % abgeschlossene Pull Requests pro Woche. Junior-Entwickler profitieren deutlich stärker als Senior-Entwickler.
• METR, Juli 2025: 16 erfahrene Open-Source-Entwickler, 246 Issues in ihren eigenen reifen Repositories. Ergebnis 19 % langsamer mit KI. Die Entwickler selbst schätzten hinterher, sie seien 20 % schneller gewesen.
• Google DORA 2024: 25 % mehr KI-Adoption gingen einher mit Throughput minus 1,5 % und Delivery Stability minus 7,2 %.
• Google DORA 2025: rund 5.000 Befragte, 90 % nutzen KI, im Median zwei Stunden täglich. Über 80 % berichten subjektiv einen Produktivitätsgewinn. 30 % haben wenig oder kein Vertrauen in den generierten Code. Die Throughput-Beziehung hat sich gegenüber 2024 ins Positive gedreht, die Instabilität bleibt negativ.

Der belastbarste Mittelwert stammt aus einer Auswertung des Stanford Software Engineering Productivity Research über knapp 100.000 Entwickler: netto nach Abzug von Nacharbeit 15 bis 20 %. Aufgeschlüsselt ergibt sich das entscheidende Bild: 30 bis 40 % bei Neuentwicklung mit geringer Komplexität, nur 5 bis 10 % im komplexen Bestandssystem.

Zwei Einordnungen dazu. Die Stanford-Zahlen stammen aus einem Konferenzvortrag, nicht aus einem begutachteten Paper. Und METR selbst warnt davor, aus 16 Personen abzuleiten, KI mache Entwickler generell langsamer.

Die Kernaussage von DORA halte ich für die brauchbarste von allen: KI ist ein Verstärker. Sie repariert kein Team. Sie vergrößert, was schon da ist.

Warum das trotzdem die Führungsetage angeht

Jetzt kommt der Punkt, an dem die meisten Diskussionen falsch abbiegen. Aus „nur 15 bis 20 Prozent" wird der Schluss gezogen, es sei halb so wild.

Das ist ein Denkfehler. Die entscheidende Frage lautet nicht, wie viel schneller Ihre Entwickler werden. Sie lautet, was mit einem Geschäftsmodell passiert, dessen Preis sich am Aufwand für Code orientiert, wenn dieser Aufwand dauerhaft sinkt. Auch 15 % pro Jahr sind über fünf Jahre eine Halbierung.

Genau hier sehe ich den blinden Fleck. KI wird als Werkzeug für die Entwicklungsabteilung behandelt, als Effizienzthema, das man delegiert. Übersehen wird, dass sich die Wertschöpfungskette darunter neu sortiert. Ich habe das für die Ebene einzelner Tätigkeiten in einem eigenen Beitrag durchdekliniert, was übrig bleibt, wenn Software die Bildschirmarbeit übernimmt. Was dort für Berufe gilt, gilt eine Etage höher für Geschäftsmodelle, nur langsamer sichtbar und mit größeren Beträgen.

Und deshalb ist es für Unternehmen an dieser Stelle später als für die einzelnen Entwickler. Ein Entwickler passt sich in Monaten an. Ein Geschäftsmodell braucht Jahre.

Erstens: Die Rechnung des Body-Leasings geht nicht mehr auf

Das Fundament von Offshoring und Nearshoring war jahrzehntelang stabil und simpel. Günstige Arbeitskräfte glichen die Reibungsverluste aus, die durch Distanz, Zeitzone, Sprache und lückenhafte Anforderungsanalyse entstehen. Solange die Stundensätze weit genug auseinanderlagen, blieb ein Vorteil.

Die aussagekräftigste Kennzahl dazu ist nicht das Marktvolumen. Es ist die Entkopplung von Umsatz und Kopfzahl.

Laut NASSCOM Strategic Review 2026 wächst die indische Tech-Industrie im Geschäftsjahr 2026 auf 315 Mrd. USD, ein Plus von 6,1 %. Der Netto-Stellenaufbau liegt bei rund 135.000 auf knapp 5,95 Mio. Beschäftigte, also bei 2,3 %. Bei TCS ist die Kopfzahl im Geschäftsjahr 2026 sogar um 23.460 Personen gesunken, von 607.979 auf 584.519. Angekündigt worden war im Juli 2025 ein Abbau von rund 12.000 Stellen, überwiegend im mittleren und oberen Management. Es wurde fast das Doppelte.

Bemerkenswert finde ich die offene Sprache der Anbieter selbst. C. Vijayakumar, CEO von HCLTech, beziffert den Umsatzdruck durch KI-bedingte Preissenkungen auf 3 bis 5 % im kommenden Jahr, „and perhaps further". Sein Kollege bei TCS nennt es „degrowth". Auch Infosys erwartet Deflation als künftigen Faktor.

Klassische Outsourcing-Verträge werden nach Köpfen und Zeit bepreist. Bricht die Kopplung zwischen Umsatz und Köpfen, bricht die Preissetzungsmacht. Für Anbieter, deren gesamtes Modell auf der Vermittlung günstiger Kapazität beruht, ist das existenziell.

Eine These, die ich nicht belegen kann: In Gesprächen höre ich zunehmend von Rückverlagerungen, weil die Neuentwicklung im eigenen Haus schneller fertig ist als die Korrektur des billig produzierten Bestands. Belastbare Zahlen zu Reshoring von IT-Projekten habe ich trotz Suche keine gefunden. Alles Verfügbare zu Rückverlagerung betrifft das produzierende Gewerbe. Ich führe das deshalb als Beobachtung, nicht als Beleg.

Zweitens: Das Lizenzmodell für Komponenten steht unter Druck

Anbieter von UI-Komponenten, Grid-Controls und Reporting-Werkzeugen waren lange die Schaufelverkäufer der Branche. Solides Geschäft, wiederkehrende Einnahmen, hohe Bindung.

Die Frage, die dieses Geschäft angreift, ist unangenehm einfach. Warum eine vierstellige Jahreslizenz für eine Reporting-Komponente zahlen, wenn dieselbe Funktionalität in einer knappen Stunde in eigenem HTML, CSS und JavaScript entsteht und danach im eigenen Repository liegt?

Bei den Zahlen muss ich Sie enttäuschen, und dieser Negativbefund ist selbst aufschlussreich. Progress Software, der Mutterkonzern von Telerik und Kendo UI, berichtet ein einziges Segment. Es gibt keine separate Umsatzzahl für das Komponentengeschäft. Sichtbar ist nur das Gesamtbild aus dem Geschäftsjahr 2025: Umsatz 977,8 Mio. USD mit rund 30 % Wachstum, das allerdings von der ShareFile-Übernahme getragen wird. Der wiederkehrende Umsatz wuchs um 2 %. Alle übrigen Anbieter sind privat und veröffentlichen nichts.

Auch die These „KI-generierte Oberflächen verdrängen bezahlte Komponenten-Suiten" lässt sich derzeit nicht quantitativ belegen. Die großen Entwicklerumfragen tracken diese Produkte gar nicht, weil ihre Kundschaft im .NET- und Enterprise-Umfeld sitzt und die Umfragen die React-Welt abbilden.

Was man dagegen gut beobachten kann, ist das Verhalten der Anbieter. Und das ist deutlich. Telerik hat im Mai 2025 KI-Coding-Assistenten samt MCP-Server veröffentlicht, inzwischen ergänzt um einen Generator, der aus einem Prompt komplette Seitenlayouts erzeugt. Nutzbar nur mit gültiger Lizenzdatei. DevExpress hat im Oktober 2025 einen Dokumentations-MCP-Server mit über 300.000 Hilfethemen veröffentlicht, kostenlos.

Das sind zwei gegensätzliche Wetten auf dieselbe Frage: Ist KI-Kontext ein Produkt oder ein Marketinginstrument? Beide Häuser haben verstanden, dass der Zugang zum Modell die neue Verteidigungslinie ist. Im November 2025 hat außerdem AG Grid mehrheitlich den Eigentümer gewechselt. Die Branche konsolidiert.

Drittens: Kunden bauen sich ihre Software selbst

Über den Begriff Vibe Coding habe ich an anderer Stelle ausführlicher geschrieben. Kurz: Software entsteht durch jemanden, der die darunterliegende Technik nicht kennt und auch nicht kennen will.

Für Dienstleister liegt hier die unmittelbarste Gefahr. Der Fachbereich löst sein spezifisches Problem selbst, statt eine Standardlösung zu kaufen, die zu 70 % passt.

Und jetzt der Teil, der in meiner Branche am ungernsten gehört wird: Das Argument, KI erzeuge grundsätzlich unwartbaren Spaghetti-Code, ist zur Schutzbehauptung geworden. Die Daten zeigen etwas Präziseres und Unangenehmeres.

Apiiro hat 2025 ausgewertet, wie sich die Art der Fehler verschiebt. Syntaxfehler gehen um 76 % zurück, Logikfehler um 60 %. Gleichzeitig steigen Privilege-Escalation-Pfade um 322 % und architektonische Designfehler um 153 %. Bis Juni 2025 kamen über 10.000 neue Security-Findings pro Monat dazu.

Das ist der Kern in einem Satz: KI beseitigt die billigen Fehler und vermehrt die teuren.

Dazu passen die übrigen Befunde. Veracode hat im Sommer 2025 über 100 Modelle an 80 Coding-Aufgaben getestet: 45 % des generierten Codes enthielten bekannte Sicherheitslücken, bei Java sogar 72 %. Im Frühjahr 2026 wurde der Test mit über 150 Modellen wiederholt. Das Ergebnis war praktisch unverändert. Veracode formuliert das trocken: Zwei Jahre revolutionärer Modell-Releases haben die Sicherheitsnadel von etwa 55 % auf etwa 55 % bewegt.

GitClear hat 211 Mio. geänderte Codezeilen zwischen 2020 und 2024 untersucht. Der Anteil verschobener, also refaktorierter Zeilen fiel von 25 % auf unter 10 %. Kopierte Zeilen stiegen von 8,3 % auf 12,3 %, der Code-Churn von 3,3 % auf 5,7 %. 2024 wurde erstmals mehr Code kopiert als aufgeräumt.

Und ein konkreter Fall zum Mitnehmen: CVE-2025-48757, CVSS 9.3. In mit Lovable erzeugten Anwendungen fehlte die Absicherung auf Datenbankebene. Über 170 Produktionsanwendungen mit vollständig zugänglichen Datenbanken wurden bestätigt, offengelegt waren Namen, Telefonnummern, API-Schlüssel und Zahlungsdaten.

Die selbstgebauten Systeme, die ich mir ansehe, sind architektonisch meist brauchbar. Wo sie brechen, ist woanders: bei Berechtigungen, bei Protokollierung, beim Verhalten unter Last und bei allem, was erst nach zwei Jahren Betrieb weh tut. Das sind keine Qualitätsprobleme im Code. Das sind Anforderungen, an die niemand gedacht hat.

Viertens: Der Wert wandert von der Produktion zur Verifikation

Damit sind wir beim Kern.

Reine Entwicklungskapazität ist kein Premium-Gut mehr. Wenn die Kosten für die Herstellung von Funktionalität fallen, verschiebt sich der Wertschöpfungskern an die Stelle, die nicht mitfällt. Und das ist die Prüfung.

Die Veracode-Zeitreihe belegt das direkt: Die Produktion wird schneller, die Fehlerquote bleibt konstant. Damit wächst die zu prüfende Menge, während das Prüfen dieselbe Zeit braucht. Genau das ist der neue Engpass.

Jemand muss garantieren, dass ein System in der echten Welt tut, was es soll, dass es keine Daten preisgibt und dass die Haftung im Schadensfall geklärt ist. Diese Garantie ist die neue Premium-Leistung, und sie hängt an einer Person mit Namen, Berufshaftpflicht und Ruf. Haftung skaliert nicht mit der Technik.

Für Dienstleister folgt daraus eine unbequeme Umstellung. Wer heute mit zwanzig Leuten zwei große Projekte pro Jahr macht, wird mit denselben zwanzig Leuten zehn Projekte betreuen. Kleinere Volumina, mehr Kunden, mehr Parallelität, mehr Übergaben. Das ist eine andere Firma. Vertrieb, Projektsteuerung, Preismodell und Personalstruktur müssen mitziehen.

Der härteste Brocken dabei ist das Preismodell. Ein Stundensatz bestraft jeden, der schneller wird. Wer den Wert seiner Arbeit auf Verifikation und Verantwortung verlagert, muss auch anders abrechnen: nach Ergebnis, nach Betriebsverantwortung, als monatliches Paket. Wir haben unser eigenes Modell aus genau diesem Grund umgestellt, hin zur laufenden Partnerschaft.

Fünftens: Für die Inhouse-IT gibt es einen dritten Weg

Inhouse-Abteilungen stehen vor einer neuen Welle an Schatten-IT. Der Fachbereich baut sich Werkzeuge, die IT erfährt davon beim ersten Vorfall. Das übliche Reflexverhalten ist ein Verbot, und das übliche Ergebnis eines Verbots ist, dass dieselben Werkzeuge unsichtbar weitergebaut werden.

Wie teuer das wird, zeigt der IBM Cost of a Data Breach Report 2025. 20 % der Organisationen hatten Sicherheitsvorfälle mit Bezug zu ungenehmigter KI-Nutzung. Solche Vorfälle kosteten im Schnitt 4,63 Mio. USD. 97 % der betroffenen Organisationen hatten keine ausreichenden Zugriffskontrollen, 63 % überhaupt keine KI-Governance-Richtlinie.

Der Vollständigkeit halber: Diese Zahlen betreffen ungenehmigte KI-Nutzung, nicht selbstgebaute Fachbereichs-Anwendungen im engeren Sinn. Die Mechanik ist dieselbe, die Quelle sagt zum zweiten Fall nichts.

Der praktikable dritte Weg sieht so aus, dass die IT den Rahmen liefert und den Rest freigibt.

• Die IT baut das Fundament. Stabile Schnittstellen, saubere Authentifizierung, Rechte- und Rollenmodell, Protokollierung, freigegebene Datenquellen. Alles, was Sicherheit und Nachvollziehbarkeit betrifft.
• Der Fachbereich baut die Oberflächen. Innerhalb dieses Rahmens, mit KI-Unterstützung, ohne Ticket und ohne Wartezeit.

Der Trick daran: Schauen Sie noch einmal auf die Apiiro-Zahlen. Die Fehlerarten, die durch KI zunehmen, sind Berechtigungs- und Architekturfehler. Genau die hängen am Fundament. Wer die Schnittstelle kontrolliert, kontrolliert die Governance, auch ohne die Oberfläche gebaut zu haben.

Voraussetzung ist eine schriftliche Regel darüber, welche Datenkategorien überhaupt in eine selbstgebaute Oberfläche dürfen. Diese Regel gehört fixiert, bevor die erste Anwendung entsteht.

Vier Fragen für die nächste Geschäftsführungssitzung

Ich halte wenig von Aufrufen zum radikalen Umdenken ohne konkreten nächsten Schritt. Deshalb vier Fragen, die in zwei Stunden zu beantworten sind.

1. Welcher Anteil unseres Umsatzes hängt daran, dass die Herstellung von Funktionalität teuer ist? Das ist die Zahl, die das Risiko beziffert. Alles andere ist Meinung.
2. Was verkaufen wir, wenn die Produktion nichts mehr kostet? Die belastbaren Antworten kreisen um Verantwortung, Betrieb, Integration und Branchenwissen.
3. Welches Preismodell bestraft uns dafür, schneller zu werden? Jede Position, die nach Aufwand abgerechnet wird, gehört auf den Prüfstand.
4. Wo baut unser Fachbereich schon heimlich Software? Diese Frage ehrlich beantwortet ist eine bessere Bestandsaufnahme als jedes Audit.

Zum Schluss, mit Maß

Ich halte nichts von der Ansage, dass die Hälfte der Branche in zwei Jahren weg sein wird. Solche Prognosen sind seit Jahrzehnten falsch und werden trotzdem gern wiederholt, weil sie Aufmerksamkeit erzeugen.

Belastbar ist etwas Nüchterneres. Der Preis für die Herstellung von Software fällt dauerhaft, auch wenn er langsamer fällt als die Faktor-Behauptungen nahelegen. Geschäftsmodelle, die genau diesen Preis in Rechnung stellen, verlieren damit ihre Grundlage. Und Anpassungen auf Geschäftsmodellebene brauchen zwei bis vier Jahre. Der Zeitpunkt zum Anfangen liegt deshalb weit vor dem Zeitpunkt, an dem der Druck spürbar wird.

Eines ist mir an der Recherche zu diesem Beitrag besonders aufgefallen. Zu den drei Thesen, die ich für die wichtigsten halte, gibt es kaum belastbare Zahlen. Rückverlagerung von IT-Projekten, Verdrängung der Komponenten-Anbieter, Ausmaß der selbstgebauten Fachbereichs-Software. Bei 15.000 Fachleuten an einem Ort und einer Branche, die von Messbarkeit lebt, ist das erstaunlich. Wer auf gesicherte Erkenntnis wartet, wartet auf etwas, das erst entsteht, während andere Erfahrung sammeln.

Die Frage, die ich Geschäftsführern derzeit stelle, lautet: Wird Ihr Geschäftsmodell in achtzehn Monaten in seinen Grundzügen dasselbe sein? Ein schnelles Ja ist meistens ein Zeichen dafür, dass die Frage noch nicht durchgerechnet wurde. Den Einstieg dazu finden Sie über meine Angebote.