Continuous Integration (CI) ist mit der zunehmenden Nutzung von Programmieragenten zu einem neuen Engpass geworden. Diese Schlussfolgerung stützt sich auf Erfahrungen, die Ingenieurteams von Anthropic, Linear und Depot im September vorgestellt haben, und nicht auf die Ankündigung eines einzelnen Tools. Das Volumen der CI-Jobs bei Anthropic ist innerhalb von sechs Monaten um das 25-Fache gestiegen, während die Ingenieure pro Quartal inzwischen etwa achtmal so viel Code ausliefern wie im Zeitraum zwischen 2021 und 2025. Bei Linear hat sich die Größe der Testsuite seit Januar nahezu vervierfacht, während Agenten inzwischen die meisten Tests schreiben.
Anthropic reagierte mit einer Testauswirkungsanalyse, um nur die Tests auszuführen, die wahrscheinlich von der Änderung betroffen sind, und Linear gestaltete seine Pipeline fast vollständig neu. Diese Maßnahmen verkürzen die Wartezeit, behandeln jedoch nur eine Ebene des Problems: die Geschwindigkeit der Repository-Prüfung.
Warum reicht CI-Geschwindigkeit nicht mehr aus?
CI wurde historisch für eine menschliche Arbeitsweise konzipiert: Der Entwickler erstellt pro Woche eine begrenzte Anzahl von Merge Requests und wartet anschließend auf das Ergebnis der Pipeline, während er zu einer anderen Aufgabe übergeht. Ein Agent kann dagegen Code, Tests und Merge Requests parallel erstellen, wodurch sich die Zahl der CI-Läufe vervielfacht. Der Artikel weist darauf hin, dass Blacksmith, ein Unternehmen, das CI-Runner verkauft, ein wöchentliches Wachstum von 5 % bis 10 % bei der Zahl der ausgeführten Jobs festgestellt hat.
Das zweite Problem betrifft den Ort der Validierung. Der Agent schreibt die Änderung und wartet anschließend nach der Erstellung des Merge Requests auf das Ergebnis. Wenn das Ergebnis nach 20 Minuten eintrifft, hat er möglicherweise den Kontext der Aufgabe verloren, während jedes Problem einen neuen Wartezyklus bedeutet.
Das Repository ist nicht das System
Bei eigenständigen Anwendungen kann ein Repository-Test ein Bild liefern, das dem Systemverhalten nahekommt. In einer cloudnativen Umgebung stellt das Repository jedoch einen einzelnen Dienst innerhalb eines Systems dar, das Dutzende von Diensten umfassen kann, während der übrige Teil des Systems meist durch Mock-Schnittstellen oder Testdaten dargestellt wird.
Deshalb kann eine Änderung Unit-Tests bestehen, CI passieren und in einer isolierten Umgebung funktionieren, dann aber bei der ersten echten Anfrage scheitern, die Dienstgrenzen überschreitet. Beispiele dafür sind die Änderung des Namens eines Feldes, von dem ein anderer Dienst abhängt, die Verkürzung eines Timeouts, die eine Kette von Wiederholungen auslöst, eine Schemaänderung, die in der Testumgebung eine Tabellensperre verursacht, oder ein Endpunkt, der sich anders verhält, wenn der konsumierende Dienst ihn tatsächlich aufruft.
Der Artikel verweist auf Daten von DevOps Research and Assessment (DORA), die eine höhere Einführung von künstlicher Intelligenz sowohl mit einer höheren Softwarebereitstellungsfrequenz als auch mit mehr Störungen bei der Bereitstellung in Verbindung bringen. Schneller erzeugter Code garantiert also keine bessere Validierung.
Was ändert sich praktisch?
Der vorgeschlagene Ansatz besteht nicht darin, CI abzuschaffen oder Agenten zu verlangsamen, sondern einen Teil der Validierung innerhalb der Arbeitsschleife des Agenten früher durchzuführen, sodass die Änderung gegen das tatsächliche System und nicht nur gegen eine Repository-Kopie getestet wird. Tools wie Cursor verwenden isolierte Cloud-Umgebungen; mehr als 30 % der von Cursor gemergten Merge Requests stammen von Agenten, die auf diese Weise arbeiten. Weitere Tools, darunter GitHub Copilot cloud agent, Codex, Devin und Greptile, bieten unterschiedliche Formen der Codeausführung in temporären Umgebungen.
Diese Umgebungen enthalten jedoch in der Regel den Branch und seine Einstellungen sowie das, was das Setup-Skript installieren kann, nicht aber die anderen Dienste, die tatsächliche Nachrichtenliste und eine Datenbank mit produktionsähnlichen Daten. Daher ist die Schleife nach Ansicht des Artikels zwar geschlossen, möglicherweise aber um das Falsche herum.
Gemeinsame Umgebungen und kontrollierte Validierung
Der Artikel schlägt vor, eine gemeinsame stabile Version der Dienste innerhalb eines Kubernetes-Clusters zu betreiben und leichtgewichtige Testumgebungen zu erstellen, die nur den geänderten Dienst bereitstellen. An diese Dienstinstanz werden markierte Anfragen geleitet, während die übrigen Pfade mit den gemeinsamen stabilen Versionen verbunden bleiben. Dadurch können viele Agenten dieselbe Umgebung gemeinsam nutzen, anstatt das gesamte System für jeden Agenten zu kopieren; der Artikel schätzt, dass die Kosten der Umgebung sich den Kosten eines einzelnen Containers annähern könnten und dass ihr Start Sekunden dauert, doch die Quelle liefert keine unabhängigen Messungen, die diese Schätzungen in allen Umgebungen belegen.
Die Umgebung allein reicht nicht aus. Plattformteams benötigen genehmigte Verfahren, die festlegen, welche Anfragen gesendet, welche Protokolle erfasst und welche Verträge nachgewiesen werden müssen. Außerdem sollten die vom Test berührten Dienste und seine Ergebnisse protokolliert werden, damit der Datensatz von Prüfwerkzeugen und Merge-Gates gelesen werden kann. Der Autor betont, dass Governance notwendig ist, um Agenten daran zu hindern, in einem gemeinsam genutzten Cluster unsichere Aktionen auszuführen.
Aus Sicht von certi.news besteht die eigentliche Veränderung nicht lediglich in der Beschleunigung von CI, sondern in einer Neudefinition dessen, was „erfolgreiche“ Validierung bedeuten soll. Repository-Tests bleiben wichtig, reichen jedoch allein für verteilte Systeme, die von Agenten mit höherer Geschwindigkeit erzeugt werden, nicht aus. Fragen zu Kosten, Isolation, Datensicherheit und zur Messung der Validierungsgenauigkeit bleiben offen; außerdem präsentiert der Beitrag eine analytische These und keinen nachgewiesenen Standard oder ein bestimmtes Produkt.