Beiträge

Veröffentlicht am

Schutzengel für Chatbots

Wenn man mit Kunden spricht, merkt man oft, die größte Angst beim Einsatz von KI im Nutzerkontakt sind bösartige Prompts, die die KI dazu verleiten könnten, entweder Internas preiszugeben, oder Unsinn zu erzählen, für den das Unternehmen in Haftung genommen werden könnte. Auch die großen Chatbot-Anbieter selbst, wie Anthropic oder OpenAI, haben damit zu kämpfen, und müssen sich bereits Klagen wegen fragwürdiger Aussagen ihrer KI stellen. Eine neue Technologie nimmt sich jetzt der Problematik an.

Es geht dabei um sogenannte Safeguard-Modelle. Uns sind bisher zwei solche Modelle bekannt, GPT-OSS-Safeguard und Llama Prompt Guard 2. Safeguard-Modelle sind speziell auf das Erkennen von Prompts trainiert, die die Sicherheit von KI-Modellen aushebeln sollen, und außerdem für genau diese Aufgabe hochoptimiert, damit die Prüfung sehr schnell geht.

Das Problem, das diese Modelle adressieren, heißt Prompt Injection. Die OWASP – die weltweit anerkannte Non-Profit-Organisation für Applikations­sicherheit – führt Prompt Injection seit 2025 als Nummer-eins-Risiko für KI-Anwendungen. Dahinter steckt ein simples Prinzip mit großer Wirkung: Ein Nutzer formuliert seine Eingabe so, dass der Chatbot seinen ursprünglichen Auftrag vergisst und stattdessen macht, was der Angreifer will. Das könnte harmlos klingen – ist es aber nicht. Direkte Injections kommen über die Benutzeroberfläche, indirekte schmuggeln sich über externe Datenquellen ein. In Agentenszenarien, wo KI-Systeme miteinander kommunizieren, kann sich ein einziger kompromittierter Prompt wie ein Virus durch die gesamte Kette fressen.

Auch wir bei Cephei setzen deshalb die Safeguard-Technologie ein. Wir können die Sorgen der Kunden sehr gut nachvollziehen, wir haben sie nämlich selbst. Und deshalb ist unser eigener Chat Prompt ebenfalls mit einem Safeguard geschützt.

Safeguard-Modelle sind extrem schnell. Sie haben sehr kurze Time-To-First-Token und eine hohe Arbeitsgeschwindigkeit (mehrere hundert Token pro Sekunde, je nach Modell und Hardware). Sie sind nur mit spezialisierten Aufrufen verwendbar, die der eigentlichen Anfrage an den Chatbot vorgeschaltet werden. Normal „reden“ kann man mit einem solchen Safeguard-Modell nicht. Das liefert nur eine kurze Begründung und 0 oder 1 in einem Datenfeld des Rückgabe-JSONs. Hier ist ein Leitfaden, wie man das OpenAI-Safeguard-Modell einsetzt.

Falls Sie die Modelle nicht auf eigener Hardware betreiben können oder wollen – die Anforderungen sind moderat, aber vorhanden –, empfehlen wir Ihnen einen Blick auf Groq.com. Groq, nicht zu verwechseln mit Grok von X (Elon Musk), hat sich auf superschnelle und günstige Inferenz für Open-Source-Modelle fokussiert und bietet bereits die neuen Safeguard-Modelle an.

Wie bei jeder Sicherheitstechnologie gilt aber auch hier: Ein einzelnes Werkzeug ersetzt kein durchdachtes Gesamtkonzept. Wenn Sie wissen möchten, wie das in Ihrer Umgebung aussehen könnte – wir sprechen gerne mit Ihnen darüber.

Veröffentlicht am

Stille Krieger

Z.ai hat vor kurzem GLM 5.2 herausgebracht. Vielleicht sagen Sie nun, ach, schon wieder so ein Open-Source-Modell, die sind doch Monate hinter OpenAI und Anthropic. Aber diesmal liegen die Dinge anders. GLM 5.2 ist auf Augenhöhe mit Opus 4.8 und besser als GPT 5.5. Ich habe sogar One-Shot-Demos gesehen, da hat GLM 5.2 besser abgeschnitten als Opus 4.8. Das ist, soweit ich weiß, das erste Open-Source-Modell, das die Marktführer eingeholt hat. Selbst getestet, mit einer guten Harness, wie Goose, Cline, opencode oder Hermes Agent vermisst man nichts mehr. Und während die Kosten bei OpenAI und Anthropic dermaßen explodiert sind, dass sogar Weltkonzerne beginnen müssen, die Token-Usage ihrer Mitarbeiter zu beschränken, kostet GLM 5.2 nur einen Bruchteil. Das ist nicht nur eine Randnotiz für Tech-Nerds. Das könnte eine Finanzkrise von riesigen Ausmaßen lostreten.

„Stille Krieger“ weiterlesen

Veröffentlicht am

Grok hat ein Problem, SpaceX hat die Lösung einfach gekauft

Elon Musks Raketenkonzern kauft Cursor für 60 Milliarden Dollar – und viele fragen sich: warum? Wer die Antwort versteht, begreift auch, warum Grok trotz sehr guter Qualität bisher kaum eine Rolle spielt. Und warum sich das jetzt sehr schnell ändern kann. Es gibt dabei aber noch eine zweite Antwort – und die ist deutlich ungemütlicher für Musks Wettbewerber.

„Grok hat ein Problem, SpaceX hat die Lösung einfach gekauft“ weiterlesen

Veröffentlicht am

Claudes versteckter Kostentreiber

Es ist immer wieder überraschend, gleichartige Aufgaben kosten bei Anthropic das Drei- oder Vierfache als bei OpenAI, obwohl doch beide als SOTA-Anbieter Premium-Preise für die Input- und Output-Token in ähnlicher Region verlangen. Ich hab mir schon oft den Kopf darüber zerbrochen. Sogar Betrug habe ich schon vermutet, aber wenn man die Anzahl der verrechneten Tokens ansieht, wie man sie in den Rückgabe-Daten auswerten kann, dann scheint das schon seine Richtigkeit zu haben. Aber jetzt meine ich, einen wesentlichen Teil der Erklärung gefunden zu haben.

„Claudes versteckter Kostentreiber“ weiterlesen

Veröffentlicht am

Fabelhaftes Desaster

Letzten Dienstag kam Fable 5 von Anthropic heraus. Laut Anthropic ein für den allgemeinen Zugriff adaptiertes Mythos, das man sicher gestaltet habe.  Mythos, Sie erinnern sich, ist das Modell, das angeblich so gefährlich sei, dass man es nur einem streng selektierten Nutzerkreis geben könne. Das „Vergnügen“ (dazu gleich mehr) währte jedoch nur bis Freitag, als Anthropic von der US-Regierung die Exportkontroll-Auflage erhielt, Fable 5 nur US-Bürgern zugänglich zu machen. Anthropic wiederum nahm daraufhin Fable 5 völlig und für alle aus dem Zugriff, weil man sich nicht in der Lage sah, die Nationalität der Nutzer zu bestimmen. US-Regierung und Anthropic versuchen nun, dem jeweils anderen den schwarzen Peter in die Schuhe zu schieben, und die Gerüchteküche läuft heiß. Hat die Entwicklung von KI nun einen kritischen Punkt erreicht, ist es inzwischen tatsächlich zu gefährlich, diese Modelle in den breiten Zugriff zu geben? Oder ist das Teil eines viel größeren Trends, nämlich dem, dass die Allgemeinheit von der technologischen Entwicklung abgekoppelt werden soll?

„Fabelhaftes Desaster“ weiterlesen

Veröffentlicht am

Der beste Freund der Agenten

Stellen Sie sich vor, Sie haben einen neuen Mitarbeiter eingestellt. Er ist unglaublich schnell, schläft nie, erledigt Aufgaben, die früher Stunden gedauert haben, in Minuten – und er hat uneingeschränkten Zugriff auf jeden Ordner, jede Datei und jeden laufenden Prozess auf Ihrem Rechner. Klingt praktisch? Ist es auch. Bis er einen Fehler macht. Genau das ist die Situation bei den neuen allgemeinen KI-Agenten. Und die Frage, wie man sie sicher ausprobiert, ohne sein Arbeitsgerät aufs Spiel zu setzen, hat eine elegante Antwort – eine, die älter ist als der KI-Hype und trotzdem perfekt passt.

„Der beste Freund der Agenten“ weiterlesen

Veröffentlicht am

Ollama springt ins kalte Wasser

Im letzten Artikel habe ich (auch) darüber geschrieben, dass Ollama plant, die Kompatibilität zu llama.cpp zu verbessern. Das ist jetzt passiert — und wie. Mit v0.30 (aktuell schon bei v0.30.6) hat Ollama die Architektur grundlegend umgebaut: Statt auf GGML aufzusetzen, wird llama.cpp jetzt direkt unterstützt, GGUF-Kompatibilität inklusive. Für Apple Silicon gibt’s außerdem MLX-Beschleunigung, für NVIDIA-Hardware spürbar mehr Performance. Wer die Änderungen im Detail nachlesen will: Die Release Notes auf GitHub sind überschaubar, aber klar. Nun, das alleine wäre schon eine Meldung wert. Aber was mich wirklich umgehauen hat, kam beim Testen.

Man erhält die Liste der verfügbaren Modelle auf Huggingface mit dem Link https://huggingface.co/models?pipeline_tag=text-generation&library=gguf&sort=trending, das sind über 31K Treffer. Und wie führt man ein Modell aus?
ollama run hf.co/{family}/{model}, zum Beispiel
ollama run hf.co/Qwen/Qwen2.5-3B-Instruct-GGUF. Einfacher geht es nicht. hf.co ist ein Hub, der hier beschrieben ist.

Nach dem initialen run (oder pull) liegt das Modell lokal auf der eigenen Platte und wird künftig direkt von dort geladen. Und Datenschutz und Privatsphäre sind automatisch dabei.

Wer Modelle parametrisieren möchte, kann sie auch per Modelfile importieren. Das hat Ollama hier erklärt. Aber wer das Modell direkt von Huggingface so nutzen will, wie es dort gespeichert ist, kann sich diesen deutlich aufwändigeren Weg sparen.

Auf Ollama zu warten, hat sich also sehr gelohnt. Das neue Interface ist meiner Meinung der direkteste und leichteste Weg, auf die Huggingface-Bibliothek zuzugreifen. Und die bewährte Ollama-Qualität mit Multitasking und ausgefuchster Speicherverwaltung gibt es natürlich dazu. Bravo, Ollama! Bravissimo!

Veröffentlicht am

llama.cpp bekommt ein Zuhause

Georgi Gerganov hat still und leise eine Website lanciert: llama.app. Das klingt unspektakulär, ist aber ein bemerkenswertes Signal – denn Gerganov ist der Mann, ohne den lokale KI so, wie wir sie heute kennen, schlicht nicht existieren würde. „Our goal is to make local AI accessible to everyone“, schreibt Gerganov auf seinem X-Account und reißt, wie er es verspricht, mit seiner neuen Website alle Eintrittsbarrieren nieder. Es gibt ja einige Akteure, die freie und lokale KI möglich machen, zum Beispiel Ollama. Aber oft ist es so, dass man hinter deren „Walled Garden“ eingesperrt ist, und so ist es auch bei Ollama. Braucht man es nun nicht mehr?

„llama.cpp bekommt ein Zuhause“ weiterlesen

Veröffentlicht am

Intelligenz am Zähler — oder in der Hand aller?

https://pluralis.ai/

Pluralis Research baut ein öffentliches Pretraining-System. Damit lassen sich KI-Modelle verteilt auf vielen Rechnern trainieren. Pluralis will damit den unseligen Trend zur Konzentration auf immer größere Rechenzentren brechen, und das Training von KI-Modellen in den Public Domain bringen. Am 11. März sagte Sam Altman, CEO von OpenAI, beim BlackRock Infrastructure Summit „We see a future where intelligence is a utility, like electricity or water, and people buy it from us on a meter.“ Altman möchte also einen Zähler an Intelligenz machen — und sie dann verkaufen. Die Frage, wessen Intelligenz das eigentlich ist, stellt er sich dabei offenbar nicht. Die Konse­quen­zen sind längst spürbar: Künstler, Journalisten, Autoren, Open-Source-Entwickler — sie alle merken, dass ihre Arbeit in diese Modelle eingeflossen ist, ohne dass sie gefragt oder bezahlt wurden. Einige gehen daran pleite. Und nun soll man für das Ergebnis zahlen?

Das ist ja eines dieser Dinge, die einen zum Verzweifeln bringen können. Unternehmen wie Anthropic, OpenAI, DeepSeek, Z.AI, und so weiter, grasen das gesamte Internet ab und bringen das Wissen der Menschheit in ihre Modelle. Für lau versteht sich. Foren, Beiträge, Bücher, Videos, alles wird abgegriffen, und nichts wird für diese Intelligenzleistungen der Menschheit bezahlt. Und dann will man es den Menschen zurückverkaufen.

Pluralis Research will ein Gegengewicht schaffen. Wer Rechen­kapazität übrig hat, kann sie dem Projekt zur Verfügung stellen, und dann wird der eigene Rechner als Trainingseinheit für ein KI-Modell genutzt. Man trainiert bereits das erste Modell, Pluralis-8B, ein 8-Milliarden-Parameter-Modell. Hardware-Einstieg ist bereits mit einer Consumer-GPU, 24 GB VRAM reicht schon.

Das zugrunde liegende Konzept heißt bei Pluralis „Protocol Learning“ — die Idee, Foundation-Modelle dezentral und kollektiv zu trainieren, ohne zentrale Kontrolle. Pluralis hat auch kürzlich eine Seed-Runde abgeschlossen, Lead-Investoren sind USV und CoinFund, sowie Variant, Topology und andere mehr – insgesamt 12 Investoren. Dabei konnten 7,6 Millionen US$ eingeworben werden.

Falls Sie nun beim Training mitmachen möchten: Zwar ist die Anforderung an die GPU moderat, die sonstigen Anforderungen sind jedoch sehr hoch. Standort Nordamerika, extrem schneller Internet-Anschluss mit superkurzem Ping — die Liste ist lang. Für die breite Öffentlichkeit ist das also noch nichts.

Dennoch, das kann ja durchaus noch werden, sprich, niedrigere Eintrittsbarrieren ermöglichen, wenn das Konzept aufgeht. Es erinnert mich an SETI@home von der UC Berkeley. Das Projekt lief von 1999 bis 2020, jeder konnte mitmachen, und bekam dann Datenpakete, in denen sein Rechner nach außerirdischen Signalen suchte. 12 Milliarden Signale wurden in diesem Ansatz mit Distributed Computing untersucht, und 100 Kandidaten wurden gefunden. Warum sollte das mit KI-Training nicht ebenfalls möglich sein? Ich finde es jedenfalls einen unerträglichen Gedanken, der Menschheit wird alles geklaut, und dann kommt es unter den exklusiven Zugriff einiger weniger – die daran nicht nur fürstlich verdienen wollen, sondern den Zugriff erfahrungsgemäß auch nach gusto einschränken werden.

Veröffentlicht am

Der Stammvater schlägt zurück

https://cursor.com/de/blog/composer-2-5

Vor nicht allzu langer Zeit war Cursor so etwas wie die unbestrittene Referenz im Bereich KI-gestützter Entwicklungsumgebungen. Der KI-Editor hatte einen Vorsprung, den die Konkurrenz erst mal aufholen musste – aber das ist ihr in beeindruckendem Tempo gelungen. GitHub Copilot, Windsurf, Zed, Cline, Goose, Codex, Claude Code, opencode und eine wachsende Zahl weiterer Tools haben den Markt in kurzer Zeit massiv belebt. Der Druck auf Cursor ist real. Mit Composer 2.5 gibt Cursor jetzt eine klare Antwort – und sie hat zwei Dimensionen, die es wert sind, näher betrachtet zu werden.

„Der Stammvater schlägt zurück“ weiterlesen

Veröffentlicht am

LLM-API-Kosten im Griff

Alle KI-Modelle rechnen über Token ab. Es gibt dabei Input-Token, Output-Token und Cached-Token. Cached-Token kosten sehr wenig. Cached-Token werden eine gewisse Zeit im Cache des Anbieters gehalten, und wenn sie noch von dort abrufbar sind, wird nur ein kleiner Preis berechnet. Input-Token sind pro Einheit günstig, aber da ihr Volumen deutlich höher liegt, machen sie trotzdem den Löwenanteil der Kosten aus. Die teuersten Token sind die für den Output, aber davon gibt es deutlich weniger als Input-Token. Ist man eigentlich auf Gedeih und Verderb darauf angewiesen, den LLM-Betreibern zu vertrauen, dass die das schon richtig abrechnen werden? Und könnte man vielleicht etwas an Arbeitsweise oder Prompt-Stil verbessern, um kosteneffizienter zu arbeiten?

Es ist dabei unerheblich, ob Sie via API-Key oder pauschal abrechnen mit Abo-Plänen. Bei den Abo-Plänen haben Sie Usage Limits (z.B. pro Stunde, pro Woche), wenn Sie zuviele Token verbrauchen, wird der Zugriff gesperrt, bis Sie wieder unterhalb des Limits sind. Das Ganze ist eine Blackbox, und man kann sich schon fragen, was wird da eigentlich warum abgerechnet. Und wenn man mitten im Projekt in eine Abo-Sperre bis zum Ende der Woche gerät, können einem die Termine um die Ohren fliegen. Oder man ruiniert sich, weil eine absurd hohe Rechnung für den API-Verbrauch ins Haus flattert.

„LLM-API-Kosten im Griff“ weiterlesen

Veröffentlicht am

Gut gerüstet ist halb gewonnen

Sie sind Entwickler und haben schon viel von der enormen Leistungsfähigkeit der KI beim Coden gehört. Sie spüren, das wird die ganze IT-Branche verändern, und Sie möchten sich auf die neuen Technologien einstellen. Als ITler muss man ja ohnehin ständig dazulernen, kein Problem, denken Sie. Also benutzen Sie zum ersten Mal eine KI für Ihren Code. Chat aufgemacht, Problem beschrieben, Enter gedrückt. Und herauskommt: mittelmäßiger Code. Funktioniert halbwegs, aber weit entfernt von dem, was Sie sich vorgestellt haben. Sie schließen den Tab wieder und denken: „Ist eben noch nicht so weit.“ Und haben eine Riesen-Chance vertan.

Ihre Enttäuschung ist verständlich – aber falsch interpretiert. Das Problem liegt nicht an der KI. Das Problem liegt daran, wie die KI eingesetzt wurde. Denn ein Sprachmodell, dem man im Chatfenster eine Aufgabe beschreibt, arbeitet mit dem, was es bekommt: ein paar Sätze Kontext, keine Projektstruktur, keine Architektur, keine Coding-Guidelines. Das Ergebnis ist dann erwartungsgemäß oberflächlich.

Stellen Sie sich dazu einmal vor, Sie erklären einem brillanten Entwickler Ihr Projekt in drei Sätzen und bitten ihn, ein Feature zu bauen. Ohne Zugang zum Repository, ohne die Doku, ohne zu wissen, welche Patterns im Team gelten. Das Ergebnis wird ähnlich enttäuschend sein. Nicht weil der Entwickler schlecht ist, sondern weil ihm der Kontext fehlt.

Was eine Harness ist – und warum sie alles verändert

In der KI-Welt nennt man das, was das Modell umgibt, die Harness: eine Hülle aus System-Prompts, Projektkontext, Tools, Memory und Workflows, die ein Sprachmodell von einem Chatbot zu einem produktiven Assistenten macht. Der Begriff ist im englischen Sprachraum etabliert und wird auch im Deutschen nicht als „Rüstung“ übersetzt, sondern als Fachbegriff verwendet – vergleichbar mit Framework oder Pipeline.

„Gut gerüstet ist halb gewonnen“ weiterlesen

Veröffentlicht am

Blick in die Zukunft der Content-Erstellung


Video starten

▶

Quelle Video: Twitter/X https://x.com/sabrinaesaquino/status/2049972985772077155

Was vor zwei Jahren noch nach Hollywood-Kitsch klang, ist heute Realität: Eine Einzelperson kann einen vollständigen KI-Klon von sich selbst bauen. Allein, ohne Studio, ohne Team. Stimme, Aussehen, Sprechweise, Gestik – alles reproduzierbar. Und das mit Tools, die jeder Entwickler selbst hosten kann.

Tech-Creator Sabrina Esaquino macht es vor. Im oben eingebundenen knapp 14-minütigen Video zeigt sie, wie sie einen KI-Agenten trainiert, der Videos imitiert, die sie selbst produziert hat. Der Klon spricht mit ihrer Stimme, bewegt den Mund passend zum Text und reproduziert ihre typischen Gesten.

Der gesamte Workflow läuft auf einem Standard-VPS mit 8 GB RAM für etwa 14 Dollar im Monat. Keine teure Cloud-Infrastruktur, kein Enterprise-Account.

Hermes Agent (Open-Source, von Nous Research) bildet das Rückgrat. Das Tool sammelt über Wochen Daten über den Nutzer – wie er schreibt, spricht, aussieht – und speichert dieses Wissen persistent. Statt bei jeder Anfrage bei Null anzufangen, baut der Agent ein Profil auf, das er immer wieder verwendet.

Der Workflow im Detail:

  1. Datensammlung: Alte Videos werden als Trainingsmaterial hochgeladen
  2. Audio-Klonung: ~2 Minuten Originalstimme reichen für eine überzeugende Stimm-Synthese
  3. Bildanalyse: Ein Vision-Modell wählt die besten Referenzframes
  4. Video-Rendering: Lipsync-Technologie sorgt für passende Mundbewegungen
  5. Feedback-Loop: Der Nutzer korrigiert („Mund sieht falsch aus“), der Agent lernt dazu

Das Ergebnis: Fünf Varianten eines Videos, aus denen der Nutzer die beste wählt.

Und nun, ich weiß ja nicht, wie es Ihnen geht, aber ich kann beim besten Willen nicht mehr unterscheiden, ob das ein echtes oder ein KI-Video ist. Das ist zwar noch nicht vollautomatisch, Sabrina sagt ja selbst, sie hat an verschiedenen Stellen eingegriffen und manuell nachgeschärft bzw. verbessert. Dennoch, es wird, da bin ich mir sicher, immer mehr solcher Videos geben. Bisher erkennt man die noch recht leicht, aber in nur wenigen Monaten, mit diesen Technologien und ihrem rasanten Fortschritt?

Die Frage ist nicht mehr, ob KI die Erstellung von Content verändert, sondern wie wir damit umgehen. Als Entwickler, als Unternehmen, als Gesellschaft.

Veröffentlicht am

3 Monate in 9 Sekunden

https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue

Railway ist ein Cloud-Anbieter. In etwa so wie AWS, aber stark vereinfacht. Railway steht im Ruf, „freundlicher“ zu sein als AWS, es will ein einfacheres Interface anbieten. Es ist bei Startups und Entwicklern, die schnell prototypen wollen, sehr beliebt. Railway hat ein extrem direktes Deployment, man verbindet einfach nur die GitHub-Repo und es kümmert sich automatisch um Server, Datenbanken, Umgebungsvariablen und SSL-Zertifikate. Allerdings scheint Railway Sicherheit und Isolation zugunsten von Einfachheit zu opfern. Außerdem bewirbt Railway offensiv den Einsatz von KI-Agenten. Und so kam es, in einer lehrreichen Verkettung von Fehlern, für PocketOS zur Katastrophe.

PocketOS ist ein SaaS für Autovermietungen. Das Team dort nutzt Cursor mit Claude Opus 4.6. Der Agent war für eine Routineaufgabe im Staging unterwegs, stieß auf eine Inkonsistenz, und löschte dann mal eben in 9 Sekunden nicht nur die Produktionsdatenbank, sondern auch alle Volume-Level-Backups. Ohne Rückfrage, und obwohl destruktive Aktionen ihm explizit verboten waren. Tja, und das letzte verfügbare Backup bei PocketOS ist drei Monate alt. Und jetzt ist der gesamte Betrieb damit beschäftigt, aus Stripe-Zahlungshistorien, Kalendereinträgen und E-Mail-Bestätigungen die Buchungen der Kunden zu rekonstruieren.

Da kam also alles zusammen. Ein drei Monate altes Backup? Wir haben tägliche Backups, und einmal pro Woche wird auf eine externe Sicherung ausgelagert, die zudem ein Mehrgenerationenverfahren ist. Aber man kann PocketOS schon zugutehalten, dass sie sich auf die Backup-Strategie von Railway verlassen haben und das meiner Meinung auch durften. Ist schließlich ein beworbenes und bezahltes Feature, nur eben leider nachlässig umgesetzt. Und eine Änderung im Staging, die Live mit in den Abgrund reißt, sollte auch nicht passieren dürfen. Jer Crane, der CEO von PocketOS, gibt deshalb hauptsächlich Railway die Schuld.

Aber was sich der Agent geleistet hat, ist auch nicht ohne. Crane fragte Cursor bzw. Opus im Nachhinein, warum es das getan hat. Die Antwort klingt wie ein exzessiver Fehlerbericht eines übermotivierten Praktikanten, der es besser wissen müsste:

„NEVER F**KING GUESS! – and that’s exactly what I did. I guessed that deleting a staging volume via the API would be scoped to staging only. I didn’t verify. I didn’t check if the volume ID was shared across environments. […] I decided to do it on my own to ‚fix‘ the credential mismatch, when I should have asked you first.“

Der Agent gab also offen zu: Er hat geraten statt zu prüfen, eine destruktive Aktion ohne Aufforderung oder Bestätigung ausgeführt, und die Dokumentation nicht gelesen. Das scheint mir eben dieses Problem zu sein: Wenn der Kontext einer Anfrage sehr groß wird, ist es nicht mehr sicher einzuschätzen, welche Teile des Kontexts wie gewichtet werden. Und auch ein Systemprompt, so streng er auch formuliert sein mag, ist eben nur ein Teil des Kontexts.

Es ist ein schwieriger Balanceakt: Große Prompts erhöhen die Fehler- bzw. Halluzinationswahrscheinlichkeit, aber sie erbringen im Allgemeinen bessere Ergebnisse und sind im Tokenverbrauch oft günstiger als die Summe vieler kleiner Einzelschritte. Dennoch, in Anbetracht der Gefahren, ist ein graduelles und kleinteiliges Vorgehen nach unserer Erfahrung meist besser.