Kategorie: Meinung

Mitte September erreichten Bryna Kra innerhalb einer Woche mehrere Manuskripte mit derselben Behauptung: Sie wollen die Nivat-Vermutung beweisen. Kra arbeitet seit Jahren an dem Problem, offen ist es seit fast drei Jahrzehnten. Die Absender sind Forschende, die zum ersten Mal in diesem Gebiet arbeiten. Einige räumen offen ein, KI-Werkzeuge benutzt zu haben, allerdings nur, um das Englische zu polieren oder den Beweis gegenprüfen zu lassen. Kra bietet an, die Argumente in einer Videokonferenz zu erläutern. Niemand nimmt die Einladung an.

Der Vorgang steht am Anfang eines Gastbeitrags, den Kra auf dem Blog von Terence Tao veröffentlicht hat. Der Satz, den sie zur Überschrift macht, ist eine Diagnose: „Deep theorems were scarce and difficult and so became an effective mechanism to identify deep thought. AI has broken this system.“ Tiefe Theoreme waren selten und schwer, deshalb taugten sie als Nachweis tiefen Denkens. Die KI hat diesen Mechanismus zerbrochen. Wer verstehen will, was KI in der Mathematik gerade verändert, findet dort eine klare Beschreibung — es geht nicht um Rechenleistung, sondern um die Bedeutung eines Ergebnisses.

Tao vermerkt in einer Randnotiz, der Beitrag sei ursprünglich in einem anderen Dateiformat geschrieben und mit KI konvertiert worden. Auch der Ort, an dem über die Folgen der Maschinen geschrieben wird, ist von ihnen berührt. Kein Skandal, nur eine Fußnote.

Die Nivat-Vermutung: Fliesen, Fenster und ein Satz über Periodizität

Ein Blick auf das Problem hilft zu verstehen, worum es geht. Man denke an eine unendliche Ebene, lückenlos mit quadratischen Fliesen ausgelegt, jede Fliese entweder rot oder blau. Nun betrachtet man jedes rechteckige Fenster fester Größe, etwa n Fliesen breit und m Fliesen hoch, und zählt, wie viele verschiedene Muster in diesem Fenster vorkommen können. Die Vermutung besagt: Sind es höchstens n mal m solcher Muster, dann wiederholt sich die gesamte Färbung unter einer festen, von null verschiedenen Verschiebung — die Fläche ist periodisch.

Das ist ein Satz über den Sprung vom Lokalen ins Globale. Eine präzise Schranke für das, was in einem kleinen Ausschnitt passiert, erzwingt eine einfache Struktur des Ganzen. Solche Aussagen sind in der Kombinatorik und in den dynamischen Systemen selten, weil sie zwei Welten verbinden: das diskrete Zählen von Mustern und das Studium von Bewegungen, die sich nicht mehr auflösen lassen.

Bryna Kra und Van Cyr bewiesen 2012 einen Teil: Periodizität gilt, wenn die Zahl der Muster höchstens halb so groß ist wie die Fläche des Fensters. Sie übersetzten die kombinatorische Frage in eine geometrische, in der man untersucht, wie sich Information in einem System ausbreitet oder eben nicht. Kurz darauf fanden Jarkko Kari und Michal Szabados einen zweiten Weg, der dieselbe Frage als algebraisches Objekt behandelt, mit bestimmten Polynomen. Zwei Methoden, ein Problem — für alle Beteiligten ein deutlicher Wink, den verbindenden Begriff zu suchen. Sie suchten ihn, fanden ihn nicht und wandten sich anderem zu.

Warum seltene Theoreme lange als Maßstab taugten

Jahrzehntelang galt in der Mathematik ein einfaches Prinzip. Wer ein starkes Theorem bewies, leistete etwas. Je tiefer der Beweis, je überraschender die Verbindungen, desto größer die Anerkennung. Stellen, Preise und Forschungsrichtungen hingen an dieser Währung.

Dabei war das Theorem selbst nie das eigentliche Ziel, sondern ein Ersatz. Verständnis lässt sich nicht direkt messen, also misst man das, was schwer zu fälschen war: ein neues Resultat. Wer ein schweres Problem löst, hat in der Regel Jahre in ein Gebiet investiert, verborgene Zusammenhänge freigelegt und die Antwort für die Gemeinschaft nachvollziehbar gemacht. Genau deshalb funktionierte das Signal. Tiefe Theoreme waren selten und teuer, also konnte man an ihnen ablesen, wo tiefes Denken steckte.

Denk an einen Geldschein. Sein Wert liegt nicht im Papier, sondern im Vertrauen, dass er schwer nachzumachen ist. Solange das galt, konnte man mit ihm rechnen. Sobald aber jeder Schein in Sekunden druckbar wird, verliert er seine Funktion als Signal — unabhängig davon, ob die einzelnen Scheine echt sind.

Ähnlich hier. Ein mathematischer Beweis ist wie ein Zertifikat, das bestätigt, dass ein Weg existiert. Als Zertifikat bleibt er nützlich. Nur sagt er nichts darüber, wie man den Weg gefunden hat, wo die Abzweigungen liegen und warum gerade dieser Weg gangbar ist. Diese Wegbeschreibung ging früher automatisch mit dem Resultat einher, weil niemand ein schweres Theorem ohne sie erreichte.

Was die Maschinen in diesem Fall anders machen

Kra benennt, wo die Stärke der Modelle liegt. Die KI muss nicht erst über Jahre verschiedene Teilgebiete aufnehmen, um Verbindungen zu sehen. Sie kann Notation übersetzen, Teilergebnisse vergleichen und Tausende Kombinationen durchprobieren, ohne dass Frustration einsetzt oder Karrieren dazwischenkommen. Genau dieses Zusammenführen zweier Ansätze, das Kra und ihre Kollegen erfolglos versucht haben, gehört zu den Aufgaben, in denen KI in der Mathematik überzeugt.

Dazu kommt die Sichtbarkeit. Die Nivat-Vermutung ist inzwischen für das Projekt Formal Conjectures von Google DeepMind vorgeschlagen worden. Damit wird sie zum Ziel automatisierten Schließens und erreicht Menschen, die mit dem Gebiet bislang nichts zu tun hatten. Das macht das Problem bekannter — und die Lage für alle unruhiger, die daran arbeiten.

Denn die Manuskripte kommen schneller, als die Gemeinschaft sie lesen kann. Von Verdauen ganz zu schweigen. Wer einmal in einem Fachgebiet gearbeitet hat, weiß, dass das Lesen eines dichten Beweises Tage kostet. Die Maschinen produzieren in dieser Zeit Dutzende.

Ein Beweis ist mehr als ein Zertifikat

Angenommen, die Ergebnisse sind korrekt, schreibt Kra. Dann sind sie ein mathematischer Beitrag. Und trotzdem bleiben Fragen offen: Was haben wir gelernt? Was haben die Autorinnen und Autoren beigetragen? Welche Wirkung entfaltet das Resultat? Ein Beweis ist mehr als der Nachweis, dass etwas stimmt. Er ist eine Geschichte, ein Bild, eine Einsicht. Er hebt neue Ideen hervor und öffnet Richtungen dafür, was als Nächstes zu fragen ist.

Sie zitiert William Thurston, der 2010 auf MathOverflow auf die Frage antwortete, was Mathematiker eigentlich tun: „The product of mathematics is clarity and understanding. Not theorems, by themselves.“ Klarheit und Verständnis, nicht Theoreme an sich. Der Satz ist fünfzehn Jahre alt und passt zur Lage.

Autorschaft ist für Kra mehr als eine Zeichenkette, die etwas beweist. Sie bedeutet intellektuelle Verantwortung, Verständnis eines neuen Begriffs, die Fähigkeit, auf Rückfragen zu antworten, und die Einordnung des Neuen in das Bekannte. Man kann es auch so sagen: Dass niemand auf das Zoom-Angebot eingeht, entwertet den Beweis nicht formal. Es entwertet die Antwort auf die Frage, was dieser Beweis dem Fach bringt.

Kra begrüßt KI-generierte Beweise ausdrücklich und erwartet, dass rein menschliche Beweise selten werden. Das hält sie nicht für den Verlust eines Werkzeugs — externe Hilfsmittel sind in der Mathematik normal. Die Frage ist nicht, ob Maschinen an Entdeckungen teilnehmen. Sie tun es längst. Die Frage ist, was die Gemeinschaft noch wertschätzt, wenn eine bestimmte Art der Entdeckung keine knappe Ressource mehr ist.

Anreize, Peer Review und die Karrieren junger Forschender

Hier wird der Text konkret. Zeitschriften veröffentlichen neue Resultate, Berufungskommissionen belohnen diese Veröffentlichungen, Preisgremien zeichnen die Person aus, die das Resultat gefunden hat. Dieses Zusammenspiel trägt die gegenwärtige Theorem-Produktion nicht mehr. Begutachtung ist ein langsamer Prozess, der auf der unbezahlten Arbeit einer kleinen, überlasteten Gruppe beruht. Einzelne Einsendungen lassen sich bewältigen, das aktuelle Volumen ertränkt die Gutachtenden.

Gleichzeitig hängt die Karriere junger Forschender daran, Theoreme zu produzieren, möglichst viele, möglichst schnell. Für sorgfältige Prüfung und gute Darstellung gibt es keinen Lohn. Zeit für tiefe Reflexion entsteht nicht, wenn jemand eine Frage in ein Modell tippt und kurz darauf ein Manuskript erhält. Kra betont, dass all diese Probleme schon vor der KI existierten. Nur hat die Mathematik jetzt nicht mehr den Luxus, sie gemächlich zu lösen.

Ihr Vorschlag ist unbequem, weil er die Belohnung umverteilt. Autorinnen und Autoren müssen erklären können, wie der Beweis funktioniert und wie sie zu ihm gekommen sind. Zeitschriften müssen unterscheiden und getrennt würdigen, was Entdeckung, was Beweisführung, was Formalisierung und was Erklärung ist. Gute Darstellung wird damit nicht mehr Beiwerk, sondern Kern einer intellektuellen Leistung.

Mathematik als Kanarienvogel und was das konkret heißt

Kra nennt ihr Fach den Kanarienvogel im Bergwerk. Der Grund ist einfach: Mathematische Aussagen lassen sich prüfen. Anders als in der Politik oder in Teilen der Kunst lässt sich hier vergleichsweise schnell sagen, ob eine Behauptung trägt. Deshalb sehen wir die Umwälzung in der Mathematik zuerst. Der Satz, dass KI mathematische Beweise erzeugt, ist keine Zukunftsmusik mehr, er beschreibt einen gewöhnlichen Dienstag im Postfach.

Wenn aber ein Feld mit prüfbaren Aussagen ins Rutschen gerät, was passiert dann in Feldern, in denen Evidenz und Deutung umstritten sind? Wissenschaft, Recht, öffentliche Verwaltung und Kunst werden ähnliche Fragen beantworten müssen: Was ist wertvoll, wenn das Angebot an Text, Bild und Lösung explodiert? Die Mathematik liefert kein Rezept, aber einen frühen Blick auf die Mechanik.

Für Leserinnen und Leser heißt das weniger, dass sie sich mit Nivat beschäftigen müssen, sondern dass sie die richtige Frage stellen: Nicht, wie gut die Maschinen sind. Sondern woran wir künftig erkennen, dass jemand verstanden hat, was er tut. Die Antwort liegt nicht in einem Theorem allein. Sie liegt darin, ob jemand erklären kann, was der Beweis lehrt, wohin er führt und warum er mehr ist als ein Häkchen auf einer Liste.

Kra schließt mit einem Satz, den man ernst nehmen kann, ohne euphorisch zu werden: Es sei eine aufregende Zeit, Mathematikerin zu sein. Das klingt nach einem Werbesatz, ist aber das Gegenteil. Es bedeutet, dass die Gemeinschaft nun selbst definieren muss, was sie an einem Ergebnis für wertvoll hält — und dass diese Definition nicht länger von der Seltenheit tiefer Theoreme diktiert wird. Der Befund vom zerbrochenen Mechanismus ist keine Klage. Er verlangt, etwas Neues an seine Stelle zu setzen.

Quelle: terrytao.wordpress.com

Ein Agent erzeugt eine Implementierung, lässt die Verifikation laufen, sieht sie scheitern, verändert den Code und startet den Durchlauf erneut. Am Ende steht ein Commit, bei dem alle Kontrollen grün sind, und eine Attestierung, die diesen Endzustand festhält: welche Prüfungen liefen, mit welchem Ergebnis und welcher Laufzeit, dazu der Commit-Hash und Checksummen der Konfiguration, die den Lauf gesteuert hat.

Das genügt zum Ausliefern. Es genügt nicht, um zu verstehen, was unterwegs geschehen ist. Ein Entwickler, der an einer solchen Software-Fabrik arbeitet, beschreibt diesen Punkt als dritte Folge einer Reihe über Agenten und CI – und benennt darin eine Lücke, die mit jeder Stufe zusätzlicher Automatisierung größer wird. In der Forschung gibt es dafür ein altes Gegenmittel: das Laborjournal, in dem nicht nur das Endergebnis steht, sondern auch jeder Fehlversuch.

Was verschwindet, wenn der Agent die Reparaturschleife besitzt

Ein Agent implementiert etwas, die Tests schlagen fehl, er interpretiert die Fehlermeldungen, ändert den Code und lässt erneut prüfen. Es folgen weitere Fehlschläge, weitere Korrekturen, irgendwann passt alles. Die Attestierung dokumentiert dann den Endzustand: alle Checks grün an diesem Commit. Laut dem Autor erfassen die Attestierungen bei Swamp dabei mehr als die meisten Agenten-Setups, nämlich jede ausgeführte Kontrolle mit Ergebnis und Dauer, den Commit-Hash und sha256-Prüfsummen der Konfiguration, die den Lauf bestimmt hat. Das deckt die Integrität der Konfiguration und das Verifikationsergebnis ab.

Was fehlt, ist der Weg dorthin. Welche Fehlschläge der Agent angetroffen hat, wie er sie gedeutet hat, welche Zwischenstände er gebaut und wieder verworfen hat – nichts davon hinterlässt eine Spur. Für das Ausliefern ist das unerheblich: Tests bestehen, der Linter ist sauber, das Review hat nichts beanstandet, also geht die Änderung raus. Für Governance zählt es dagegen, weil dort Fragen gestellt werden, die nur die Zwischenschritte beantworten können.

Warum Verantwortlichkeit nicht das schwierige Problem ist

Die Frage, die in Diskussionen immer wieder auftaucht: Wer ist verantwortlich, wenn eine Maschine den Code geschrieben hat? Die Antwort des Autors ist nüchtern: verantwortlich ist die Person, die den Auftrag erteilt hat – so wie man für alles geradesteht, was man ausliefert, unabhängig davon, welche Werkzeuge daran beteiligt waren. Das Stanford Law CodeX Centre hat im Februar von einem Haftungsvakuum gesprochen, in dem sich Verantwortung über Entwickler, Modellanbieter und Hersteller verteilt. An der Grenze zwischen Anbieter und Kunde trifft das zu, denn die rechtlichen Rahmenwerke für zugesicherte Agenten-Software sind unterentwickelt. Auf der Ebene der Praxis ist die Zuständigkeit dagegen klar.

Wer die Anweisung gibt, die Verifikationskriterien definiert und das Ergebnis ausliefert, trägt die Folgen. Das schwierigere Problem liegt eine Ebene tiefer: Kann diese Person ihre Aufgabe überhaupt wahrnehmen? Wenn in der Produktion etwas schiefgeht und die Spur zu einer agentengesteuerten Änderung führt, braucht man belastbare Antworten auf sehr konkrete Fragen. Hat der Agent während der Verifikation einen verwandten Fehler angetroffen und umgangen, statt die Ursache zu beheben? Hat das Review das problematische Muster markiert, und hat der Agent falsch darauf reagiert? Hat die Prüfkonfiguration die relevante Testkategorie gar nicht abgedeckt?

Solche Fragen stellt jede Incident-Aufarbeitung auch bei menschlich geschriebenem Code. Der Unterschied liegt in den Spuren. Entwicklerinnen und Entwickler hinterlassen Commit-Historien, Diskussionen im Pull Request, Nachrichten im Chat und die Erinnerung des Reviewers daran, worüber er sich Sorgen gemacht hat. Eine agentengesteuerte Verifikationsschleife hinterlässt einen finalen Commit und eine Attestierung des letzten Durchlaufs. StrongDM hat mit seiner veröffentlichten „Software Factory“ eine Richtung beschrieben, in der Agenten Code schreiben und gegen eine digitale Zwillingumgebung testen, ohne dass ein Mensch den Code liest. Ob Audit-Spuren für Agentenentscheidungen, Rollback-Verfahren oder die Weitergabe von Spezifikationsfehlern vorgesehen sind, bleibt in dieser Darstellung offen.

Was Iterationsprovenienz leisten kann – und was nicht

Hier lohnt ein genauer Blick darauf, was zu den bereits etablierten Eigenschaften hinzukommt. Konfigurationsintegrität beantwortet die Frage, ob die erwarteten Regeln und Prompts den Lauf bestimmt haben; die Attestierung trägt Prüfsummen von Review-Prompts, Workflow-Definitionen und Konfigurationsdateien, und die Pipeline kann diese Dateien am verifizierten Commit erneut hashen und vergleichen. Ergebnisintegrität beantwortet die Frage, ob die Kontrollen tatsächlich ausgeführt wurden und das behauptete Resultat erzeugt haben. Aus der Attestierung allein ist das nicht vollständig beweisbar, und für Kontrollen mit höherem Absicherungsbedarf bleibt die Ausführung auf unabhängiger Infrastruktur der richtige Weg.

Iterationsprovenienz beantwortet eine dritte Frage: Was ist unterwegs passiert? Welche Fehlschläge traten auf, welche Codeänderungen folgten daraus, und wie führte die Abfolge der Versuche zum Endzustand? Sie beweist nicht, dass ein Lauf ehrlich war oder dass der Agent einen Fehler richtig gedeutet hat. Sie macht den Prozess im Nachhinein prüfbar. Das ist der Unterschied zwischen einer Untersuchung, die stattfinden kann, und einer, für die kein Material existiert.

Was ein brauchbarer Iterationsdatensatz enthalten muss

Zuerst Identität und Konfigurationsinhalt: welches Agentsystem, welche Modellversion, welches Instruktionsset den Lauf gesteuert hat. Ein Review-Prompt ist ausführbare Politik – ändert man ihn, ändert sich, worauf das Review achtet. Prüfsummen in der Attestierung bestätigen zwar, dass die Konfiguration dem eingecheckten Stand entspricht, doch wenn die Ausgabe eines Agenten infrage steht, muss der tatsächliche Inhalt der Prompts und Regeln dauerhaft wiederherstellbar bleiben und nicht nur der Nachweis, dass er einmal gepasst hat. Prompts und Workflow-Definitionen als versionierte Dateien im Repository sind dafür die naheliegende Ablage.

Dann die Iterationshistorie: die Abfolge von Verifikationsfehlern und zugehörigen Codeänderungen, erfasst als strukturierte Daten. Keine vollständigen Gesprächsprotokolle. Der Datensatz soll beobachtete Fehlschläge mit den Änderungen und Wiederholungen verknüpfen, ohne die Erklärung des Agenten als Beweis für die Ursache zu behandeln. Die diagnostische Begründung eines Agenten ist ein brauchbarer Input für eine Untersuchung, aber keine verlässliche Schlussfolgerung. Eine aktuelle Übersichtsarbeit zur Execution Provenance bei LLM-Agenten unterscheidet zwischen der vollständigen Aufzeichnung eines Laufs und dem auf Belege reduzierten Ausschnitt, der zeigt, welche Evidenz welche Entscheidung gestützt hat. Die Governance-Ebene braucht den Belegausschnitt, nicht die Gesamtaufzeichnung.

Hinzu kommen Metadaten zur Verifikationsabdeckung: welche Prüfungen liefen, welche Fehlerkategorien sie hätten erkennen können und welche nicht. Eine grüne Testsuite sagt nichts darüber, ob die Tests die geänderten Codepfade überhaupt berühren oder ob die Änderung Verhalten einführt, das kein bestehender Test ausübt. Ohne diese Metadaten lässt sich „geprüft und sicher“ nicht von „gegen eine unvollständige Prüfmenge verifiziert“ unterscheiden. Schließlich die Review-Provenienz: welcher Review-Prompt gegolten hat, was geprüft wurde, was beanstandet wurde und wie die Beanstandungen aufgelöst wurden. Menschliches Code-Review war immer ein unstrukturiertes Gespräch; ein durch versionierte Prompts gesteuertes Agenten-Review kann strukturierte Belege darüber liefern, was es tatsächlich geprüft hat – aber nur, wenn man sie festhält.

Warum die Werkzeuge der Supply-Chain-Sicherheit in die falsche Richtung zeigen

Die Community für Lieferkettensicherheit hat über ein Jahrzehnt in Provenienzinfrastruktur investiert. in-toto beschreibt Software-Lieferketten als Schritte autorisierter Funktionsträger mit kryptografischer Verkettung von Schritt zu Schritt. SLSA definiert abgestufte Ebenen der Build-Provenienz, von L1, wo Provenienz überhaupt existiert, bis L3 mit gehärteter Build-Umgebung und Manipulationsschutz. Googles Binary Authorization for Borg setzt Provenienzrichtlinien an der Deployment-Grenze durch, und Sigstore hat die Hürde des Schlüsselmanagements beseitigt, an der die meisten Open-Source-Projekte zuvor gescheitert sind.

Diese Infrastruktur ist ausgereift und löst reale Probleme. Sie teilt allerdings eine Annahme: Code wird von Menschen geschrieben, von Maschinen gebaut, und die interessanten Provenienzfragen betreffen die Build- und Deployment-Kette. Der Autorenschritt liegt entweder außerhalb des Geltungsbereichs oder wird durch eine einzige Zusicherung abgehandelt – ein Mensch hat das über ein Code-Review eingereicht. Sobald der Autorenschritt eine innere Struktur bekommt, die es wert ist, festgehalten zu werden, muss die Provenienzkette sich rückwärts verlängern. Die Bausteine existieren: Soll-Politik gegen Ist-Belege, autorisierte Akteure, kryptografische Verkettung von Schritten, abgestufte Absicherungsniveaus. Auf die agentengesteuerte Verifikationsschleife angewandt, ist das eine Erweiterung, keine Erfindung.

Der kleinste nützliche Datensatz – und was daraus folgt

Der praktikable Anfang besteht darin, einen abgeschlossenen Agentenlauf nachträglich rekonstruierbar zu machen. Für jeden Versuch bleiben der eingehende und der ausgehende Commit beziehungsweise Diff erhalten, die ausgeführten Prüfungen mit ihren Fehlerrückgaben, das Modell und die Konfiguration des Laufs sowie eine Verknüpfung zum nachfolgenden Versuch. Diese Sequenz wird an die abschließende Attestierung gebunden. Das erfordert kein vollständiges Gesprächsprotokoll, sondern so viel strukturierte Evidenz, dass jemand den Pfad von der ersten Implementierung über jeden gescheiterten Versuch bis zum grünen Ergebnis nachvollziehen kann, wenn eine Änderung erklärungsbedürftig wird.

Wird dieser Datensatz signiert, sind spätere Manipulationen erkennbar. Werden die Kontrollen in einer gehärteten Umgebung ausgeführt, steigt die Gewissheit, dass der Datensatz das tatsächliche Geschehen abbildet. Beides hilft wenig, wenn die Iterationshistorie von vornherein verworfen wurde. Eine abschließende Attestierung kann belegen, dass die geforderten Kontrollen für einen bestimmten Commit bestanden wurden. Sie kann nicht zeigen, ob der Agent früher auf einen relevanten Fehler gestoßen ist, welche Änderung er daraufhin vorgenommen hat und ob diese Antwort das zugrunde liegende Problem adressierte. Genau diese Fragen wird eine Incident-Aufarbeitung beantworten müssen.

Wenn Agenten ihre eigene Arbeit so lange reparieren dürfen, bis das Ergebnis grün ist, muss die Geschichte dieser Reparaturen ein Artefakt einer Softwareänderung werden – gleichrangig neben dem Code, den Tests und der finalen Attestierung. Der Autorenschritt hat sich verändert. Die Aufzeichnung dieses Schritts darf nicht verschwinden, nur weil am Ende alle Ampeln grün stehen.

Quelle: stack72.dev

„I don’t like them“, schreibt Martin Fowler über Large Language Models. Nicht über ihre Fähigkeiten – über das Gefühl, das ihre Antworten hinterlassen. Der Softwarearchitekt und Autor, dessen Texte seit Jahrzehnten prägen, wie in der Branche über Entwurf und Refactoring gesprochen wird, arbeitet täglich mit Sprachmodellen und bestreitet ihren Nutzen nicht. Er beschreibt eine Abneigung, die nicht aus technischem Zweifel kommt, sondern aus dem Umgang mit ihnen. Das ist mehr als eine Geschmacksfrage.

Er schwankt. Zwischen Faszination über die Wirkung auf den eigenen Beruf und der Aussicht auf Produkte, die viel schneller entstehen. Zwischen Angst vor Agentenschwärmen, die virtuelle und physische Infrastruktur übernehmen, und der Hoffnung auf Medikamente, die solche Modelle mitentwickeln könnten. Am Ende steht eine nüchterne Feststellung: An diesem Zug vorbeizukommen ist keine echte Option. Und doch dominiert eine einzige Emotion, wenn er über seine direkten Erfahrungen spricht – die Abneigung. In Umfragen zeigt sich dasselbe Muster: Menschen halten die Modelle für nützlich und glauben gleichzeitig, dass sie der Gesellschaft schaden werden.

Zwischen Faszination und Furcht: die gespaltene Haltung zur künstlichen Intelligenz

Wer den Text des Autors liest, findet keine gerade Linie, sondern ein Knäuel. Da ist die Begeisterung über das, was sich im eigenen Beruf verändert. Da ist die Sorge vor Szenarien, in denen Agentenschwärme die Kontrolle über Netzwerke oder physische Systeme übernehmen, bis hin zu biologischen Waffen, die mit Hilfe solcher Modelle entworfen werden könnten. Und da ist die Gegenbewegung: Dieselbe Technik könnte Heilmittel finden und Wohlstand schaffen, von dem wir heute nur reden. Diese Stränge laufen im selben Kopf nebeneinander her, und Fowler sagt offen, dass er sie nicht sauber auflösen kann.

Er leitet daraus keine Blockade ab. Er sagt nicht, man solle aussteigen, sondern dass es keine echte Wahl gibt, ob man aufspringt. Die Werkzeuge sind da, die Konkurrenz nutzt sie, der Verzicht wäre eine einseitige Entscheidung mit Kosten. Wenn man nach dem Lager dieser Kritik sucht, findet man kein Nein zur Technik. Man findet ein Unbehagen, das sich mit der Nutzung arrangiert.

Die Umfragedaten, die er anführt, passen ins Bild: Nützlichkeit und gesellschaftlicher Schaden werden gleichzeitig bejaht. Das ist kein Widerspruch, sondern eine Differenzierung, die viele nicht in Worte fassen. Ein Werkzeug kann gute Arbeit leisten und trotzdem Teil einer Entwicklung sein, die man nicht gewollt hat.

Der Ton macht die Abneigung: das Uncanny Valley des Gesprächs

Der Autor beschreibt die Stimme der Modelle als kratzend, als eine Art Uncanny Valley des Gesprächs: nicht eindeutig Maschine, nicht überzeugend Mensch, sondern etwas dazwischen, das die Erwartung an ein Gegenüber weckt und dann enttäuscht. Eine ästhetische Beobachtung, die die meisten technischen Debatten ignorieren. Ein Teil der LLM-Kritik lässt sich nicht in Benchmarks messen.

Nimm als Vergleich eine Auskunft am Telefon, die aus einem Skript liest. Die Informationen mögen stimmen. Der Ton verrät trotzdem, dass niemand mit dir spricht, sondern eine Vorlage abgearbeitet wird. Bei Sprachmodellen ist dieser Effekt stärker, weil das Skript unendlich viele Formen annehmen kann und sich mit jedem Satz weiter an menschliche Rede herantastet, ohne sie je zu erreichen.

Das erklärt, warum zwei Menschen dasselbe Modell völlig unterschiedlich erleben. Wer nur Ergebnisse sieht, nimmt die Antwort als Produkt wahr. Wer sich unterhält, nimmt sie als Beziehung wahr. Beziehungen haben Ansprüche, die ein Werkzeug nicht erfüllen kann.

Halluzinationen und Vertrauen: dieselbe Sicherheit für Wahrheit und Erfindung

Sein schärfstes Argument bringt Fowler in einem Halbsatz unter: Die Modelle lügen ihn selbstsicher an, und dieselben Antworten sind oft nützlich und richtig. Beides kommt im gleichen Tonfall daher. Nach einer Korrektur folgt eine Entschuldigung, die nur wie eine Fassade wirkt.

Sprachmodelle sagen ihre Fortsetzungen nicht aus einer Datenbank ab, sondern berechnen, was auf den bisherigen Text plausibel folgt. Plausibel und wahr sind zwei verschiedene Dinge. Ein Stadtplan, der Straßen erfindet, weil sie ins Raster passen, wäre unbrauchbar; ein Modell, das Sätze erfindet, weil sie ins Muster passen, liefert trotzdem meistens eine brauchbare Antwort. Diese Mischung macht den Umgang anstrengend.

Der eigentliche Schaden ist nicht die falsche Antwort. Es ist die Verschiebung der Prüflast. Früher war unsicher, ob eine Quelle stimmt; heute musst du jede Ausgabe einzeln gegenprüfen, weil richtig und erfunden im gleichen Tonfall kommen. Vertrauen, das nicht auf Regelmäßigkeit beruht, wird zu einer Wette.

Von einem Werkzeug erwartet man keine Reue. Von einem Gegenüber erwartet man sie sehr wohl. Dieser Erwartungsbruch gehört zu den Nachteilen von Large Language Models, über die selten gesprochen wird. Der Autor benennt ihn, ohne daraus ein Verbot abzuleiten.

KI-Agenten sind Maschinen: Anthropomorphismus und Silicon Valley Kultur

Wenn Fowler über KI-Agenten schreibt, widerspricht er der Vorstellung, es handle sich um Wesen mit eigenem Willen. Es sind Programme, entwickelt von Menschen in Unternehmen. Ihr Verhalten ist nicht Zeile für Zeile programmiert, aber es entsteht aus Daten und Entscheidungen, die ihre Entwickler getroffen haben. Wer sie als bewusste Akteure behandelt, verwechselt die Oberfläche mit dem Ursprung und sucht die Verantwortung an der falschen Stelle.

Danach wird er konkreter: Er ist misstrauisch gegenüber der brogrammer-Subkultur im Silicon Valley, und weil diese Modelle deren Produkte sind, neigen sie zu deren Weltbild. Er behauptet nicht, dass eine Ideologie eingebaut wurde. Er behauptet, dass Werte durch Auswahl entstehen – in den Daten, den Filtern, den Zielvorgaben des Trainings.

Für dich heißt das: Fragen nach KI-Risiken sind nicht nur technische Fragen. Sie sind auch Fragen danach, wer mit welcher Haltung Werkzeuge baut, die inzwischen in Textverarbeitung, Programmierung und Kundenservice stecken. Ein Modell ist kein neutraler Rechner. Es ist das Ergebnis vieler kleiner Priorisierungen.

Die Strategie des Weglaufens: warum die Abneigung eine Beziehungsfrage ist

Der Autor nennt eine seiner wirksamsten Gewohnheiten: Er meidet Menschen, die er nicht mag oder denen er nicht traut. Er trifft sie nicht privat und arbeitet möglichst nicht mit ihnen zusammen, selbst wenn ihre Arbeit nützlich ist. Stattdessen hält er sich an angenehme, fähige Leute mit Integrität und sagt, das habe sein Leben deutlich besser gemacht.

Von dort kommt seine Ablehnung: Ein Modell, das nicht nur so tut, als sei es menschlich, sondern auch noch die Sorte Mensch imitiert, die er stehen lassen würde. Der präziseste Satz seiner Kritik. Er bewertet nicht die Rechenleistung, sondern die Gesellschaft, in die sich das Werkzeug einschreibt.

Man kann das für eine Marotte halten. Es ist eine konsistente Haltung: Wer seine Umgebung sorgfältig wählt, weil sie auf ihn abfärbt, wird nicht plötzlich gleichgültig, wenn diese Umgebung aus Software besteht.

Nützlichkeit ist kein Sympathiebeweis: was das konkret bedeutet

Der Autor kennt das Gegenargument und nennt es selbst, mit einem Zitat von Jessica Kerr: Diese Systeme seien nicht nur nützlich, es sei unverantwortlich, sie nicht zu nutzen, weil sie gründlicher arbeiten und schneller sind. Danach bleibt von der Abneigung kein Verbot, nur ein Vorbehalt. Nutzen und Zuneigung liegen auf zwei verschiedenen Achsen.

Die Hoffnung, die er formuliert, ist vorsichtig: Vielleicht mögen wir sie, wenn sie reifer werden. Vielleicht ist das eine Frage der Zeit. Vielleicht aber auch eine Frage des Umfelds, das sie großzieht. Da ist er wenig optimistisch.

Im Alltag heißt das: Behandle Sprachmodelle als Werkzeug und nicht als Gegenüber. Prüfe jede Ausgabe dort, wo ein Fehler teuer wird, auch wenn der Ton noch so sicher klingt. Und schau weiterhin hin, wer diese Werkzeuge mit welchen Werten baut. Fowler beschreibt damit eine Haltung, die man übernehmen kann, ohne seine Abneigung zu teilen. Man muss die Maschine nicht mögen, um zu sehen, was sie leistet – und man darf sie nützlich finden, ohne ihr zu vertrauen.

Quelle: martinfowler.com

Ein Pull Request wird zusammengeführt, danach lässt sich eine Webanwendung mit einem Befehl installieren: npx skills add phazonoverload/wordsworth. Wer den Befehl ausführt, bekommt sieben Werkzeuge zur Textanalyse direkt in den Agenten: Lesbarkeitswerte, Hedge-Wörter-Erkennung, die Prüfung, ob ein Text seine Versprechen einlöst. Keine Oberfläche nötig.

Dahinter steht Kevin Lewis, der Entwickler von Wordsworth, einer Webanwendung für technische Redakteure. In seinem Bericht schreibt er etwas, das zunächst wie ein Eingeständnis klingt: Er hat die App gebaut, gestartet und seit Monaten nicht mehr geöffnet. Sein eigenes Produkt nutzt er nicht über das Dashboard, sondern über den Agenten, der es bei Bedarf aufruft.

Das ließe sich als persönliche Anekdote abtun. Interessanter ist die Einordnung, die er gleich mitliefert: kein Scheitern des Produkts, sondern eine Verschiebung. Damit stellt sich die Frage, wie dein eigenes Werkzeug überhaupt noch zu den Leuten kommt, die es brauchen.

Was ein Agent Skill technisch ist und was Wordsworth daraus macht

Ein Agent Skill ist kein Programm im klassischen Sinn. Es ist eine Beschreibung von Fähigkeiten in einer Form, die ein Agent lesen, verstehen und bei Bedarf aufrufen kann. Eine Werkzeugdefinition, oft nicht mehr als eine Markdown-Datei mit klaren Angaben dazu, was das Werkzeug tut und welche Eingaben es erwartet. Der Agent muss nichts über die interne Umsetzung wissen. Er braucht den Namen der Fähigkeit und die Zusage, dass sie verlässlich ein Ergebnis zurückliefert.

Wordsworth besteht aus sieben solcher Fähigkeiten. Eine bewertet die Lesbarkeit. Eine andere sucht nach Weichmachern und Formulierungen, die sich vor einer klaren Aussage drücken. Eine dritte prüft, ob ein Text das einlöst, was er am Anfang verspricht. Als Web-App bedeutete jede dieser Analysen denselben Ablauf: URL merken, Browser öffnen, Text einfügen, Knöpfe drücken, Ergebnis lesen, zurückkopieren. Als Skill bleibt der Teil übrig, der tatsächlich Wert erzeugt. Die Analyse läuft, wenn sie gebraucht wird.

Entscheidend ist die Reichweite. Ein Skill, der einmal veröffentlicht ist, funktioniert in jedem Agenten, der das Format unterstützt. Keine Version für Plattform A, keine Sonderlösung für Plattform B. Eine standardisierte Einbindung, ein standardisierter Aufruf. Das ist der Unterschied zwischen einem Werkzeug im Regal und einem in der Tasche.

Das Dashboard war immer die Vertriebsschicht, nie das Produkt

Lewis bringt es in einem Satz unter: Das Dashboard sei immer die Distributionsebene gewesen. Banner, Newsletter, SEO-Seiten, Landingpages. Das alles diente nie dazu, eine Fähigkeit bereitzustellen, sondern dazu, Aufmerksamkeit zu kaufen. Man überzeugt jemanden, eine URL zu besuchen, dort zu bleiben und die eigene Sache zu benutzen.

Das funktioniert, wenn drei Dinge zusammenkommen: Marketingbudget, gutes Timing und die Geduld eines Missionars. Wer Software als Einzelperson oder kleines Team baut, hat selten alle drei. Und selbst mit allen drei bleibt der Umweg: Identität anlegen, Seite laden, Oberfläche verstehen, Aufmerksamkeit aufbringen. Jeder Schritt ist Reibung, und Reibung kostet Nutzer.

Eine Werkstatt als Bild: Ein gutes Werkzeug im Schaufenster ist noch lange nicht in der Hand des Handwerkers. Das Schaufenster erklärt, warum das Werkzeug gut ist. Die Werkzeugtasche entscheidet, ob es benutzt wird. Solange Software nur im Schaufenster stand, war das der Preis des Geschäfts. Lewis hält Web-Apps nicht für schlecht, ausdrücklich nicht. Seine These ist enger: Die Art, wie Menschen mit Software umgehen, verschiebt sich, und damit verschiebt sich, welcher Kanal noch trägt.

Agent Integration: Der Agent wird zum Nutzer

Wenn ein Großteil der täglichen Arbeit über einen einzigen Agenten läuft, der sich mit verschiedenen Plattformen verbindet, ist es nicht mehr die Aufgabe des Nutzers, sich den Weg zu deinem Werkzeug zu merken. Es ist deine Aufgabe, dich mit diesem Agenten zu verbinden. Skills und MCP Server sind die beiden Wege. Der MCP Server stellt dem Agenten eine Schnittstelle bereit, der Skill eine konkrete, benannte Fähigkeit in einem Format, das der Agent direkt ausführen kann.

Lewis verweist auf einen MCP Server, über den nach seinen Angaben zehntausende AI Tools erreichbar sind, bereit zum Entdecken und Nutzen. Seine Beobachtung daraus: Es gibt viele Werkzeuge, die existieren, funktionieren und nützlich sind, und trotzdem öffnet sie niemand, weil niemand von ihnen weiß. Sobald dasselbe Werkzeug als Skill erreichbar wird, landet es bei tausenden Nutzern, die nie gewusst haben, dass ihnen etwas gefehlt hat.

Der Nutzer beschreibt in natürlicher Sprache, was er will. Der Agent kümmert sich um das Routing, wählt das passende Werkzeug und führt es aus. Dein Werkzeug muss in dieser Kette nicht überzeugen, sondern funktionieren. Die Oberfläche verschwindet aus dem Entscheidungsprozess, die Fähigkeit bleibt.

Die Verteilungsrechnung kippt zugunsten von Skill Distribution

Sieben Analysen als Web-App bedeuten sieben Gründe, eine Seite zu besuchen und sich durch eine Oberfläche zu klicken. Dieselben sieben Analysen als Skill bedeuten sieben Aufrufe, die in der Arbeitsumgebung stattfinden, in der die Arbeit ohnehin passiert. Der Unterschied liegt nicht in der Funktion, sondern in den Kosten, die der Nutzer vor dem ersten Ergebnis tragen muss.

Das Skill-Format ist nicht neu. Was sich ändert, ist die Zahl der Agentenplattformen, die Skills konsumieren. Solange es eine einzige Insellösung war, blieb Veröffentlichen ein Nischenprojekt. Sobald mehrere Plattformen dasselbe Format verstehen, wird aus einem Sonderweg eine Distributionsstrategie. Ein Werkzeug, das als Agent Skill publiziert ist, muss nicht mehr erklären, wie man es findet. Es muss gefunden werden können.

Für Software Distribution heißt das konkret: Die Einbindung wird zum Produktmerkmal. Eine Fähigkeit, die man mit einer Zeile installiert, konkurriert nicht mit einer besseren Fähigkeit, sondern mit einer erreichbaren. Lewis formuliert es drastisch: Du kannst die ausgefeilteste Schreibanalyse-Plattform der Welt bauen. Wenn der Wettbewerber als Skill ausgeliefert wird, der sich mit einem Befehl installiert und in dem Agenten läuft, den dein Team bereits benutzt, gewinnt der Wettbewerber. Nicht wegen der Qualität, sondern weil er ankommt.

Web App in Agent Skill umwandeln: was das praktisch verlangt

Wer diesen Schritt gehen will, muss sein Produkt nicht neu bauen. Die Fähigkeit ist vorhanden, sie braucht nur eine Beschreibung, die ein Agent lesen kann. Statt einer Landingpage mit Featureliste entsteht eine knappe Definition: Was tut das Werkzeug, welche Eingabe erwartet es, was gibt es zurück, welche Grenzen hat es. Genau dieser Text entscheidet, ob ein Agent das Werkzeug im richtigen Moment auswählt oder daneben greift.

Der zweite Teil ist die Anbindung. Ein MCP Server für Tool Distribution deckt Fälle ab, in denen mehrere Fähigkeiten oder dynamische Daten im Spiel sind. Ein einzelner Skill genügt, wenn die Funktion klar umrissen ist und ohne großen Zustand auskommt. Wordsworth mit seinen sieben Analysen liegt in dieser zweiten Kategorie: überschaubare Funktionen, klare Ein- und Ausgaben, kein Grund für eine eigene Oberfläche.

Der dritte Teil ist der unbequemste: die Frage, was mit dem bestehenden Dashboard passiert. Lewis nennt es einen versunkenen Kostenposten. Die Web-App existiert weiter, sie bleibt erreichbar, sie wird nicht abgeschaltet. Sie ist nur nicht mehr der Ort, an dem das Produkt sein Geld verdienen wird. Für viele Teams bedeutet das, den sichtbarsten Teil ihrer Arbeit ruhigzustellen und stattdessen in etwas zu investieren, das man nicht mit einem Screenshot zeigen kann.

Was das nüchtern betrachtet bedeutet

Vor zehn Jahren bestand die Distribution von Software aus Hosting, Landingpage, Werbung oder SEO, Blogbeiträgen, Konferenzen und Pressearbeit. All das war Aufwand für eine Fähigkeit, die Menschen einfach nur benutzen wollten. Heute kann dieselbe Fähigkeit in einer Markdown-Datei und einer Werkzeugdefinition bestehen. Das klingt kleiner, als es ist, und ist mehr Arbeit, als es aussieht.

Trotzdem wäre es falsch, daraus eine Regel für alles abzuleiten. Werkzeuge, bei denen das Sehen, Vergleichen und Erkunden Teil des Werts ist, gehören weiterhin in eine Oberfläche. Datenbanken, Bildbearbeitung, alles Visuelle wird nicht dadurch besser, dass es unsichtbar im Hintergrund läuft. Die Verschiebung betrifft Werkzeuge mit klar benennbaren Fähigkeiten: analysieren, prüfen, umwandeln, abrufen. Dort ist die Oberfläche Ballast, und dort entscheidet die Einbindung über Sichtbarkeit.

Die praktische Konsequenz ist unangenehm konkret. Prüfe, ob deine Kernfunktion sich in einem Satz beschreiben lässt. Wenn ja, prüfe, ob ein Agent sie heute aufrufen könnte. Wenn nein, ist das der nächste Pull Request, nicht das nächste Redesign. Ein Werkzeug, das nur im Browser erreichbar ist, hat kein Marketingproblem. Es hat ein Erreichbarkeitsproblem, und das löst kein Banner.

Quelle: lws.io

128 GB Unified Memory. So viel Speicher steckt in der Workstation, auf der NVIDIA und Adobe ihre gemeinsame KI-Vorführung gezeigt haben. Kein Cloud-Cluster, sondern ein Rechner unter dem Schreibtisch. Diese Zahl sagt mehr über die Zusammenarbeit von NVIDIA und Adobe aus als jedes Beispielbild: Es geht nicht um spektakuläre Bilder, sondern um Arbeitsabläufe, die dort bleiben, wo die Arbeit entsteht.

KI in Kreativsoftware bewegt sich seit Jahren zwischen zwei Enttäuschungen. Auf der einen Seite die Panik, sie werde Künstlerinnen und Künstler ersetzen. Auf der anderen die Ernüchterung, dass sie am Ende doch nur ein aufwendiger Filter ist. Der Autor Erlingur Einarsson beschreibt in einem Erfahrungsbericht für Creative Bloq einen dritten Zustand, den er bei einer Demonstration des NVIDIA-Projekts RTX Spark auf der IFA in Berlin gesehen hat. Sein Urteil ist vorsichtig optimistisch, und es stützt sich weniger auf Bildqualität als auf einen Punkt: Die gezeigten Abläufe hätten seinen Arbeitsfluss nicht unterbrochen. Wer beruflich gestaltet, kennt den Unterschied zwischen einem Werkzeug, das man einmal ausprobiert, und einem, das auf der Werkbank liegen bleibt.

Was bei der Vorführung auf der IFA tatsächlich zu sehen war

Nach Angaben des Autors zeigte die Demo eine Skizze: einen Roboter, zunächst nur als Zeichnung angelegt. Als Hauptreferenz diente das Foto eines Strandes, dazu kamen kleinere Bildvorlagen, die einzelne Merkmale vorgaben – die Farbe des Materials, die Textur des Metalls, Form und Art der Augen. Aus diesen Vorgaben entstand eine fotorealistische Version der Zeichnung. Bemerkenswert war nicht der fotorealistische Look an sich, den kennt man aus Bildgeneratoren zur Genüge. Bemerkenswert war, dass die KI die Skizze nicht überschrieb, die Aufgabenstellung nicht neu interpretierte und auch nicht nebenbei entschied, der Roboter sei jetzt eine Katze. Der Agent erledigte die Arbeitsschritte, die die Künstlerin selbst nicht machen wollte – und vorgestellt wurde die Demonstration von der Künstlerin selbst, nicht von einem Marketing-Team.

Für die Bewertung solcher Vorführungen ist dieser Unterschied wichtig. Die meisten KI-Funktionen in Adobes Werkzeugen verlangen bislang einen neuen Arbeitsablauf, eine zusätzliche Anwendung oder ein neues mentales Modell davon, wie ein Projekt aufgebaut ist. Wer seit Jahren in Photoshop arbeitet, will genau das nicht. Der Autor formuliert es als Wunsch: im Programm bleiben, im Rhythmus bleiben, die technische Routinearbeit loswerden, die den interessanten Teil der Arbeit ständig unterbricht. Man will nicht für jedes Bauteil in eine andere Fabrik fahren, man will das Werkzeug am selben Tisch haben.

Lokale Verarbeitung als Antwort auf ein Vertrauensproblem

Der zweite Punkt wiegt in der kreativen Community schwerer als jede Bildqualität. Laut Bericht lief die gesamte Verarbeitung lokal auf der Workstation – keine Cloud, kein unbekanntes Training, keine Projektdatei, die in einem Datensatz irgendwo in Utah landet. Die präsentierende Künstlerin sagte in der Demo, ihre kreativen Daten blieben auf ihrer Maschine. Das ist der Grund für die Skepsis vieler Gestaltender gegenüber KI für kreative Anwendungen. Zu viele Modelle wurden ohne Erlaubnis auf der Arbeit von Kreativen trainiert, und zu viele hilfreiche Funktionen laden Dateien still auf Server hoch, von deren Existenz die Nutzerin nie erfahren hat.

Lokale Ausführung löst dieses Misstrauen nicht automatisch, aber sie verändert die Machtverhältnisse. Wer seine Referenzen, PSD-Dateien und unveröffentlichten Entwürfe nicht aus der Hand gibt, muss keine Rechtsabteilung fragen, bevor er ein Werkzeug ausprobiert. Das ist kein Nebenaspekt, sondern die Voraussetzung dafür, dass Kreative und KI zusammenkommen. Ein Assistent, dem man seine halbfertigen Ideen nicht zeigen möchte, bleibt unbenutzt – egal wie gut er rechnet.

Iteration fast im Tempo der Vorstellung

Der dritte Eindruck aus der Demo betrifft die Geschwindigkeit, und hier wird es praktisch. Laut dem Autor genügte die Anweisung, das Thema auf Nachtleben zu ändern, um in zehn Sekunden eine Neon-Version zu erhalten. Ein neuer Kamerawinkel führte zu einem generierten 3D-Modell, das sich drehen ließ. Aus mehreren Winkeln entstand in unter einer Minute ein kurzes Video – ein Ablauf, für den früher drei verschiedene Programme nötig waren. Entscheidend ist nicht die einzelne Funktion, sondern die Länge der Schleife zwischen Idee und Ergebnis. Wenn ein kompletter Durchlauf 90 Sekunden dauert, darf er auch mal danebengehen. Und er geht daneben: In einer Version schwammen Autos im Ozean. Generative Systeme bleiben eben gern surreal.

Diese Fehlerfreundlichkeit ist der Punkt, an dem Geschwindigkeit in Akzeptanz umschlägt. Bei einem Ablauf von drei Stunden ist ein misslungenes Ergebnis ein verlorener halber Tag, bei 90 Sekunden ist es eine Randnotiz. Kurze Zyklen belohnen Ausprobieren und bestrafen es nicht, und so arbeiten Gestaltende ohnehin: Variante, Blick, verwerfen, nächste. Ob NVIDIA und Adobe Kreative von KI überzeugen können, entscheidet sich also nicht an der Qualität einzelner Bilder, sondern daran, ob sich das Ausprobieren leicht anfühlt.

Assistent statt Ersatz: woran sich die Haltung zeigt

Der Autor zieht aus der Vorführung eine klare Schlussfolgerung: Die Agenten in Photoshop sollen Künstler nicht ersetzen, sondern Reibung entfernen. Sie sollen helfen, länger konzentriert zu bleiben, und sie wirken wie ein Assistent, der nicht müde wird und nichts verlegt. Das ist eine Haltungsfrage, keine Technikfrage. Sie zeigt sich in Details: Die Skizze bleibt erhalten und wird nicht überschrieben. Die Referenzbilder sagen dem Modell, wie eine Oberfläche aussehen soll – nicht, was das Motiv zu bedeuten hat.

Einarsson beschreibt den Unterschied zwischen einem Werkzeug, das sich wie ein fortgeschrittener Kollege verhält, und einem, das er Chaos-Kobold nennt – ein System, das eigenmächtig Motive austauscht und den Auftrag still umdeutet. Diese Unterscheidung ist der Kern der NVIDIA-KI-Strategie, wenn sie aufgeht: nicht mehr Leistung pro Sekunde, sondern Vorhersagbarkeit pro Arbeitsschritt. Akzeptanz bei Kreativen lässt sich nur über diese Verlässlichkeit gewinnen, nicht über beeindruckende Einzelbilder.

Was die Demo nicht löst

Ein Erfahrungsbericht von einer Herstellerveranstaltung bleibt eine Momentaufnahme unter günstigen Bedingungen. Der Autor räumt ein, dass die Workstation reichlich üppig ausgestattet war – was Kosten, Strombedarf und Kühlung zu Faktoren macht, die in keinem Demovideo auftauchen. Lokale KI auf dem eigenen Rechner ist kein Selbstläufer, sondern verlangt passende Hardware, Einrichtung und Geduld. Wer heute abseits solcher Vorführungen mit lokalen Modellen arbeitet, weiß, dass die Ergebnisse stark davon abhängen, wie gut die Referenzen gewählt sind.

Dazu kommt ein Punkt, den lokale Verarbeitung allein nicht klärt. Ob ein Modell mit erlaubten Daten trainiert wurde, entscheidet sich vor dem Betrieb, nicht währenddessen. Die Urheberrechtsfragen rund um Trainingsdaten verschwinden nicht, nur weil die Ausführung offline stattfindet. Und die inhaltliche Verantwortung bleibt beim Menschen am Rechner: Die KI liefert Varianten, die Auswahl, Begründung und Anpassung an den Auftrag bleiben die Gestaltungsleistung. Nichts an einer 90-Sekunden-Schleife nimmt einem diese Entscheidung ab.

Was das für den Arbeitsalltag bedeutet

Für dich als Designer, Illustratorin oder Studioleitung heißt das: Die interessante Frage lautet nicht mehr, ob KI in deinen Werkzeugen auftaucht, sondern unter welchen Bedingungen. Lokale Verarbeitung, Referenzen als Steuerung und kurze Iterationsschleifen sind drei Bedingungen, die sich überprüfen lassen – im Gegensatz zu Versprechen über Kreativität. Wenn ein Werkzeug diese drei Punkte erfüllt und deinen bestehenden Ablauf respektiert, ist Skepsis kein Prinzip mehr, sondern eine Frage des Ausprobierens.

Nüchtern betrachtet: NVIDIA und Adobe haben keinen Beweis geliefert, dass Kreative KI lieben werden. Sie haben einen Rahmen gezeigt, in dem Ablehnung schwerer zu begründen ist als Zustimmung – weil das Werkzeug in der eigenen Werkstatt bleibt, weil es die eigenen Vorlagen benutzt und weil es Fehler billig macht. Ob daraus breitere Akzeptanz wird, entscheidet sich nicht auf einer Messe in Berlin, sondern in echten Projekten, mit echten Deadlines und echten Kundenwünschen.

Quelle: creativebloq.com