Es gibt eine Zahl, über die in der Branche erstaunlich wenig gesprochen wird: die Kosten, ein Feature zu bauen. Nicht die Kosten für Infrastruktur, nicht die Lizenzgebühren, nicht die Betriebskosten – sondern die reinen Produktionskosten. Mensch sitzt vor Bildschirm, denkt nach, tippt, testet, deployt.
Diese Kosten fallen gerade ins Bodenlose.
Was vor zwei Jahren einen Entwickler drei Tage gekostet hat, dauert heute einen Nachmittag. Was ein Team eine Woche beschäftigt hat, erledigt ein einzelner Entwickler mit AI-Unterstützung in zwei Tagen. Und das ist erst der Anfang. Die Werkzeuge werden besser, schneller, kontextbewusster. In drei Jahren werden die Produktionskosten für Software so niedrig sein, dass sie als Kostenfaktor praktisch irrelevant werden.
Das klingt nach einer guten Nachricht. Ist es auch – auf den ersten Blick.
Wenn alles billig ist, ist nichts mehr besonders
Es gibt ein Muster, das sich durch jede Branche zieht, in der die Produktionskosten dramatisch gefallen sind. Musik. Fotografie. Text. Video. Überall dasselbe: Wenn die Herstellung nichts mehr kostet, explodiert die Menge. Und wenn die Menge explodiert, wird es fast unmöglich, das Gute vom Mittelmäßigen zu unterscheiden.
Software steht am Anfang genau dieser Entwicklung.
Wenn jedes Startup in einem Wochenende einen funktionierenden Prototyp bauen kann. Wenn jede Fachabteilung sich ihre internen Tools zusammenprompen lässt. Wenn der Freelancer für fünfhundert Euro eine App liefert, die vor drei Jahren fünfzigtausend gekostet hätte. Dann entsteht nicht weniger Software. Es entsteht mehr. Viel mehr. Und der größte Teil davon wird mittelmäßig sein.
Nicht technisch mittelmäßig – der Code wird funktionieren, die Tests werden grün sein, die App wird starten. Mittelmäßig in dem Sinne, dass sie das falsche Problem löst. Oder das richtige Problem auf die falsche Art. Oder ein Problem, das niemand hat.
Denn die Produktionskosten sinken. Aber die Kosten, das Richtige zu bauen, bleiben gleich. Und in einer Welt voller billiger Software werden genau diese Kosten zum entscheidenden Faktor.
Die eigentlichen Kosten waren nie der Code
Das ist etwas, das die Branche ungern hört: Der Code war nie der teure Teil.
Ja, Entwickler sind teuer. Ja, Projekte kosten Millionen. Aber wenn man ehrlich aufschlüsselt, wofür das Geld tatsächlich draufgeht, dann ist es selten die reine Implementierung. Es ist alles drumherum. Es ist das halbe Jahr, in dem ein Team das falsche Feature baut, weil die Anforderung falsch verstanden wurde. Es sind die drei Monate Verzögerung, weil die Architekturentscheidung im zweiten Sprint eine Sackgasse erzeugt hat, die im achten Sprint auffliegt. Es ist der Rewrite nach achtzehn Monaten, weil niemand früh genug gefragt hat, ob die gewählte Technologie mit den Compliance-Anforderungen kompatibel ist.
Diese Kosten – die Kosten für falsche Richtung, für fehlenden Kontext, für Entscheidungen, die niemand hinterfragt hat – werden durch AI nicht billiger. Sie werden teurer. Weil die Geschwindigkeit steigt.
Wenn ein Team in der alten Welt drei Monate brauchte, um ein Feature zu bauen, dann hatte es drei Monate, um zu merken, dass es das Falsche baut. In einer AI-gestützten Welt steht das Feature nach einer Woche. Und wenn es das Falsche ist, stehen in einem Monat vier falsche Features in Produktion statt einem.
Was passiert, wenn jeder bauen kann
Man sieht die ersten Ausläufer schon. Fachabteilungen, die sich mit No-Code-Tools und AI eigene Lösungen bauen, ohne die IT einzubeziehen. Startups, die in Wochen ein Produkt auf den Markt werfen, das technisch funktioniert, aber an keiner Stelle durchdacht ist. Interne Projekte, die mit AI in Rekordzeit geliefert und in Rekordzeit wieder eingestampft werden, weil sie nicht in die bestehende Systemlandschaft passen.
Das ist kein AI-Problem. Es ist ein Urteilsproblem, das durch AI beschleunigt wird.
In einer Welt, in der die Produktion kein Nadelöhr mehr ist, verschiebt sich die Verantwortung. Weg von „Können wir das bauen?“ – die Antwort ist fast immer ja – hin zu „Sollten wir das bauen?“ Und diese Frage erfordert Wissen, das in keinem Prompt steckt. Regulatorik, bestehende Architektur, organisatorische Abhängigkeiten, Wartbarkeit. Alles Dinge, die kein AI-Tool von allein mitdenkt.
Das Preisparadox
Für alle, die in der Branche ihr Geld verdienen – Studios, Freelancer, Beratungshäuser – entsteht ein Paradox, das nicht einfach aufzulösen ist.
Die Kunden werden sehen, dass Software schneller und einfacher zu produzieren ist. Und sie werden erwarten, dass sie weniger kostet. Das ist menschlich, das ist logisch, und das ist auch nicht falsch. Ein Feature, das einen Tag statt einer Woche dauert, sollte nicht dasselbe kosten.
Aber gleichzeitig wird die Arbeit, die tatsächlich Wert schafft – die Analyse, die Architekturentscheidung, die strategische Richtung, die Domänenexpertise – nicht billiger. Sie wird wertvoller. Weil sie der einzige Faktor ist, der den Unterschied zwischen einem Produkt und einem weiteren Tool ausmacht, das niemand braucht.
Das Ergebnis: Die Branche muss lernen, Code und Urteil zu trennen – und beides unterschiedlich zu bepreisen.
Wer weiterhin Stunden verkauft, wird verlieren. Weil die Stunden weniger werden, aber der Preis pro Stunde nicht proportional steigen kann – kein Kunde zahlt tausend Euro die Stunde, egal wie gut du bist. Wer hingegen Ergebnisse verkauft, kann von der Verbilligung profitieren: weniger Aufwand für die Produktion, gleicher Wert für den Kunden, bessere Marge.
Das klingt in der Theorie elegant. In der Praxis bedeutet es, dass die gesamte Branche ihr Pricing-Modell umbauen muss. Und das wird dauern, wehtun und für viele nicht gut ausgehen.
Was bleibt, wenn der Code nichts mehr kostet
Bisher war es ein Vorteil, schnell Software bauen zu können. Gute Entwickler, effiziente Prozesse, moderne Toolchains. In drei Jahren wird das keiner mehr sein. Jeder wird schnell bauen können.
Was bleibt als Differenzierung, ist nicht Geschwindigkeit und nicht Technologie. Sondern das Verständnis dafür, was gebaut werden muss – und die Disziplin, alles andere zu lassen.
Unternehmen, die das verstehen, werden weniger bauen und öfter treffen. Sie werden nicht das zehnte Feature im Backlog implementieren, nur weil es jetzt billig genug ist. Sie werden fragen, ob es das richtige ist. Und sie werden Leute einstellen – oder beauftragen – die diese Frage beantworten können.
Die, die in einem Meeting den Satz sagen: „Das können wir bauen. Aber wir sollten es nicht. Und hier ist warum.“
Der ehrlichste Satz
Die Frage für die nächsten Jahre ist nicht, wer am schnellsten baut. Es ist, wer am klarsten denkt.
Wenn alles billig zu bauen ist, wird das Teuerste die Entscheidung sein, was man nicht baut.