Make-or-Buy: Die Rechnung ändert sich

Make wird schneller und günstiger#

Coding Agents verändern die Rechnung für individuelle Software. Ein kleines Team kann heute schneller und günstiger zu einer passenden Lösung kommen als noch vor zwei Jahren. Agentic Make ist damit nicht automatisch besser als Buy, aber deutlich häufiger eine wirtschaftlich realistische Option.

Softwareanbieter nutzen allerdings dieselben Modelle und Tools. Ihr Vorteil liegt nicht allein in der Entwicklung, sondern in der Skalierung: Security, Regulierung, Wartung und Betrieb verteilen sich auf viele Kunden. Wenn Standardsoftware ohne größere Anpassungen eingesetzt werden kann, bleibt Buy deshalb schwer zu schlagen.

Wie ernst Investoren die Verschiebung nehmen, zeigte sich Anfang Februar 2026. Kurz zuvor hatte Anthropic agentische Werkzeuge veröffentlicht, die ganze Arbeitsschritte in Rechts-, Vertriebs- und Analyseprozessen übernehmen. Reuters nannte diese Entwicklung als wichtigen Auslöser für den folgenden Abverkauf; betroffen waren unter anderem Salesforce, ServiceNow sowie Daten- und IT-Dienstleister. Die Kurse beweisen keine neue Make-or-Buy-Ökonomie. Sie zeigen, dass der Markt sie bereits einpreist.[1][2][3]

Coding-Tempo ist noch keine kürzere Time-to-Market#

Coding Agents verkürzen die Implementierung. Time-to-Market umfasst aber auch fachliche Klärung, Integration, Security, Tests und Release. Wenn diese Schritte unverändert bleiben, erreicht auch eine schneller entwickelte Lösung ihre Nutzer nicht früher.

Studien messen große Zeitgewinne vor allem bei klar abgegrenzten Coding-Aufgaben. Im Unternehmensalltag fällt der Effekt kleiner aus, weil bestehende Systeme, Abstimmung und Qualitätssicherung hinzukommen. Für Make-or-Buy zählt deshalb nicht, wie viel Code ein Team erzeugt. Entscheidend sind Zeit und Kosten von der Idee bis zur produktiven Änderung.

Buy wirkt im Auswahlprozess oft konkreter: Anbieter können ein fertiges Produkt zeigen. Für Make gibt es zu diesem Zeitpunkt meist nur eine Kostenschätzung. Coding Agents verringern diesen Vorsprung, weil ein Agentic-Make-Prototyp früh denselben Use Case mit denselben Daten und Anforderungen abbilden kann. So vergleicht das Unternehmen zwei Lösungen statt eines Produkts mit einer Präsentation.[4]

Time-to-Market folgt dem langsamsten Feedback Loop#

Sobald die Implementierung schneller wird, fallen ungeklärte Requirements stärker ins Gewicht. Das Team wartet dann nicht auf Code, sondern auf Entscheidungen über Ausnahmen, Prioritäten und gewünschtes Verhalten. Coding Agents machen Requirements nicht weniger wichtig; offene Fragen bremsen nur früher.

AI kann vorhandenes Prozesswissen zusammenführen, Widersprüche markieren und einen ersten Spec-Entwurf erstellen. Agent Skills strukturieren offene Fragen, halten Fachbegriffe konsistent und überführen Entscheidungen in kleine, testbare Arbeitspakete. Ohne den Kontext zu Geschäftsziel, Stakeholdern und Sonderfällen bleibt das Ergebnis jedoch allgemein. Die Fachbereiche müssen weiterhin entscheiden, wie der Prozess funktionieren soll.

Das Open-Source-Projekt Agent Skills Toolbelt bündelt dafür Skills zu Requirements-Klärung, Debugging und Review.[5][6][7]

Validation muss mit dem Output skalieren#

Nach der fachlichen Klärung folgt der nächste Feedback Loop: Review. In einer Studie mit 802 Entwicklern verdoppelte sich die Zahl eingereichter Codeänderungen pro Kopf. Gleichzeitig verdoppelte sich ungefähr die Last pro Reviewer. Der Fall lässt sich nicht auf jedes Unternehmen übertragen, macht den Mechanismus aber sichtbar: Wenn Code schneller entsteht als Review skaliert, wird die gewonnene Zeit dort wieder verloren.

Automatisierte Tests und Reviews sind deshalb notwendig, aber nicht ausreichend. Wenn Code und Tests aus derselben unklaren Spezifikation entstehen, können beide denselben Fehler bestätigen. Geschäftskritische Logik braucht eine unabhängige Referenz, etwa bestätigte Fallbeispiele, regulatorische Vorgaben oder Produktionsdaten.

Nicht jede Änderung braucht dafür denselben Prozess. Eine neue Abrechnungsregel verlangt mehr Validation als eine reversible Änderung an einer internen Oberfläche. Mehr Code ist kein Ziel. Entscheidend sind Releases, die fachlich richtig sind und im Betrieb zuverlässig funktionieren.[9]

Eigenentwicklung heißt Produktverantwortung#

Auch mit Coding Agents bleibt Make mehr als ein einmaliges Projekt. Das Unternehmen übernimmt Produktentscheidungen, Wartung und Betrieb. Dafür kann es Workflows, Schnittstellen und den Umgang mit Daten ändern, ohne auf die Roadmap eines Anbieters zu warten.

Voraussetzung ist, dass das Unternehmen Code und Daten kontrolliert, Änderungen selbst deployen kann und den Betrieb beherrscht. Außerdem braucht es ein dauerhaft verantwortliches Produktteam. Wenn diese Gestaltungsfreiheit keinen messbaren Mehrwert schafft, gewinnt weiterhin der Skalenvorteil von Buy.[10]

Welche Vorhaben heute neu bewertet werden sollten#

Agentic Make macht Buy nicht grundsätzlich schlechter. Es verschiebt den Punkt, ab dem eigene Entwicklung wirtschaftlicher wird. Vorhaben zwischen dem bisherigen und dem neuen Make-or-Buy-Crossover sollten Unternehmen deshalb erneut bewerten.