Wenn KI von Anfang an existierte: Billigerer Code macht die Entscheidung, was zu bauen ist, nicht einfacher

Für den größten Teil der Geschichte der Software war der teure Teil das Bauen. Teams verbrachten Monate damit, Ideen in funktionierenden Code umzusetzen, und diese Knappheit prägte alles, wie die Arbeit organisiert wurde.

Roadmaps wurden sequenziert, um die verfügbare Engineering-Kapazität zu berücksichtigen; Architekten verdienten ihren Platz am Tisch, weil sie Systeme verstanden, die niemand anders verstand; Product-Manager verbrachten ihre Wochen damit, vage Geschäftsanfragen in etwas umzusetzen, das ein Entwickler ausführen konnte. Die Erstellung von Software war der Flaschenhals, und natürlich lag der Hebel dort, wo die Erstellung stattfand.

Dies ist nicht mehr wahr, und der Wandel erfolgte schneller, als die meisten Engineering-Führer Zeit hatten, ihn zu verarbeiten.

AI-Coding-Tools haben die Kosten für die Implementierung gesenkt. So kann Arbeit, die ein Team von Ingenieuren Wochen gekostet hat, jetzt von einem Agenten in ein paar Stunden erledigt werden. Und die offensichtliche Annahme war, dass schnelleres Bauen direkt in schnelleren Wert übersetzt würde.

Was jedoch tatsächlich passiert ist, ist komplizierter: Teams können jetzt mehr Software produzieren, als sie wissen, was sie damit anfangen sollen, und das, was sie verlangsamt, hat sich stillschweigend an einen anderen Ort verlagert.

“Man kann AI nicht auf einen kaputten Prozess anwenden”, sagte Pablo Gamba, Leiter der Technologie Americas bei dem globalen Software- und AI-Lösungs-Startup intive. “Es ist, als ob man einem Arbeiter eine schnellere Schaufel gibt. Er wird schneller arbeiten, aber nur in die falsche Richtung.”

Schnellere Ausführung, gleiche alte Einschränkung

Jede große Wendung in der Technologie – das Internet, die Cloud und die Auslagerung – hat eine identische Form verfolgt. Etwas, das früher teuer war, wurde fast über Nacht billig, und alles, was ein Unternehmen auf der Annahme dieser Kosten aufgebaut hatte, musste abgerissen und neu aufgebaut werden.

Dieses Mal ist es die angewandte technische Intelligenz selbst, die billig wird, was zufällig genau das ist, wofür Dienstleistungsunternehmen und Engineering-Teams jahrzehntelang berechnet haben, behauptet Gamba.

Billigere Ausführung macht die Einschränkung nicht verschwinden, sondern verlagert sie nur an einen weniger sichtbaren Ort. Der Codier-Flaschenhals zum Beispiel, der bei der Migration stromaufwärts beschleunigt wurde, hat die Implementierung beschleunigt, aber das Hindernis liegt jetzt in der Code-Überprüfung. Automatisiert man die Code-Überprüfung, zeigt es sich in Tests und Bereitstellung; automatisiert man auch dies, landet es schließlich bei den Menschen, die die Spezifikationen schreiben, die die Agenten ausführen.

Weil ein Agent nur bauen kann, was genau genug beschrieben ist, um ohne Raten auszuführen.

Das ist die Falle, in die viele Teams jetzt geraten, oft ohne es zu bemerken. Wenn man fast alles in einem Bruchteil der Zeit bauen kann, die es früher gekostet hat, steigt der Kosten des Bauens des falschen Dings, nicht sinkt, weil man schneller und mit mehr bereits geliefertem Code herausfindet, dass man falsch lag.

Eine Annahme, die früher langsam an die Oberfläche kam, über Wochen manuellen Codierens, kann jetzt zu tragfähiger Infrastruktur werden, bevor jemand daran denkt, sie in Frage zu stellen. Priorisierung, nicht rohe Ausgabe, entscheidet letztendlich, ob die AI-Investition sich selbst bezahlt macht.

In diesem Paradigma glaubt Gamba, dass Unternehmen nicht die Entwicklungsgeschwindigkeit verfolgen sollten, sondern den gesamten Zyklus von der Absicht bis zur Produktion. “Wenn man die Entwicklungsgeschwindigkeit verbessert, aber die QA der Flaschenhals ist, hat man nur die QA schneller erreicht. Dann behebt man die QA und der Flaschenhals verlagert sich auf die Anforderungen”, sagte er.

Die Zahlen bestätigen ihn auch. Fortune-50-Unternehmen, die AI-gestützte Entwicklung verwenden, liefern Commits 3-4 Mal schneller als ihre Peers, laut Forschung der Cloud Security Alliance, aber sie führen neue Sicherheitsfeststellungen bei etwa zehn Mal der Rate ein.

Geschwindigkeit ohne ein klares Ziel, in diesem Sinne, verschwendet nicht nur Anstrengung; sie potenziert das Risiko schneller, als die meisten Sicherheitsteams es bewältigen können.

Anforderungen in eine Sprache übersetzen, die AI tatsächlich nutzen kann

Wenn die Definition der Ort ist, an dem die eigentliche Einschränkung jetzt sitzt, ist die Lösung nicht mehr Dokumentation. Es ist andere Dokumentation, die in einer Form geschrieben ist, die ein AI-System ausführen kann, ohne Lücken selbst zu füllen.

Das bedeutet, die Anforderungsdokumentation, die für einen Menschen geschrieben wurde, um mit Urteilsvermögen zu interpretieren, durch strukturierte Akzeptanzkriterien, explizite Domänenmodelle und Vertragsprüfungen zu ersetzen, die ausdrücken, was eine Funktion nie tun sollte, so klar wie das, was sie tun sollte.

Agenten füllen Ambiguität auf die gleiche Weise aus, wie ein junger Ingenieur es tun könnte, mit einer selbstsicheren Vermutung. Der Unterschied liegt darin, dass die Vermutung des Letzteren in einer gewissen Unsicherheit verpackt ist, einer Flagge für einen erfahrenen Kollegen, einem Gefühl, dass etwas nicht stimmen könnte.

Die Vermutung eines Agenten sieht nichts dergleichen. Sie erscheint als sauberer, flüssiger, vollständig ausgebildeter Code, und es gibt keine Einschränkung darin, auch wenn sie falsch ist.

Das Schreiben einer Spezifikation, die präzise genug ist, um diese Lücke zu überleben, beginnt, sich weniger wie das Erstellen eines Produktbriefs und mehr wie das Erstellen eines Vertrags anzufühlen. Man benennt jeden Akteur, kartiert jeden Zustandsübergang, den das System ausführen darf, und berücksichtigt die Randfälle, anstatt sie stillschweigend dem glücklichen Pfad zu überlassen, wie es die meisten Anforderungsdokumente noch tun.

Teams, die dies als Dokumentationschore behandeln, lernen auf die harte Tour, dass vage Absicht nur vagen Code in Maschinengeschwindigkeit produziert.

Die Teams, die tatsächlich die Produktivitätsgewinne einfangen, sind diejenigen, die das Schreiben von Spezifikationen als eigene Ingenieursdisziplin behandeln, mit dem gleichen Versionskontrollsystem, Überprüfungszyklen und Testrigor, das früher für den Code selbst reserviert war.

In Gamba’s Worten ist AI-nativ nicht die Erlaubnis, den Prozess zu überspringen, sondern die Forderung, von Grund auf neu zu entwerfen. “Viele Organisationen versuchen, AI auf alte Prozesse anzuwenden. Das ist keine Transformation. AI-nativen Organisationen beginnen mit einer anderen Frage: Wenn AI von Anfang an existierte, wie würden wir diesen Prozess heute entwerfen?”

Backlog-Manager, Kuratoren der Absicht

Produkt, Architektur und Engineering liefen früher als drei separate Funktionen mit sauberen Übergaben zwischen ihnen: Produkt entscheidet, was zu bauen ist, Architektur entscheidet, wie, Engineering liefert es aus.

Wenn die Implementierung billig und schnell wird, werden diese Übergaben zum langsamsten Teil der gesamten Kette. Was hier zählt, ist, wer das gesamte Bild auf einmal halten kann, die Absicht in etwas übersetzen kann, das ein Agent ausführen kann, und eine falsche Annahme auffangen kann, bevor sie zu geliefertem Code wird, den niemand wollte.

Diese Neugestaltung formt stillschweigend um, wer die Definition macht und was die Arbeit überhaupt ist.

“Denken Sie daran, was mit der Rolle des Software-Ingenieurs passiert. Sie schreiben nicht mehr nur Code. Sie überwachen die Ausgabe von Agenten, definieren Spezifikationen, bereiten Tests vor, validieren Ergebnisse. Das ist das Verschmelzen dessen, was früher drei separate Rollen waren, in eine”, sagte Gamba.

Mit anderen Worten, was jetzt wertvoll ist, ist nicht das Wissen, wie man ein Ticket schreibt oder einen Sprint durchführt. Es ist das Wissen, wie “großartig” aussieht, bevor die Arbeit überhaupt beginnt, die Fähigkeit, den Unterschied zwischen dem, was intellektuell interessant ist und was Kunden tatsächlich benötigen, zu erkennen, und den Mut, eine Idee schnell zu töten, wenn sie offensichtlich nicht die Latte erreicht.

Das sind Urteilsentscheidungen, die früher auf einen Product-Manager, einen Architekten und einen Tech-Lead verteilt wurden, die ihre Notizen verglichen. Immer öfter landen sie bei dem, der am nächsten an der Definition der Arbeit ist.

Und es ist auch wichtig zu beachten: None von all dem macht die Titel verschwinden. Aber die Linien zwischen ihnen werden immer schwerer zu verteidigen, während die Menschen, die in diesem Nebel gedeihen, diejenigen sind, die als Kuratoren der Absicht handeln.

Schnelle Ausführung ohne Schutzmechanismen ist kein Sieg

Es gibt ein Risiko, das leicht zu übersehen ist, wenn die Absicht klar ist und die AI-Pipeline tatsächlich summt: Schnelle, gut definierte Ausführung kann immer noch Fehler einführen, die ein langsamerer, menschlich vermittelter Prozess fast zufällig erwischt hätte.

Die Zahlen hier sind nicht einmal nah dran. Veracodes Frühjahr-2026-Test bei führenden Modellen fand heraus, dass nur 55% der Code-Generierungsaufgaben sichere Ausgabe produzierten, wenn keine explizite Sicherheitsanleitung gegeben wurde, eine Zahl, die sich in zwei Jahren kaum bewegt hat, auch wenn die funktionale Genauigkeit erheblich gestiegen ist.

Es ist klar, dass das Richtigstellen der Syntax aufgehört hat, das harte Teil zu sein. Die Urteilsentscheidungen, die ein menschlicher Ingenieur instinktiv getroffen hat, während er tippte, um Sicherheit, Compliance und was für Daten sollten und nicht sollten, sind die Teile, die schwer zu ersetzen sind.

Dies bedeutet, dass die gleiche Strenge, die auf die Definition dessen angewendet wird, was zu bauen ist, auch auf die Definition dessen ausgedehnt werden muss, was nicht erlaubt ist, wie Compliance-Grenzen, Datenhandhabungsregeln und ethische Einschränkungen, die mit der gleichen Sorgfalt wie funktionale Anforderungen ausgedrückt werden.

Das Stillschweigen über diese impliziten Regeln und die Hoffnung, dass ein Agent sie richtig ableitet, ist der gleiche Fehler wie das Stillschweigen über Produktanforderungen und das Kreuzen der Finger, damit der Bau irgendwie gut wird.

Was Führung ausmacht

Nichts davon spricht gegen AI-beschleunigte Entwicklung; das Bauen hat noch nie schneller oder billiger sein können, und es gibt kein Zurück in die Flasche.

Aber was nicht einfacher geworden ist und sogar schwieriger geworden ist, ist die Entscheidung mit echter Präzision, was es wert ist zu bauen, es gut genug zu beschreiben, damit eine Maschine es treu ausführen kann, und die Linien zu ziehen, die es nicht überschreiten darf, während es dies tut.

Auf Unternehmensebene sind die Teams, die vorne liegen, nicht diejenigen mit den schnellsten Codieragenten, das ist klar. Es sind diejenigen, die herausgefunden haben, bevor ihre Wettbewerber es taten, dass die Definition immer das schwierigere Problem sein würde – und begonnen haben, es so zu behandeln.