Das Technologieberatungsunternehmen Thoughtworks hat die 34. Ausgabe seines halbjährlichen Technology Radar veröffentlicht. Zentrales Thema: sogenannte kognitive Schulden, die entstehen, wenn künstliche Intelligenz immer größere Codemengen generiert und das gemeinsame Verständnis von Softwaresystemen in Entwicklerteams schneller erodiert, als es sich erneuern lässt.

Während frühere Ausgaben des Radars die wachsenden Fähigkeiten von KI im Software-Engineering beleuchteten, verschiebt sich der Fokus dem aktuellen Report zufolge nun auf die Risiken beim Skalieren und im produktiven Einsatz. Der Unterschied zu klassischen technischen Schulden ist dabei wesentlich: Technische Schulden stecken im Code selbst, kognitive Schulden dagegen in den Köpfen der Entwicklerinnen und Entwickler. Die Kluft zwischen Mensch und System wird größer, wenn KI-generierter Code schneller entsteht, als Teams ihn durchdringen können.

Thoughtworks-CTO Rachel Laycock formuliert es so: „Der Wendepunkt, an dem wir uns befinden, hat weniger mit Technologie zu tun – es geht vielmehr um die Methode“. Die KI-Fähigkeiten haben sich im vergangenen Jahr in atemberaubendem Tempo entwickelt. Doch statt den Menschen zu verdrängen, zeige sich, dass geeignete Praktiken und technische Kontrollmechanismen nötig seien, um diese Fähigkeiten sicher und effektiv einzusetzen.

Kontrollmechanismen für Coding-Agenten

Ein zentrales Konzept des Radars sind sogenannte Harnesses – technische Kontrollmechanismen für KI-gestützte Coding-Agenten. Diese unterteilen sich in zwei Kategorien: Feedforward-Kontrollen steuern vor der Ausführung, etwa durch Agent Skills oder spezifikationsgetriebene Entwicklung. Feedback-Systeme hingegen beobachten die Ergebnisse nach der Ausführung – beispielsweise durch Mutationstests – und lösen eine Selbstkorrektur aus, bevor ein Mensch eingreifen muss. Ausführlich beschreibt dieses Konzept ein Artikel zu Harness Engineering von Birgitta Böckeler.

Zero Trust für KI-Agenten gefordert

Ein weiterer Schwerpunkt liegt auf der Absicherung von KI-Agenten, die zunehmend Zugriff auf private Daten und externe Systeme benötigen. Thoughtworks empfiehlt dafür Zero-Trust-Architekturen, Sandboxing und Defense-in-Depth-Strategien. Das Spannungsfeld zwischen maximalem Nutzen und Sicherheitsrisiken erfordere Prinzipien wie explizite Verifikation und minimale Rechtevergabe – Grundsätze, die auch mit Datenschutzanforderungen wie der DSGVO harmonieren.

Darüber hinaus empfiehlt der Radar eine Rückkehr zu bewährten Metriken wie den DORA-Kennzahlen (Deployment Frequency, Lead Time for Changes, Mean Time to Restore und Change Fail Percentage), um die steigende Komplexität messbar zu machen. Auch die Bewertung neuer Technologien werde durch einen Marktstau kleiner KI-Projekte und semantische Diffusion – also uneinheitliche Begriffsverwendung – zunehmend erschwert.

Passend dazu: Schneller coden, langsamer testen

Die Warnung vor kognitiven Schulden fügt sich in eine breitere Debatte ein. Wie auch andere Studien zeigen, beschleunigt generative KI zwar das Schreiben von Code, macht aber die Verifikation aufwendiger. Der Engpass verschiebt sich vom Erzeugen zum Verstehen und Prüfen. Genau an dieser Stelle setzt der Technology Radar an und fordert eine Rückbesinnung auf Engineering-Grundlagen, um die wachsenden Fähigkeiten von KI nachhaltig nutzen zu können.

Der interaktive Technology Radar steht online zur Verfügung, ein PDF-Download ist ebenfalls möglich.

(map)

Wenn jemand sagt, man solle ein Plug-in für ein KI-Tool entwickeln, denken die meisten an SDKs, an Boilerplate-Code, an Dokumentationen, die man erst dreimal lesen muss, bevor man den Einstiegspunkt findet. Ich hatte dieselbe Erwartung, als ich mich vor ein paar Wochen entschieden habe, ein Plug-in für Claude Code zu bauen. Claude Code ist Anthropics Kommandozeilen-Tool für KI-gestützte Softwareentwicklung, und seit einiger Zeit lassen sich dafür eigene Plug-ins entwickeln und über einen Marketplace verteilen.

Das Plug-in, das ich gebaut habe, bindet EventSourcingDB an, eine Datenbank, die speziell für Event Sourcing konzipiert ist. Der Vollständigkeit halber: EventSourcingDB ist ein Produkt meines Unternehmens, der the native web GmbH. Dieser Blogeintrag ist jedoch kein Text über die Datenbank, sondern über das, was ich beim Entwickeln des Plug-ins gelernt habe. Die Datenbank dient lediglich als konkretes Beispiel, an dem sich die Erkenntnisse nachvollziehen lassen.

Was Claude-Code-Plug-ins eigentlich sind

Bevor ich auf das Plug-in selbst eingehe, lohnt sich eine kurze Einordnung. Denn Claude-Code-Plug-ins sind nicht das, was man vielleicht erwartet, wenn man den Begriff „Plug-in“ hört.

In der Welt der KI-gestützten Entwicklungstools hat sich in den vergangenen Monaten vor allem ein Standard etabliert: das Model Context Protocol, kurz MCP. MCP-Server stellen einem KI-Modell Werkzeuge zur Verfügung, die es aufrufen kann. Das Modell entscheidet selbst, wann welches Werkzeug sinnvoll ist, und ruft die entsprechende Funktion auf. Für EventSourcingDB gibt es bereits einen solchen MCP-Server. MCP-Server sind mächtig, erfordern aber eine gewisse Infrastruktur: Man braucht einen laufenden Serverprozess, eine Transportschicht und eine Tooldefinition im JSON-Schema-Format.

Claude-Code-Plug-ins verfolgen einen anderen Ansatz. Sie erweitern Claude Code nicht durch laufende Prozesse, sondern durch sogenannte Skills (genau genommen kann ein Plug-in neben Skills noch andere Dinge enthalten, aber für mein Beispiel beschränke ich mich auf sie). Ein Skill ist dabei im Kern eine Textdatei, die Claude Code erklärt, wie es eine bestimmte Aufgabe erledigen soll. Das klingt zunächst unspektakulär, ist aber bemerkenswert effektiv. Statt einer programmatischen Schnittstelle erhält das Modell eine natürlichsprachliche Anleitung, die es interpretiert und umsetzt. Plug-ins lassen sich über einen Marketplace installieren und verteilen, sodass andere Entwicklerinnen und Entwickler sie einfach nutzen können.

Die Anatomie eines Plug-ins

Was mich am meisten überrascht hat, war die Struktur eines Plug-ins. Oder besser gesagt: wie wenig Struktur nötig ist. Die Verzeichnisstruktur des EventSourcingDB-Plug-ins sieht beispielsweise folgendermaßen aus:

/
  .claude-plugin/
    marketplace.json
  plugins/
    esdb/
      .claude-plugin/
        plugin.json
      skills/
        ping/
          SKILL.md
        write-events/
          SKILL.md
        read-events/
          SKILL.md
        ...

Das ist die gesamte Struktur. Kein SDK, kein Framework, kein Build-Schritt. Im Kern besteht ein Plug-in aus zwei Dingen: einer Plug-in.json und einer Sammlung von SKILL.md-Dateien.

Die plugin.json ist das Manifest. Sie definiert den Namen, die Version und eine kurze Beschreibung. Das sieht für das EventSourcingDB-Plug-in in etwa so aus:

{
  "name": "esdb",
  "version": "1.0.0",
  "description": "Interact with EventSourcingDB using its HTTP API",
  "author": {
    "name": "the native web GmbH",
    "email": "hello@thenativeweb.io"
  }
}

Jeder Skill liegt in einem eigenen Unterverzeichnis und besteht aus einer eigenen SKILL.md-Datei. Diese Datei beginnt mit einem Frontmatter-Block, der den Namen und eine Beschreibung enthält, gefolgt von den eigentlichen Anweisungen in natürlicher Sprache:

---
name: ping
description: Check whether an EventSourcingDB instance is reachable.
---

# Ping

Send a GET request to $ESDB_URL/api/v1/ping to check whether
the EventSourcingDB instance is reachable. No authentication
is required for this endpoint. A successful response returns
HTTP 200 with the text "OK".

Das ist, in vereinfachter Form, der gesamte Ping-Skill. Claude Code liest diese Beschreibung und setzt sie eigenständig um. Es generiert den HTTP-Aufruf, sendet ihn und interpretiert die Antwort. Die eigentliche Logik steckt nicht in ausführbarem Code, sondern in einer präzisen Beschreibung. Die Qualität des Plug-ins hängt damit nicht von der Qualität des Codes ab, sondern von der Qualität der Beschreibung.

Auf der Ebene darüber liegt die marketplace.json. Sie beschreibt, welche Plug-ins ein Marketplace anbietet. Claude Code hat einen offiziellen Marketplace, der von Anthropic verwaltet wird und geprüfte Plug-ins enthält. Darüber hinaus kann aber jede Person und jede Organisation einen eigenen Marketplace erstellen. Es genügt ein GitHub-Repository mit einer marketplace.json im Verzeichnis .claude-Plug-in. Das war für mich ein entscheidender Punkt: Man ist nicht auf eine zentrale Instanz angewiesen, sondern kann Plug-ins auch intern oder für die eigene Community bereitstellen, ohne einen Freigabeprozess durchlaufen zu müssen.

Für jemanden wie mich, der seit über zwanzig Jahren Software entwickelt, ist die Art der Plug-in-Entwicklung ein bemerkenswerter Perspektivwechsel. Statt in Funktionen und Klassen zu denken, denkt man in Erklärungen und Anleitungen. Statt eine API zu implementieren, beschreibt man eine API. Die Fähigkeit, präzise und unmissverständlich zu formulieren, wird zur eigentlichen Entwicklungskompetenz.

Vom leeren Verzeichnis zum funktionierenden Plug-in

Wie sah nun der praktische Weg aus? Ich habe mit einem leeren Repository und der Frage begonnen, welche Interaktionen mit EventSourcingDB ich abbilden wollte. Die Datenbank bietet eine HTTP-API mit einer überschaubaren Anzahl von Endpunkten: Events schreiben, Events lesen, Events beobachten, Subjects abfragen, Event-Typen auflisten, EventQL-Queries ausführen und Schemas registrieren. Dazu kommen administrative Funktionen wie Ping und die Verifikation des API-Tokens.

Für jeden dieser Endpunkte habe ich einen eigenen Skill angelegt. Das klingt nach viel Arbeit, war es aber nicht. Zum einen folgt nämlich jeder Skill demselben Muster: eine kurze Beschreibung des Zwecks, die relevanten API-Endpunkte mit ihren Parametern, Hinweise zur Authentifizierung und Beispiele für typische Aufrufe und Antworten. Die Markdown-Dateien sind jeweils zwischen rund 30 und 80 Zeilen lang. Zum anderen habe ich auch dazu wiederum Claude Code genutzt: Ich habe die Skills also nicht von Hand geschrieben, sondern Claude Code jeweils beschrieben, was ich erreichen möchte und die Skills anschließend generieren lassen.

Der erste Skill, den ich auf diesem Weg erstellt habe, war der einfachste: der oben bereits erwähnte Ping-Skill. Dieser Skill prüft, ob eine EventSourcingDB-Instanz erreichbar ist. Die zugehörige Beschreibung umfasst kaum mehr als den API-Endpunkt, die erwartete Antwort und einen Hinweis, dass keine Authentifizierung nötig ist. Innerhalb weniger Minuten war der Skill fertig, und Claude Code konnte ihn verwenden.

Was mich überrascht hat: Es funktionierte auf Anhieb. Kein Debugging, kein Trial-and-Error, kein stundenlanges Nachjustieren. Claude Code las die Beschreibung, verstand die Aufgabe und führte den HTTP-Aufruf korrekt aus. Ermutigt durch diesen schnellen Erfolg habe ich die weiteren Skills in rascher Folge geschrieben. Nach einem Nachmittag war das Plug-in vollständig.

Das soll nicht den Eindruck erwecken, es hätte keinerlei Herausforderungen gegeben. Die Beschreibung des Skills für das Beobachten von Events erforderte mehr Sorgfalt, weil hier eine langlebige HTTP-Verbindung mit NDJSON-Streaming im Spiel ist. Ich musste Claude Code erklären, dass die Verbindung offen bleibt und kontinuierlich Daten liefert. Aber auch das war eine Frage der richtigen Formulierung, nicht der richtigen Implementierung.

Was das Plug-in kann und wie es funktioniert

Das fertige Plug-in umfasst zehn Skills, die fast die gesamte HTTP-API von EventSourcingDB abdecken. Die Installation erfolgt in zwei Schritten. Zunächst fügt man den Marketplace hinzu:

/plugin marketplace add thenativeweb/claude-plugins

Anschließend installiert man das Plug-in:

/plugin install esdb@thenativeweb

Danach stehen die Skills zur Verfügung. Jeder Skill hat einen Namespace-Präfix, der sich aus dem Plug-in-Namen ergibt, und wird als Slash-Command aufgerufen. Um etwa die Erreichbarkeit einer EventSourcingDB-Instanz zu prüfen, genügt:

/esdb:ping

Für komplexere Interaktionen übergibt man Argumente in natürlicher Sprache. Ein Aufruf wie:

/esdb:write-events Schreibe ein Event vom Typ „io.eventsourcingdb.library.book-acquired“ für das Subject „/books/42“ mit den Daten title „2001“, author „Arthur C. Clarke“

veranlasst Claude Code, den passenden HTTP-Request zu konstruieren und an die Datenbank zu senden. Das Modell interpretiert die natürlichsprachliche Beschreibung, bildet sie auf die API-Parameter ab und gibt das Ergebnis lesbar aus. Dasselbe gilt für EventQL-Queries, bei denen Claude Code die Abfrage auf Basis der Skill-Beschreibung in das richtige Format übersetzt.

Besonders aufschlussreich war die Arbeit an den Skills für das Lesen und Beobachten von Events. Beide nutzen denselben Endpunkt, unterscheiden sich aber in ihrem Verhalten: Lesen liefert eine endliche Menge von Events und schließt die Verbindung, Beobachten hält die Verbindung offen und streamt neue Events in Echtzeit. Diese Unterscheidung musste in der Beschreibung klar herausgearbeitet werden, weil Claude Code sonst nicht wüsste, wann es die Verbindung schließen soll und wann nicht.

Hier zeigt sich ein wichtiges Muster: Die Qualität eines Skills hängt davon ab, wie gut man die Semantik einer Aktion beschreiben kann. Es reicht nicht, die technischen Parameter eines API-Aufrufs aufzulisten. Man muss dem Modell das Warum und das Wann vermitteln, nicht nur das Wie. Das ist eine andere Art zu denken als beim klassischen Programmieren, und sie erfordert eine andere Art von Sorgfalt.

Die Konfiguration des Plug-ins erfolgt über Umgebungsvariablen. Die URL der EventSourcingDB-Instanz und der API-Token werden beim Start gesetzt, und die Skills referenzieren diese Werte in ihren Beschreibungen. Auch das ist bemerkenswert einfach: keine Konfigurationsdateien, keine verschachtelten Einstellungen, keine Initialisierungslogik.

Plug-ins als Brücke zwischen KI und Fachdomäne

Was lässt sich aus dieser Erfahrung verallgemeinern? Drei Beobachtungen erscheinen mir besonders relevant.

Erstens: Die Einstiegshürde für Claude-Code-Plug-ins ist bemerkenswert niedrig. Wer eine HTTP-API hat und sie in natürlicher Sprache beschreiben kann, kann ein Plug-in bauen. Es sind keine besonderen Programmierkenntnisse nötig, kein Verständnis von Compiler-Infrastruktur, keine Erfahrung mit Plug-in-Architekturen. Die einzige Voraussetzung ist die Fähigkeit, präzise zu formulieren, was eine Aktion tut, welche Eingaben sie erwartet und welche Ausgaben sie liefert. Das macht die Plug-in-Entwicklung zugänglich für eine breite Gruppe von Entwicklerinnen und Entwicklern.

Zweitens: Skills als natürlichsprachliche Beschreibungen sind ein ungewöhnlich mächtiges Konzept. Sie ermöglichen es, domänenspezifisches Wissen in ein KI-Tool einzubringen, ohne eine einzige Zeile ausführbaren Code zu schreiben. Das verschiebt die Kernkompetenz: Nicht die Implementierung ist entscheidend, sondern das Verständnis der Domäne und die Fähigkeit, dieses Verständnis klar auszudrücken. Für Teams, die mit fachlich komplexen Systemen arbeiten, ist das ein interessanter Ansatz, weil er die Brücke zwischen Fachexpertise und Werkzeugentwicklung verkürzt.

Drittens: Die Grenze zwischen Plug-ins und MCP-Servern verschwimmt, und das ist beabsichtigt. Plug-ins eignen sich gut für Szenarien, in denen ein KI-Tool eine bestehende API nutzen soll und die Interaktion über natürliche Sprache gesteuert wird. MCP-Server sind die bessere Wahl, wenn man programmatische Kontrolle braucht, etwa für komplexe Authentifizierungsflüsse, zustandsbehaftete Sitzungen oder bidirektionale Kommunikation. Beide Ansätze ergänzen sich, und für viele Systeme lohnt es sich, beides anzubieten.

Was mich persönlich am meisten beeindruckt hat, ist die Verschiebung der Perspektive. Ich bin es seit vielen Jahren gewohnt, Code zu schreiben, der Maschinen sagt, was sie machen sollen. Bei einem Claude-Code-Plug-in hingegen schreibe ich lediglich natürlichsprachlichen Text, der einem Sprachmodell erklärt, was es tun soll. Das klingt technisch nach einem kleinen Unterschied, fühlt sich aber nach einem großen an. Die Frage ist nicht mehr „Wie implementiere ich das?“, sondern „Wie erkläre ich das so, dass es verstanden wird?“. Das ist vergleichbar mit einer Erklärung, die man Kolleginnen und Kollegen gibt.

Wer das Plug-in ausprobieren möchte, findet den Quellcode auf GitHub. Die Installation in Claude Code erfordert lediglich die beiden oben genannten Befehle. EventSourcingDB lässt sich bis 25.000 Events kostenfrei nutzen, sodass dem Experimentieren nichts im Wege steht. Wer ein eigenes Plug-in für eine andere API bauen möchte, braucht dafür nicht mehr als ein leeres Verzeichnis und die Bereitschaft, präzise zu formulieren.

(rme)

Cloudflare hat ein neues, einheitliches Kommandozeilen-Tool vorgestellt, das alle Produkte und APIs des Anbieters abdecken soll. cf befindet sich aktuell in einer Preview und soll langfristig die bisherige Fragmentierung auflösen: Statt je nach Produkt zwischen Dashboard, Wrangler-CLI, Terraform und REST-API zu wechseln, sollen Entwickler künftig alle Dienste über ein einziges Werkzeug steuern können. Gleichzeitig richtet Cloudflare das Tool auf die Nutzung durch KI-Agenten aus. Ebenfalls neu ist der Local Explorer, der erstmals direkten Einblick in lokal simulierte Cloudflare-Ressourcen bietet.

In Cloudflares Portfolio befinden sich aktuell mehr als 100 Produkte mit rund 3.000 API-Operationen. Dazu gehören die serverlose Laufzeitumgebung Workers, die Datenbank D1, der Objektspeicher R2, der Key-Value-Store KV und Durable Objects für zustandsbehaftete Anwendungen. Bislang verwalten Entwickler diese Dienste über verschiedene Werkzeuge: die Wrangler-CLI für Workers-Deployment, Miniflare für die lokale Emulation der Laufzeitumgebung, das Web-Dashboard und Terraform. Keines dieser Tools deckt alle Produkte ab.

Genau das soll cf ändern. Es erweitert Wrangler und bildet perspektivisch die gesamte API-Oberfläche ab. Entwickler können die Preview bereits per npx cf ausprobieren oder global über npm installieren. Cloudflare plant, dass sich über das neue Tool alle Dienste nach dem Infrastructure-as-Code-Prinzip konfigurieren lassen – mit einheitlicher Syntax. Ein Beispiel wäre cf kv get statt produktabhängig variierender Befehle.

TypeScript-Schema als zentrale Quelle

Unter der Haube steckt ein neues, TypeScript-basiertes Schema, das als zentrale Quelle für alle Schnittstellen dient. OpenAPI beschreibt nur REST-Endpunkte; das neue Schema erfasst darüber hinaus CLI-Kommandos, Konfigurationsdateien, Bindings sowie lokale Entwicklung und Tests. Daraus generiert Cloudflare automatisch SDKs, Terraform-Provider, Dokumentation und CLI-Befehle. Verbindliche Regeln auf Schema-Ebene erzwingen Konsistenz: Befehle heißen immer get, nie info; Flags wie --json stehen einheitlich zur Verfügung.

Diese Konsistenz zielt vor allem auf KI-Agenten, die Cloudflare inzwischen als „primäre Kunden“ der APIs betrachtet. Agenten sind auf vorhersagbare Schnittstellen angewiesen – weicht die Syntax eines Befehls von der erwarteten Konvention ab, rufen sie nicht existierende Kommandos auf. Ebenso wichtig: Die CLI signalisiert künftig klar, ob ein Befehl lokale oder entfernte Ressourcen betrifft. Bisher konnte es passieren, dass ein Agent eine lokale Datenbank beschrieb, während der Entwickler mit Remote-Bindings arbeitete.

Local Explorer für lokale Ressourcen

Der ebenfalls vorgestellte Local Explorer ermöglicht die Inspektion und Bearbeitung lokal simulierter Cloudflare-Ressourcen. Das Werkzeug integriert sich in Wrangler und das Cloudflare-Vite-Plugin und zeigt lokal simulierte Ressourcen wie KV, R2, D1, Durable Objects und Workflows an. Bisher mussten Entwickler dafür das Zustandsverzeichnis .wrangler/state durchsuchen oder auf Drittanbieter-Tools zurückgreifen. Nun lassen sich Datenbankinhalte direkt prüfen, Testdaten einfügen oder Tabellen zurücksetzen.

Technisch stellt der Local Explorer eine lokale Spiegelung der Cloudflare-API unter /cdn-cgi/explorer/api bereit. Diese verhält sich wie die produktive API, arbeitet aber ausschließlich mit lokalen Daten. Dadurch funktionieren dieselben CLI-Befehle lokal wie remote – ein Flag wie --local lenkt die Anfrage lediglich an den lokalen Endpunkt um. Ein D1-Query adressiert dann die lokale SQLite-Instanz statt der gehosteten Datenbank, ohne dass sich die Semantik ändert. Agenten können den lokalen API-Endpunkt direkt ansprechen und finden dort eine OpenAPI-Spezifikation vor.

Die Ankündigungen fallen in Cloudflares Agents Week, in der das Unternehmen seine Plattform stärker auf KI-Agenten ausrichtet. Weitere Neuerungen umfassen unter anderem Durable Object Facets für isolierte Datenbankinstanzen in dynamisch erzeugten Anwendungen, persistente Sandbox-Umgebungen für Agenten (jetzt allgemein verfügbar) sowie eine identitätsbasierte Zugriffskontrolle für ausgehende Verbindungen aus Sandboxes.

Die neue CLI unterstützt derzeit nur einen Teil der Cloudflare-Produkte. Die vollständige API-Abdeckung und die Integration bestehender Wrangler-Funktionen plant Cloudflare für die kommenden Monate. Das Unternehmen ruft Entwickler auf, über den Cloudflare-Developers-Discord Feedback zur weiteren Ausgestaltung zu geben.

(fo)