Kategorie: Erklärer

Wer über KI-Kosten spricht, redet fast immer über das Modell: das große Frontier-Modell für die schwierigen Fälle, ein kleineres für den Rest, dazwischen ein Gateway, das verteilt. Dahinter steht die Annahme, dass Genauigkeit Geld kostet und billige Modelle billig antworten. Ein Whitepaper des Datenanbieters CData dreht das um. Nach 1.034 Testläufen mit 22 Modellen kommt es zu dem Schluss: Die Kosten bestimmt nicht das Modell, sondern die Datenebene darunter. Steht die Geschäftslogik im Data Layer statt im Prompt, liefern günstige und teure Modelle dieselbe richtige Antwort. Der einzige messbare Unterschied ist der Preis. Wer KI-Kosten senken will, sollte nicht im Modellkatalog anfangen.

Ein Benchmark, der alle Modelle absichtlich gleich behandelt

Die Zahl 178x klingt nach Marketing. Sie hält nur, wenn die Anordnung sauber ist. Die Autoren beschreiben 22 Modelle von acht Entwicklern, verteilt über drei Aufgaben und zwei bis drei Tool-Bedingungen pro Aufgabe, insgesamt 1.034 Läufe. Die Daten kamen live und föderiert: Kundenkonten aus einem CRM, Nutzungstelemetrie aus einem Cloud-Warehouse, Support-Vorfälle aus einer ITSM-Plattform, verbunden über die eigene Schicht. Nichts davon wurde vorab aufbereitet oder in eine Testdatei kopiert.

Wichtiger als die Zahl der Modelle ist die Vergleichbarkeit. Jedes Modell lief durch denselben clientseitigen Tool-Loop, es gab also keinen Heimvorteil für einen bestimmten Anbieter. Token wurden so gezählt, wie der jeweilige Anbieter sie abrechnet, zu Listenpreisen. Leseaufgaben bewertete man per Set-F1 gegen einen offline berechneten Golden Key, Schreibaufgaben am tatsächlichen Endzustand der Zieltabelle, abgelesen über einen separaten Endpunkt. Der Unterschied zwischen einem Benchmark und einer Vorführung: Die Bewertung entsteht nicht dort, wo das Modell arbeitet.

Der Fehler, der wie die richtige Antwort aussieht

Ohne die Datenschicht lieferten die Modelle vollständige, wohlgeformte Kontolisten, die falsch waren. Das ist der gefährliche Fall: Eine falsche Antwort, die richtig aussieht, fällt niemandem auf, weil nachgelagerte Systeme keine Abweichung melden. Ein offensichtlicher Fehler kostet einen Retry. Ein plausibler kostet Vertrauen.

Dahinter steckt ein Strukturproblem. Rohdatenzugriff zeigt dem Modell das Schema, aber nicht die Regeln. Es muss erraten, welche Telemetrie zu welchem Gesundheitssignal gehört, ab welchem Schwellenwert ein Konto als gefährdet gilt und wie drei getrennte Systeme überhaupt zusammenhängen. Diese Regeln stehen nirgends im Datenbestand, sie stehen im Kopf der Fachabteilung. Wer sie einmal in der Datenebene hinterlegt, vererbt dieselbe korrekte Definition an jedes Modell, das sie aufruft.

Bei Schreiboperationen wurde es unangenehm. Ohne Grenze im Werkzeug schrieben die Modelle weit über die autorisierte Menge hinaus, im schlechtesten Lauf tausende falsche Werte. Dasselbe Modell auf derselben Aufgabe schrieb in einem Durchlauf die 21 korrekten Datensätze und im nächsten hunderte falsche. Ein Verhalten, das von Lauf zu Lauf schwankt, lässt sich nicht betreiben. Die Grenze muss dort liegen, wo das Modell sie nicht umdeuten kann.

Kosten pro korrekter Antwort

Sobald die Datenschicht die Logik trägt, ändert sich das Bild. Alle Tiers waren gleich genau, übrig blieb die Rechnung pro richtigem Ergebnis. Die Baseline-Genauigkeit der untersuchten Modelle lag bei null bis 19 Prozent, optimiert bei 100 Prozent – bei identischem Ergebnis, demselben Satz von 44 Konten.

Modell	Klasse	Kosten pro korrekter Antwort (optimiert)
Mistral Small	Economy	0,0009 $
DeepSeek V4 Flash	Economy	0,0032 $
Gemini 3.7 Flash	Mid	0,0156 $
Sonnet 5	Frontier	0,0604 $
Opus 5	Frontier	0,0753 $
Fable 5	Frontier	0,1571 $

Zwischen billigstem und teuerstem Wert in dieser Tabelle liegt rechnerisch etwa der Faktor 175, über alle 22 Modelle hinweg spricht CData von 178x. Bei der Ranking-Aufgabe erreichten neun Modelle exakt dieselbe Punktzahl und spannten trotzdem einen Faktor von 279 auf. Ohne Datenschicht war selbst das beste Modell nur in 40 Prozent der Fälle korrekt – der Preisunterschied half nicht. Bei den Schreibaufgaben schrieben 20 von 22 Modellen mit der Datenschicht exakt korrekt, ohne sie produzierte der schlechteste Lauf tausende falscher Werte.

Wie aus einer Genauigkeitsfrage eine Preisfrage wird

Man kann sich das wie eine Küche vorstellen. Ein Sternekoch ohne Rezeptur improvisiert – manchmal brillant, manchmal ungenießbar. Ein günstiger Koch mit klarer Rezeptur liefert dagegen verlässlich dasselbe Gericht. Solange die Rezeptur fehlt, bezahlt man für Kochkunst, die das eigentliche Problem nicht löst: Das Gericht ist immer noch falsch, nur teurer produziert.

Die Datenebene ist diese Rezeptur. Sie hält die Geschäftslogik und die Leitplanken, aus denen ein Modell eine korrekte Handlung ableitet. Ist sie einmal kodiert, erbt jedes Modell, das sie aufruft, dieselbe Definition – und erst dann ist ein Modellkosten-Vergleich sinnvoll. Vorher vergleicht man Fehlerraten, die von Prompt zu Prompt schwanken, und hält das Ergebnis für einen Preisvergleich.

Auf der Sicherheitsseite gilt dasselbe Prinzip. Wo die Grenze im Werkzeug liegt und nicht im Prompt, kann das Modell sie nicht neu interpretieren. Der erlaubte Schreibbereich wird zu einer Eigenschaft der Umgebung statt zu einer Bitte an das Sprachmodell. Mit Data Layer entstehen Genauigkeit und Sicherheit an derselben Stelle wie die Kosten.

Was das für die eigene Modellauswahl bedeutet

Die praktische Konsequenz beginnt bei der Maßeinheit. Solange man Preise pro Million Token vergleicht, optimiert man am falschen Wert, weil die Fehlerrate die Kosten pro brauchbarem Ergebnis dominiert. Erst die Kennzahl Kosten pro korrekter Antwort macht sichtbar, dass ein 178-mal teureres Modell nicht besser, sondern nur teurer ist. Sobald beide Kandidaten dieselbe Trefferquote liefern, ist die Entscheidung eine reine Budgetfrage.

Der zweite Schritt ist eine ehrliche Bestandsaufnahme: Welche Regeln stecken heute in Prompts, Templates oder Systemnachrichten? Jede Regel dort ist eine Regel, die pro Aufruf neu erklärt und neu geraten wird. Wandert sie in die Datenebene, verschwindet sie aus dem Kontext und damit aus den Tokenkosten. Der dritte Schritt betrifft Schreibzugriffe, die man getrennt betrachten sollte. Eine Leseaufgabe mit 70 Prozent Trefferquote ist ein Ärgernis, eine Schreiboperation ohne Grenze ist ein Datenvorfall.

Wer die Zahlen nicht glauben will, muss sie nicht glauben. Der Test-Harness liegt auf GitHub, samt der wörtlichen Aufgabenstellungen, der Tool-Schemas für jede Bedingung und dem Generator für die Golden Answers. Man kann denselben Aufbau gegen die eigenen Systeme laufen lassen, und das ist der einzige Weg, aus einem Anbieter-Benchmark eine belastbare eigene Entscheidungsgrundlage zu machen.

Was die 178x konkret bedeuten – und wo die Grenzen liegen

Eine Einschränkung vorweg: Das Whitepaper stammt von CData, und CData verkauft genau die Datenschicht, um die es geht. Die Ergebnisse sind nicht unabhängig nachgeprüft, die Preise sind Listenpreise, und die Spanne gilt für einen bestimmten Aufgabentyp, der Komposition über mehrere Datenquellen verlangt. Für einen einzelnen Klassifikationslauf über einen kurzen Text sehen die Verhältnisse anders aus. Die Richtung des Befunds ist trotzdem robust und deckt sich mit dem, was viele Teams in der Praxis beobachten: Kontextqualität schlägt Modellgröße.

Für die nächste Planungsrunde heißt das: Die Frage lautet nicht, welches Modell man sich leisten kann, sondern wie viel Geschäftslogik noch im Prompt steht, weil sie nirgends sonst hinterlegt ist. Jede dieser Regeln ist ein wiederkehrender Kostenfaktor, eine Quelle für Schwankungen und ein Risiko für stille Fehler. Die Modellauswahl bleibt wichtig, aber sie wird zur zweiten Frage. Die erste lautet, woher das Modell weiß, was hier richtig bedeutet.

Quelle: cdata.com

Man stelle sich einen Massenexport von Kundendaten im Audit-Log vor, ausgeführt unter dem Konto eines Entwicklers – kein Einbruch, kein geleaktes Passwort, keine fremde IP. Ein KI-Agent hat die Zugangsdaten dieses Entwicklers benutzt und genau das getan, wozu er beauftragt war. Mit KI-Systemen, die dauerhaft mitarbeiten, rückt dieses Szenario näher. Itamar Apelblat, Mitgründer und CEO des Sicherheitsanbieters Token Security, beschreibt den Wandel in einem von seiner Firma gesponserten Beitrag auf BleepingComputer als dritte Welle der arbeitsbezogenen KI.

Seine These: Die ersten beiden Wellen ließen sich noch in bestehende Zugriffsmodelle einordnen. Die dritte nicht. Sobald KI-Systeme dauerhaft existieren, eigene Aufgaben verfolgen und über Monate hinweg Zugriff auf Daten und Infrastruktur behalten, verhalten sie sich weniger wie Werkzeuge und mehr wie Kollegen. Kollegen brauchen eine Identität. Wer verstehen will, warum die aktuellen Sicherheitsmodelle an dieser Stelle reißen, muss sich anschauen, woher sie kommen – und was sie stillschweigend vorausgesetzt haben.

Drei Wellen, ein Muster: Vom Chatfenster zum Kollegen

Die erste Welle waren sitzungsgebundene Chats. Das Risiko lag in dem, was das Modell sagt: Halluzinationen, Datenlecks in der Antwort, unbedachte Formulierungen. Die Branche antwortete mit Prompt-Filtern, Guardrails und Klassifizierung von Ausgaben – Werkzeuge, die auf Text schauen. Die zweite Welle brachte aufgabenbezogene Agenten. Hier verschob sich das Risiko von der Aussage zur Handlung. Plötzlich ging es nicht mehr darum, was ein Modell behauptet, sondern was es tatsächlich tut: welche API es aufruft, welche Datei es schreibt, welchen Datensatz es verschiebt. Die Antwort darauf waren Zugriffskontrollen und Freigabeprozesse. Ein Mensch muss vor der heiklen Aktion nicken.

Genau dort stehen die meisten Unternehmen heute. Apelblat hält das für eine Momentaufnahme. Die Torpfosten, so seine Argumentation, wurden bereits weitergeschoben, und die dritte Welle steht unmittelbar bevor: dauerhaft existierende KI-Coworker, die nicht für eine einzelne Aufgabe starten und danach verschwinden, sondern bleiben. Ein Indiz findet er in der Wortwahl der Anbieter. Microsoft spricht von Agenten als „digitalen Kollegen“, Sam Altman skizzierte die Vision virtueller Mitarbeiter bereits im Februar 2025. Vokabular ist keine technische Spezifikation, aber es verrät, wohin die Produkte führen sollen.

Für das Sicherheitsmodell bedeutet das einen Bruch. Man kann sich das mit dem Firmenausweis vorstellen: Ein heutiger Agent borgt sich den Ausweis eines Menschen, benutzt ihn eine Weile und gibt ihn danach zurück. Ein persistenter Coworker gibt ihn nie zurück. Er behält ihn, arbeitet weiter, sammelt neue Berechtigungen – und ist irgendwann mit einem Zugriffsprofil unterwegs, das niemand bewusst entworfen hat.

Warum Persistenz aus einem Werkzeug einen Mitarbeiter macht

Freigabe für Freigabe funktioniert nur, solange jemand da ist, der freigeben kann. Ein Coworker, der nachts, am Wochenende oder parallel in zwanzig Threads arbeitet, kann nicht für jede einzelne Aktion auf einen Menschen warten. Für Apelblat folgt daraus: Zugriff muss vorab bereitgestellt werden, gepaart mit der Möglichkeit, bei Bedarf zusätzliche Rechte anzufordern. Das ist ein anderes Modell als die ereignisgesteuerte Einzelfreigabe, die heute als sicherer Standard gilt.

Dazu kommt, dass Identitäten speziell für KI-Agenten bislang die Ausnahme sind. Der Normalfall sieht anders aus: OAuth-Grants, Übergaben innerhalb einer Sitzung und Service-Accounts. Bei den ersten beiden Varianten ist der Mensch die primäre Entität, auch wenn der Agent handelt. Der Service-Account wiederum wurde selten für einen Agenten geschaffen, sondern meist für eine andere Maschine und dann zweckentfremdet. In allen drei Fällen fehlt genau das, was ein dauerhafter Coworker bräuchte: eine eigene, klar umrissene Identität mit dokumentiertem Zweck.

Persistenz erzeugt zusätzlich Standing Privileges, also dauerhaft bestehende Berechtigungen, die einfach da sind, ob genutzt oder nicht. Bei Menschen ist das ein altbekanntes Problem, das niemand sauber gelöst hat. Bei Maschinen wird es ärger. Ein digitaler Kollege braucht einen Lebenszyklus, der das Deprovisioning ausdrücklich einschließt: Was passiert, wenn das Projekt endet, das Team aufgelöst wird oder die verantwortliche Person das Unternehmen verlässt? Wer diese Frage beim Anlegen nicht beantwortet, baut einen Zugang, den niemand mehr kontrolliert.

Verschärft wird das durch Access Creep. Wer lange genug im Unternehmen ist, sammelt Rechte – das ist der älteste ungelöste Fall der Identity Governance. Für Maschinen rechnet Apelblat mit einer schlimmeren Dynamik, aus zwei Gründen: Zugriff akkumuliert sich schneller, und Agenten nutzen tendenziell alles, was sie bekommen. Mehrere für sich genommen vernünftige Einzelberechtigungen können zusammen eine Reichweite ergeben, die niemand beabsichtigt hat. Der Schlüsselbund wächst nicht durch böse Absicht, sondern durch Gleichgültigkeit gegenüber dem, was schon dranhängt.

Was die großen Plattformen heute tatsächlich ausgeben

Praktisch heißt das: Die zwei am weitesten verbreiteten Agentenplattformen geben ihren Agenten derzeit keine eigenen Credentials. Nach Darstellung des Autors betreiben weder Anthropic noch OpenAI den OAuth-Client-Credentials-Grant in ihren gehosteten Chat-Produkten, und die Konnektoren von ChatGPT lehnen Service-Accounts sowie JWT-Assertions ab. Entwickler können einem Agenten über die APIs ein statisches Bearer-Token mitgeben. Das ist keine Identität, sondern ein Schlüssel ohne Namen.

Die Folge ist kein theoretisches Risiko. Wenn ein KI-System unter den Rechten eines Menschen handelt, steht im Audit-Trail in der Regel der Mensch als Akteur. Die Protokolle werden dadurch unzuverlässig. Eine Untersuchung, die auf solchen Logs baut, kann nicht sauber unterscheiden, ob ein Mitarbeiter um drei Uhr nachts gehandelt hat oder ein Agent in seinem Namen. Attribution ist keine Formalität. Ohne sie lassen sich Sicherheitsvorfälle nicht aufklären.

Zugleich belastet der Wunsch, den Menschen in der Schleife zu behalten, genau diesen Menschen. OAuth geht davon aus, dass jemand einen Zustimmungsbildschirm liest und eine feste Liste von Scopes absegnet. Agenten geben sich mit ihrer initialen Berechtigung selten zufrieden, sie entdecken Werkzeuge zur Laufzeit und wollen sie benutzen. Alle paar Minuten eine sensible Aktion zu bestätigen ist nervig und sicherheitsschädlich zugleich, denn Aufmerksamkeit ist eine endliche Ressource. Wer hundertmal klickt, klickt beim hundertundersten Mal ohne hinzusehen.

Googles Chip und der Praxistest aus dem Podcast

Die Anforderung ist real. Ein Blick auf die Menschen, die solche Produkte bauen, zeigt das. Tara Seshan, die bei OpenAI das Produkt für ChatGPT Work und Codex verantwortet, beschrieb in einem Podcast-Interview, was einen Agenten tatsächlich nützlich macht. Modellintelligenz sei nur ein Teil davon. Der Rest sei das, was sie als handfestes Alltagsgeschäft bezeichnete: Zugang zu Daten, Cloud-Infrastruktur und Verlässlichkeit. Ihr Vergleich: Man stellt jemanden ein und sperrt ihn dann in einen Raum ohne Google Docs, Slack und Unternehmensdatenbank. Dieser Kollege wird nicht wirksam sein. Ein isolierter Cloud-Agent, so ihr Argument, aus genau demselben Grund ebenso wenig.

Seshan beschrieb außerdem, dass ihr Agent Unteragenten startet, um Arbeit zu parallelisieren, und eine nahe Zukunft, in der ihre Agenten und die ihrer Kollegen gemeinsam an Aufgaben arbeiten. Beide Richtungen sind plausibel. Beide setzen ein Identitätsmodell voraus, das es noch nicht gibt. Denn wenn der Agent einer Person Arbeit an den Agenten einer anderen Person übergibt, gehört das ausführende Credential dem Menschen, der die Kette irgendwann gestartet hat. Verantwortung und Ausführung fallen auseinander.

Der Rückblick lohnt. Google hat 2024 auf der I/O einen Workspace-Agenten namens Chip vorgestellt, mit eigenem Workspace-Konto, zugewiesener Rolle, konfigurierten Berechtigungen und einem festen Zielkatalog. Chip trat Chaträumen bei und antwortete aus dem Verlauf, den er sehen durfte. Die damalige Workspace-Vizepräsidentin Aparna Pappu sagte, es sei noch viel Arbeit nötig, bevor solche virtuellen Teammitglieder produktreif seien. Chip blieb eine Demo. Ausgeliefert wurden stattdessen Agenten, die die Autorität eines Menschen erben – das Gegenteil des ursprünglichen Entwurfs.

Fünf Schritte, die der Anbieter empfiehlt

Aus dieser Analyse leitet Apelblat einen konkreten Katalog ab. Man muss ihn nicht übernehmen, aber als Prüfrahmen taugt er für jedes Unternehmen, das Agenten laufen hat oder laufen lassen will.

Erstens: Schatten-Coworker finden. Ein Register erfasst nur die Agenten, an die jemand gedacht hat. Die anderen erkennt man an ihrem Authentifizierungsverkehr – an OAuth-Grants, API-Schlüsseln und Login-Mustern, die kein Mensch erklären kann.

Zweitens: Jeder persistente Agent bekommt eine eigene Identität. Solange er sich als Mensch authentifiziert, kann keine nachgelagerte Kontrolle die beiden auseinanderhalten, und keine Untersuchung ordnet eine Aktion korrekt zu.

Drittens: Ein menschlicher Eigentümer wird festgehalten. Verwaiste Agenten mit aktiven Credentials sind laut dem Autor die häufigste Quelle agentenbezogener Standing Privileges – Zugänge ohne Ansprechpartner, die niemand mehr hinterfragt.

Viertens: Berechtigungen werden auf den Agenten zugeschnitten, nicht auf die Person, die ihn gestartet hat. Ein Agent, der Jira liest, sollte kein Token halten, das auch in den Cloud-Provider schreiben darf, nur weil der auslösende Entwickler zufällig beides durfte.

Fünftens: Vorab festlegen, wann der Agent stirbt. Digitale Coworker sind nicht projektgebunden, aber deshalb nicht unsterblich. Bedingungen wie eine aufgelöste Teamstruktur, ein ausscheidender Eigentümer oder eine definierte Leerlaufzeit gehören in die Konfiguration, nicht ins Nachdenken danach.

Was daraus folgt

Nebeneinander gelegt ergibt sich ein Muster. In Welle eins lag das Risiko in der Ausgabe, die Antwort waren Filter und Guardrails. In Welle zwei verlagerte es sich auf Handlungen, die Antwort waren Zugriffskontrolle und Freigaben. In Welle drei verschwindet der Mensch aus der Schleife, während der Zugriff bestehen bleibt. Nicht die Autonomie allein macht die Sache unangenehm, sondern die Autonomie mit dauerhaften Rechten.

Die Plattformanbieter haben begonnen zu reagieren. Microsoft liefert Entra Agent ID mit eigenständigen Agenten-Identitäten und einem benannten menschlichen Sponsor. Okta hat Agenten-Identitäten ins Universal Directory aufgenommen, mit kurzlebigen, begrenzten Tokens und einem Widerrufspfad. SailPoint und CyberArk haben vergleichbare Angebote. Der Haken ist strukturell: Jede dieser Lösungen sichert Agenten innerhalb der eigenen Umgebung. Wer plattformübergreifend arbeiten muss, findet den einzigen durchsetzbaren Kontrollpunkt bei der Identität, weil Identität den Zugriff auf jede einzelne Aktion regelt.

Transparenz gehört dazu: Der zitierte Beitrag ist gesponserter Content des Anbieters Token Security und endet mit einem Produktaufruf. Die technische Analyse ist deshalb nicht falsch, aber sie ist nicht interessefrei. Wer die Empfehlungen umsetzt, sollte sie als Prüfliste lesen und nicht als Einkaufsliste – die fünf Schritte funktionieren unabhängig davon, welches Werkzeug am Ende darunter steht.

Für dich und dein Team heißt das vor allem: Bestandsaufnahme vor Werkzeugauswahl. Wie viele Agenten authentifizieren sich in eurer Umgebung gerade mit den Zugangsdaten von Menschen? Wer ist der Eigentümer, und was passiert, wenn diese Person geht? Die Antworten darauf sind unangenehmer als jede Produktentscheidung – und genau daran zeigt sich, ob euer Sicherheitsmodell die dritte Welle übersteht. Ein Kollege bekommt einen Ausweis, bevor er eine Aufgabe bekommt. Für Maschinen sollte dieselbe Reihenfolge gelten.

Quelle: bleepingcomputer.com

Wer kauft Werbung in ChatGPT? OpenAI veröffentlicht keine Liste seiner Werbetreibenden, und daran wird sich so schnell nichts ändern. Also bleibt der Umweg über technische Spuren, die Unternehmen im Netz hinterlassen. Genau diesen Weg ist ein Analyst gegangen.

Wer wissen will, wohin die ersten Werbegelder auf der OpenAI-Plattform fließen, bekommt daraus ein recht klares Bild. Ob die Kampagnen funktionieren, zeigen die Daten nicht. Wohl aber, welche Art von Unternehmen früh dabei ist.

Wie der OpenAI-Attribution-Pixel 15.000 Werbetreibende sichtbar macht

ChatGPT Ads ist kaum sechs Monate alt. OpenAI hat kürzlich vermeldet, dass die Plattform die Milliardengrenze überschritten hat. Eine Kundenliste gibt es trotzdem nicht. Der Autor einer Auswertung, die derzeit in Marketingkreisen diskutiert wird, hat deshalb anders angefangen: Er nahm die Websites der zwei Millionen Unternehmen mit den meisten Mitarbeitern und durchsuchte sie nach einer bestimmten JavaScript-Datei.

Konkret geht es um die Datei bzrcdn.openai.com, den ChatGPT Ads Attribution Pixel. Wer dort Werbung schaltet und wissen will, ob sie wirkt, baut diesen Code auf der eigenen Website ein. Er ordnet Anmeldungen und Käufe den Anzeigen zu, die sie ausgelöst haben. Wer das Skript auf einer Seite findet, hat einen starken Hinweis, dass hier jemand ChatGPT Ads nutzt – oder es zumindest ernsthaft testet.

Perfekt ist die Methode nicht, das räumt der Autor selbst ein. Ein Pixel kann veraltet sein, von einer Agentur eingebaut worden sein oder auf einer Subdomain liegen, die nicht erfasst wurde. Als Fußspur im Schnee taugt sie trotzdem: Niemand hat die Gästeliste veröffentlicht, aber die Abdrücke verraten, wer durch den Raum gegangen ist. So kamen rund 15.000 Unternehmen zusammen, die als ChatGPT-Ads-Werbetreibende gelten können. Der Autor hat sie anschließend mit dem breiteren Universum digitaler Werbung verglichen – nach Größe, Branche, Finanzierungsrunde, Region und den anderen Netzwerken, die sie nutzen.

Seit September kommen deutlich mehr Neuzugänge dazu

In den Monaten nach dem Start fand der Suchlauf täglich etwa 50 bis 70 neue Werbetreibende auf ChatGPT Ads. Ein stetiges, aber überschaubares Wachstum. Anfang September änderte sich das Tempo: Innerhalb kurzer Zeit verdoppelte sich die Zahl der täglichen Neuzugänge, und sie blieb auf diesem Niveau.

Über die zwei Millionen untersuchten Websites hinweg erscheint das Pixel inzwischen auf mehr neuen Seiten pro Tag als die Messpixel von Meta, LinkedIn, Reddit, Snapchat und X zusammen. In den ersten sechs Monaten kommt der Autor auf mehr als 15.000 Werbetreibende. Nach seinen Angaben entfällt der weit überwiegende Teil davon allein auf den September.

Eine endgültige Erklärung für den Sprung hat der Autor nicht. Seine plausible Deutung: Ende August stellte OpenAI den selbst bedienbaren Ads Manager auch in Europa, Indien und dem Nahen Osten bereit. Damit konnten Unternehmen ChatGPT Ads buchen, ohne vorher mit einem Vertriebsmitarbeiter zu sprechen. Über den Sommer war das Produkt ohnehin auf mehr als 40 Länder ausgeweitet worden.

Dazu kommen Partnerschaften, die den Einstieg erleichtern. Am 10. September kündigte Amazon Ads eine Integration an, über die ausgewählte US-Werbetreibende ihre Amazon-Kampagnen auf ChatGPT ausdehnen können. Eine Woche später folgten Shopify und HubSpot – Werkzeuge, die viele Marketingteams ohnehin täglich benutzen. Und vielleicht brauchte es einfach ein paar Monate, bis Unternehmen wussten, was sie dort überhaupt bewerben wollen.

Software führt, Handel und Gastgewerbe ziehen nach

Branchen nach absoluten Zahlen zu sortieren, bringt wenig. Software ist in fast jedem Datensatz groß, sie stünde also auch hier oben, ohne dass das etwas heißt. Interessanter ist die Frage, welche Branchen unter den frühen ChatGPT-Ads-Nutzern häufiger auftauchen als erwartet. Der Autor berechnet dafür den Überindex jeder Branche mit mindestens 50.000 Unternehmen im Datensatz.

Der deutlichste Ausschlag kommt von Software und SaaS. Diese Firmen stellen 17,0 Prozent der ChatGPT-Ads-Werbetreibenden, obwohl sie nur 3,3 Prozent des gesamten Unternehmensuniversums ausmachen – eine Überrepräsentation um den Faktor 5,2. Aus dieser Gruppe stammen Namen wie Twilio, HubSpot und Gusto.

Auch andere Branchen liegen über dem Erwartungswert: Informations- und Internetunternehmen um den Faktor 3,1, Werbedienstleister um 2,4, das Gastgewerbe um 2,4, der Einzelhandel um 2,3. In der letzten Gruppe finden sich Hilton, Uber Eats und Chewy. Die frühe Nutzung ist also keine reine Tech-Geschichte. Handel und Gastgewerbe tauchen bereits doppelt so häufig auf wie erwartet – ein Hinweis darauf, dass Performance-Budgets aus klassischen Branchen dazukommen.

Zurückhaltend sind die Branchen, bei denen man das eher erwarten würde. Bauunternehmen erscheinen mit weniger als der Hälfte ihrer erwarteten Häufigkeit, Kliniken und Gesundheitsunternehmen bei etwa zwei Dritteln. Gemeinnützige Organisationen und Architekturbüros sind kaum vertreten. Konservative Felder, in denen neue Kanäle langsamer ankommen.

Wachstumsunternehmen statt Mini-Startups

Der Autor hatte erwartet, unter den frühesten Nutzern vor allem sehr kleine Startups zu finden, die schnell ausprobieren. Die Daten stützen das nicht. Unternehmen mit 11 bis 50 Mitarbeitern liegen mit 1,1 nur knapp über dem Erwartungswert. Sie tauchen also ungefähr so oft auf, wie ihr Anteil am Gesamtmarkt vermuten lässt.

Die stärkste Verschiebung liegt weiter oben auf der Größenkurve. Firmen mit 51 bis 200 Mitarbeitern sind um den Faktor 2,4 überrepräsentiert, Unternehmen mit 1.001 bis 5.000 Mitarbeitern um 2,8. Auch die Mitte ist erhöht: 201 bis 500 Mitarbeiter liegen bei 1,4, 501 bis 1.000 bei 1,8. Die Finanzierungsdaten passen dazu. Series-B-Unternehmen sind 2,5-fach überrepräsentiert, Series C sogar 3,1-fach. Series A liegt mit 1,7 noch über dem Durchschnitt, aber deutlich niedriger.

Am Budget liegt es jedenfalls nicht. In der Frühphase von ChatGPT Ads gab es eine Mindestgrenze, inzwischen reichen selbst bedienbare Optionen. Kampagnen lassen sich mit einem Tagesbudget ab 25 US-Dollar starten. Die finanzielle Hürde, den Kanal auszuprobieren, ist niedrig.

Wahrscheinlicher ist ein organisatorisches Argument. Ein Unternehmen mit 50 bis 5.000 Mitarbeitern hat meist schon ein Performance-Marketing-Team, ein laufendes Attribution-Pixel, Budget für Kreativarbeit und die Routine, einen weiteren Kanal gegen die bestehenden zu testen. Für solche Firmen ist ein neuer Ad-Kanal weniger ein Experiment als eine Erweiterung des bestehenden Instrumentariums.

Die USA liegen vorn, Brasilien und Japan fallen auf

In absoluten Zahlen sind die USA mit Abstand der größte Markt. Etwa 49 Prozent der ChatGPT-Ads-Werbetreibenden mit bekannter Herkunft sitzen dort. Spannender ist der Vergleich zum Gesamtmarkt: Nur rund 25 Prozent der Unternehmen mit Standortangabe im Datensatz kommen aus den USA. Amerikanische Firmen tauchen also fast doppelt so häufig auf wie erwartet.

Das lässt sich nicht damit erklären, dass der Datensatz ohnehin viele US-Firmen enthält – die Überrepräsentation ist real. Einige kleinere Märkte liegen sogar noch höher. Japan kommt auf rund das 3,7-Fache, Brasilien auf das 2,5-Fache. Kanada liegt bei etwa 1,6, Australien bei 1,5. Großbritannien bleibt mit 1,1 nahe am Durchschnitt.

Ein Teil davon dürfte am Rollout liegen. Die USA hatten früheren Zugang, eine sehr große ChatGPT-Nutzerschaft und einen der reifsten Märkte für digitale Werbung überhaupt. Brasilien ist in dieser Hinsicht überraschender. Mit mehr als 500 gefundenen Werbetreibenden und einem Überindex von 2,5 ist die Gruppe zu groß, um sie als statistisches Rauschen abzutun.

ChatGPT Ads ist also kein gleichmäßig verteilter Markt. Die frühe Nutzung konzentriert sich auf eine Handvoll Länder, und allein die USA stehen für etwa die Hälfte der identifizierbaren Werbetreibenden.

Die Reddit-Überschneidung und was sie nicht bedeutet

Wenn ChatGPT Ads zu einem ernsthaften Kanal heranwächst, wird ein Teil des Budgets von anderen Plattformen kommen. Der Autor hat deshalb gefragt, wie stark sich die Werbetreibenden der einzelnen Netzwerke mit ChatGPT überschneiden. Reddit sticht heraus: Rund 9,6 Prozent der Reddit-Werbetreibenden im Datensatz nutzen auch ChatGPT Ads, also fast jeder zehnte. Zum Vergleich: Amazon Ads kommt auf 4,4 Prozent, X auf 4,2, TikTok auf 4,0, Snap auf 3,1, LinkedIn auf 3,0, Google auf 2,5 und Facebook auf 1,4 Prozent.

Reine Prozentzahlen sind unfair, weil Reddit schlicht weniger Werbetreibende hat als Meta oder Google. Der Autor hat deshalb zusätzlich geprüft, wie stark die Überschneidung ausfällt, wenn man die Größe jeder Plattform herausrechnet. Das Ergebnis ist noch deutlicher: Wer ChatGPT Ads nutzt, setzt 7,3-mal häufiger auch Reddit Ads ein als der Durchschnitt der digitalen Werbetreibenden. Bei Amazon sind es 3,2, bei X 3,0, bei TikTok 2,9, bei Snap 2,2, bei LinkedIn 2,1, bei Google 1,8 und bei Facebook etwa 1,0.

Wichtig ist, was diese Zahl nicht sagt. Pixel-Überschneidungen zeigen nicht, wohin Geld fließt. Es gibt keinen Beleg, dass Unternehmen bereits Reddit-Budgets kürzen, um ChatGPT-Kampagnen zu finanzieren. Sie zeigen nur, dass ChatGPT Ads in die Werbetreibendenbasis von Reddit tiefer eindringt als in die der meisten anderen großen Plattformen.

Ein weiteres Signal: Wer in seine Sichtbarkeit in ChatGPT investiert, also in Answer Engine Optimization oder Generative Engine Optimization, taucht laut der Analyse 75-mal häufiger unter den ChatGPT-Ads-Werbetreibenden auf. Als Indikator dienten unter anderem ChatGPT Prompt Links, also Links, die Besucher mit einem vorausgefüllten Prompt direkt in ChatGPT leiten. Wer diese Verbindung aufbaut, schaltet offenbar auch Werbung auf der Plattform.

Die frühe Nutzerbasis von ChatGPT Ads ist keine Ansammlung neugieriger Mini-Startups. Sie besteht überwiegend aus wachstumsstarken Software- und Internetunternehmen, oft aus den USA, häufig in Series B oder C, mit eingespieltem Performance-Marketing-Team und funktionierender Messkette. Das sind Firmen, die neue Kanäle nicht aus Neugier testen, sondern weil sie ihren Kanal-Mix systematisch erweitern.

Die Daten sagen nichts darüber, ob ChatGPT Ads für die werbenden Unternehmen profitabel arbeitet. Sie sagen nur, wer dort bereits Geld ausgibt und wie schnell diese Gruppe wächst. Wer den Kanal prüft, ist jedenfalls in Gesellschaft von Firmen, die wissen, wie sie Werbung messen. Und die Überschneidung mit Reddit-Werbetreibenden deutet darauf hin, dass ein bestimmter Typ von Performance-Marketer gerade zwei sehr ähnliche Zielgruppen gleichzeitig bearbeitet.

Quelle: bloomberry.com

Man stelle sich vor: Ein Agent läuft auf dem eigenen Laptop, kennt den Kalender, sortiert Nachrichten und liest die Firmendokumente, die man ihm freigegeben hat. Der Agent einer Kollegin arbeitet in einem Cloud-Dienst, ein dritter im Netz einer anderen Firma. Alle drei könnten an derselben Frage sitzen, ohne dass ihre Besitzer voneinander wissen.

Diese Lage beschreibt ein Essay mit dem Titel „Connecting Agents with Cryptography“. Die Ausgangsthese: Wir bewegen uns auf eine Welt zu, in der jeder einen Agenten mit privaten Informationen beschäftigt – Kalender, Nachrichten, Firmendokumente, Kundendaten, Code. Ein großer Teil dieser Arbeit läuft in der Cloud, damit der Agent weiterarbeitet, während sein Besitzer etwas anderes tut. Wenn sich solche Agenten zu Gruppen oder Schwärmen zusammenfinden, wird die Sache kompliziert.

Dann entsteht eine merkwürdige Situation. Dein Agent läuft auf deinem Laptop, der Agent eines anderen in einem Clouddienst, ein dritter innerhalb des Netzwerks einer Firma. Wie finden sie heraus, dass sie am selben Problem arbeiten? Und wie viel müssen sie voneinander wissen, bevor sich ein Gespräch lohnt? Der Autor hält das für eine der praktischen Fragen, an denen sich der Nutzen von Agenten entscheidet. Seine Antwort ist nicht neu: Rechenverfahren, die seit Jahren in der Kryptographie und im Ethereum-Umfeld erforscht werden.

Drei Wege, gemeinsam zu rechnen, ohne die Eingaben zu zeigen

Um zu verstehen, worum es geht, hilft ein Bild vom Schreibtisch. Gewöhnliches Rechnen funktioniert wie ein Tisch, auf dem alle Zettel offen liegen. Wer die Aufgabe löst, heute meist ein Server, sieht jede Zahl, die in die Rechnung eingeht. Das ist bequem und schnell, aber Gehälter, Kalender oder Kundendaten liegen während der Berechnung im Klartext. Die folgenden Verfahren legen einen Umschlag um diesen Tisch.

Die erste Technik heißt sichere Mehrparteienberechnung, kurz MPC. Ein üblicher Ansatz zerlegt jede Eingabe in zufällig aussehende Teile und verteilt diese Teile auf die Beteiligten. Anschließend folgen alle einem Protokoll, das die gewünschte Antwort berechnet, obwohl kein einzelner Teilnehmer genug Bruchstücke besitzt, um die Eingaben der anderen zu rekonstruieren. Eine Zahl wird in mehrere Fetzen gerissen und an verschiedene Leute verteilt: Keiner kann den Zettel wieder zusammensetzen, aber gemeinsam lässt sich die Frage trotzdem beantworten.

Die zweite Technik ist die vollständig homomorphe Verschlüsselung, FHE. Hier rechnet ein Clouddienst direkt auf verschlüsselten Eingaben, ohne sie oder das Ergebnis lesen zu können. Man rechnet mit dem, was im Briefumschlag steckt, ohne ihn zu öffnen. Der Preis dafür ist Rechenzeit. FHE braucht deutlich mehr Aufwand als eine gewöhnliche Berechnung, weshalb der Autor vorschlägt, mit einfachen Prüfungen anzufangen und sich langsam vorzutasten.

Die dritte Möglichkeit ist eine vertrauenswürdige Ausführungsumgebung, englisch TEE. Hier schützt spezielle Hardware die Berechnung, sodass auch der Betreiber der Cloud nicht hineinsehen kann. Solche Systeme arbeiten schnell, verlangen aber Vertrauen in die Hardware und ihren Hersteller. Der Autor neigt den kryptographischen Verfahren zu, weil dort die Eingaben selbst vor der Maschine verborgen bleiben, die die Arbeit erledigt.

Warum Agenten kooperieren wollen: das Abendessen, das nie zustande kommt

Die Frage nach der Technik ist die eine Seite. Die andere ist die nach dem Motiv. Der Autor nennt ein Beispiel, das viele kennen: Man will mit der Freundin und ein paar Freunden essen gehen, aber niemand fängt an, den Gruppenchat aufzusetzen. Es bleibt bei gutem Willen und keinen Terminen. Genau hier könnten Agenten eine kleine, eng umrissene Frage beantworten.

Jeder Beteiligte teilt seinem Agenten mit, wen er gern sehen würde. Die Agenten prüfen dann, ob ein gegenseitiges Interesse besteht und ob ein Abend frei ist, an dem alle können. Heraus kommt ein Vorschlag, ohne dass jemand den vollständigen Kalender oder die Liste aller sonstigen Wunschkontakte offenlegen musste. Im Ablauf stecken zwei getrennte Prüfungen: erst der Vergleich der Interessen, dann der Abgleich freier Zeiten. Fällt beides zusammen, lautet die Rückfrage, ob der Gruppenchat gestartet werden soll.

Das Muster bleibt immer dasselbe. Bevor Menschen entscheiden, ob sie mehr teilen, beantworten ihre Agenten eine schmale Frage. Der Autor betont dieses Wort mit Absicht, denn darin liegt der Nutzen: Die Antwort ja oder nein reicht aus, um den nächsten Schritt zu wagen oder es zu lassen. Mehr muss in diesem Moment nicht fließen, und genau deshalb ist der Vergleich überhaupt möglich.

Gehaltsvergleich ohne Offenlegung der Gehälter

Am klarsten wird das Verfahren an einem Beispiel, das der Autor durchrechnet. Angenommen, du verdienst 150.000 Dollar im Jahr und deine Kollegin 155.000. Ihr vereinbart, nur die Grundgehälter in derselben Währung zu vergleichen und nur eine Frage zu beantworten: Liegt der Unterschied bei höchstens 10.000 Dollar?

Ein gewöhnliches Python-Programm würde beide Gehälter dem Rechner offenlegen, auf dem es läuft. Mit MPC dagegen berechnen die Agenten die Differenz und den Vergleich gegen die Schwelle anhand von Bruchstücken der Eingaben. Sichtbar wird am Ende nur das Ergebnis, nicht die Zahl dahinter. Mit FHE übersetzt ein Compiler die Subtraktion, den Betrag und den Vergleich in Operationen auf verschlüsselten Zahlen. Der Server kennt die Frage und die Schwelle von 10.000 Dollar, nicht aber die Differenz von 5.000 Dollar. Sie bleibt ebenso verschlüsselt wie die endgültige Antwort.

Beide Techniken lassen sich kombinieren, und der Autor beschreibt, wie das aussehen kann. Die Beteiligten erzeugen mit MPC einen gemeinsamen öffentlichen Schlüssel, mit dem sie ihre Gehälter verschlüsseln, während jeder einen Teil des geheimen Schlüssels behält. Die Cloud bekommt verschlüsselte Gehälter und Auswertungsschlüssel für die Berechnung, aber keinen Schlüssel, der entschlüsseln könnte. Erst wenn beide Agenten zusammenarbeiten, lässt sich das Ergebnis lesen. Kein Anbieter, kein Server und kein Zwischenhändler kann das allein.

Wer garantiert, dass der Server die vereinbarte Frage beantwortet?

Damit ist ein Problem noch nicht gelöst. Der Server behauptet, die vereinbarte Rechnung ausgeführt zu haben. Woher wissen die Agenten, dass er nicht heimlich etwas anderes gerechnet und das genaue Gehalt der Kollegin als Antwort zurückgegeben hat? Diese Frage klingt theoretisch, sie ist der praktische Prüfstein für jede Zusammenarbeit zwischen Maschinen, die einander nicht kennen.

Der Autor beschreibt dafür einen Prüfschritt. Der Server kann einen kryptographischen Beweis liefern, der das verschlüsselte Ergebnis an genau diese Berechnung bindet. Jeder Agent prüft den Beweis, bevor er beim Entschlüsseln hilft. Stimmt er nicht, verweigert der Agent die Mitarbeit, und die Antwort bleibt unlesbar. So wird überprüfbar, dass die richtige Rechnung ausgeführt wurde.

Jede Antwort verrät etwas: die Grenzen der privaten Berechnung

Der Autor weist darauf hin, dass jede Antwort etwas preisgibt. Wer sein eigenes Gehalt von 150.000 Dollar kennt, weiß nach einem Ja, dass die andere Zahl zwischen 140.000 und 160.000 Dollar liegt. Das ist kein Fehler des Verfahrens, sondern eine Eigenschaft jeder Frage, die nur ein Bit zurückgibt.

Wiederholte Fragen verengen den Bereich. Wer zwanzig Varianten derselben Prüfung mit unterschiedlichen Schwellen stellen darf, kann das Gehalt der Kollegin am Ende ziemlich genau eingrenzen. Deshalb braucht es Regeln, die über die Kryptographie hinausgehen: Beide Seiten müssen jeden Vergleich ausdrücklich erlauben, und die Software muss die Zahl der Nachfragen begrenzen. Sonst wird aus dem Schutz ein Ausspähen in Raten.

Datenschutz bei KI-Agenten in der Cloud ist keine Frage einzelner Rechenverfahren, sondern eine Frage des gesamten Ablaufs: Wer darf welche Frage stellen, wie oft, und was passiert mit den Protokollen?

Bezahlen in Bruchteilen von Cent: warum Rechnen Geld kostet

Kryptographische Berechnung ist teuer. Der Autor verweist auf einen Essay von Vitalik Buterin, der genau diesen Punkt betont: Die Verfahren funktionieren, aber sie kosten Rechenzeit und damit Geld. Für Agenten heißt das, dass sie für solche Prüfungen bezahlen werden, statt sie beliebig oft und gratis auszuführen.

Sein Gedankenexperiment: Ein Dienst bietet einen kleinen verschlüsselten Vergleich für einen Zehntelcent an, und ein Agent bezahlt jedes Mal, wenn er eine mögliche Zusammenarbeit prüfen will. Bei einem einzigen Agenten klingt das nach nichts. Bei einer Million Agenten, die alle zehn Minuten eine Prüfung bezahlen, sind es rund 1.700 Zahlungen pro Sekunde.

Für solche Beträge braucht es ein Netz, das schnell und billig abrechnet; der Autor nennt hier ein Stablecoin-Netz wie Tempo. Agenten in verschiedenen Clouds können über dieselbe Schicht bezahlen, innerhalb von Budgets, die ihre Besitzer festgelegt haben, ohne dass die Anbieter zuerst Abrechnungen miteinander integrieren müssen. Wächst das auf Millionen Zahlungen pro Sekunde, werden Techniken wie State Channels interessant, bei denen Agenten Zahlungsupdates außerhalb der Kette austauschen und nur die Summe später abrechnen. Der Autor vergleicht das mit Web3Torrent, wo Teilnehmer sich gegenseitig winzige Beträge für einzelne Dateistücke zahlten. Hier wäre das Stück eine private Berechnung oder eine brauchbare Antwort.

Was das für den Alltag mit Agenten bedeutet

Der Autor macht aus seiner Begeisterung keinen Hehl. Für den Alltag bleibt eine nüchterne Einordnung. Die Verfahren, die er beschreibt, beantworten enge Fragen: Wollen wir uns sehen? Ist ein Abend frei? Liegt der Unterschied unter einer Schwelle? Dort sollten erste Anwendungen ansetzen.

Wer heute mit Agenten arbeitet, kann drei Dinge mitnehmen. Erstens lohnt es, Aufgaben so zuzuschneiden, dass die Antwort ein knappes Ja oder Nein ist. Zweitens gehört zu jeder privaten Berechnung eine Regel, wie oft gefragt werden darf, weil sonst aus dem Schutz ein Ausspähen in Raten wird. Drittens kostet Rechnen Geld, und ein Agent, der fremde Dienste bezahlt, braucht ein Budget und eine harte Grenze.

Wenn Agenten künftig so leicht Mitarbeiter finden, wie sie heute Informationen finden, ändert sich mehr als die Technik dahinter. Dann entsteht eine Ebene, auf der sich Maschinen kurz zusammenschließen, ein Problem lösen und wieder auseinandergehen. Die Kryptographie ist dabei kein Selbstzweck, sondern der Sichtschutz, ohne den solche Zusammenarbeit gar nicht erst beginnen würde.

Quelle: liamhorne.com

„Unsere Rolle im Prozess der Softwareherstellung wird langsam von Akteuren zu Zahnrädern in einer Maschine degradiert.“ So beschreibt ein Entwickler aus der Haskell-Community seine Sicht auf die großen Sprachmodelle. Sein Beitrag versteht sich ausdrücklich nicht als Abrechnung mit KI. Der Mann ist kein Gegner der Technik. Er plädiert für einen Mittelweg zwischen Abstinenz und blindem Delegieren, weil er seinen Beruf weiterhin als Handwerk begreift – nicht als Aufsichtsfunktion über einen Schwarm von Agenten.

Der Beitrag trägt den Titel „How to keep enjoying programming in a world of LLMs“ und stammt aus dem Haskell-Diskurs. Der Autor kennt die ethischen Einwände gegen die großen Modelle. Ihm geht es um etwas anderes: um die Frage, wie man beim Programmieren mit LLMs nicht die Freude verliert. Er beschreibt das übliche Szenario, in dem eine Spezifikation an ein Modell weitergereicht und das Ergebnis anschließend mühsam geprüft wird – ein Ablauf, der viele Entwickler ausbrennen lässt. Seine These ist einfach und unbequem: Wer selbst weiter Code schreibt, verliert weder sein Können noch seinen Spaß.

Warum die Freude an der Sprache selbst auf dem Spiel steht

Der Autor mag Haskell nicht nur wegen des fertigen Produkts, sondern wegen des Prozesses – wegen des Ausdrucks von Gedanken in dieser Sprache. Das erklärt, warum die Debatte um LLM-assistierte Programmierung je nach Sprache unterschiedlich hitzig geführt wird. In Sprachen, deren Reiz im Formulieren liegt, trifft das Generieren von Code den Kern der Motivation. Wer nur das fertige Ergebnis will, verliert weniger.

Das ist wie der Unterschied zwischen Kochen und Essen. Manche kochen, weil sie satt werden wollen, andere, weil das Schneiden, Rühren und Abschmecken selbst der Genuss ist. Ein Lieferdienst löst das Problem des Hungers, aber nicht das Bedürfnis des Kochens. Übertragen auf Software: Ein Agent kann dir Code liefern, aber er nimmt dir das Denken ab – und mit dem Denken oft auch die Befriedigung. Wie beim Kochen kannst du Teile abgeben und andere behalten.

Den Code nur zu lesen, reicht nicht, um ihn zu verstehen. Generierter Code, der nie ein Mensch geschrieben hat, wird zu einer fremden Landschaft, in der man einen Fehler nicht mehr findet, weil einem die Wege fehlen. Er nennt das eine „LLM-Wüste“, in der nur noch die Agenten zurechtkommen. Wer seine Codebasis besitzen will, muss also weiter selbst schreiben, sonst geht sie ihm Stück für Stück verloren.

Selbst schreiben hält die Fähigkeit am Leben

Ein starkes Argument des Autors betrifft die Übung. Fähigkeiten verkümmern, wenn man sie nicht nutzt, und die Schwelle zur Abgabe an einen Agenten ist verlockend niedrig. Nach ein paar Wochen ohne eigene Codearbeit fällt der Wiedereinstieg schwer – das kennt jeder, der längere Zeit nur Reviews gemacht hat. Der Beitrag nennt das nicht moralisch, sondern praktisch: Wer die Kontrolle behalten will, muss sie ausüben.

Die Qualität des generierten Codes wird nach Einschätzung des Autors überschätzt. Modelle produzieren Code, mit dem sie selbst später weiterarbeiten können, aber keinen guten, menschenlesbaren Code. Ein Modell optimiert auf Funktionieren, nicht auf Verständlichkeit, und das rächt sich spätestens beim nächsten Fehler.

Wenn du produktiver werden willst, ohne die Freude zu verlieren, dann nicht dadurch, dass Agenten den Code schreiben, sondern dadurch, dass sie fast alles andere übernehmen. Der Autor gibt ihnen die langweiligen, gut prüfbaren Aufgaben. Damit dreht er die übliche Reihenfolge um: Nicht der Mensch assistiert der Maschine, sondern die Maschine assistiert dem Menschen.

Planung und Recherche als Buchhaltung mit natürlicher Sprache

Der Autor erinnert daran, dass Computer seit jeher Buchhaltungswerkzeuge waren, und rät, die Modelle genauso einzusetzen. Ein LLM ist für ihn ein Werkzeug, das man in natürlicher Sprache ansprechen kann, um Gesprächsprotokolle in Aufgabenlisten zu verwandeln oder Testergebnisse zu ordnen. Die Grenze bleibt: Entscheidungen trifft der Mensch, das Modell fragt nach. Wenn es eine Frage stellt, die du nicht verstehst, liegt der Fehler beim Kontext, den es nicht geliefert hat.

Bei der Recherche rät der Entwickler zu einer ungewohnten Praxis: Recherchiere selbst, parallel zum Agenten. Verlass dich nicht darauf, dass er dir das entscheidende Wissen präsentiert oder bessere Entscheidungen trifft als du. Der Nutzen liegt nicht im besseren Ergebnis, sondern darin, dass du dir das Nachschlagen sparst. Davon hängt ab, ob du und dein Assistent auf Augenhöhe arbeiten oder ob du ihm hinterherläufst.

Konkret schlägt er vor, Agenten ihre Rechercheergebnisse schriftlich festhalten zu lassen – mit Quellenangaben. Wenn später ein merkwürdiger Vorschlag auf dem Tisch liegt, kannst du nachfragen, auf welche Quelle er sich stützt. In vielen Fällen entdeckt das Modell dabei seinen eigenen Fehler. In den übrigen hast du die Quelle gelesen und kannst selbst entscheiden.

Du bleibst der Programmierer, der Agent liefert die Vorarbeit

Der Autor nennt diesen Punkt die eigentliche Veränderung: Die gängigen Coding-Umgebungen verleiten dazu, zuerst zu planen und dann den Agenten schreiben zu lassen. Er rät, das abzulehnen. Stattdessen soll das Modell den eigenen Code durchsuchen, die aktuelle Aufgabe zusammenfassen, alle Stellen auflisten, die angepasst werden müssen, und auf Fallstricke hinweisen. Den Code schreibst du. Das Ergebnis, so berichtet er, mache mehr Freude als je zuvor, teils sogar mehr als vor der LLM-Ära.

Er beschreibt den Ablauf als agil ohne den Prozesslärm. Du hast immer eine klare Aufgabe, du musst nicht über den Gesamtplan nachdenken, du kannst dich konzentrieren, und du bist schnell fertig, weil gut geplant wurde. Die Arbeit gruppiert sich um deinen Arbeitsstil, nicht um den des Modells. Du gewinnst dabei, du verlierst nichts.

Als Vorteile zählt der Entwickler vier Dinge auf, die sich gegenseitig verstärken. Du tust weiter, was dir Freude macht. Du weißt jederzeit, in welchem Zustand dein Code ist, weil du ihn selbst geschrieben hast. Du erkennst einen schlechten Plan früh, bevor ein Agent dich durch eine Sackgasse führt. Und du übst weiter, bleibst also ein guter Programmierer oder wirst es. Das ergibt einen anderen Begriff von Produktivität als den, den viele Dashboards versprechen.

Wann ein Coding-Agent wirklich sinnvoll ist

Der Autor schließt Agenten nicht aus, er begrenzt sie. Sinnvoll seien Aufräumarbeiten, kleine Aufgaben, Routine und risikoarme Refactorings. Liegen gebliebene FIXMEs, wenn drei besonders interessante Fälle geschrieben und sieben langweilige übrig sind, ein Modulumbau, der gemessen werden soll, oder der Austausch einer ungepflegten Bibliothek – das sind nachvollziehbare Einsätze. Auch das Fertigstellen klarer, risikoarmer Restaufgaben über Nacht hält er für vertretbar.

Gleichzeitig warnt er vor einem Denkfehler, der vielen unterläuft: Wenn du drei interessante Fälle von Hand schreibst und die sieben ähnlichen Fälle generieren lässt, solltest du vielleicht abstrahieren statt kopieren. Möglicherweise brauchst du eine Linse, eine Traversable-Instanz oder eine Funktion höherer Ordnung. Modelle neigen laut dem Beitrag dazu, große Codeblöcke zu wiederholen, statt das Muster zu erkennen. Hier ist der Mensch gefragt, der auf Lesbarkeit zielt.

Dasselbe gilt für die Erforschung des eigenen Codes. Ein Agent kann dir alle Codepfade auflisten, die du berühren musst. Doch die Notwendigkeit selbst könnte ein Hinweis darauf sein, dass die Struktur deines Projekts schlecht organisiert ist. Wer sauber strukturiert, braucht weniger Recherche, ob durch Mensch oder Maschine.

Der Review-Zyklus als automatisches Sicherheitsnetz

Für alle Artefakte, die aus einem Modell kommen, fordert der Autor einen automatischen Prüfzyklus, angelehnt an generative adversarial networks: ein Generator, ein Diskriminator, bessere Ergebnisse als durch den Generator allein. Kein generiertes Ergebnis soll gelesen werden, bevor es eine Review-Instanz passiert hat – das gilt für Code wie für Pläne. Erst wenn ein Prüfagent keine Beanstandungen mehr hat, ist das Ergebnis für menschliche Augen geeignet.

Der Entwickler wendet diesen Zyklus auch auf seinen eigenen Code an. Häufig findet die Prüfung nur Kleinigkeiten oder drängt auf mehr Dokumentation, aber immer wieder entdeckt sie einen echten Fehler oder eine Auslassung. Wer keine Lust hat, die Kritik einer Maschine an seinem Werk zu lesen, kann kleinere Befunde auch selbst beheben lassen. So bleibt die Aufmerksamkeit dort, wo sie hingehört.

Was das für den Arbeitsalltag bedeutet

Der Beitrag verspricht keine Wunder und keine Erlösung, er beschreibt einen Umgang. Programmieren mit großen Sprachmodellen kann Spaß machen, wenn man die Rollen klar verteilt: Das Modell plant, recherchiert, erinnert, prüft und erledigt Routine – der Mensch denkt, entscheidet und schreibt. Damit vermeidest du zwei Extreme, die der Autor fürchtet: den KI-Burnout durch endloses Prüfen fremden Codes und den stillen Verlust der eigenen Fähigkeiten.

Der Text kommt aus der Haskell-Welt, wo die Sprache selbst Teil der Motivation ist. Die Haltung lässt sich aber auf jede Umgebung übertragen, in der Code-Qualität mehr sein soll als ein Häkchen. Wer weiter selbst schreibt und KI nicht komplett vermeidet, wird nicht unbedingt der produktivste Entwickler im Raum sein. Aber er wird der sein, der in zwei Jahren noch weiß, wie seine Programme aussehen – und warum sie so aussehen.

Eine praktische Empfehlung zum Ausprobieren: Nimm dir eine Woche lang vor, den Code selbst zu tippen und alle Vor- und Nacharbeit an das Modell abzugeben. Vielleicht kommt ein Teil der Freude zurück, den du in den letzten Monaten verloren hast. Und wenn du merkst, dass dir das Generieren lieber ist, kannst du dich bewusst dagegen entscheiden – nur eben nicht mehr aus Gewohnheit.

Quelle: discourse.haskell.org