Viele Teams haben Bedürfnisse, die eine eigene Anwendung nicht ganz rechtfertigen: ein Vergleichswerkzeug zum Prüfen von Angeboten, ein Entscheidungsprotokoll oder ein Inventar, das nur während einer Migration gebraucht wird. Meist behilft man sich mit dem, was ohnehin zur Hand ist. Etwas Eigenes zu bauen zwingt zu Entscheidungen: wo es gehostet wird, wie die Daten gespeichert werden und wer Zugang hat. Manchmal wiegt diese Arbeit drumherum schwerer als das Werkzeug selbst.
In Wenn Software so lange lebt wie das Problem ging es um Anwendungen, die für eine konkrete Aufgabe erzeugt werden. Doch den Code zu schreiben ist nur ein Teil: Sie brauchen einen Ort, an dem sie laufen, festhalten, was wir tun, und geteilt werden können. Cloudflare OS schlägt einen solchen Ort vor. Bei Codin haben wir es bereitgestellt, um zu erkunden, was sich damit machen lässt.
Eine Arbeitsumgebung, die man auch verändern kann
Cloudflare OS ist ein offenes Projekt von Cloudflare, das KI-Agenten, kleine Anwendungen und kontrollierten Zugriff auf externe Dienste zusammenbringt. Es wird im Browser genutzt und lässt sich in einer eigenen Installation betreiben.
Der Vergleich, den Cloudflare anbietet, hilft beim Verständnis: Man stelle sich eine Office-Suite vor, in der jede Datei eine maßgeschneiderte Anwendung sein könnte. Statt immer zwischen Dokument, Tabelle oder Präsentation zu wählen, könnte man ein Werkzeug mit genau den Feldern, Ansichten und Aktionen erstellen, die man braucht. OS nennt diese Anwendungen Gadgets; man kann sie anpassen und teilen.
Der Unterschied zeigt sich schon an etwas Einfachem. Angenommen, wir wollen Angebote mehrerer Anbieter vergleichen. Eine Tabelle sammelt die Daten, aber vielleicht müssen wir auch Unklarheiten markieren, die Begründung jeder Bewertung festhalten und nur die relevanten Unterschiede anzeigen. Eine eigene Anwendung könnte diesen ganzen Ablauf auf einem Bildschirm bündeln. Das Interessante an OS ist, dass es eine gemeinsame Umgebung bietet, um solche Werkzeuge zu bauen, ohne für jedes eine eigene Infrastruktur vorzubereiten.
Veranschaulichendes BeispielVon der Idee zum Werkzeug
Unterhaltung
Ich möchte drei Angebote von Anbietern vergleichen: Dauer, Umfang und Support.
Ich lege einen Vergleich mit einer Spalte pro Angebot und einer Zeile pro Kriterium an.
Füge die Konditionen jedes Angebots hinzu und ermögliche einen Filter nach inklusivem Support.
Beschreiben: Die Anfrage geht von einer konkreten Aufgabe aus. Es genügt zu erklären, was verglichen werden soll und nach welchen Kriterien.
Bauen: Der Assistent schlägt eine erste Version des Gadgets vor. Hier ist es ein Grundgerüst mit drei fiktiven Anbietern, Dauer und Umfang.
Anpassen: Während der Prüfung entsteht ein neuer Bedarf. Das Werkzeug ergänzt eine Zeile mit Konditionen und einen Filter, der das Angebot ohne inklusiven Support in den Hintergrund rückt.
Vom Anfordern eines Werkzeugs zur Arbeit damit
Mit dem integrierten Assistenten lässt sich ein Gadget beschreiben und anschließend verändern. Die Unterhaltung kann weitergehen, wenn die erste Version bereits existiert: eine Ansicht hinzufügen, die Darstellung eines Ergebnisses ändern oder eine Aktion einbauen. Der Code des Werkzeugs bleibt verfügbar, um ihn weiter anzupassen.
Das verändert das Verhältnis zu einer kleinen Anwendung. Um beim Vergleichswerkzeug zu bleiben: Stellt sich mitten in der Prüfung heraus, dass eine Kondition des Anbieters noch erfasst werden muss, könnte das zu einer Änderung am Werkzeug führen. Wir müssten nicht mehr die ganze Aufgabe in das zwängen, was der erste Bildschirm hergab. Natürlich müsste man prüfen, dass die Änderung die Daten erhält und tut, was wir erwarten.
In OS teilen sich Unterhaltung und Anwendung denselben Raum. Links stehen der Auftrag und sein Verlauf; rechts können wir das Gadget nutzen, seine Dateien öffnen oder die angebundenen Dienste prüfen. Das sind die drei Ansichten aus unserer Installation:
Echte ScreenshotsEin Gadget, drei Arbeitsweisen
1 · Der Auftrag bleibt sichtbar. In diesem Fall: ein CRM mit Pipeline, Nachverfolgung und Chancen aus Radar. Darunter ist festgehalten, dass die Änderungen übernommen wurden.
2 · Die Anwendung wird daneben genutzt. Der Tab App öffnet das Gadget: Man kann das Board einsehen und mit seinen Daten arbeiten, ohne den Arbeitsbereich zu verlassen.
1 · Die Dateien sind zugänglich. Code vereint Oberfläche und Logik des Gadgets. Mit einem Tab gelangen wir von der Anwendung zu ihrer Implementierung.
2 · Die Regeln lassen sich prüfen. Hier sieht man die Phasen des CRM und den Kontext, den es verwendet. Die Unterhaltung bleibt daneben, während wir den Code untersuchen.
1 · Die Ressourcen des Gadgets haben ein eigenes Panel. Connections zeigt das verfügbare Modell und den Namen, unter dem der Code es verwendet: LUNA. Über diese Verbindung lässt sich aus dem CRM heraus eine Analyse anfordern.
Mit dem CRM haben wir diesen Ablauf anhand öffentlicher Informationen aus Codin Radar erprobt. Es ist eine erste Version mit manuellem Import, vereint aber eine Anwendung, die ihre Daten behält, Code, den wir ändern können, und eine KI-Anbindung zur Analyse von Chancen.
Das Beispiel trennt außerdem zwei Einsatzweisen von KI. Die eine hilft, das Werkzeug zu schreiben; die andere erledigt eine Aufgabe darin. Eine Notiz speichern oder eine Phase ändern ist weiterhin herkömmliche Software. Die Anwendung braucht kein Modell, das sie bei jeder Nutzung neu erfindet.
Mit den Werkzeugen bauen, die man schon nutzt
In unserem Test haben wir das Gadget mit Codex in unserer gewohnten Umgebung geschrieben und über die API von OS installiert. Diese API nutzt Cap’n Web, eine Bibliothek von Cloudflare, um entfernte Funktionen aus JavaScript aufzurufen. Der Ablauf bestand darin, den Code zu ändern, ihn zu prüfen und die neue Version zu senden.
Diese Möglichkeit halten wir besonders für technische Teams für nützlich. Wir können den Editor, das Modell und die Art der Code-Review beibehalten, mit denen wir bereits arbeiten. OS wird zum Ort, an dem die Anwendung läuft und ihre Daten behält, auch wenn sie außerhalb seines Assistenten gebaut wird.
Sie erlaubt auch, die Arbeit aufzuteilen. Jemand kann formulieren, was gebraucht wird, und die Oberfläche prüfen; eine andere Person kann sich um die Teile kümmern, die mehr Sorgfalt erfordern. Die Unterhaltung hilft, das Werkzeug zu konkretisieren, und der Code ist weiterhin da, wenn man sein Verhalten verstehen oder korrigieren muss.
Ein Werkzeug teilen oder sein Design wiederverwenden
OS unterscheidet zwischen Zugriff zum Nutzen und Zugriff zum Bauen. Wer den ersten erhält, arbeitet mit der Anwendung und ihren Funktionen; wer den zweiten erhält, kann zusätzlich den Code ändern. Nutzen heißt nicht nur Lesen: Ein Gadget kann erlauben, Informationen zu erfassen oder eine Analyse anzufordern, ohne Zugriff auf seine Entwicklung zu gewähren.
Es gibt eine weitere, ebenso interessante Art des Teilens: Blueprints. Das sind Vorlagen vollständiger Anwendungen. Mit ihnen kann eine andere Person eine eigene Kopie des Gadgets mit eigenem Speicher und eigenen Verbindungen anlegen, ohne Verlauf, gespeicherte Daten oder Zugangsdaten der ursprünglichen Instanz mitzunehmen.
Der Unterschied ist praktischer Natur. Ein Team könnte gemeinsam am selben Migrationsinventar arbeiten. Ein anderes könnte dessen Design für eine andere Migration wiederverwenden, mit eigenen Systemen und Verantwortlichen. Im ersten Fall teilen sie die Arbeit; im zweiten ein Werkzeug, das ihnen erspart, bei null anzufangen.
Veranschaulichendes BeispielDie Arbeit oder das Design teilen
Lucíadieselbe Instanzursprüngliche Instanz
Migration Nord
- Mailserver Lucía: DNS prüfen
- Kundendatenbank Andrés: exportiert
- Büro-VPN Lucía: ausstehend
Andrésdieselbe Instanzneue Kopie
Migration Nord
- Mailserver Lucía: DNS prüfen
- Kundendatenbank Andrés: exportiert
- Büro-VPN Lucía: ausstehend
Migration Süd
- Lieferantenportal Andrés: Zugang anfragen
- Dateiablage
- Etagendrucker Andrés: inventarisieren
Gemeinsam arbeiten: Beide Personen öffnen dasselbe Werkzeug und sehen dieselben Daten, sodass das, was die eine notiert, auch bei der anderen erscheint. Mit Zugriff zum Nutzen können sie Informationen erfassen; um den Code zu ändern, braucht es Zugriff zum Bauen.
Kopie erstellen: Ein Blueprint beschreibt die vollständige Anwendung und ermöglicht eine weitere Instanz mit eigenem Speicher und eigenen Verbindungen. Wiederverwendet wird das Design; Verlauf, Daten und Zugangsdaten des Originals gehen nicht auf die Kopie über.
Auch externe Verbindungen haben ihren Platz in diesem Konzept. OS verwendet Gatekeepers, Komponenten, die den Zugriff von Agenten und Gadgets auf bestimmte Ressourcen vermitteln. Dafür müssen die entsprechenden Integrationen eingerichtet werden: Wer OS bereitstellt, verbindet damit nicht automatisch alle Systeme des Unternehmens.
Was ein eigenes Werkzeug verdient
Cloudflare stellt OS als Projekt vor, das sich noch in Entwicklung befindet. Auch unsere Erfahrung ist noch jung: Wir haben eine Anwendung ausprobiert, nicht eine Veränderung der Produktivität des Teams gemessen. Und ein eigenes Werkzeug muss weiterhin gewartet werden; ein etabliertes Produkt kann einen Prozess besser abdecken, der von vielen Integrationen abhängt oder laufenden Support braucht.
Dennoch lohnt sich ein Blick auf jenen Bereich kleiner Aufgaben, den generische Werkzeuge nur zur Hälfte abdecken. Ein Werkzeug zur Angebotsprüfung kann einen wiederkehrenden Prozess begleiten. Ein Migrationsinventar ist vielleicht nur einige Wochen lang sinnvoll. Beide brauchen eine Oberfläche, Regeln und Daten, die erhalten bleiben, auch wenn ihre Lebensdauer unterschiedlich ist.
Genau diese Möglichkeit wollen wir mit Cloudflare OS weiter erkunden: den Ort, an dem solche Werkzeuge leben können, schon bereitzuhaben. Wenn jedes davon ein ganzes Projekt erfordert, werden viele gar nicht erst in Betracht gezogen. Wenn ein Teil der Arbeit bereits erledigt ist, kann die Frage näher an die Aufgabe rücken: was wir tun müssen und welche Anwendung uns dabei helfen würde.
