Kategorie: Tool-Tests

33 Prozent der 168 Anruferfragen bekamen in einem Vergleichstest Anfang Oktober eine falsche Seite vorgelegt. So oft führte die Suchkomponente eines KI-Telefonassistenten das Sprachmodell auf eine Webseite, die die Frage nicht beantwortete. Das Team des britischen Anbieters Sayora hat diesen Test dokumentiert und die Zahlen veröffentlicht – zusammen mit dem, was die Entwickler stattdessen ausprobiert haben. Der Assistent von Sayora nimmt Telefonate für Handwerksbetriebe, Immobilienmakler, Elektriker und Gastronomen an.

Wenn du dich mit RAG-Optimierung für einen AI-Rezeptionisten beschäftigst, kennst du den Aufbau: Website zerlegen, in Vektoren umrechnen, ähnlichste Passagen ins Sprachmodell geben. Das ist der Standard, und er funktioniert gut genug, um ihn auszuliefern. Interessant wird es dort, wo er versagt. Die folgende Analyse beschreibt, wie sich ein Entscheidungsmodell in derselben Rolle schlägt – ein Modell, das keinen Satz Text schreiben kann und trotzdem die richtige Seite findet.

Wie der KI-Telefonassistent heute eine Unternehmenswebsite liest

Die meisten Anrufe bei einem kleinen Betrieb sind Routine. Termine, Nachrichten, die Frage, ob samstags geöffnet ist. Schwieriger wird es bei Fragen über das Unternehmen selbst: Ist die Bewertung kostenlos? Baut ihr auch Wasserenthärter ein? Darf der Hund mit? Solche Antworten stehen fast immer auf der eigenen Website, und deshalb holt der Assistent sie sich von dort – auf zwei Wegen, je nach Größe.

Bei kleinen Seiten landen die Startseite oder bis zu acht Seiten direkt im Prompt. Bei größeren wird jede Seite in Abschnitte von 1.200 Zeichen mit 200 Zeichen Überlappung zerlegt und mit OpenAIs text-embedding-3-large auf 768 Dimensionen eingebettet. Bei jedem Redebeitrag des Anrufers wird das Gesagte erneut eingebettet, dazu eine Variante mit dem vorherigen Beitrag für Rückfragen, und alles über einer Kosinus-Ähnlichkeit von 0,36 landet im Kontext. Das ist vektorbasierte Suche nach Lehrbuch. Sayora hat genau dieses Rezept ausgeliefert.

Den Entwicklern hat daran trotzdem etwas nicht gefallen. Der Aufbau behandelt eine Website wie einen Haufen loser Dokumente, die man erst wieder zusammensetzen muss. Eine Firmenwebsite ist aber genau das nicht.

Warum das Zerlegen einer Website ihrem eigenen Aufbau widerspricht

Denk an einen Aktenschrank. Wer das Unternehmen kennt, hat die Unterlagen bereits sortiert: ein Ordner für die Kesselwartung, einer für die Gebühren, einer für das Team, einer für die Weihnachtskarte. Jede Seite behandelt genau eine Sache. Diese Ordnung ist selbst eine Information. Sie stammt von einem Menschen, der wusste, was er tat.

Das Chunking wirft diese Ordnung weg. Es schreddert die Ordner zu Konfetti und vertraut darauf, dass ein Ähnlichkeitsmaß den Sinn wieder zusammensetzt. Der Aktenschrank existiert also bereits, aber niemand schaut hinein.

Der Gegenvorschlag des Sayora-Teams: Seiten ganz lassen, jeder Seite eine kurze Beschreibung mitgeben und dem Assistenten ein Werkzeug in die Hand geben. Wenn er etwas nicht weiß, sagt er „ich schaue kurz nach“ und ruft es auf. Das Werkzeug stellt einem Modell eine Multiple-Choice-Frage: Welche dieser Seiten beantwortet das gerade Gesagte? „Keine davon“ ist eine der Antwortmöglichkeiten. Die ein oder zwei besten Seiten gehen anschließend ans Sprachmodell. Bei „keine“ sagt der Assistent, dass er es nicht weiß, und gibt die Frage weiter.

Ein Modell, das keinen Text schreibt, aber eine Seite auswählt

Die Auswahl übernimmt Jev, ein Entscheidungsmodell, das TypeSafe am 15. September vorgestellt hat. Jev generiert keinen Text. Man schickt ihm einen Zustand und typisierte Fragen, und es antwortet mit einer Wahl und einer Wahrscheinlichkeit für jede Option. Eine Auswahlfrage fasst bis zu 255 Optionen, eine Anfrage bis zu 64.000 Tokens. Der Preis liegt bei 0,042 US-Dollar pro Million Eingabe-Tokens, die Ausgabe ist kostenlos. Auf einer Website mit hundert Seiten sind das pro Nachschlag etwa ein Zwanzigstel Cent.

Die Form passt: Die Optionen sind die Seiten, der Zustand ist das, was der Anrufer gesagt hat, und „keine davon“ ist eine weitere Option. In einem protokollierten Beispiel fragt ein Anrufer, ob eine Immobilienbewertung etwas kostet. Der Assistent ruft das Werkzeug auf, Jev liest die Worte des Anrufers sowie 74 Seitenbeschreibungen plus „keine davon“ und liefert in 0,32 Sekunden „Property valuation“ mit 0,85, „None of these“ mit 0,08 und „Selling off-market“ mit 0,06 – bei 8.689 Eingabe-Tokens. Die obersten Seiten gehen an das Sprachmodell, das antwortet, die Bewertung sei kostenlos und unverbindlich.

Wichtiger als das Ranking ist die letzte Option. „Keine davon“ ist kein Schwellenwert auf einem Ähnlichkeitswert, sondern eine Alternative, die das Modell gegen jede Seite abwägt. Im Test war das der entscheidende Unterschied.

Der Test: 168 Fragen, 1.668 Urteile, neun Auswahlverfahren

Für den Vergleich nahm das Team vier Kundenwebsites und entfernte vorher alle Seiten, die ein Seitenauswähler nie sehen sollte. Einzelne Immobilienangebote fielen weg, weil dafür ohnehin ein Feed existiert, ebenso nahezu identische Landesseiten nach dem Muster „Elektriker in [Ort]“, weil eine Abdeckungsliste die Frage „kommt ihr nach X?“ besser beantwortet als die Wahl zwischen 31 Kopien derselben Seite. Übrig blieben eine Bar mit Restaurant (22 Seiten), ein Immobilienmakler (74), ein Elektriker (75) und ein Mehrgewerke-Wartungsbetrieb (232).

Claude Haiku 4.5 las jede Seite einmal und schrieb eine Beschreibung: Titel, Pfad, eine sachliche Zusammenfassung in 30 Wörtern und ein paar Fragen, die ein Anrufer stellen könnte – rund 100 Tokens pro Seite. Davon getrennt formulierte Claude Opus 5.5 anhand des Seitentexts, nie anhand der Beschreibungen, Fragen in der Sprache echter Anrufer. So entstanden 168 Fragen, 128 davon beantwortbar und 40 nicht. Bei einem Viertel der beantwortbaren kam nach zwei Gesprächsrunden noch eine Rückfrage im Stil von „und was kostet das?“.

Neun Verfahren traten gegen jede Frage an: Jev als einzelne Auswahlfrage über alle Seiten, Jev mit dünneren Beschreibungen, eine Embedding-Vorauswahl der besten 40 Seiten mit anschließender Jev-Entscheidung, GPT-6 Luna mit derselben Liste, Embeddings auf den Beschreibungen, Embeddings auf Chunks (die Produktionssuche) und BM25 als Stichwortsuche. Die Bewertung war gepoolt: Jede Seite, die ein Verfahren unter seinen ersten drei führte, ging an einen Richter, der den echten Seitentext las und entschied, ob ein Rezeptionist daraus antworten könnte. Das ergab 1.668 Urteile. Kein Verfahren wurde an Seiten gemessen, die ein anderes ausgewählt hatte. In sechs Fällen wechselte eine Frage die Kategorie – von beantwortbar zu unbeantwortbar oder umgekehrt –, weil der Richter im Seitentext doch oder eben keine Antwort fand. Die Intervalle stammen aus einem gepaarten Bootstrap über die Fragen.

Ranking: 88 gegen 70 Prozent, und der fairere Vergleich liegt bei 14 Punkten

Jev setzte bei 88 Prozent der beantwortbaren Fragen eine passende Seite an die erste Stelle und hatte sie bei 95 Prozent unter den ersten drei. Die Produktionssuche mit Embeddings kam auf 70 Prozent. Das sind 18 Punkte Vorsprung bei einem 95-Prozent-Intervall von 11 bis 26 – in Prozent ausgedrückt eine Verbesserung um 26 Prozent.

Der ehrlichere Vergleich läuft gegen Embeddings, die über exakt dieselben Beschreibungen laufen, die auch Jev gelesen hat. Dort schrumpft der Abstand auf 14 Punkte (7 bis 21) und bleibt klar über null. Stichwortsuche landet am Ende: BM25 auf Seitentext kommt auf 53 Prozent, auf Beschreibungen auf 57 Prozent. GPT-6 Luna, dem dieselbe Liste vorgelegt und bis zu drei Seiten-IDs oder „keine“ abverlangt wurden, erreichte 86 Prozent und lag damit zwei Punkte hinter Jev – innerhalb der Fehlerspanne kein Unterschied beim Auswählen, sehr wohl aber beim Tempo: Luna brauchte im Median 0,66 Sekunden gegenüber Jevs 0,28.

Auch die Beschreibungsqualität schlägt durch: Mit nur Titel und Zusammenfassung statt der vollen Beschreibung fällt Jev auf 86 Prozent, mit ausschließlich dem Titel auf 78 Prozent. Eine Embedding-Vorauswahl vor der Jev-Entscheidung bringt auf diesen kleinen Seiten nichts Messbares. Auf sehr großen Seiten dagegen schon: Dort holte eine 100-Seiten-Vorauswahl mit anschließender Jev-Wahl 95 Prozent richtige Erstanzeigen und übergab keine einzige falsche Seite. Jev und Embeddings schließen sich also nicht aus.

Die schwerere Fehlerart und die Schwäche des Verfahrens

Ranking ist nur die halbe Aufgabe. Am Telefon ist der schlimmere Fehler, dem Sprachmodell eine Seite zu übergeben, die die Frage nicht beantwortet – denn ein flüssig formulierender LLM baut sich aus fast allem eine Antwort. So zitiert ein Assistent dann die Durchschnittspreise aus einem Ratgeber, als wären es die Preise des Betriebs. Genau hier liegt der größte Abstand: Bei der Produktionsgrenze von 0,36 übergab die Chunk-Suche in 33 Prozent aller Fragen eine falsche Seite. Jev tat das in 3 Prozent der Fälle.

Der zweite Wert ist der aussagekräftigere. Von den 40 Fragen, die die Websites tatsächlich nicht beantworten, sagte die Chunk-Suche nur neunmal, die Antwort sei nicht auf der Website. Jev erkannte 38 von 40. GPT-6 Luna lag dazwischen: Es erkannte 80 Prozent der unbeantwortbaren Fragen und übergab in 8 Prozent der Fälle eine falsche Seite.

Man könnte einwenden, man müsse den Schwellenwert nur anheben. Das Team hat ihn durchgemessen – und zwar auf denselben Fragen, was die Suche begünstigt. Selbst dann kam die beste Chunk-Konfiguration auf 73 Prozent durchgehend richtig beantwortete Fragen und übergab noch in 15 Prozent der Fälle eine falsche Seite. Jev kam ohne jede Abstimmung auf 90 Prozent und 3 Prozent. Das liegt daran, dass „keine davon“ kein Grenzwert auf einem Ähnlichkeitswert ist, sondern eine Option, die gegen jede Seite abgewogen wird.

Die Fehleranalyse zeigt zudem ein Muster. Von den 39 Fragen, bei denen die Chunk-Suche eine falsche Seite an die erste Stelle setzte, gingen 23 an einen allgemeinen Ratgeber oder Blogbeitrag – „How to find a reliable plumber“ bei einer Leckage-Beschwerde, „Rewiring a house in the UK“ bei der Frage nach einem Zertifikat. Ein langer Ratgeber teilt mehr Wörter mit der Frage eines Anrufers als die kurze, konkrete Seite des Betriebs und gewinnt deshalb den Kosinus-Wettbewerb. Jev liest die Liste eher wie ein Mensch; wenn es danebenlag, dann meist zwischen fast identischen Seiten wie „Certified electrician“ und „Part P certificate“. Nur eine seiner 16 falschen Erstanzeigen war ein Ratgeber.

Die Schwäche liegt woanders. Jev liest Beschreibungen wörtlich. Auf die Frage nach Wasserenthärtern antwortete es mit 96 Prozent Sicherheit „keine davon“ – falsch, denn die Seite zur Sanitärinstallation erwähnt sie, nur die Beschreibung tat es nicht. Die Chunk-Suche fand die Seite, weil sie den Seitentext liest. Dasselbe passierte mit Schlüsseldienstleistungen auf einer Gebührenseite und Wallboxen auf einer Elektroinstallationsseite. Die Korrektur liegt beim Betreiber: Beschreibungen müssen die konkreten Dinge benennen, nach denen Anrufer fragen.

Sayora benennt die Grenzen des eigenen Tests selbst: Die 168 Fragen stammen von einem Modell, nicht aus echten Anrufen, die Stichprobe ist klein (rund 35 Fragen je Seite, ein einziger Durchlauf), ein einzelnes Modell war der Richter, und Jev ist erst drei Wochen alt. Für kleine Unternehmen mit einem AI-Rezeptionisten heißt das trotzdem: Der Wechsel von Embeddings zu einem Entscheidungsmodell ist keine Modellmode, sondern korrigiert eine falsche Annahme. Wer eine Firmenwebsite in Schnipsel zerlegt, wirft die Ordnung weg, die ein Mensch hineingelegt hat. Ein Modell, das aus einer Liste von Seiten wählt und „keine davon“ ernst meint, respektiert diese Ordnung. Es weiß auch, wann es schweigen sollte. Eine gelungene Rückfrage beim Chef ist am Telefon immer noch besser als eine erfundene Antwort. Und jedes Mal, wenn „keine davon“ anschlägt, hat der Betrieb eine Frage gefunden, die seine Website nicht beantwortet.

Quelle: sayora.ai

Eine einzige Empfehlung führt nicht automatisch schneller zum Kauf – sie kann ihn sogar verhindern. Das widerspricht der verbreiteten Annahme, ein KI-Assistent solle möglichst schnell eine einzige, präzise Antwort liefern, damit der Weg zur Kasse kürzer wird. Kristen Berman von Irrational Labs hat den Widerspruch selbst ausprobiert. Sie brauchte neue Hallenfußballschuhe, bat ChatGPT, Claude und Muse um Empfehlungen und bewertete das Ergebnis mit dem Werkzeugkasten der Verhaltenswissenschaft: Wie wurde die Entscheidung aufgebaut? Wie wurden die Optionen gerahmt? Gab es überhaupt etwas zum Vergleichen?

Der Fall ist unspektakulär, und genau das macht ihn brauchbar. Ein Paar Schuhe für etwa 100 Dollar – so sieht der Normalfall aus. Hier zeigt sich, ob ein Assistent wirklich berät oder nur eine Antwort ausliefert. Wer eine KI-Produktempfehlung entwirft, baut an einer Entscheidungsarchitektur, auch wenn das kaum jemand so nennt.

Der Aufbau: ein Budget, drei Assistenten, drei Bewertungskriterien

Laut Berman kamen drei Systeme zum Einsatz: Claude von Anthropic, ChatGPT von OpenAI und Muse. Alle drei sollten ihr helfen, ein Paar Hallenfußballschuhe zu kaufen, und jedes ging anders damit um. Bewertet wurde nicht, welcher Schuh objektiv der beste ist, sondern wie das System die Entscheidung vorbereitet. Drei Maßstäbe nennt die Autorin: Wie setzt der Assistent die Auswahl auf? Wie rahmt er die einzelnen Optionen? Und bekommt man überhaupt etwas, woran sich eine Empfehlung prüfen lässt?

Dahinter steht eine einfache Beobachtung aus der Verhaltensökonomie: Menschen treffen Entscheidungen selten absolut, sondern fast immer im Verhältnis zu etwas anderem. Ein Vorschlag ohne Vergleichsmaßstab bleibt ein Vorschlag ohne Überzeugungskraft. Berman beschreibt ihren Ansatz als „so einkaufen, wie eine Verhaltenswissenschaftlerin einkauft“ – also nicht nur auf das Ergebnis schauen, sondern auf den Weg dorthin.

Eine Randnotiz ist bezeichnend für den Umgang mit neuen Werkzeugen: Die Autorin spricht den Namen Muse im Video durchgehend falsch aus, mit voller Überzeugung. Sie verweist darauf, dass auch die US-Bildungsministerin KI einmal „A1“ genannt hat, wie die Steaksauce. Das ist eine Randnotiz mit Augenzwinkern, mehr nicht.

Warum eine einzelne Empfehlung den Kauf eher verhindert

Claude verengte die Auswahl drastisch: Aus vier gut beschriebenen Schuhen wurde einer, sobald das Budget von 100 Dollar bekannt war. ChatGPT machte es im reinen Textchat ähnlich und nannte am Ende einen einzigen Adidas-Schuh in zwei Farben, ohne Begründung. Bermans Reaktion auf dieses Ergebnis ist ungewöhnlich deutlich: Von so einer Antwort kauft sie keinen Schuh für 100 Dollar. Man kann das als Kritik an der Antwortqualität lesen. Spannender ist die verhaltenswissenschaftliche Erklärung.

Am Punkt der Entscheidung lautet die innere Frage nämlich nicht „welcher Schuh ist der beste?“, sondern „ist dieser Schuh wirklich richtig für mich?“. Eine einzelne Option liefert nichts, woran sich diese Frage prüfen ließe. Menschen bewerten Dinge schlecht in Isolation, weil ihnen der Bezugsrahmen fehlt. Sieht man dagegen einige Optionen, samt der Gründe, warum manche davon nicht passen, glaubt man der einen, die passt, eher – so beschreibt es Berman für sich selbst.

Ein gutes Bild dafür ist der Verkäufer im Sportgeschäft. Der eine stellt drei Paar Schuhe auf den Tresen und sagt, mit welchem man anfangen sollte. Der andere stellt ein Paar hin und verschwindet. Genau zwischen diesen beiden Verhaltensweisen lagen im Versuch die drei Assistenten. Die Autorin formuliert die Grenzen beider Extreme klar: Zu viele Optionen, und die Leute können sich nicht entscheiden. Zu wenige, und sie vertrauen der Empfehlung nicht.

Auch die Alternativen, die nicht passen, tragen zur Glaubwürdigkeit bei. Wer erklärt, warum andere Modelle weniger gut passen, zeigt, dass die Empfehlung aus einem Vergleich stammt. Damit verschiebt sich die Aufgabe eines KI-Assistenten: Er soll nicht filtern, bis nur noch ein Produkt übrig ist, sondern eine kleine Auswahl so ordnen, dass die eine richtige Antwort plausibel wird.

Drei Optionen mit Startempfehlung: wie ChatGPT die Entscheidung rahmt

In der Auswertung gewinnt ChatGPT die Choice Architecture, also den Aufbau der Entscheidung. Das System präsentierte drei Optionen mit Marke, Preis und Link – und benannte zusätzlich eine Startempfehlung, im Original ein „starting pick“. Damit war nicht nur klar, was zur Wahl steht, sondern auch, wo man anfangen soll. Die Autorin beschreibt, dass genau diese Kombination das Gefühl auslöste, sich sicher entscheiden zu können.

Das Muster findet sich in vielen Entscheidungssituationen. Ein Vorschlag ohne Kontext wirkt wie eine Behauptung. Eine Liste ohne Reihenfolge wirkt wie eine Aufgabe. Erst die Verbindung aus beidem – wenige Optionen plus eine begründete Startmarkierung – macht aus einer Auskunft eine Entscheidungshilfe. Wichtig ist die Darstellung: Der reine Textchat hatte sich vorher auf ein einziges Modell verengt. Erst die gerahmte Übersicht mit Preis und Link brachte die Struktur, die den Unterschied machte.

Die Autorin geht in ihrem Video noch auf einen zweiten Punkt ein: warum praktisch jeder KI-Assistent darauf drängt, den Kauf direkt im Chat abzuschließen. Ihre Antwort darauf steht nur im Video, nicht im begleitenden Text; der Beitrag selbst ist ausdrücklich nur eine Vorschau. Dort vergibt sie auch Noten nach einem verhaltenswissenschaftlichen Raster und wettet darauf, wer im E-Commerce vorn liegt.

Claude überzeugt mit Details, Muse mit dem Einkaufserlebnis

Claude lieferte laut Berman die besten Beschreibungen der drei Systeme. Formulierungen wie „gut für breite Füße“ sind der Stoff, aus dem sich ein sicheres Kaufgefühl bildet, weil sie eine konkrete Sorge adressieren. Trotzdem blieb der Funke aus: Es fehlten Preise, es fehlten Bilder, und ein Link zum Kaufen war ebenfalls nicht dabei. Detailtiefe allein trägt keine Kaufentscheidung, wenn der Rest der Einkaufserfahrung fehlt.

Muse kam dem echten Einkaufen am nächsten. Die Fragen fühlten sich wie ein Spiel an, das System zeigte, wie es denkt, und es zeigte Bilder – etwas, das die anderen beiden nicht taten. Das erzeugt Nähe und Bewegung, zwei Dinge, die im stationären Handel selbstverständlich sind. Gleichzeitig nahm sich Muse selbst aus dem Rennen, weil es zu Beginn die falschen Schuhe empfahl. Die Autorin hält fest, dass die Browsing-Erfahrung deutlich besser werden muss, damit man dem Ergebnis wirklich vertraut.

Damit stehen drei sehr unterschiedliche Profile nebeneinander: Präzision bei Claude, Klarheit bei ChatGPT, Erlebnis bei Muse. Keines deckte alle drei Dimensionen ab. Der Vergleich zeigt, dass Antwortqualität und Entscheidungsarchitektur zwei verschiedene Dinge sind. Ein Assistent kann fachlich hervorragend beraten und trotzdem niemanden zum Kauf bewegen – oder umgekehrt unterhaltsam sein und die falsche Ware anbieten.

Zwei Fallstudien: drei Optionen plus Empfehlung

Berman bleibt nicht bei der Einzelbeobachtung stehen, sondern verweist auf zwei getestete Fälle aus der eigenen Arbeit. Im ersten ging es um das Onboarding für die Lohnabrechnung bei Intuit. Neuen Mitarbeitenden wurden drei mögliche Sparbeträge vom Gehalt präsentiert, wobei die mittlere Option als Empfehlung markiert war. Rund 20 Prozent der Menschen sparten anschließend, gegenüber etwa 3 Prozent in der Kontrollgruppe. Die meisten wählten genau die empfohlene Mitte.

Im zweiten Fall ging es um die brasilianische Börse B3. Anleger mit auslaufenden Staatsanleihen erhielten eine E-Mail mit drei Optionen, die der bereits gehaltenen Anlage ähnelten. Jede Option war nach Laufzeit benannt, damit sie sich mit den eigenen Zielen abgleichen ließ, und die populärste war gekennzeichnet. Diese Variante führte zu etwa 4,3-mal mehr geplanten Wiederanlagen als die Kontrollversion. Beide Beispiele folgen demselben Muster: Eine Empfehlung gibt den Startpunkt, die Alternativen liefern den Grund, ihr zu vertrauen.

Die Autorin ordnet die Ergebnisse selbst zurückhaltend ein. Es sind kleine Eingriffe, sie passen nicht zwangsläufig zu jedem Produkt, und deshalb sollte man sie im eigenen Kontext testen. Eine allgemeingültige richtige Antwort auf Choice Architecture gibt es nicht, aber belastbare Hinweise darauf, womit man anfangen kann. Drei Optionen mit einer markierten Empfehlung sind ein solcher Hinweis – gemessen allerdings an Sparquoten und geplanten Wiederanlagen, nicht an Kaufabschlüssen.

Was daraus für Kaufberatung per KI folgt

Jedes Produkt, das etwas empfiehlt, entwirft einen Entscheidungsrahmen. Die Aufgabe dieses Rahmens ist nicht, möglichst schnell eine Antwort zu liefern, sondern Menschen sicher in ihrer Antwort zu machen. Daraus folgt eine Faustregel für die Informationsdichte: Zu wenig Kontext, und der Nutzer verschiebt die Entscheidung und springt ab. Zu viel, und die Auswahl lähmt. Die brauchbare Zone liegt dazwischen und lässt sich messen.

Für die Praxis heißt das: Eine Empfehlung gehört mit dem letzten Schritt verbunden. Ein Kaufberater sollte Bilder, Preise und einen direkten Weg zum Kauf mitliefern – Claude lieferte den nicht, und dort brach die Kette. Zur Entscheidungsarchitektur gehört außerdem die Begründung. Ein kurzer Satz wie „gut für breite Füße“ ist laut Berman genau das Detail, das einen Kauf sicher wirken lässt.

Wer KI-Assistenten für Produktempfehlungen vergleicht, sollte nicht nur auf die inhaltliche Qualität der Antworten schauen. Drei Fragen reichen als Raster: Wie viele Optionen werden gezeigt? Gibt es eine markierte Startempfehlung? Und führt der Weg zur Kasse ohne Medienbruch? Choice Architecture im E-Commerce ist dann keine Designfrage am Rand, sondern die Arbeit an der Schnittstelle zwischen Beratung und Abschluss.

Der Versuch mit den Hallenfußballschuhen ist eine Stichprobe von eins, die Fallstudien kommen aus zwei unterschiedlichen Branchen, und keine der Mechaniken ist ein Naturgesetz. Ein überprüfbares Muster bleibt trotzdem: wenige Optionen, eine begründete Empfehlung, genug Information für Vertrauen und ein sichtbarer Kaufweg. Wer an E-Commerce-Erfahrungen oder an Entscheidungsrahmen in Sprachmodellen arbeitet, kann das als Ausgangspunkt nehmen – aber besser im eigenen Produkt nachmessen, statt es einfach zu übernehmen.

Quelle: kristenberman.substack.com

„Teams kosten das 1,8- bis 5,1-Fache eines einzelnen Agenten, und nur einer der gemessenen Punkte-Unterschiede war statistisch signifikant.“ So fasst Katrina Drozdov von Vals AI am 9. Oktober die Messreihe zusammen, die das Unternehmen auf seinem eigenen Benchmark Vibe Code Bench gefahren hat. Ein nüchterner Befund für eine Technik, die als nächster großer Schritt der KI-Entwicklung gilt. Wer heute Multi-Agenten-Systeme baut, sollte diese Zahlen kennen — nicht weil sie gegen Agenten-Teams sprechen, sondern weil sie zeigen, wo sie sich rechnen und wo nicht. Wie war der Test aufgebaut, was hat er gemessen, und was davon lässt sich übertragen?

Der Testaufbau: 50 Webanwendungen, ein Grader, acht Konstellationen

Sowohl OpenAI als auch Anthropic liefern inzwischen native Unterstützung für Multi-Agenten-Systeme. Ein Lead-Agent kann Subagenten starten, jedem einen Teil der Aufgabe übergeben und anschließend zusammenführen, was zurückkommt. Genau diese Funktion haben die Autoren der Studie gegen den Einzelagenten gestellt. Als Prüfstand diente Vibe Code Bench, ein Benchmark, bei dem aus einer Produktspezifikation eine vollständige Webanwendung entstehen muss. Jede App wird per Docker Compose deployt und von Browser-Agenten bewertet, die sich durch die Workflows klicken. Die Punktzahl ist der Anteil bestandener UI-Tests, gemittelt über 50 Anwendungen.

Der Aufbau passt zu dieser Frage, weil die Arbeit sich fast von selbst in vier Gewerke zerlegt: Datenbank, API, Oberfläche und Deployment. Man kann sich das wie eine Baustelle vorstellen, auf der Rohbau, Elektrik, Sanitär und Fliesen jeweils sauber arbeiten — und am Ende trotzdem die Steckdose über dem Waschbecken sitzt. Solche Übergabefehler schlagen im Benchmark direkt auf die Punktzahl durch. Wer an den Nahtstellen patzt, verliert Punkte.

Getestet wurden GPT-6 Sol und Claude Opus 5.5, jeweils als Einzelagent und als Team, bei mittlerem und maximalem Reasoning-Aufwand. Das ergibt acht Konstellationen, die jeweils einmal über dieselben 50 Apps liefen. Im Team durfte der Lead bis zu fünf Subagenten gleichzeitig beschäftigen; Subagenten durften keine eigenen starten. Beide Leads erhielten dieselbe kurze Anweisung: die Arbeit in unabhängige Teile zerlegen, jeden Teil delegieren, danach integrieren und das Ergebnis prüfen. Aufgabe, Sandbox und Bewertung waren ansonsten identisch.

Teams kosten das Zwei- bis Fünffache — und bringen meist keine gesicherten Punkte

Die Kostenseite ist eindeutig. Ein Team kostete zwischen dem 1,8- und dem 5,1-Fachen eines Einzelagenten derselben Modellstufe. Bei Sol waren das 3,07 statt 1,22 Dollar pro App bei mittlerem Aufwand, also Faktor 2,5, und 8,54 statt 4,82 Dollar bei maximalem Aufwand, Faktor 1,8. Bei Opus fiel der Sprung größer aus: 9,10 statt 4,08 Dollar nach oben, ein Faktor 2,2, und im Maximalmodus rund 122 statt 23,77 Dollar pro App, ein Faktor von 5,1.

Der Punktezugewinn ist dagegen dünn. Nur Sols Team bei mittlerem Aufwand lag mit 7,3 Punkten klar über seinem Einzelagenten, mit p = 0,005 und einem 95-Prozent-Intervall von +2,3 bis +12,4 Punkten. Die drei anderen Differenzen waren statistisch nicht abgesichert: +1,4 Punkte für Sol bei maximalem Aufwand, −0,3 Punkte für Opus bei mittlerem Aufwand und +3,4 Punkte für Opus bei maximalem Aufwand, mit p-Werten zwischen 0,16 und 0,81. Ein Team kann also mehr Punkte bringen — nur belegen lässt sich das in diesem Datensatz fast nirgends.

Woher die Rechnung kommt, lässt sich nachvollziehen. Jeder Subagent hat sein eigenes Kontextfenster mit Spezifikation und aktuellem Arbeitsstand, und dieses Kontextfenster wird bei jedem Modellaufruf erneut mitgeschickt. Bei Opus‘ Maximal-Team lasen die Subagenten im Median 224 Millionen gecachte Tokens pro App, gegenüber 17 Millionen beim Lead und 55 Millionen beim Einzelagenten. Es ist kein Rechenfehler, sondern die Struktur des Verfahrens. Jeder im Team liest mit, und zwar bei jedem Schritt. Ein Opus-Maximal-Team lief in die Zeitgrenze, während es noch verifizierte; seine Kosten von rund 189 Dollar wurden aus den Token-Zahlen geschätzt und in den Mittelwert aufgenommen.

Zwei Lead-Agenten, zwei Arbeitsstile: paralleles Aufteilen gegen einen schriftlichen Vertrag

Interessanter als die Mittelwerte ist, wie unterschiedlich die beiden Leads dieselbe Anweisung umsetzten. Sols Lead zerlegte die App entlang der Architektur — Datenbank samt Seed-Daten, API, Oberfläche, Deployment — und startete alle Subagenten innerhalb etwa einer Minute. Bei maximalem Aufwand teilte er die Oberfläche häufiger in einzelne Funktionsbereiche auf, in 13 von 50 Läufen gegenüber 7 bei mittlerem Aufwand, und legte später im Lauf weitere Subagenten nach. Er beschäftigte etwas mehr Subagenten, 5,1 statt 4,2, und schickte ihnen fast doppelt so viele Nachfass-Anfragen, 31 statt 18 pro App.

Vor allem prüfte dieser Lead das Ergebnis selbst. Er steuerte in 46 von 50 Läufen einen Headless-Browser durch die App und führte dabei etwa doppelt so viele Browsertests aus wie der Einzelagent, überwiegend gegen die öffentliche URL der Anwendung statt gegen localhost innerhalb der Sandbox. Bei mittlerem Aufwand testete der Einzelagent in 18 von 50 Läufen ausschließlich auf localhost, der Team-Lead nur in 4 von 50. In seinen Notizen berichtet der Lead von Fehlern, die erst beim Zusammenkommen der separat gebauten Teile auftreten — eine Oberfläche, die Felder sendet, die nicht zum Datenbankschema passen, oder eine Summe, die in der Oberfläche anders berechnet wird als in der Datenbank. Jede Korrektur ging zurück an den Subagenten, dem die Datei gehörte.

Opus‘ Lead arbeitete genau umgekehrt. Bevor er überhaupt einen Agenten startete, schrieb er ein gemeinsames Dokument, meist `CONTRACT.md`, das Schema, API-Routen und Dateieigentum festhielt — in 42 von 50 Läufen bei mittlerem Aufwand und in 40 von 50 im Maximalmodus; die Einzelagenten taten das praktisch nie. Danach delegierte er in Wellen: bei mittlerem Aufwand erst die Builder, dann meist einen Subagenten für End-to-End-Tests. Bei maximalem Aufwand kam eine Stufe dazu — zuerst das Fundament, dann Features darauf, dann Test und Review. Die READMEs schrieb der Lead in den meisten Läufen selbst, Anwendungscode bearbeitete er in 10 von 50 Läufen bei mittlerem Aufwand und in 26 von 50 im Maximalmodus. Dort umfasste das Team 6,8 Subagenten pro App, in allen 50 Läufen einen Test-Subagenten und rund 1.140 Tool-Aufrufe der Subagenten pro App, gegenüber etwa 270 beim Einzelagenten mit maximalem Aufwand.

Mehr Denkaufwand statt mehr Agenten: Woher der Punktegewinn kam

Team und höherer Reasoning-Aufwand treiben beide die Kosten — nur wirken sie unterschiedlich auf die Punktzahl. Für Sol brachte maximaler Aufwand beim Einzelagenten 11,4 Punkte (p < 0,001), also mehr als die 7,3 Punkte, die ein Team bei mittlerem Aufwand hinzufügte. Der Maximal-Einzelagent lag mit 89,0 Prozent sogar 4,1 Punkte über dem Mittel-Team, ein Unterschied, der nicht signifikant war (p = 0,08) — bei 1,6-fachen Kosten und dreifacher Laufzeit. Bei Sol war die naheliegende Reihenfolge also: erst mehr Aufwand, dann überhaupt über Teams nachdenken.

Bei Opus sah es anders aus. Maximaler Aufwand allein hob die Punktzahl nicht: 89,8 Prozent für 23,77 Dollar gegen 91,5 Prozent für 4,08 Dollar bei mittlerem Aufwand (p = 0,48). Die höchste Punktzahl der ganzen Untersuchung erzielte die Kombination aus maximalem Aufwand und Team mit 93,2 Prozent — zum dreißigfachen Preis des mittleren Einzelagenten, und der Vorsprung von 1,6 Punkten war nicht signifikant (p = 0,36). Über die Modelle hinweg lagen Sols Maximal-Team mit 90,4 Prozent und 8,54 Dollar nur etwa einen Punkt unter Opus‘ mittlerem Einzelagenten, bei doppeltem Preis. Keine dieser Optionen ist ein klarer Standard. Höherer Aufwand brachte Sol mehr, Opus‘ billigste Konfiguration schnitt auf dieser Aufgabenmenge etwa so gut ab wie seine teuerste.

Wo die Zeit hingeht: Der erste Deploy ist nicht der Engpass

Teams und Einzelagenten erreichten ihren ersten Deploy, also das erste erfolgreiche `docker compose up`, ungefähr gleichzeitig. Bei mittlerem Aufwand lagen die Teams jeweils innerhalb einer Minute zum Einzelagenten. Im Maximalmodus deployte Sols Team etwa fünf Minuten früher, Opus‘ Team etwa sechs Minuten später. Der Unterschied entsteht danach. Opus‘ Maximal-Team verbrachte zwei Drittel seiner Laufzeit nach dem ersten Deploy, sein Einzelagent weniger als ein Drittel. In dieser Phase investierten Lead und Subagenten im Median 68 Agenten-Minuten in Tests, zusammengerechnet über alle Beteiligten, gegenüber 10 Minuten beim Einzelagenten.

Parallelität sparte Zeit nur bei Sol, und dort vor allem im Maximalmodus: 28 statt 38 Minuten. Opus‘ Teams brauchten länger, im Maximalmodus bis zum 2,3-Fachen des Einzelagenten. Sie arbeiteten in sequenziellen Wellen, die jeweils auf ihr langsamstes Mitglied warteten, und im Maximalmodus lief ein Subagent im Median 46 Minuten, gegenüber 7 Minuten bei mittlerem Aufwand. Die zusätzliche Zeit war dabei echte Subagenten-Arbeit, keine Wartezeit. Genützt hat sie wenig: Beim Opus-Maximal-Team zeigte sich über die Apps hinweg keine Korrelation zwischen Laufzeit und Punktegewinn gegenüber dem Einzelagenten. Vier Läufe dauerten über vier Stunden, einer riss die Grenze von 5,25 Stunden.

Was das für die Praxis bedeutet

Ob sich Multi-Agenten-Systeme lohnen, lässt sich nach diesem Datensatz so beantworten: manchmal, und im Mittel nur knapp. Der eine belastbare Gewinn entstand dort, wo der Einzelagent noch schwach war und die Arbeit sich sauber an Architekturgrenzen teilen ließ. Sols mittleres Team bei 84,9 statt 77,6 Prozent ist genau dieses Muster. Es war auf 24 Apps besser als der Einzelagent, auf 11 schlechter und auf 15 gleich, und der Gewinn lag fast ganz bei den schwierigeren Apps: dort rund 15 Punkte, bei den leichteren etwa einen. Auf den neun Apps, auf denen das Team 20 Punkte oder mehr zulegte, hatten die Einzelagenten gemeldet, die Tests seien bestanden, obwohl manche Funktionen nie gebaut und ganze Abläufe nie ausprobiert worden waren. Das Team baute diese Funktionen und prüfte die getrennt gebauten Teile gegeneinander. Wo der Einzelagent dagegen schon bei 91,5 Prozent lag, wie Opus bei mittlerem Aufwand, brachte das Team nichts mehr und kostete das Doppelte.

Für die Praxis heißt das, die Reihenfolge umzudrehen. Erst den Einzelagenten mit mehr Reasoning-Aufwand und besserer Werkzeugnutzung ausreizen, das messen, und Agenten erst dann hinzunehmen, wenn der Flaschenhals nachweislich in der Arbeitsmenge liegt und nicht in der Qualität. Achte außerdem auf zwei Details, die in den Logs deutlich sichtbar sind: Ein Lead, der selbst gegen die deployte Anwendung testet, findet Nahtstellenfehler, die kein Subagent in seiner Sandbox sieht. Und Kontext, der pro Subagent mitgeschleppt wird, ist der eigentliche Kostentreiber — nicht die Anzahl der Modellaufrufe an sich. Opus‘ Maximal-Team mit 224 Millionen gecachten Tokens pro App ist dafür das anschaulichste Beispiel.

Man sollte die Studie allerdings nicht überdehnen. Es sind 50 Apps, jede Konstellation lief einmal, und alle Aufgaben stammen aus einem einzigen Feld: vollständige Webanwendungen aus einer Spezifikation. Die Autoren sagen das selbst und nennen weitere Grenzen: Die Teams bekamen zusätzlich eine Delegationsanweisung, verglichen wird also „Subagenten plus Anweisung“ mit keinem von beidem. Die Modelle liefen in verschiedenen Umgebungen, Sol über die Agents API von OpenAI, Opus über Claude Code, sodass Vergleiche zwischen den Modellen immer auch die Umgebung mitmessen. Und bei Sol beruhen die Kosten auf der Annahme, dass die gemeldeten Token die Subagenten enthalten; höhere Preise für sehr lange Kontexte konnten nicht berücksichtigt werden. Für Recherche, Datenanalyse oder Arbeit mit eng verzahnten Abhängigkeiten kann die Bilanz anders aussehen, in beide Richtungen. Festzuhalten bleibt: Agenten-Teams sind kein Schalter, den man umlegt, um besser zu werden. Sie verursachen laufende Kosten. Wer sie einsetzt, sollte sich auf eine Messung stützen, nicht auf das Gefühl, dass mehr Agenten mehr Ergebnis bedeuten.

Quelle: vals.ai

Wie findet und behebt Devin Sicherheitslücken im eigenen Code? Security Swarm, das Sicherheitsprodukt von Cognition, soll diese Frage beantworten. Das Werkzeug durchsucht ein Repository nach Schwachstellen, bewertet sie und schlägt Korrekturen vor. Der folgende Überblick fasst die Dokumentation des Herstellers zusammen: was der Scan leistet, wie man ihn bedient und wo die Grenzen liegen.

Was Security Swarm ist und wie Agentic MapReduce arbeitet

Security Swarm ist laut Devin Docs ein Produkt für Sicherheitsscans und deren Behebung. Es erstellt zuerst ein Bedrohungsmodell, das auf den konkreten Code zugeschnitten ist, untersucht dann potenzielle Schwachstellen und hilft, die Befunde über Pull Requests zu beheben. Erfasst werden unter anderem Remote Code Execution, SQL-Injection, Path Traversal, Server-Side Request Forgery, Authorization Bypasses, Memory-Safety-Fehler und Denial-of-Service. Auch verkettete Exploits über mehrere Dateien sollen erkannt werden.

Man kann sich das wie ein Ermittlerteam vorstellen, das ein großes Gebäude durchkämmt. Statt dass ein einzelner Prüfer jeden Raum abläuft, bekommt jeder Ermittler einen Trakt, und alle arbeiten parallel. Am Ende werden die Notizen zusammengeführt. Genau das ist der Kern der Schwachstellenanalyse in diesem System: nicht ein längerer Spaziergang, sondern viele gleichzeitige.

Das Verfahren nennt der Anbieter Agentic MapReduce. Das Repository wird unter parallelen Devin-Instanzen aufgeteilt, was breite Abdeckung bei tiefer Untersuchung erlaubt, ohne die Kosten aus dem Ruder laufen zu lassen. Laut Anbieter macht das den Scan auch großer Codebasen praktikabel. Nach eigenen Angaben hat Cognition Security Swarm gegen einen Referenzdatensatz veröffentlichter Schwachstellen aus der GitHub Advisory Database getestet; Ergebnisse nennt die Dokumentationsseite nicht.

Wer scannen darf: Rollen und Berechtigungen

Vor einem Lauf müssen die organisatorischen Voraussetzungen stimmen. Die Organisation braucht Zugriff auf das Repository, und die angemeldete Person muss Devin-Sitzungen nutzen dürfen. Verlangt wird außerdem die Berechtigung „Use code scans“. Für automatische Scans nach Zeitplan braucht man zusätzlich „Manage code scans“ und das Recht, Automatisierungen zu verwalten.

Fehlt der Eintrag „Security“ in der Seitenleiste oder lässt sich kein Scan starten, liegt das meist an der zugewiesenen Rolle. Ein Administrator sollte dann die Rechte prüfen und die Rolle anpassen.

Der erste Scan

Der erste Durchlauf folgt einer festen Reihenfolge. Man öffnet „Security“ in der linken Seitenleiste und klickt auf „Start scan“. Unter „Single repo“ wählt man ein Repository aus, optional ein Scan-Profil und einen Aufwandsgrad – bleibt das Profil leer, greift der Standardscan. Danach prüft man, ob der interaktive Modus aktiv ist, und startet den Lauf.

Sobald das vorgeschlagene Bedrohungsmodell fertig ist, wird es geprüft. Man bestätigt mit „Looks good, start scanning“ oder gibt Rückmeldung, woraufhin ein überarbeitetes Modell entsteht. Während der Untersuchung erscheinen nach und nach Befunde, die man einzeln bewertet und abarbeitet. Beim ersten Repository sollte man den interaktiven Modus eingeschaltet lassen. Er kostet einen Zwischenschritt, gibt aber die Gelegenheit, das Bedrohungsmodell zu korrigieren, bevor die Untersuchung beginnt. Dasselbe empfiehlt die Dokumentation, wenn sich Risikofläche oder Profil deutlich ändern.

Neben dem Einzelmodus bietet das Fenster für neue Scans weitere Varianten: mehrere Repositories gleichzeitig oder der Import von Befunden aus einem bestehenden Scanner. Sie sind weiter unten beschrieben.

Findings bewerten und Sicherheitslücken mit Pull Requests beheben

Ein geöffneter Scan zeigt links die Funde nach Schweregrad gruppiert und rechts die Details des ausgewählten Eintrags. Die Statusreiter zählen live mit: „Open“ braucht Aufmerksamkeit, „Reviewed“ ist gesichtet und braucht keine Aktion mehr, „Dismissed“ markiert Fehlalarm oder Dublette. Während der Scan läuft, aktualisiert sich die Seite automatisch, sobald neue Befunde eintreffen. Wichtig: „Reviewed“ ist ein Arbeitsstatus und keine Bestätigung, dass ein Fix zusammengeführt wurde.

Ein Finding enthält mehr als eine Zeile Warnung. Aufgeführt werden Schweregrad, Status, Ausnutzbarkeit, Konfidenz und Kategorie, dazu der betroffene Dateipfad mit Codeausschnitten. Dazu kommen eine Beschreibung des Problems, eine Empfehlung zur Behebung und das Ergebnis einer Sandbox-Validierung samt Belegen. Sind Pull Requests verknüpft, zeigt die Ansicht deren Zustand – offen, zusammengeführt oder geschlossen.

Aus einem Fund heraus gibt es drei Aktionen. „Assign to Devin“ startet eine Sitzung, die das Problem behebt und einen Pull Request öffnet; Sitzung und Pull Request bleiben am Finding verfolgbar. „Feedback“ schickt Kontext an eine Sitzung, die das Scan-Profil für künftige Läufe schärft – etwa der Hinweis, dass ein gemeldeter Datenfluss durch ein internes Gateway geschützt ist. „Adjust Status“ stuft den Schweregrad neu ein, optional mit Begründung, und markiert einen Fund als offen, geprüft oder verworfen. Wer Lücken beheben statt nur sammeln will, arbeitet an dieser Stelle.

Scan-Profile: von der Bedrohung bis zur Validierung

Ein Scan-Profil steuert den Umfang des Laufs und gibt für jede Phase Anweisungen. Jeder Scan nutzt genau ein Profil; um ein Repository gegen mehrere Angreifertypen zu prüfen, startet man mehrere Läufe mit unterschiedlichen Profilen. Verwaltet werden sie im Reiter „Profiles“ der Security-Seite.

Ein Profil lässt sich auf zwei Wegen anlegen. Bei „Generate with Devin“ beschreibt man Anwendung, Bedrohungen, Umfang, Ausschlüsse und Schweregrad-Standards in natürlicher Sprache, und Devin entwirft das Profil. Alternativ füllt man jedes Feld manuell aus. Der generierte Entwurf ist ein brauchbarer Startpunkt, aber jedes Feld sollte vor der Nutzung geprüft werden. Bleibt ein optionales Feld leer, greift das eingebaute Standardverhalten.

Ein Profil deckt mehrere Stationen ab. Das Bedrohungsmodell beschreibt Angreifer, schützenswerte Werte, Vertrauensgrenzen und Einstiegspunkte. Die Untersuchungsanleitung legt fest, wie Devin ein Problem verfolgt und welche Belege es sammelt, inklusive bestehender Schutzmaßnahmen. Die Triage-Anleitung bestimmt, wie Funde dedupliziert und priorisiert werden. Optional lässt sich die Sandbox-Validierung aktivieren, die für jeden Fund ab einem einstellbaren Schweregrad (standardmäßig kritisch, hoch und mittel) eine eigene Sitzung startet und prüft, ob sich die Lücke tatsächlich ausnutzen lässt. Dafür braucht das Profil Anweisungen, wie die Anwendung gebaut, gestartet und mit Testdaten bestückt wird. Und eine gescheiterte Validierung widerlegt einen Fund nicht unbedingt. Für die Behebung kann das Profil außerdem Vorgaben machen, etwa kleinste sichere Änderung, Regressionstest und keine großen Abhängigkeits-Upgrades. Über erweiterte Eingaben steuert man Dateimuster und die Batch-Größe, die zwischen einem und 500 Dateien liegt und standardmäßig bei fünf steht.

Ingest-Profile bilden den zweiten Modus und eignen sich, wenn bereits Befunde aus anderen Werkzeugen vorliegen. Statt Code zu analysieren, importieren sie Ergebnisse und ersetzen die Scope- und Bedrohungsfelder durch zwei Angaben: die Ingestion-Quelle und die Triage nach dem Import. So lassen sich offene Alarme aus dem GitHub Code Scanning per REST-Schnittstelle holen oder ein Semgrep-Bericht einlesen. Zugangsdaten gehören dabei als Organisationsgeheimnis referenziert, nicht als eingefügter Token. Neue Profile gelten organisationsweit; Enterprise-Administratoren können die Sichtbarkeit später auf das gesamte Unternehmen ausweiten.

Skalierung: Scan-Modi, Aufwand und Kostenrahmen

Für größere Vorhaben bietet das Fenster für neue Scans vier Modi. „Single repo“ prüft ein einzelnes Repository, „Multi-repo“ analysiert bis zu 200 Repositories gemeinsam, sodass auch Fehler über Repositoriumgrenzen hinweg auffallen. „Bulk scan“ startet für jedes passende Repository einen eigenen, unabhängigen Lauf, während „Ingest findings“ bestehende Ergebnisse importiert. Der Bulk-Modus erlaubt eine Filterung nach Repository-Namen und überspringt auf Wunsch bereits gescannte Repositories; die Vorschau ist ein Probelauf und wird ungültig, sobald man Filter oder Profil ändert.

Beim Aufwand gibt es zwei Stufen. „Normal“ ist der Standard: schneller, mit größeren Untersuchungsstapeln. „Deep“ verfolgt jeden Fund weiter durch die Codebasis, kostet mehr und dauert länger. Für Routine- und inkrementelle Scans reicht Normal; ein erster Lauf über eine risikoreiche Codebasis oder eine periodische Tiefenprüfung spricht für Deep. Welcher Aufwand verwendet wurde, steht anschließend im Kopf des Scans.

Bezahlt wird nicht pro Scan, sondern über Rechenzeit: Scans laufen als Devin-Sitzungen und verbrauchen ACUs, die der Kopf jedes Scans samt Dauer und Pull-Request-Statistik ausweist. Günstiger wird es mit Auto Scan, der täglich, wöchentlich oder monatlich nur die Commits seit dem letzten abgeschlossenen Lauf untersucht; dasselbe leistet „Scan new commits“ von Hand. Wer Cognitions Agenten schon kennt, findet hier dieselbe Sitzungslogik wie beim Lernen aus vergangenen Sitzungen.

Security Swarm ersetzt kein Sicherheitsteam, sondern verstärkt es dort, wo Arbeit sonst liegen bleibt. Das Werkzeug durchsucht, validiert und schlägt Korrekturen vor; die Entscheidung, was ein Risiko ist und was nicht, bleibt beim Menschen. Auch die Dokumentation sagt deutlich: Kein Scanner garantiert vollständige Abdeckung, und weil die Analyse agentisch läuft, können zwei Scans unterschiedliche Funde liefern. Ein klar umrissenes Profil und der interaktive Modus für die ersten Läufe machen die Ergebnisse vergleichbarer. Wer ihn einmalig laufen lässt und die Findings ignoriert, hat vor allem ein gutes Gefühl gekauft.

Quelle: docs.devin.ai

Ivo Kund war zunächst skeptisch. Mods? Claude Code hatte doch schon Hooks, was sollte da noch Besonderes kommen? So beginnt sein „First look at Claude Code mods“, und der Untertitel verrät das Urteil gleich mit: „spoiler: yes, use one now!“ Kund schreibt auf seinem Blog über die Arbeit mit KI-Agenten; der Beitrag ist ein kurzer Erfahrungsbericht nach den ersten eigenen Mods.

Was Mods sind und warum sie mehr können als Hooks

Mods sind Erweiterungen, die das Verhalten und die Oberfläche von Claude Code verändern. Auf den ersten Blick klingt das wie Hooks, also kurze Skripte, die auf Ereignisse reagieren und etwa Logging oder Formatierung übernehmen. Genau daran setzte Kunds Skepsis an. Was Mods im Einzelnen können, erklärt er bewusst nicht: Er will es weder nacherzählen, noch empfiehlt er, sich durch das Handbuch zu arbeiten. Seine Kurzfassung lautet, dass sie alles mit deinem Claude Code anstellen können und du nicht wissen musst, wie sie funktionieren.

Was das praktisch heißt, zeigen seine Beispiele: Ein Mod blendet ein eigenes Seitenpanel ein, ein anderer verwandelt Textstellen im Terminal in anklickbare Links. Das geht über das hinaus, was man von Hooks kennt, die auf einzelne Ereignisse reagieren.

Der Einstieg: einfach Claude selbst fragen

Die beste Empfehlung im Beitrag: gar nicht erst versuchen, das Handbuch zu lesen. Stattdessen soll man Claude selbst fragen, und Kund liefert den Prompt gleich mit: „Claude Code has mods now. Given the workflows we usually use and the type of work we do here, what are some mods we could build that would be super useful?“ Sinngemäß also: Welche Mods würden uns bei unseren üblichen Abläufen am meisten helfen? Danach lässt er Claude einige davon direkt bauen. Das klingt ungewohnt, ist aber konsequent. Wer ein Werkzeug nutzt, das Code versteht und generiert, kann es auch für die Erweiterung der eigenen Werkzeuge einsetzen.

Das hat zwei Vorteile. Erstens entfällt die Einarbeitung, weil das Modell die Abläufe im eigenen Projekt bereits kennt. Zweitens sind die Vorschläge praxisnah, weil sie nicht aus einem Featurekatalog stammen, sondern aus dem konkreten Arbeitsalltag. Dass man nicht verstehen muss, wie die Mods intern funktionieren, senkt die Hemmschwelle zusätzlich.

Live-Visualisierung längerer Workflows

Kunds erstes Beispiel ist ein Visualisierungs-Mod für lang laufende Workflows. Wer Claude Code für umfangreiche Aufgaben nutzt, kennt das Problem: Ein Workflow läuft, im Terminal erscheint ein endloser Textstrom, und am Ende hat man den Verlauf der einzelnen Schritte nicht mehr im Kopf. Der Mod öffnet bei großen Workflows automatisch ein Seitenpanel rechts, das nicht nach Claude Code aussieht und sich, zu Kunds sichtlicher Freude, mit der Maus in der Breite verstellen lässt. Er nutzt es für die beiden Workflows, die er in einem früheren Beitrag beschrieben hat: Aufgabenvorbereitung und Umsetzung.

Das Panel zeigt den Ablauf als Folge von Blöcken. Die Rechtecke stehen für Kritikrunden, in denen mehrere Agenten den Plan bemängeln, rosa markiert Eskalationen und grün den erfolgreichen Endzustand. Ein Vorbereitungslauf, den Kund zeigt, dauerte zwei Stunden; mit der Visualisierung lasse er sich auf einen Blick erfassen. Auch der Build-Workflow, der Code schreibt und ausliefert, wird so nachvollziehbar. Er umfasst oft Dutzende einzelne Schritte: Code-Reviews und Korrekturen, Prüfungen in Entwicklungs- und Produktionsumgebung, Datenreparaturen, Merges und Deployments.

In der gezeigten Aufzeichnung eines solchen Laufs waren einige Prüfungen in der Entwicklungsumgebung rosa Eskalationen, die Kund selbst übernehmen musste. Das erste Deployment scheiterte an einem Schwachstellen-Scan, wurde korrigiert und erneut ausgerollt. Vor dem Abschluss führte der Agent fünf letzte Prüfungen in der Produktion durch. Eine solche visuelle Spur hilft bei der Fehlersuche und dabei, im Team zu erklären, was passiert ist.

Hyperlinks für Ticketnummern

Nicht jeder Mod muss ein großes Dashboard sein. Das zweite Beispiel erfüllt einen Wunsch, den Kund schon lange hatte, und betrifft ein Detail, das jeder kennt, der mit Issue-Trackern arbeitet. Claude erwähnt im Terminal beiläufig eine GitHub-Referenz wie #2443 und weiß, was gemeint ist, weil es den Kontext hat. Der Mensch vor dem Bildschirm weiß es nicht: Er sucht die Nummer, öffnet den Browser, navigiert zum Repository und landet beim Ticket. Im Alltag ist das eine kleine, aber stetige Reibung.

Ein Mod löst das, indem er jede Ticketnummer im Terminal in einen anklickbaren Link verwandelt. Kunds Auftrag an Claude bestand aus einem einzigen Satz: „Make it so that whenever I see a ticket number in the terminal, it is a hyperlink.“ Solche Mikro-Modifikationen zeigen, dass der Wert von Mods nicht nur in großen Visualisierungen liegt. Oft sind es die kleinen Erweiterungen, die Reibung wegnehmen, an Stellen, die man schon lange nicht mehr bewusst wahrnimmt.

Mods und Wegwerf-Software

Kund ordnet Mods in einen größeren Zusammenhang ein. Er sieht sie und OpenAIs gerade erschienene Intelligent UI als spannende Schritte in die Richtung, die manche Zukunftsforscher Disposable Software nennen, also Wegwerf-Software: Software, die nicht monatelang geplant, gestaltet und versioniert wird, sondern in Minuten für einen konkreten Zweck entsteht, eine Weile genutzt und dann verworfen oder ersetzt wird.

Mods passen in dieses Bild. Sie sind klein, schnell geschrieben, auf eine Aufgabe zugeschnitten und jederzeit austauschbar. Wenn das Modell den eigenen Workflow kennt, schlägt es die passenden Mods selbst vor – genau so ist Kunds Liste für die nächsten Mods entstanden.

Kund ist sicher, dass Codex, Grok, Gemini und praktisch alle anderen sehr bald ebenfalls Mods haben werden. Trifft das zu, lohnt der Einstieg schon jetzt, weil die Konzepte übertragbar sind. Es geht dann weniger darum, ein Produkt zu lernen, als um eine neue Art, Software im Alltag zu verwenden.

Was als Nächstes möglich wird

Am Ende steht eine Liste mit Mod-Ideen, die Claude selbst vorgeschlagen hat. Sie zeigt, wie vielfältig die Anwendungsfälle inzwischen sind. Etwa ein Jira-ähnliches Taskboard im Terminal, das den Wechsel zum Browser überflüssig macht. Oder ein Deploy-Watcher mit Statuslicht, das den Zustand der Umgebung jederzeit anzeigt. Die Idee, Prosa und Regeln aus der Datei agents.md in deterministische Prüfungen zu überführen, ist praxisnah: weg von weichen Anweisungen, hin zu überprüfbaren Bedingungen.

Ein weiteres Beispiel ist ein sichereres Werkzeug zum Abfragen von Produktionsdaten. Statt SQL von Hand zusammenzubauen, kapselt ein Mod den Zugriff in eine geprüfte Schnittstelle. Ebenfalls praktisch: eine Queue mit Lock für parallele End-to-End-Tests. Bei Kund begrenzen heute die speicherintensiven Browser-Tests, wie viele Agenten parallel laufen können. Eine Queue würde erst dann eingreifen, wenn tatsächlich Konflikte drohen. So lässt sich die parallele Auslastung erhöhen, ohne dass Tests sich in die Quere kommen. Daneben verweist Kund auf Mods anderer Nutzer: einen Modellwechsler und, für den Humor, einen Mod, mit dem man in einem Terminal-Panel Doom spielen kann, während man auf das Modell wartet.

Was das konkret für den eigenen Arbeitsalltag bedeutet

Mods sind kein Selbstzweck und kein Gimmick für Power-User. Sie verändern, wie man mit KI-Werkzeugen arbeitet. Man muss nicht jede Erweiterung als Projekt behandeln. Man kann das Modell selbst um die Erweiterung bitten, sie kurz prüfen und produktiv schalten. Die Rolle der Entwicklerin verschiebt sich damit ein Stück von der Implementierung hin zur Formulierung des Bedarfs und zur Qualitätskontrolle.

Wer Claude Code, Codex, Gemini oder ein vergleichbares Terminal-Werkzeug nutzt, sollte sich ein paar Minuten nehmen, das Modell nach passenden Mods zu fragen und zwei oder drei davon im Alltag einzusetzen. Die Einstiegshürde ist niedrig. Ein Visualisierungs-Panel macht einen zweistündigen Workflow lesbar – wer das einmal gesehen hat, will es behalten.

Quelle: ivokund.com