Der Agent Development Lifecycle ist bei Cloudflare angekommen

Engineering-Manager haben in den vergangenen Jahrzehnten Methoden entwickelt, die es vielen Entwicklerinnen und Entwicklern ermöglichen, gemeinsam an einer geteilten Codebasis zu arbeiten. Diese Arbeit reicht bis zum „Systems Development Lifecycle“ (RAND, 1975) zurück, der heute allgemein als „Software Development Lifecycle“ (SDLC) bezeichnet wird, der die folgenden Phasen definiert:

• Plan (Planen)
• Design (Designen)
• Implement (Implementieren)
• Test (Testen)
• Deploy (Bereitstellen)
• Maintain (Warten)
• Retire (Stilllegen)

Durch KI ist aus dem zuvor zeitaufwendigsten und teuersten Schritt — der Implementierung — der schnellste und kostengünstigste geworden. Dadurch geraten die nachfolgenden Prozesse unter Druck, insbesondere die Personen, die die übrigen Phasen des SDLC verantworten. Betroffen sind sowohl Open-Source-Maintainer, die von Tausenden Pull Requests und Fehlermeldungen überrollt werden, als auch Production Engineers, die Produktionsumgebungen stabil halten müssen, während die Auslieferungsrate von Software um Größenordnungen steigt.

Wir alle versuchen, unsere Systeme, unsere Kunden und uns selbst vor Nachlässigkeit zu bewahren.

Die Lösung besteht — so paradox es klingt — darin, Agenten mehr Verantwortung zu übertragen. Das ist nur fair! Kein Team würde einem Entwickler erlauben, ausschließlich Code zu schreiben, während andere ihn prüfen, zusammenführen, deployen, den Bereitschaftsdienst in der Produktion übernehmen und neue Bugs sichten. Genau das tun die meisten Unternehmen derzeit jedoch mit Agenten. Die Modelle haben sich enorm verbessert, und Agenten können über längere Zeiträume arbeiten und wesentlich umfangreichere Aufgaben bewältigen. Über die verschiedenen Phasen des SDLC hinweg werden sie bislang jedoch noch sehr ungleich eingesetzt.

Bei Cloudflare behandeln wir Agenten als unsere Kundschaft. Sie können Domains kaufen, temporäre Konten erstellen und die gesamte Cloudflare API nutzen. Wir wissen, dass Agenten APIs und Tools benötigen, um den gesamten SDLC im Namen unserer Kunden verwalten zu können – und nicht lediglich die ersten Schritte.

Aus diesem Grund führen wir heute die ersten Werkzeuge einer neuen Tool-Suite ein, die Agenten dabei unterstützt, nicht nur Code zu erzeugen, sondern größere Teile des SDLC zu übernehmen. Dabei geben wir Einblick in das, was wir beim Aufbau unserer eigenen Lösung entwickelt und gelernt haben:

• @cloudflare/ci — eine neue Möglichkeit, CI/CD über Millionen von Repositories hinweg auszuführen. Das System kann sich selbst reparieren, Agenten für deutlich komplexere Aufgaben starten und basiert auf Cloudflare Workflows.
• OpenTelemetry-Traces für die lokale Entwicklung — sie bieten Agenten dieselben Einblicke wie im Produktivbetrieb und sind in Wrangler sowie das Cloudflare-Vite-Plugin integriert.
• Wir präsentieren: Cloudflare Agents und Agent Traces – eine zentrale Umgebung zum Beobachten, Warten und Verbessern von Agenten auf Basis ihrer OpenTelemetry-Traces.
• Wie Cloudflare Engineering-Standards mit KI durchsetzt: unsere Erfahrung damit, Best Practices über die Repositories und Spezifikationen all unserer Produkte und Systeme hinweg durchzusetzen.
• Wie wir eine Softwarefabrik gebaut haben, um die Zahl der GitHub-Issues bei Astro auf null zu senken: unsere Erfahrung mit Systemen, die Issues für ein großes und wachsendes Open-Source-Projekt automatisch triagieren, reproduzieren, verifizieren und beheben.

Aber es geht um mehr als einzelne Tools. Der SDLC wurde für eine andere Geschwindigkeit gebaut. Selbst mit starker Automatisierung skaliert er nicht mit der Code-Menge, die Agenten erzeugen können, und mit dem Tempo, in dem Softwareteams heute arbeiten müssen, um wettbewerbsfähig zu bleiben. Deshalb ist es aus unserer Sicht Zeit für den ADLC: den Agent Development Lifecycle.

Der SDLC passt zu Softwareteams. Der ADLC passt zu Softwarefabriken.

Derzeit sprechen viele über den Bau von „Softwarefabriken“: Systeme, in denen Agenten aus einer Eingabe eigenständig Software bauen, verbessern, deployen und betreiben. Diese Eingabe kann ein Produktionsfehler sein, ein Bug-Report aus dem Support oder eine neue Feature-Idee. Im Idealfall übernimmt ein Agent den gesamten Ablauf.

In der Praxis hängen die meisten Projekte aber weiterhin an Human-in-the-Loop-Schritten. Menschen prompten Agenten, schieben sie an, lassen sie Review-Feedback einarbeiten, beaufsichtigen mehrere Agenten parallel und geben immer neue Anweisungen. Damit bleibt der Mensch der Manager jedes SDLC-Schritts. Nur die einzelnen Aufgaben innerhalb dieser Schritte werden an Agenten ausgelagert.

Softwarefabriken stellen deshalb eine größere Frage: Was passiert, wenn wir nicht einzelne Aufgaben, sondern den gesamten Prozess neu bauen? Wie schaffen wir mehr Raum für das, was Menschen wirklich beitragen: Inspiration, Geschmack und Urteilskraft? Dann bleibt mehr Zeit für Design, Kundengespräche und größere Ideen.

Eine Softwarefabrik deckt weiterhin die bekannten SDLC-Schritte ab, aber sie braucht eine Plattform, die wesentlich mehr leisten kann. Sobald der Agent das Steuer übernimmt, müssen alle bisher manuellen Schritte so umgebaut werden, dass sie für Agenten funktionieren (und nicht mehr auf Menschen angewiesen sind):

• Programmatisch — ClickOps war für Menschen schon fragwürdig. Für Agenten funktioniert es gar nicht. Jede Operation braucht eine API, die Agenten verlässlich aufrufen, debuggen und nutzen können.
• Horizontal skalierbar — Preview-Deployments waren praktisch, solange Menschen auf Bildschirme schauten oder Staging-Server manuell übernahmen, um Probleme vor der Produktion zu finden. Damit Agenten steuern können, braucht jeder Agent eine eigene Preview, die der Produktion entspricht.
• Reproduzierbar — Manche Bugs treten nur unter bestimmten Bedingungen auf, etwa bei simuliertem 4G auf einem iPhone 15 oder aus einem bestimmten Land. Klassische Unit- und Integrationstests decken solche Fälle nicht ausreichend ab.
• Echtzeitfähig, push-basiert – Dashboards funktionieren nicht, wenn niemand aktiv hinschaut. Ein Ereignis (Event) muss den Agenten automatisch auslösen.
• Atomar – Jede Änderung muss separat testbar, auslieferbar, beobachtbar und rückgängig machbar sein (ohne anderes Verhalten zu beeinflussen).
• Berechtigungsbasiert — Menschen erhalten manchmal SSH-Zugriff auf Produktion, wenn es kritisch wird. Agenten dürfen diesen Zugriff nicht einfach bekommen. Trotzdem brauchen sie kontrollierte Eskalationswege.
• Selbstverbessernd – Menschen lernen aus Erfahrung. Beim ersten Ship oder der ersten On-Call-Schicht sind sie langsam und müssen anderen über die Schulter schauen. Danach werden sie besser und schneller. Auch Agenten brauchen Wege, aus Erfahrung zu lernen.

Damit Softwarefabriken echte Produktionssoftware sicher betreiben können, brauchen wir ein neues Fundament. Die Herausforderung ähnelt der bei selbstfahrenden Autos: Sie müssen von „funktioniert in 80 Prozent der Fälle“ zu Zuverlässigkeitswerten weit über 99 Prozent kommen.

Wer Agenten den SDLC steuern lässt, darf ihnen kein Fahrzeug geben, das für Menschen entworfen wurde.

Ein autonomes Fahrzeug ist mit Sensoren und Technologien ausgestattet, die ein gewöhnliches Auto nicht hat. Lidar-Sensoren, Kameras, leistungsstarke Compute-Ressourcen für Inferenz und Konnektivität zu einem zentralen Kommandosystem, das bei Bedarf aus der Ferne übernehmen kann.

Damit ein autonomes Fahrzeug 80 Prozent so gut fährt wie ein Mensch, bräuchte es vermutlich nicht all das. Selbstfahrende Systeme waren schon vor zehn Jahren ungefähr 80 Prozent so gut wie Menschen. Aber das ist nicht die Messlatte. Die Messlatte ist, deutlich besser und sicherer als ein menschlicher Fahrer zu sein. Genau das erwarten wir, wenn wir einer Maschine die Schlüssel übergeben und uns sicher genug fühlen wollen, auf dem Highway 101 bei 60 mph ein Nickerchen zu machen. Genau deshalb verfügen autonome Fahrzeuge über speziell für autonomes Fahren entwickelte Technologie: Sie schafft Vertrauen und bewältigt Edge Cases, die sich nicht vollständig im Voraus planen lassen.

Bei selbstfahrender Software ist es genauso. Warum lassen Sie Ihren Agenten seine eigenen PRs für Produktionsservices noch nicht automatisch genehmigen und mergen? Wahrscheinlich fallen Ihnen sofort viele Gründe ein. Und je wichtiger das System ist, desto länger wird diese Liste.

Denn es geht nicht nur darum, katastrophale Fehler zu verhindern. Es geht auch darum, wirklich das Richtige für Kundinnen und Kunden zu bauen. Das ist zu komplex für eine lineare Schrittfolge in einer GitHub Actions YAML-Datei. Auch klassische automatisierte Tests reichen nicht aus. Schon eine kleine Dashboard-Änderung kann Rollen, Spezialgebiete und Organisationsstrukturen berühren. Subjektive Änderungen sind besonders schwer zu testen und zu delegieren. Heute steckt vieles davon wahrscheinlich nicht in Ihrer CI/CD-Pipeline. Wenn Agenten die Softwarefabrik steuern sollen, muss genau das aber Teil des Systems werden.

Wenn Agenten den ganzen Prozess übernehmen sollen, brauchen wir eine bessere Art, dynamische Schrittketten zu orchestrieren. Aus unserer Sicht ist das ein Workflow, der Container, Agenten und Browser starten kann. Ein solcher Workflow kann Feature Flags setzen, sie für Testnutzer aktivieren, Logs und Traces auswerten, Produktionsmetriken beim schrittweisen Rollout beobachten und alles koordinieren, was für eine sichere Bereitstellung nötig ist.

Eine CI/CD-Pipeline ist im Grunde nur ein Workflow. Aber ein Workflow kann weit mehr leisten.

Cloudflare Workflows verketten Schritte, wiederholen fehlgeschlagene Aufgaben automatisch und speichern Zustand für Minuten, Stunden oder Wochen. So lassen sich komplexe, dynamische Geschäftsprozesse als logisches Programm beschreiben. Dieser Beitrag zeigt, warum Workflows gemeinsam mit Artifacts CI/CD-Pipelines wesentlich einfacher definierbar und auslösbar machen. Ein Beispiel:

import { CIWorkflow } from `@cloudflare/ci`

const deps: CiRunnerResult = await ci.runner({
      name: 'install',
      command: 'bun install --frozen-lockfile',
      cache: { inputs: ['package.json', 'bun.lock'] },
    });

    await Promise.all([
      deps.runner({ name: 'lint', command: 'bun run lint' }),
      deps.runner({ name: 'test', command: 'bun run test' }),
      deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
      deps.runner({ name: 'build', command: 'bun run build' }),
    ]);

    await deps.runner({
      name: 'deploy',
      command: 'bun wrangler deploy',
      cloudflareCredentials: {
        accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
      },
    });

Workflows sind nicht auf lineare Schrittfolgen beschränkt. Sie lassen sich dynamisch definieren und können Agenten oder weitere Workflows starten. Das Beispiel zeigt einen Workflow, der neue Daten der letzten 24 Stunden überprüft. Der Workflow steuert, wann und wie der Agent gepromptet wird, und gibt Kontext von Schritt zu Schritt weiter.

import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';

type Params = { date: string };

export class NightlyReview extends WorkflowEntrypoint {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const findings = await step.do('collect findings', () => collectFindings(event.payload.date));

    const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });

    const receipt = await step.do('dispatch review', () =>
      agent.dispatch(`Review these findings:\n${findings}`),
    );

    const review = await step.do('read review', async () => {
      const reply = await agent.read(receipt);
      return { text: reply.text, data: reply.data };
    });

    // ...
  }
}

Sobald man dieses Muster verstanden hat und so von Workflows überzeugt ist wie Cloudflare, stellt sich fast automatisch die Frage: Was könnte ein Workflow noch für mich erledigen? Welche menschlichen Engpässe lassen sich an Workflow plus Flue-Agenten delegieren?

Der vollständige ADLC auf dem Cloudflare-Stack

Workflows orchestrieren komplexe Schritte, Artifacts speichern Code. Zusammen ergibt das auf Cloudflare die Grundlage, mit der Agenten den gesamten Weg vom Bauen über die Bereitstellung bis zur Wartung von Software übernehmen können.

Grundbausteine für den Aufbau Ihrer Softwarefabrik

Die Menschen an der vordersten Entwicklungsfront bauen heute die Softwarefabriken von morgen. Mit der Zeit werden Softwarefabriken so selbstverständlich werden wie Agenten und KI: eine normale Art, Software zu bauen. Aber für die meisten Menschen und Organisationen ist dieser Punkt noch nicht erreicht.

Wir wollen das ändern.

Unsere Leitfragen waren: Wie machen wir diesen Wandel einfach und zugänglich, damit alle im Internet davon profitieren können? Und welche Basis-Bausteine können wir öffnen, egal ob für ein kleines Startup oder eine der größten Plattformen der Welt?

Wir glauben: Die Bausteine sind jetzt vorhanden. Es bleibt Arbeit, sie weiter zu verbinden, unsere eigene Softwarefabrik auszubauen und aus ihr zu lernen. Doch ab heute können Sie auf Cloudflare Ihre Maschine bauen, die die Maschine baut. Starten Sie mit @cloudflare/ci, bauen Sie einen Agenten und sehen Sie, wie viel des SDLC Sie automatisieren können.