Programmierung und Softwareentwicklung

Programmieragenten erleichtern das Bauen, doch Teams, die bei null anfangen, fehlt 3,5-mal häufiger eine Strategie

Eine Analyse auf Grundlage einer Umfrage unter 379 Fachleuten für Platform Engineering stellt fest, dass Teams, die auf Eigenentwicklung von Grund auf setzen, häufiger über das Fehlen einer klaren Strategie berichten und weniger Plattformziele erreichen. Mit der Beschleunigung der Entwicklung von KI-Tools wird die Governance dessen, was gebaut und gewartet wird, wichtiger als die Geschwindigkeit seiner Erstellung.

2026-10-12
4 Min. Lesezeit
11 Aufrufe
certi.news Editorial Team
Programmieragenten erleichtern das Bauen, doch Teams, die bei null anfangen, fehlt 3,5-mal häufiger eine Strategie

Die Erstellung eines internen Tools mithilfe von Programmieragenten ist deutlich schneller geworden. Die Daten des Berichts Future of Platform Engineering 2026 zeigen jedoch, dass die einfache Umsetzung nicht zwangsläufig mit einer klaren Vision einhergeht. Von den 379 Fachleuten für Platform Engineering gaben Teams, die bei den meisten ihrer Funktionen auf Eigenentwicklung von Grund auf setzen, etwa 3,5-mal häufiger an, dass das Fehlen einer klaren Strategie ein Hindernis für sie darstellt.

Dieses Ergebnis belegt nicht, dass Eigenentwicklung von Grund auf eine falsche Entscheidung ist. Es zeigt jedoch einen Zusammenhang zwischen der Art und Weise, wie Plattformfähigkeiten bereitgestellt werden, und dem Grad der Klarheit der Richtung, an der sich die Teams orientieren.

Fertige Tools sind die häufigste Option

51,3 % der Befragten gaben an, dass die Nutzung eines fertigen Basistools ihr wichtigster Ansatz zur Unterstützung von Plattformfunktionen ist. 31,2 % setzen auf vorhandene Vorlagen und 17,5 % entwickeln von Grund auf. Bei als leistungsstark eingestuften Teams war die Abhängigkeit von Tools mit 58,8 % höher, verglichen mit 47,8 % bei Vorlagen und 33,3 % bei Eigenentwicklung von Grund auf.

Ausnahmen zeigen sich in Umgebungen, die unmittelbar mit einem bestimmten technischen Pfad verbunden sind, etwa lokalen Entwicklungsumgebungen, Projekten, die mit einem Klick erstellt werden, und temporären Umgebungen. In diesen Fällen können Vorlagen eine Übereinstimmung mit den etablierten Pfaden bieten, die allgemeine Tools nicht ohne Weiteres gewährleisten.

Temporäre Umgebungen sind ein Indikator für die Reife der Plattform

Teams, die temporäre Umgebungen bereitstellen, berichteten häufiger von einer positiven Wirkung der künstlichen Intelligenz auf die Geschwindigkeit und Stabilität der Softwarebereitstellung sowie auf die Codeabdeckung und die Kostenkontrolle. Unter den Teams, die die Wirkung als äußerst positiv beschrieben, nutzten mehr als drei Viertel temporäre Umgebungen.

Dieser Zusammenhang bedeutet jedoch nicht zwangsläufig, dass die temporäre Umgebung allein die Verbesserung verursacht hat. Teams, die solche Umgebungen bereitstellen, arbeiten häufig innerhalb umfassenderer Plattformen mit mehreren automatisierten Fähigkeiten. Dadurch könnten der Umfang und die Reife der Plattform wichtigere Faktoren dafür sein, das Volumen der von der künstlichen Intelligenz erzeugten Änderungen zu bewältigen, ohne die Stabilität zu beeinträchtigen.

Warum ist diese Nachricht wichtig?

Die wichtigste praktische Veränderung besteht darin, dass künstliche Intelligenz die Kosten des Schreibens von Code senkt, aber nicht die Kosten seines Besitzes beseitigt. Ein Tool, das schnell entwickelt wird, benötigt Wartung, Upgrades und Governance und kann mit zunehmendem Änderungsvolumen im Entwicklungsprozess den Betriebsaufwand erhöhen.

Die Daten stützen diese Unterscheidung: 57,9 % der Teams, bei denen Eigenentwicklung von Grund auf überwog, bezeichneten das Fehlen einer klaren Strategie als Hindernis, verglichen mit 15,6 % der Teams, die auf Vorlagen setzen, und 16,7 % der Teams, die Basistools verwenden. Außerdem nutzten Teams mit Eigenentwicklung von Grund auf künstliche Intelligenz häufiger zur Modernisierung veralteter Systeme und zur Migration von Programmiersprachen. Dies deutet darauf hin, dass ein Teil dieser Nutzung in die Wartung von Komplexität fließt, die die Teams selbst geschaffen haben.

Die Frage lautet nicht nur: selbst entwickeln oder kaufen?

Die Kosten-Nutzen-Analyse war mit 29,6 % der häufigste Grund für Entscheidungen zwischen Eigenentwicklung und Kauf. Es folgten die Präferenz für Open Source mit 28,6 %, die Bewertung von Eignung und Anforderungen mit 22,4 %, die Präferenz für kommerzielle Tools mit 22,4 % sowie die Entwicklung zur Erzielung eines wesentlichen Wettbewerbsvorteils mit 16,3 %.

Der Beitrag stellt zwei mögliche Erklärungen vor, zwischen denen die Daten nicht entscheiden können: Möglicherweise geht die Strategie der Entscheidung zwischen Eigenentwicklung und Kauf voraus; möglicherweise wird die Eigenentwicklung selbst zu einem vorübergehenden Ersatz für eine Strategie, die sich noch nicht herausgebildet hat. Die klarste redaktionelle Schlussfolgerung lautet jedoch, dass das Problem nicht in der Eigenentwicklung von Grund auf liegt, sondern darin, sie standardmäßig und ohne konkreten Grund einzusetzen. Einzigartige Fähigkeiten sollten rund um den Kontext des Unternehmens entwickelt werden, während Tools, die standardisierte Probleme effizient lösen, gekauft oder übernommen werden sollten – unter Einbeziehung der Wartungskosten und der langfristigen Abhängigkeit.

Nachrichtenquelle
The New Stack - Software Development
Originalquelle öffnen ↗
c
Autor

certi.news Editorial Team

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen