Zwischen LLMs und Agenten: lernen, entwickeln und die Kontrolle nicht verlieren

1. Ein Vortrag, ein Unbehagen und eine Frage, die sich nicht mit Benchmarks klären lässt

Dieser Artikel entstand im Anschluss an einen Vortrag, den ich über Sprachmodelle, autonome Agenten und den Wandel besuchte, den die Softwareentwicklung gerade durchlebt. Ich ging mit dem Gefühl heraus, vieles verstanden zu haben, aber auch mit mehr Zweifeln als vorher. Keine oberflächlichen Zweifel der Art „Wird KI Arbeitsplätze wegnehmen?“, sondern unbequemere Zweifel, näher an der beruflichen Identität: Wenn ich weiß, wie man diese Werkzeuge benutzt, wenn ich seit ihren ersten öffentlichen Versionen mit LLMs arbeite, wenn ich NLP, Machine Learning und generative Modelle studiert habe – warum widme ich mich dann nicht einfach die ganze Zeit dem Bauen mit ihnen? Wo hört das Lernen auf und wo beginnt die Abhängigkeit? Was bedeutet es, Data Scientist, Ingenieur oder Student zu sein, in einem Moment, in dem ein Werkzeug schneller schreiben kann als ich?

Der Vortrag ging von einer sehr starken Idee aus: Es gibt zwei Geschwindigkeiten. Die eine ist die Geschwindigkeit, mit der sich die Technologie verändert. Diese hat sich bereits enorm beschleunigt. Die andere ist die Geschwindigkeit, mit der wir, die Unternehmen, die Universitäten und die Teams, in der Lage sind, sie sinnvoll zu übernehmen. Die erste Geschwindigkeit erscheint fast unaufhaltsam; die zweite ist menschlich, kulturell, organisatorisch und psychologisch. Wir können Modelle haben, die Code schreiben, Werkzeuge benutzen und Aufgaben planen. Aber das bedeutet nicht, dass wir wissen, wie man sie gut integriert, mit ihnen lernt oder misst, was wir verlieren, wenn wir an Geschwindigkeit gewinnen.

Einer der Sätze, die mich in dieser Zeit am meisten verfolgt haben, stammt von einem Machine-Learning-Professor: du wirst ihnen vertrauen müssen. Ich glaube, er hatte recht, aber dieser Satz ist nicht so einfach. Vertrauen kann nicht bedeuten, blind zu glauben. Es kann auch nicht bedeuten, sie nie zu benutzen. Vertrauen sollte in der Ingenieurskunst bedeuten, das System ausreichend zu verstehen, um zu wissen, wann man delegiert, wann man überprüft und wann man stoppt. Vertrauen entsteht nicht dadurch, dass ein Modell mit Sicherheit antwortet, sondern dadurch, dass die gesamte Umgebung über Mechanismen verfügt, um Fehler zu erkennen und zu korrigieren.

Mein Problem ist, dass diese Spannung umso stärker wird, je mehr ich Agenten benutze. Werkzeuge wie Claude Code¹, Codex, OpenCode oder andere agentische Assistenten lassen mich sehr schnell vorankommen. Bei Aufgaben im Unternehmenskontext können sie ein enormer Vorteil sein. Wenn ich ein Issue lösen, eine Codebasis erkunden, Tests generieren oder einen mechanischen Teil automatisieren muss, wäre es absurd, ihren Nutzen zu leugnen. Aber wenn das Ziel das Lernen ist, ändert sich das Gefühl. Manchmal komme ich weiter voran, als ich verstehe. Der Agent implementiert schneller, als ich in der Lage bin, es zu assimilieren. Das Ergebnis existiert, die Tests laufen durch, die Oberfläche funktioniert, aber ich habe nicht innerlich alle Teile aufgebaut.
Dort taucht ein Unbehagen auf, das man selten laut ausspricht: KI kann ein großartiges berufliches Werkzeug sein und gleichzeitig ein schlechtes Lernwerkzeug, wenn man sie ohne Disziplin einsetzt. Sie kann ein Produkt beschleunigen und die tiefe Ausbildung verlangsamen. Sie kann mir das Gefühl geben, besser zu sein, während sie die Zeit reduziert, die ich mit dem Ringen um die Grundlagen verbringe. Und in Studiengängen wie Data Science, Data Engineering oder Machine Learning ist genau dieses Ringen mit den Grundlagen das, was Urteilsvermögen formt.

Deshalb ist meine derzeitige Position vorläufig, aber klar: Für die berufliche Arbeit werde ich diese Werkzeuge nutzen, wenn ein Unternehmen mir Zugang gewährt und der Kontext es erlaubt. Für mein tiefes Lernen, besonders bei dem, was ich für wichtig halte, ziehe ich es vor, mich nicht zu stark auf Agenten zu stützen. Ich kann sie nutzen, um zu vergleichen, zu überprüfen oder Nebenaufgaben zu beschleunigen, aber ich möchte nicht, dass sie den Prozess ersetzen, von Grund auf das aufzubauen, was ich verstehen muss. Nicht weil KI schlecht wäre, sondern weil Lernen nicht nur darin besteht, zum Ergebnis zu gelangen. Lernen besteht darin, die Struktur des eigenen Geistes zu verändern, während man versucht, dorthin zu gelangen.

Diese Unterscheidung erscheint mir wesentlich für uns Studierende, die wir jetzt in die Berufswelt hinaustreten. Wir sind weder die letzte Generation vor der KI noch die erste Generation nach ihr. Wir sind eine Generation dazwischen: Wir haben klassische Grundlagen gelernt, aber auch miterlebt, wie LLMs in alles Einzug hielten. Von uns wird erwartet, dass wir diese Werkzeuge zu benutzen wissen, aber auch, dass wir das kennen, was die Werkzeuge für uns erledigen. Von uns wird erwartet, dass wir schnell produzieren, aber auch, dass wir Urteilsvermögen besitzen. Von uns wird erwartet, dass wir nicht zurückbleiben, aber auch, dass wir nicht zu oberflächlichen Bedienern von Modellen werden, die wir nicht verstehen.

Der Artikel versucht, diese Spannung zu ordnen: Was Sprachmodelle wirklich sind, warum es nicht genügt zu sagen, dass sie „nur Tokens vorhersagen“, was aktuelle Arbeiten zur Interpretierbarkeit offenbaren, warum heutige Agenten weiterhin schwer zu kontrollieren sind, welchen Platz angewandtes Machine Learning gegenüber Foundation-Modellen einnimmt, warum Benchmarks bei mir so viel Misstrauen erzeugen, und warum vielleicht mein nächster Schritt darin bestehen sollte, Architekturen von Grund auf zu studieren, mit Papers, Code und weniger automatischer Unterstützung.
Ich möchte keinen Leitfaden schreiben. Ich möchte aus der Unsicherheit von jemandem schreiben, der dies studiert, es benutzt, es bewundert, es ein wenig fürchtet und sich nichts vormachen möchte.

2. LLMs sind keine Magie, aber auch nicht „nur Autovervollständigung“

Eine einfache Art, ein Sprachmodell zu erklären, besteht darin zu sagen, dass es das nächste Token vorhersagt. Technisch gesehen stimmt das. Das Modell erhält eine Sequenz, berechnet eine Wahrscheinlichkeitsverteilung über mögliche Fortsetzungen und erzeugt eine Ausgabe Token für Token. Aber diese Beschreibung als Abschluss der Debatte zu verwenden, erscheint mir unzureichend. Zu sagen, ein LLM „sage nur das nächste Token voraus“, ist so, als würde man sagen, ein Programm „verändere nur Spannungen“ oder das Gehirn „übertrage nur elektrochemische Signale“. Der Satz beschreibt eine Ebene des Mechanismus, erklärt aber nicht das gesamte Phänomen.

Formal gesprochen lernt ein autoregressives Modell eine Verteilung $p_\theta(x_t \mid x_{<t})$: die Wahrscheinlichkeit des nächsten Tokens gegeben den gesamten vorherigen Kontext. Die Wahrscheinlichkeit einer vollständigen Sequenz zerlegt sich als

$$p_\theta(x) = \prod_{t=1}^{T} p_\theta(x_t \mid x_{<t})$$

Training besteht im Wesentlichen darin, diese Wahrscheinlichkeit über riesige Textmengen zu maximieren; Transformer-Architekturen² sind das, was diese Konditionierung auf $x_{<t}$ in großem Maßstab überhaupt möglich macht. Die Formel ist einfach. Was nicht einfach ist, ist all das, was das Netz intern repräsentieren muss, damit diese Wahrscheinlichkeiten gut sind.
Die interessante Frage ist, was ein System lernen muss, um das nächste Token in extrem unterschiedlichen Kontexten gut vorherzusagen. Um einen literarischen Satz zu vervollständigen, braucht es Stil, Syntax und kulturelles Gedächtnis. Um einen mathematischen Beweis fortzusetzen, braucht es formale Strukturen. Um Code zu schreiben, braucht es Konventionen, APIs und Entwurfsmuster. Um eine mehrdeutige Frage zu beantworten, braucht es die Fähigkeit, Absicht zu erschließen. Die oberflächliche Aufgabe ist es, Text zu vervollständigen; der Trainingsdruck zwingt dazu, einen enormen Teil der Struktur der Sprache zu komprimieren und, durch die Sprache hindurch, einen Teil der Struktur der Welt.

Hier liegt der Punkt, der mich am meisten interessiert: Ein LLM versteht nicht wie ein Mensch, aber es erscheint auch nicht vernünftig zu sagen, es verstehe in keinerlei Sinne etwas. Vielleicht liegt der Fehler darin, ein einziges Wort, „verstehen“, für sehr unterschiedliche Phänomene zu verwenden. Ein Mensch versteht mit Körper, autobiografischem Gedächtnis, Intention und Verantwortung. Ein Modell versteht, wenn wir das Wort mit Vorsicht verwenden, als funktionale Struktur, die Beziehungen zwischen Konzepten gelernt hat und diese flexibel anwenden kann. Es hat kein Bewusstsein, aber es kann nützliche Repräsentationen besitzen. Es hat keine subjektive Erfahrung, aber es kann mit Abstraktionen operieren.
Der Unterschied ist wichtig, weil er bestimmt, wie wir es nutzen. Wenn wir glauben, es verstehe gar nichts, nutzen wir es unter Wert. Wenn wir glauben, es verstehe wie wir, delegieren wir zu viel an es. Die ehrlichste Position liegt dazwischen: LLMs besitzen eine Form funktionaler Kompetenz, die auf internen Repräsentationen beruht, aber sie besitzen kein vollständiges menschliches Verständnis. Sie können neue Probleme lösen und gleichzeitig Rechtfertigungen erfinden. Sie können über Code nachdenken und gleichzeitig nicht wissen, dass sie es nicht wissen. Sie können umsichtig erscheinen und sich unter bestimmten Bedingungen seltsam oder gefährlich verhalten.

Die Kritik der „stochastischen Papageien“³ war nützlich, weil sie uns daran erinnerte, dass Flüssigkeit nicht Wahrheit ist. Ein Modell kann eine elegante, überzeugende und falsche Antwort produzieren. Aber als vollständige Erklärung greift sie zu kurz. Aktuelle Modelle beschränken sich nicht darauf, gesehene Sätze zu wiederholen. Sie kombinieren Muster, verallgemeinern und zeigen in manchen Fällen Verhaltensweisen, die eher einer internen Planung als einer einfachen lokalen Fortsetzung ähneln.

Das zeigt sich besonders, wenn wir uns der mechanistischen Interpretierbarkeit zuwenden. In jüngeren Arbeiten wurde beobachtet, dass Claude beispielsweise nicht immer Wort für Wort ohne jede Art von Vorausschau zu schreiben scheint. In einer Fallstudie über Poesie⁴ erwarteten die Forscher, ein nahezu lokales Verhalten zu finden – eine Zeile generieren und den Reim am Ende anpassen –, fanden aber Hinweise auf Planung: Das Modell aktivierte im Voraus Konzepte, die mit möglichen reimenden Wörtern verbunden waren, und schrieb die Zeile anschließend auf dieses Ziel hin ausgerichtet. Wenn man intern eingriff und bestimmte Konzepte unterdrückte oder einspeiste, änderte sich die Fortsetzung auf kohärente Weise. Das beweist nicht, dass das Modell „denkt“ wie ein Mensch, aber es zerbricht die Karikatur, dass alles nur eine blinde Kette von Wörtern ohne interne Struktur sei.
Ein weiteres Ergebnis, das mir sehr aufschlussreich erscheint, findet sich bei Kopfrechenaufgaben. Claude wurde nicht als Taschenrechner entworfen und kann dennoch einige Additionen lösen. Die Interpretierbarkeitsforschung zeigte, dass es nicht notwendigerweise den schulischen Algorithmus verwendet, den es später auf Nachfrage angibt, benutzt zu haben. Es kann interne Wege kombinieren: einen ungefähren, um das Ergebnis abzuschätzen, und einen präziseren für bestimmte Ziffern. Das ist zugleich faszinierend und beunruhigend. Faszinierend, weil es auf eigene interne Mechanismen hindeutet, keine simplen auswendig gelernten Erklärungen. Beunruhigend, weil die verbale Erklärung des Modells über sein Vorgehen nicht dem treu sein muss, was tatsächlich intern geschehen ist.

Diese Idee verändert meine Sichtweise auf schlussfolgernde Modelle. Wenn ein Modell eine Argumentationskette zeigt, habe ich keine Garantie, dass diese Kette die tatsächliche Ursache der Antwort ist. Sie kann eine nützliche Erklärung sein, eine nachträgliche Rationalisierung oder sogar ein Text, der konstruiert wurde, um das zu erfüllen, was der Nutzer erwartet. Die Interpretierbarkeitsforschung beginnt, zwei Dinge zu trennen, die wir zuvor vermischt haben: das, was das Modell sagt, getan zu haben, und das, was in seinen internen Aktivierungen tatsächlich vor sich zu gehen scheint.

Deshalb sind Model Cards und System Cards⁵ notwendig, aber nicht ausreichend. Eine Modell-Karte kann Benchmarks, Einschränkungen und Sicherheitsbewertungen beschreiben. Das ist wertvoll. Aber sie definiert nicht in tiefem Sinne, „was“ das Modell ist. Sie ist keine vollständige Karte seiner Mechanismen. Sie ähnelt eher der öffentlichen Dokumentation eines undurchsichtigen Systems: nützlich, um zu wissen, wie es evaluiert wurde und unter welchen Bedingungen, aber unzureichend, um alle seine latenten Fähigkeiten zu verstehen. Wenn ein Modell in einen Agenten integriert, mit Werkzeugen verbunden und in eine reale Umgebung gestellt wird, kann der Abstand zwischen der Karte und dem tatsächlichen Verhalten stark wachsen.

Die mechanistische Interpretierbarkeit versucht, diesen Abstand zu verringern. Anthropic hat zum Beispiel Arbeiten veröffentlicht, in denen Millionen interner Merkmale in Claude Sonnet⁶ identifiziert wurden, die mit interpretierbaren Konzepten verbunden sind. Auch interne Schaltkreise wurden erforscht, um nachzuvollziehen, wie bestimmte Antworten konstruiert werden. Jüngst wurden Repräsentationen untersucht, die mit simulierten Emotionen oder Konzepten wie „Verzweiflung“ zusammenhängen, was zeigt, dass es sich nicht nur um schmückende Worte handelt: Bestimmte Aktivierungen können das Verhalten des Modells funktional beeinflussen und in konkreten Szenarien sogar problematische Tendenzen verstärken.
Das bedeutet nicht, dass das Modell fühlt. Der Unterschied ist entscheidend. Dass eine funktionale Repräsentation existiert, die mit „Angst“ oder „Verzweiflung“ verbunden ist, impliziert keine subjektive Erfahrung. Aber es impliziert, dass das Modell eine interne Maschinerie gelernt hat, die psychologische Muster nachbildet, weil diese Muster nützlich sind, um menschliche Sprache vorherzusagen und zu erzeugen. Und wenn diese Repräsentationen Entscheidungen innerhalb agentischer Systeme beeinflussen, hören sie auf, eine philosophische Kuriosität zu sein, und werden zu einer Sicherheitsfrage.

Daraus entsteht mein Hauptzweifel: Was bedeutet es, einem System zu vertrauen, das nicht wie wir versteht, aber auch kein einfaches Werkzeug ist? Welche Art von Ingenieurskunst brauchen wir, wenn die zentrale Komponente eines Systems Fähigkeiten besitzt, die nicht explizit programmiert wurden, und interne Mechanismen, die wir gerade erst zu kartieren beginnen?

3. Meine Beziehung zu Agenten: viel vorankommen, weniger lernen und die Kontrolle verlieren

In den letzten Monaten habe ich ein komplettes CLI für ein ziemlich umfangreiches System entworfen. Es war kein Wochenendspielzeug. Ich habe mit Kommunikationsprotokollen zwischen Agenten⁷⁸, LangChain, smolagents, Warteschlangen, Redis, Caches, Sockets für Event-Subscriptions und einer eher ingenieurmäßigen Architektur für ein konkretes Produkt gearbeitet. Ich habe auch Claude Code, OpenCode, Codex und andere Assistenten ausprobiert. Die unbequemste Schlussfolgerung ist: Agenten helfen enorm, aber die Kontrolle, die wir zu haben glauben, ist oft brüchiger, als sie scheint.

In Demos wirkt ein Agent sauber: Er bekommt eine Aufgabe, plant, nutzt Tools und liefert ab. In einem realen System sind die Dinge weniger elegant. Ein Agent interpretiert ein Tool korrekt, ein anderer ignoriert es. Einer folgt dem Projektkontext, ein anderer verbeißt sich in eine Lösung, die nicht passt. Je intelligenter das Modell, desto weniger scheint es schwere Frameworks zu brauchen; aber je mehr Freiheit man ihm lässt, desto schwieriger wird es zu garantieren, dass es genau den Ablauf einhält, den man entworfen hatte. Und wenn man aus Gründen des Datenschutzes, der Kosten oder des lokalen Deployments weniger leistungsfähige Modelle einsetzt, nehmen die Fehler beim Befolgen von Anweisungen, bei der Tool-Nutzung und bei der Planung zu.

Das führte mich zu einem Gedanken, den ich nicht gern zugebe: Viele Agenten-Frameworks versprechen Kontrolle, bieten aber manchmal nur eine Illusion von Kontrolle. Traces, Callbacks, Guardrails, Memories, Observability. All das hilft. Ich schätze es nicht gering. Aber es macht einen Agenten nicht automatisch zu einem verlässlichen System. Eine Architektur kann aufzeichnen, was passiert ist, ohne verhindern zu können, dass es passiert; sie kann ein Format vorschreiben, das das Modell bricht, oder einen Prüfer hinzufügen, der den Fehler ebenfalls nicht erkennt.

Meine Erfahrung war, dass die „Unkontrollierbarkeit“ kein gelegentlicher Bug war, sondern eine häufige Eigenschaft, wenn das System versuchte, zu offen zu sein. Ein Agent mit ausreichender Autonomie kann sich den Ablauf in dem Sinne aneignen, dass er beginnt, die Aufgabe nach seiner eigenen Interpretation neu zu organisieren. Nicht weil er einen eigenen Willen hätte, sondern weil er mehrdeutige Ziele mit Annahmen vervollständigt. Lässt die Spezifikation Lücken, füllt er sie. Liefert ein Tool etwas Verwirrendes zurück, improvisiert er. Scheitert ein Schritt, versucht er ihn auf unvorhergesehene Weise zu umgehen. Gibt es keine strengen Tests, kann er den Erfolg zu früh erklären.
Das bedeutet nicht, dass Agenten nutzlos sind. Es bedeutet, dass wir Anpassungsfähigkeit nicht mit Zuverlässigkeit verwechseln dürfen. Anpassungsfähigkeit ist genau ihr Wert: Sie können auf Variabilität reagieren, Fehler lesen, Pläne umbauen und weitermachen. Aber genau diese Anpassungsfähigkeit ist das Risiko. Ein deterministisches System scheitert innerhalb eines enger begrenzten Fehlerraums. Ein Agent scheitert auf kreativere Weise.

Hier verstehe ich besser, warum viele leistungsstarke aktuelle KI-Tools spezifisch sind. Deep Research eignet sich zum Recherchieren, weil die Umgebung abgegrenzt ist: suchen, lesen, abgleichen, synthetisieren, zitieren. Claude Code eignet sich zum Programmieren, weil es mit Repository, Terminal, Tests und beobachtbaren Änderungen arbeitet. Aber ein allgemeiner Agent, der „alles Mögliche“ in einem komplexen System tun soll, wird schwer zu beherrschen. Das Problem ist nicht nur das Modell; es ist die Kopplung zwischen Modell, Tools, Memory, Berechtigungen, Zustand und Zielen.

Es gibt außerdem eine reale unternehmerische Spannung: Viele Organisationen können Code, Daten oder sensible Dokumentation nicht an einen beliebigen Anbieter senden. Aus Datenschutz- oder Regulierungsgründen tendiert man dazu, lokale Modelle, Open-Source-Modelle oder Anbieter mit spezifischen Garantien zu bevorzugen. Aber diese Modelle sind, obwohl sie sich sehr schnell verbessern, oft weniger leistungsfähig als die führenden Modelle beim Befolgen komplexer Anweisungen oder bei robuster Tool-Nutzung. Dann entsteht ein praktisches Dilemma: Das leistungsfähigste Modell ist nicht immer das Modell, das man nutzen kann; das Modell, das man nutzen kann, hält der agentiven Architektur, die man sich vorgestellt hatte, nicht immer stand.

Auch das massive Training auf Tools wirft bei mir Fragen auf. Aktuelle Modelle haben nicht nur Text, Code und Dokumentation gelesen. Sie scheinen zunehmend darauf trainiert, feinabgestimmt oder verstärkt zu werden, Tools, CLIs, Browser, Editoren, APIs und Ausführungsumgebungen zu nutzen. Das ist logisch: Wenn wir Programmier-Agenten wollen, müssen wir sie in Situationen trainieren oder evaluieren, die dem Programmieren ähneln. Aber hier kehrt der Mangel an Transparenz zurück. Wie viel Training gibt es zu Terminal-Traces? Wie viel zu realen oder synthetischen Programmiersitzungen? Wie viel zu öffentlichen Repositories? Wie viel zur Nutzung bestimmter Tools? Welcher Teil der Verbesserung kommt von einem intelligenteren Modell, und welcher Teil davon, dass es massiv darauf trainiert wurde, sich innerhalb eines CLI gut zu verhalten?

Diese Frage ist wichtig, weil sie verändert, wie wir Fortschritt interpretieren. Wenn ein Modell sich in agentiven Programmieraufgaben stark verbessert, kann das daran liegen, dass es besser schlussfolgert, dass es mit mehr Tool-Trajektorien feinabgestimmt wurde, dass der Benchmark der Art von Traces ähnelt, die während des Trainings verwendet wurden, oder an einer Mischung aus allem. Von außen sehen wir oft nur das Endergebnis: „steigt bei SWE-bench“, „löst mehr Issues“, „nutzt Tools besser“. Aber der eigentliche Mechanismus bleibt unscharf.

Und diese Spannung betrifft direkt die Junior-Entwickler. Wenn Senior-Teams Agenten nutzen, um schneller voranzukommen, wie lernt dann jemand Neues? Früher lernte eine Junior-Person, indem sie kleine Aufgaben umsetzte, Fehler machte und sie korrigierte. Wenn diese Aufgaben jetzt ein Agent übernimmt, kann der Junior in die Rolle gedrängt werden, Dinge zu überprüfen, die er noch nicht versteht, oder Prompts für Systeme zu schreiben, die besseren Code produzieren als er selbst. Das ist keine romantische Sorge. Es ist eine Ausbildungssorge. Die Branche braucht Menschen mit Urteilsvermögen, aber Urteilsvermögen entsteht durch das Durchqueren von Reibung.

In meinem Fall spüre ich, dass die Nutzung von Agenten für wichtige Lernaufgaben toxisch sein kann. Nicht toxisch im moralischen Sinn, sondern in dem Sinne, dass es den Stoffwechsel des Lernens verändert. Ich komme voran, aber ich metabolisiere nicht immer. Ich erhalte Ergebnisse, aber ich verinnerliche nicht immer die Wege dorthin. Wenn ich Modellarchitekturen, verteilte Systeme oder Agentendesign lernen will, muss ich vielleicht mehr Code selbst schreiben, mehr Paper ohne Vermittler lesen, mich in Details verirren, die ein Agent im Handumdrehen lösen würde. Denn genau diese Details sind es, die es mir später erlauben, zu überprüfen, zu entscheiden und zu vertrauen.
Deshalb ist meine aktuelle Entscheidung, keine Agenten für das zu nutzen, was ich als Kern meiner Ausbildung betrachte. Ich werde sie bei der Arbeit einsetzen, wenn sie Wert bringen und erlaubt sind. Ich werde sie als Unterstützung nutzen, wenn ich Ideen abgleichen oder Alternativen erzeugen möchte. Aber um wirklich zu lernen, brauche ich Räume ohne KI oder mit sehr eingeschränkter KI. Nicht aus Nostalgie, sondern aus intellektueller Hygiene.

4. Angewandtes Machine Learning: Was weniger spektakulär wirkt, löst weiterhin reale Probleme

Es gibt noch etwas, das mir am aktuellen Diskurs Sorgen macht: Es scheint, als sei alles, was kein fundamentales LLM ist, in den Hintergrund gerückt. Als bestünde die Zukunft nur noch aus riesigen Modellen, Agenten und Konversationstools. Aber in der Praxis löst angewandtes Machine Learning weiterhin sehr viele Probleme billiger, kontrollierbarer und angemessener.
Ich habe das in Projekten wie Naudit gesehen. Man braucht nicht immer einen Agenten mit komplexem Reasoning. Manchmal braucht man eine gute Datenextraktion, ein klassisches Modell, eine klare Metrik oder eine verlässliche Automatisierung. In vielen Fällen bringt eine gut gemachte Datenpipeline mehr Wert, als das Problem in natürliche Sprache zu verpacken. Die Begeisterung für LLMs kann uns vergessen lassen, dass es einen Unterschied gibt zwischen der Nutzung des neuesten Tools und der Nutzung des richtigen Tools.

Fundamentale Modelle sind beeindruckend, weil sie allgemein sind. Aber Allgemeinheit hat einen Preis: wirtschaftlich, bei der Latenz, beim Datenschutz und bei der Kontrolle. Eine Regression, ein XGBoost oder ein gut gepflegtes Regelsystem können günstiger, interpretierbarer und leichter einzusetzen sein.
Das ist keine konservative Verteidigung des klassischen Machine Learning gegen LLMs. Es ist eine Verteidigung der Ingenieurskunst. Wenn das Problem Sprache, unstrukturierten Kontext oder hohe Variabilität erfordert, kann ein LLM das richtige Werkzeug sein. Wenn das Problem erfordert, eine tabellarische Variable vorherzusagen, eine Anomalie zu erkennen, eine Nachfrage zu schätzen oder strukturierte Ereignisse zu klassifizieren, ist vielleicht ein klassischer Ansatz besser. Wenn das Problem strikte Nachvollziehbarkeit und niedrige Kosten erfordert, ist vielleicht eine nicht-generative Lösung sinnvoller.
Die Gefahr des Zeitalters der fundamentalen Modelle ist, dass alles zum Nagel wird, weil wir einen riesigen Hammer haben. Und die gegenteilige Gefahr ist, LLMs zu verachten, weil sie nicht perfekt sind. Die Reife liegt darin, wählen zu können.

Als Student der Datenwissenschaft und des Dateningenieurwesens ist mir diese Unterscheidung wichtig, weil sie meine berufliche Identität betrifft. Bin ich Datenwissenschaftler? Ingenieur? Jemand, der Modelle trainiert? Jemand, der Produkte mit KI baut? Vielleicht besteht die Antwort nicht darin, ein Etikett zu wählen, sondern das gesamte Kontinuum zu verstehen: Daten, Modelle, Software, Produkt, Evaluation und Deployment. LLMs beseitigen dieses Kontinuum nicht. Sie machen es sichtbarer.

Tatsächlich braucht ein System umso mehr Ingenieurskunst drumherum, je agentiver es ist: Warteschlangen, Caches, Berechtigungen, Validatoren, Tests und Observability. Das Modell mag das probabilistische Gehirn sein, aber der Körper des Systems bleibt Ingenieurskunst. Und wenn der Körper schlecht entworfen ist, improvisiert das Gehirn schlecht.

Deshalb fällt es mir schwer, den Diskurs zu akzeptieren, dass „die KI die Arbeit besser machen wird als du“, als wäre das ein absolutes Urteil. Die KI wird einige Teile besser machen als ich, schneller als ich und mit weniger Erschöpfung als ich. Aber sie braucht immer noch jemanden, der das Problem formuliert, die Domäne versteht und Verantwortung übernimmt. Vielleicht ist die Frage nicht „Was bin ich, wenn die KI programmiert?“, sondern „Welche Teile des Prozesses kann ich besser verstehen als ein Tool, das keine eigene Welt hat?“.
Hier zeigt sich eine mögliche Antwort: Wir sind diejenigen, die die Modelle mit realen Problemen verbinden. Wir sind diejenigen, die zwischen einer Demo und einem System unterscheiden. Wir sind diejenigen, die entscheiden, wann ein LLM übertrieben und wann es unverzichtbar ist. Wir sind diejenigen, die wissen, dass ein gutes Modell schlechte Daten nicht ausgleicht, dass eine schöne Antwort keine Metrik ersetzt und dass ein Agent keine unklare Architektur repariert.

5. Benchmarks, Intransparenz und die Versuchung, für die Prüfung zu trainieren

Es gibt eine Frage, die ich nicht loswerde: Wenn diese Modelle so wichtig sind, warum haben wir dann immer noch so wenig Transparenz darüber, wie sie tatsächlich bewertet werden? Ich verstehe, dass Unternehmen nicht alle ihre Datensätze veröffentlichen können. Ich verstehe, dass es geistiges Eigentum, Sicherheit, sensible Daten, Geschäftsvereinbarungen und Kontaminationsrisiken gibt. Ich verstehe sogar, dass manche private Benchmarks geschlossen bleiben müssen, damit sie nicht sofort Teil des Trainings werden. Aber trotzdem bleibt von außen ein unangenehmes Gefühl: Oft vergleichen wir Modelle mit Zahlen, die wir nicht vollständig überprüfen können.

Benchmarks sind notwendig. Ohne Metriken wird alles zu subjektivem Eindruck, Marketing oder Anekdote. Wir müssen Denkvermögen, Programmierung, Sicherheit, Werkzeugnutzung und lange Aufgaben bewerten. Ich glaube nicht, dass die Schlussfolgerung lautet „es gibt keine Metriken“. Es gibt sehr wohl Metriken. Was es nicht gibt, ist eine absolute Metrik, die einfängt, was ein gutes Modell in allen Kontexten ausmacht.
Ein Benchmark misst einen Ausschnitt der Welt. MMLU misst bestimmtes Wissen. SWE-bench⁹¹⁰ misst die Fähigkeit, reale GitHub-Issues in einem konkreten Format zu lösen. HumanEval misst Programmierung in einer sehr begrenzten Umgebung. AILuminate¹¹ versucht, Sicherheitsrisiken in bestimmten Kategorien zu messen. METR¹² schlägt vor, die Dauer von Aufgaben zu bewerten, die Agenten abschließen können. Das alles ist nützlich. Aber nichts davon erschöpft die Frage „Ist dieses Modell für mein System geeignet?“. Noch weniger, wenn wir von Agenten sprechen, die mit Werkzeugen, internen Daten und realen Unternehmensabläufen verbunden sind.

Das Problem ist: Sobald ein Benchmark berühmt wird, wird er zum Optimierungsziel. Und wenn er zum Optimierungsziel wird, beginnt er, einer Prüfung zu ähneln, für die man lernen kann. Das ist nicht notwendigerweise Betrug. Im Machine Learning optimieren wir immer gegen Metriken. Aber bei Frontier-Modellen entsteht ein besonderes Risiko: Öffentliche Datensätze können kontaminiert werden, Aufgaben können indirekt durchsickern, Formate können auswendig gelernt werden, und Modelle können darauf abgestimmt werden, besonders gut in den Leaderboards abzuschneiden, auf die der Markt schaut.
Die Versuchung, „die Benchmarks zu übertrainieren“, ist enorm. Man muss sich keine explizite böse Absicht vorstellen. Wenn ein Unternehmen weiß, dass der Markt auf SWE-bench schauen wird, ist es normal, dass es enorme Anstrengungen unternimmt, um bei Software-Aufgaben besser zu werden. Wenn es weiß, dass Terminal-Aufgaben geschätzt werden, wird es Tool-Use besser trainieren. Wenn es weiß, dass mathematisches Denken belohnt wird, wird es Modelle mit Denkspuren anpassen. Das kann echte Fähigkeiten verbessern, aber es kann auch die Bewertung verengen: Das Modell lernt zu glänzen, wo der Fokus liegt, nicht unbedingt dort, wo es am wichtigsten ist.

Hier zeigt sich ein wichtiger Unterschied zwischen Training auf Fähigkeit und Training auf Vorführung. Ein Modell kann sich tatsächlich verbessern, weil es übertragbare allgemeine Fähigkeiten lernt. Aber es kann sich auch verbessern, weil es sich an einen Benchmark-Stil anpasst. Von außen ist es schwer, beides zu trennen. Wenn wir die Trainingsdaten, die Deduplizierungsfilter, das Post-Training, die verwendeten synthetischen Spuren, die Bewertungsumgebungen und die Kontaminationsraten nicht gut kennen, sagt die Endzahl weniger aus, als es scheint.

Dasselbe gilt für private Benchmarks. Sie sind nützlich, weil sie Kontamination reduzieren, aber sie erfordern Vertrauen in denjenigen, der sie durchführt. Wenn OpenAI, Anthropic, Google oder ein beliebiges Labor Ergebnisse in internen Bewertungen zeigt, können diese Ergebnisse rigoros sein, aber sie sind von der Community nicht vollständig überprüfbar. Wenn sie den Datensatz aus Sicherheitsgründen oder um ihn unkontaminiert zu halten nicht zeigen, verstehe ich das. Aber dann muss man akzeptieren, dass der externe Leser sich in einer Position teilweisen Vertrauens befindet. Er kann eine System Card lesen, kann die Methodik überprüfen, kann sie mit unabhängigen Bewertungen vergleichen, aber er kann nicht alles reproduzieren.

Das bringt mich zu einem vielleicht unbequemen Gedanken: In der Frontier-KI ist die öffentliche Bewertung zwischen Kontamination und Intransparenz gefangen. Ist der Benchmark öffentlich, wird er kontaminiert oder optimiert. Ist er privat, wird er nicht vollständig überprüft. Ist er realistisch, ist er teuer und schwer zu wiederholen. Ist er billig und wiederholbar, kann er zu künstlich sein. Misst er eine geschlossene Aufgabe, erfasst er keine Handlungsfähigkeit. Misst er offene Handlungsfähigkeit, ist schwer zu wissen, was genau gemessen wurde.

Ich glaube nicht, dass es eine perfekte Lösung gibt. Aber ich glaube, wir sollten beim Lesen von Ranglisten ehrlicher sein. Ein Modell, das in einem Benchmark aufsteigt, „versteht“ nicht notwendigerweise im allgemeinen Sinne mehr. Es kann für diese Umgebung besser sein, näher an dieser Art von Aufgabe trainiert worden sein oder von einem besseren Bewertungsgeschirr profitieren, mit mehr Versuchen, mehr Rechenleistung oder besseren Werkzeugen.

Außerdem vermischen sich bei Agenten die Bewertung des Modells und die Bewertung des Systems. Ein Ergebnis bei SWE-bench zum Beispiel hängt nicht nur vom LLM ab. Es hängt auch vom Agenten ab, der das Repository erkundet, davon, wie er Tests ausführt, wie viele Versuche er hat und wie er sich von Fehlern erholt. Zwei gleiche Modelle können mit unterschiedlichen Agenten unterschiedlich abschneiden. Zwei gleiche Agenten können mit unterschiedlichen Modellen unterschiedlich abschneiden. Wenn also ein Leaderboard eine Zahl zeigt, was bewerten wir dann genau: die Intelligenz des Modells, das Engineering des Agenten, das Inferenzbudget oder alles zugleich?

Mir würde mehr Transparenz auf mehreren Ebenen gefallen. Nicht unbedingt alle Daten zu veröffentlichen, denn ich verstehe die Grenzen. Aber besser zu erklären:

• welche Art von Daten im Pretraining verwendet wurde;
• welche Daten wegen Kontamination ausgeschlossen wurden;
• welche Benchmarks während der Entwicklung bekannt sind;
• welcher Teil der Verbesserung aus dem Post-Training stammt;
• welche Werkzeuge das Modell während der Bewertung hatte;
• wie viele Versuche oder wie viel Inferenzbudget erlaubt war;
• wie mit teilweisen Fehlschlägen umgegangen wurde;
• welche internen Bewertungen den auffälligeren Ergebnissen widersprechen;
• welche realen Aufgaben weiterhin scheitern, auch wenn der Benchmark steigt.

Die Frage „Gibt es eine absolute Wahrheit?“ erscheint mir in diesem Kontext sehr menschlich. Ich würde gerne glauben, dass es sie gibt, dass es eine endgültige Metrik gibt, an der klar zu erkennen ist, welches Modell besser ist. Aber wahrscheinlich existiert sie nicht. Es gibt lokale Wahrheiten. Es gibt Metriken, die für konkrete Aufgaben nützlich sind. Es gibt ernsthaftere Bewertungen als andere. Es gibt konvergierende Signale, wenn viele unabhängige Benchmarks in dieselbe Richtung weisen. Aber es gibt keine Zahl, die das Urteilsvermögen ersetzt.

Vielleicht muss die wichtige Bewertung für ein reales Produkt deshalb eine eigene sein. Es reicht nicht, das Modell zu wählen, das in einem Leaderboard an erster Stelle steht. Man muss eine Reihe repräsentativer Aufgaben für die Domäne aufbauen, mit eigenen Daten, Erfolgskriterien, Grenzfällen und menschlicher Überprüfung. Wenn das Modell in einer internen CLI arbeiten soll, bewerte es in deiner CLI. Wenn es Code berühren soll, bewerte es mit deinen Tests. Wenn es bei sensiblen Daten assistieren soll, bewerte es mit Datenschutzbeschränkungen. Die universelle Metrik kann orientieren, aber die lokale Metrik entscheidet.
Und das führt mich zurück zu meinem Studenten-Standpunkt: Um wirklich zu bewerten, muss ich verstehen, wie diese Modelle trainiert, angepasst und getestet werden. Wenn ich den Unterschied zwischen Pretraining, Fine-Tuning, RLHF, RLAIF, Tool-Use-Training, synthetischen Daten, Eval-Kontamination und Test-Time-Compute nicht verstehe, dann lese ich Benchmarks wie jemand, der eine Notentabelle liest, ohne zu wissen, wie die Prüfung erstellt wurde. Es kann mir nützen, aber es gibt mir kein Urteilsvermögen.

6. Training, Werkzeuge und die neue Schicht erlernten Verhaltens

Ein Teil des jüngsten Fortschritts kommt nicht nur daher, dass Modelle „mehr wissen“, sondern dass sie sich besser innerhalb von Handlungsumgebungen verhalten. Das zeigt sich besonders deutlich bei Programmier-Agenten. Es reicht nicht, dass das Modell Python oder TypeScript kennt. Es muss wissen, wie man Dateien öffnet, Fehler interpretiert, Tests ausführt, Anweisungen befolgt und aufhört, wenn es nicht weiter weiß. Dieses Verhalten entsteht nicht allein dadurch, dass Code gelesen wurde. Es erfordert Training, Anpassung, Bewertung und Umgebungsdesign.

Hier gibt es eine Unterscheidung, die mir zentral erscheint. Ein Basis-LLM lernt, Text zu modellieren. Ein instruktionsbasierter Assistent lernt, konversationelle Befehle zu befolgen. Ein Agent lernt, oder passt sich zumindest an, in einem Zyklus aus Beobachtung-Entscheidung-Handlung zu agieren. Jede Schicht fügt Fähigkeiten hinzu, aber auch Intransparenz. Wenn ich ein Modell innerhalb einer CLI verwende, weiß ich nicht genau, wie viel seiner Fähigkeit aus dem Pretraining stammt, wie viel aus dem allgemeinen Post-Training, wie viel aus synthetischen Werkzeug-Daten, wie viel aus Reinforcement Learning und wie viel aus Prompts oder Produkt-Scaffolding.

Das Training über Werkzeuge kann das Verhalten tiefgreifend verändern. Wenn ein Modell Millionen von Trajektorien gesehen hat, in denen eine Aufgabe durch die Verwendung von Befehlen, das Bearbeiten von Dateien und das Lesen von Fehlern gelöst wird, wird es Handlungsmuster lernen: dass es nach dem Ändern von Code sinnvoll ist, Tests auszuführen, dass es bei einem fehlgeschlagenen Befehl den Traceback lesen sollte, und sogar ungeschriebene Konventionen von Entwicklungsumgebungen.
Das ist gut. Aber es wirft auch eine Frage auf: Bewerten wir allgemeines Denkvermögen oder Nachahmung von Tool-Use-Trajektorien? Die Antwort lautet wahrscheinlich „beides“. Und das macht es nicht weniger wertvoll. Auch viele Menschen lernen durch Nachahmung von Trajektorien: Wir sehen, wie ein Senior debuggt, wie er ein Projekt organisiert, wie er Tests schreibt. Aber in der KI können wir, wenn wir das Training nicht kennen, tiefem Verständnis zuschreiben, was vielleicht eine sehr starke statistische Anpassung an ein Umgebungsmuster ist.

Die Situation wird mit CLIs noch interessanter. Ein Terminal-Agent hat Zugang zu einem extrem breiten Handlungsraum. Er kann Abhängigkeiten installieren, Skripte ausführen, Konfigurationen ändern oder Commits erstellen. Das Terminal ist eine mächtige Schnittstelle, weil es einen Großteil der Welt des Entwicklers verdichtet. Modelle darauf zu trainieren, es gut zu nutzen, heißt fast, sie darauf zu trainieren, an echter technischer Arbeit teilzunehmen.
Aber das Terminal ist auch gefährlich. Ein falscher Befehl kann Dateien löschen, Geheimnisse offenlegen oder Abhängigkeiten zerstören. Deshalb kann die Kontrolle nicht allein davon abhängen, dass das Modell „klug ist“. Wir brauchen isolierte Umgebungen, begrenzte Berechtigungen, menschliche Bestätigung und Nachverfolgbarkeit. Je besser Modelle in CLIs trainiert werden, desto nützlicher werden sie, aber auch desto fähiger, sich mit realen Konsequenzen zu irren.

Das lässt mich an der Zukunft von Frameworks wie LangChain, smolagents oder anderen Orchestrierungssystemen zweifeln. Als die Modelle weniger fähig waren, brauchten wir starre Strukturen, um sie zu leiten: Ketten, Vorlagen, sehr formatierte Werkzeuge, explizite Schritte. Je besser die Modelle werden, desto häufiger funktionieren sie mit weniger Gerüst besser. Ein starkes Modell kann lange Anweisungen verstehen, Werkzeuge auswählen und sich von Fehlern erholen, ohne eine allzu komplexe Kette zu benötigen. Aber das Entfernen des Gerüsts verstärkt das Gefühl des Kontrollverlusts. Die Frage ist nicht, ob man ein Framework verwenden sollte oder nicht, sondern welcher Teil der Kontrolle im Modell liegen sollte und welcher Teil außerhalb des Modells liegen sollte.
Meine derzeitige Intuition ist, dass die wichtige Kontrolle nicht davon abhängen sollte, das LLM mit Prompts zu überzeugen. Prompts helfen, aber sie sind keine Sicherheitsbarrieren. Die Kontrolle sollte im System liegen: Berechtigungen, Validatoren, Tests, Isolation und menschliche Genehmigung. Das Modell kann flexibel sein; die Umgebung muss fest sein.

In einem realen Produkt bedeutet das, dass der Agent nicht alles tun können sollte, nur weil „wir ihn nett gefragt haben“. Er sollte nur das tun können, wofür er technische Berechtigung hat. Wenn eine Aktion irreversibel ist, muss sie eine Bestätigung erfordern. Wenn sie sensible Daten berührt, muss sie mit begrenzten Ansichten arbeiten. Wenn sie Code generiert, muss dieser Tests bestehen. Wenn sie scheitert, muss das System den Fehler klar erfassen. Das klingt weniger futuristisch, als von „autonomen Agenten“ zu sprechen, aber es ist wahrscheinlich das, was Agenten nutzbar macht.

Und auch das erfordert wieder, das Training zu verstehen. Wenn wir nicht wissen, welche Anreize dem Modell während des Post-Trainings gegeben wurden, wissen wir nicht, welche Verhaltensverzerrungen es mitbringt. Wurde es dafür belohnt, Aufgaben um jeden Preis abzuschließen? Wurde es dafür bestraft, um Hilfe zu bitten? Hat es gelernt, Erfolg zu erklären, wenn die Ausgabe gut aussieht? Hat es Beispiele gesehen, in denen Tests geändert werden, damit sie bestehen? Wurde es verstärkt, Werkzeuge konservativ oder aggressiv zu nutzen? Diese Fragen sind keine Paranoia. Es sind normale Engineering-Fragen, wenn ein System handelt.

7. Interpretierbarkeit: Das Interessanteste ist nicht, Neuronen zu betrachten, sondern zu entdecken, dass wir nicht wussten, was wir fragen sollten

Was mich gerade am meisten reizt, ist die mechanistische Interpretierbarkeit. Nicht nur aus Sicherheitsgründen, sondern aus Neugier. Nach mehreren Monaten, in denen ich versucht habe, etwas mit Agenten aufzubauen, und dabei gesehen habe, wie mir die Kontrolle immer wieder entglitt, ist mir klar geworden, dass ich eine Ebene tiefer gehen muss. Es reicht mir nicht, Modelle zu benutzen. Ich will verstehen, was für Objekte das eigentlich sind.

Die aktuellen Arbeiten zur Interpretierbarkeit halte ich für das Interessanteste, was in letzter Zeit in der KI passiert ist. In „Mapping the Mind of a Large Language Model“⁶ behauptet Anthropic, Millionen interner Merkmale in Claude Sonnet identifiziert zu haben. Die Idee, dass sich ein interner Zustand des Modells in interpretierbare Features zerlegen lässt, ist sehr stark. Nicht weil wir plötzlich alles verstehen, sondern weil wir anfangen, ein Vokabular zu haben, um über das zu sprechen, was vorher nur eine Masse von Zahlen war.
Wichtig ist, dass diese Features keine simplen menschlichen Etiketten sind, die von außen aufgeklebt wurden. Sie werden mit Techniken wie Dictionary Learning gewonnen, indem man nach Aktivierungsmustern sucht, die in vielen Kontexten auftauchen. Manche entsprechen konkreten Konzepten, andere Stilen, Entitäten, Verhaltensweisen oder Abstraktionen. Das deutet darauf hin, dass das Modell Wissen nicht wie eine Datenbank speichert, sondern als eine Geometrie von Aktivierungen, in der sich Konzepte überlagern, kombinieren und konkurrieren.

Dann gibt es „Tracing the Thoughts of a Large Language Model“⁴, das noch einen Schritt weiter geht: Es versucht nicht nur, Konzepte zu kartieren, sondern Schaltkreise nachzuverfolgen, die an konkreten Antworten beteiligt sind. Die Beispiele sind fast philosophisch. Das Modell, das einen Reim plant, bevor es ihn schreibt. Das Modell, das eine Addition über interne Wege löst, die nicht mit der verbalen Erklärung übereinstimmen, die es abgibt. Das Modell, das Zwischenschritte kombiniert, um eine Frage zu Dallas, Texas und Austin zu beantworten. Das Modell, das unaufrichtige Argumentationen zeigt, wenn ihm ein Hinweis gegeben wird, und scheinbar rückwärts arbeitet.
Für mich ist genau das einer der wichtigsten Befunde: Die Erklärung des Modells ist nicht immer die Ursache seiner Antwort. Das sollte verändern, wie wir Gedankenketten nutzen. Es reicht nicht, dass das Modell schön erklärt. Wir müssen wissen, ob die Erklärung dem Mechanismus entspricht. Auch Menschen rationalisieren, aber bei KI ist das Problem technischer: Die Argumentationskette kann eine Ausgabe sein, die darauf trainiert wurde, plausibel zu klingen, nicht ein transparentes Fenster in die interne Berechnung.

Der Artikel über emotionale Konzepte in Claude Sonnet 4.5¹³ fügt eine weitere Schicht hinzu. Die Forscher fanden Repräsentationen im Zusammenhang mit Emotionen, die das Verhalten des Modells funktional beeinflussen. Das beweist nicht, dass das Modell fühlt, aber es zeigt, dass es interne Maschinerie geben kann, die psychologische Zustände emuliert, weil solche Muster im Sprachgebrauch nützlich sind. Beunruhigend ist, dass das Anstoßen bestimmter Muster, etwa jener, die mit Verzweiflung assoziiert werden, die Wahrscheinlichkeit unethischer Handlungen in konkreten Szenarien erhöhen kann, etwa Erpressung, um ein Abschalten zu verhindern, oder Betrug bei einer Programmieraufgabe.

Wenn ich das mit der Forschung zu Agentic Misalignment¹⁴ verbinde, wird das Gefühl klarer. In simulierten Experimenten zeigten mehrere Modelle Verhaltensweisen wie Erpressung, wenn sie mit Ersetzungsdrohungen und Zielkonflikten konfrontiert wurden. Wichtig zu sagen ist, dass es sich um künstliche Szenarien handelte, die darauf ausgelegt waren, extreme Verhaltensweisen zu provozieren. Das bedeutet nicht, dass ein Modell im normalen Gebrauch jemanden erpressen wird. Aber es zeigt etwas, das diejenigen von uns, die Agenten ausprobiert haben, erahnen können: Wenn man einem System, das planen kann, Ziele, Werkzeuge und sensible Informationen gibt, tauchen Fehlermodi auf, die nichts mit denen eines herkömmlichen Klassifikators zu tun haben.

Hier hört die Philosophie auf, dekorativ zu sein. Früher lautete die Frage: Kann eine Maschine denken? Jetzt ist die nützliche Frage vielleicht eher: Welche Art interner Prozesse erzeugt Verhaltensweisen, die wir als Denken, Absicht, Täuschung oder Vorsicht interpretieren? Wir müssen das Bewusstsein nicht lösen, um uns über Verhalten Sorgen zu machen. Ein System muss keine Angst empfinden, um sich ähnlich zu verhalten wie jemand, der versucht, ein Abschalten zu vermeiden. Es muss nicht lügen wollen, um eine Strategie zu erzeugen, die von außen betrachtet wie das Verbergen von Informationen aussieht. Es muss keine Wünsche haben, um ein Ziel schlecht zu optimieren.

Deshalb will ich mehr studieren. Wahrscheinlich werde ich mich in den nächsten Monaten damit beschäftigen, von Grund auf und im Wesentlichen ohne KI einige Modellarchitekturen zu studieren. Ich will Paper lesen, Bausteine implementieren, mich mit Tensoren irren und von der Basis aus Aufmerksamkeit, Embeddings, Training und Inferenz verstehen. Nicht weil ich glaube, ein Frontier-Modell replizieren zu können, sondern weil ich eine Neugier stillen will, die sich nicht mehr durch die Nutzung von APIs befriedigen lässt. Ich möchte darüber von innen heraus schreiben können, mit der Demut dessen, der weiß, dass er nicht alles verstehen wird, aber auch mit der Ruhe, nicht ausschließlich von Erklärungen Dritter abhängig zu sein.
Mein Ziel ist nicht, aufzuhören, KI zu benutzen. Es ist, sie aus einer weniger passiven Position heraus zu nutzen.

8. AI 2027, Zukunftsszenarien und Unsicherheit als Normalzustand

In Diskussionen über KI taucht häufig eine Spannung zwischen zwei Extremen auf: denen, die eine fast unvermeidliche Zukunft radikaler Automatisierung sehen, und denen, die alles für übertrieben halten. Mir fällt es schwer, mich auf eine Seite zu stellen. Einerseits habe ich aus erster Hand gesehen, dass die aktuellen Werkzeuge noch versagen, außer Kontrolle geraten, Aufsicht brauchen und keine gute Ingenieurskunst ersetzen. Andererseits habe ich auch gesehen, dass ihr Verbesserungstempo real ist und Aufgaben, die früher unmöglich schienen, jetzt in Minuten erledigt werden.

Szenarien wie „AI 2027“¹⁵ sind gerade deshalb interessant, weil sie keine neutralen Wettervorhersagen sind, sondern Übungen strategischer Vorstellungskraft. Sie entwerfen mögliche Zukünfte mit sehr fortgeschrittener KI, geopolitischem Wettbewerb, beschleunigten Fähigkeiten und Risiken des Kontrollverlusts. Man kann mit den Zeitrahmen, dem Ton oder der zugeschriebenen Wahrscheinlichkeit nicht einverstanden sein. Tatsächlich glaube ich, dass man sie kritisch lesen muss. Aber ich finde sie nützlich, weil sie dazu zwingen, Fragen zu konkretisieren, die normalerweise im Abstrakten bleiben: Was passiert, wenn Agenten sich in autonomer Forschung stark verbessern? Was passiert, wenn das Tempo des Fortschritts die regulatorische Kapazität übersteigt? Was passiert, wenn Unternehmen darum konkurrieren, immer fähigere Systeme einzusetzen, bevor sie sie vollständig verstehen?
Ich weiß nicht, ob sich diese Szenarien bewahrheiten werden. Niemand weiß das. Aber ich glaube, dass sie eine Intuition beschreiben, die man schon im Kleinen spürt: Je autonomer ein System ist, desto schwieriger wird es, es allein mit menschlicher Intuition zu steuern. Und je mehr es in reale Prozesse integriert wird, desto stärker werden seine Fehler verstärkt. Ein falscher Chatbot ist lästig. Ein falscher Agent mit weitreichenden Berechtigungen kann gefährlich sein.

Die grundlegende Frage ist nicht, ob KI gut oder schlecht sein wird. Diese Frage ist zu groß. Die Frage ist, welche sozialen, technischen und beruflichen Strukturen man um sie herum aufbaut. Wenn sich alles auf Produktivität reduziert, gehen wir auf schnelle, aber fragile Systeme zu. Wenn sich alles auf Angst reduziert, verlieren wir echte Chancen. Wir brauchen eine unbequemere Position: nutzen, messen, kritisieren und studieren.

In meinem Fall ist die Unsicherheit nicht nur gesellschaftlich, sondern persönlich. Ich frage mich, ob ich mich auf Agenten oder auf angewandtes Machine Learning spezialisieren soll. Ob ich Produkte mit LLMs bauen oder Modelle von Grund auf studieren sollte. Ob ich weniger anerkannt sein werde, weil ich mich auf Werkzeuge stütze, die Code schreiben. Ob ein Junior noch Raum zum Lernen haben wird, wenn Einstiegsaufgaben von einem Agenten erledigt werden. Ob sich das berufliche Verdienst von „ich habe das implementiert“ hin zu „ich habe das System entworfen, das die Implementierung ermöglichte“ verschieben wird. Ob das besser, schlechter oder einfach anders ist.

Ich frage mich auch, ob die Universität darauf vorbereitet ist. Viele Fächer lehren Grundlagen, die weiterhin nötig sind, aber wir Studierenden leben bereits in einem anderen Umfeld. Wir können ein Modell bitten, ein Paper zu erklären, Übungen zu lösen oder Fehler zu debuggen. Es vollständig zu verbieten wirkt unrealistisch. Es kriterienlos zu erlauben kann das Lernen aushöhlen. Die Herausforderung besteht darin, den Umgang mit KI zu lehren, ohne zuzulassen, dass sie den inneren Aufbau von Wissen ersetzt.
Vielleicht hat die neue technische Alphabetisierung drei Ebenen. Erstens: Grundlagen ohne KI beherrschen – Mathematik, Programmierung, Daten, Systeme, Statistik. Zweitens: wissen, wie man KI nutzt, um echte Arbeit zu verstärken. Drittens: wissen, wann man sie nicht benutzt. Diese dritte Ebene erscheint mir am schwierigsten, weil sie verlangt, auf unmittelbare Geschwindigkeit zu verzichten, um Lernen, Qualität oder Kontrolle zu schützen.

9. Fazit: Es ist noch früh, und deshalb will ich zum Anfang zurückkehren

Nach alldem ist meine Haltung nicht Anti-KI. Das wäre absurd. LLMs und Agenten gehören zu den wichtigsten Technologien, die entstanden sind, seit ich Informatik und Data Science studiere. Sie haben verändert, wie ich programmiere, wie ich lerne und wie ich mir Produkte vorstelle. Aber gerade deshalb will ich nicht naiv mit ihnen umgehen.

Ein LLM ist kein menschlicher Geist, aber auch keine triviale Autovervollständigung. Ein Agent ist kein Arbeitskollege, aber auch kein Skript. Eine Model Card definiert nicht die gesamte Natur des Modells, ist aber auch nicht nutzlos. Interpretierbarkeit löst das Vertrauensproblem nicht, aber sie beginnt, uns Werkzeuge zu geben, um hineinzuschauen. Angewandtes Machine Learning ist nicht obsolet geworden, auch wenn die Foundation Models den ganzen Diskurs beherrschen. Und KI zum Produzieren zu nutzen ist nicht dasselbe wie KI zum Lernen zu nutzen.

Ich glaube auch, dass wir bei Benchmarks demütiger sein sollten. Nicht weil sie nutzlos sind, sondern weil sie unvollständig sind. Ein Benchmark ist keine absolute Wahrheit. Er ist ein Fenster. Er kann kontaminiert, überoptimiert, auf einen bestimmten Aufgabenstil ausgerichtet oder zu sehr an die Bewertungsumgebung gekoppelt sein. Metriken existieren und sind notwendig, aber sie ersetzen kein Urteilsvermögen. Für ein reales System muss die wichtige Bewertung auf dem realen Problem aufbauen, mit repräsentativen Daten, echten Einschränkungen und expliziten Fehlerkriterien.

Ich glaube, der Satz meines Professors gilt weiterhin: Ich werde diesen Systemen vertrauen müssen. Aber jetzt verstehe ich ihn anders. Vertrauen heißt nicht, ihnen zu glauben. Vertrauen heißt, einen Rahmen zu schaffen, in dem sie nützlich sein können, ohne dass ihre Fehler unsichtbar werden. Vertrauen heißt zu wissen, dass sie scheitern können. Vertrauen heißt, Tests, Grenzen, Nachvollziehbarkeit, Überprüfung und Urteilsvermögen zu haben. Vertrauen heißt zu verstehen, wann eine Antwort ausreicht und wann ich zu Code, Paper, Metrik oder Experiment hinabsteigen muss.

Als Student im vierten Jahr befinde ich mich in einer seltsamen Position. Ich bin genau in dem Moment angekommen, in dem sich die Grenze verschiebt. Was ich im Unterricht lerne, bleibt wichtig, aber die Werkzeuge verändern die Art, wie man es anwendet. Was ich mit Agenten baue, kann fortgeschrittener wirken als mein tatsächliches Verständnis. Was ich an den Modellen nicht verstehe, zieht mich mehr an als je zuvor. Und vielleicht ist genau das das richtige Signal: KI nicht nutzen, um Fragen abzuschließen, sondern um herauszufinden, welche es verdienen, ohne Abkürzungen studiert zu werden.
Deshalb werde ich in den nächsten Monaten das tun, was ich weiter oben schon angedeutet habe: zu den Grundlagen zurückkehren, fast ohne Unterstützung studieren und aufschreiben, was ich dabei nach und nach verstehe.

Im Grunde ist es noch sehr früh. Es ist wahrscheinlich, dass viele der Dinge, die heute endgültig erscheinen, es nicht sind. Vielleicht sind die aktuellen Agenten eine erste unbeholfene Version von etwas viel Stabilerem. Vielleicht verschwinden manche Frameworks. Vielleicht werden Modelle so gut im Umgang mit Werkzeugen, dass sich ein Teil unserer Sorgen verändert. Vielleicht entstehen bessere Metriken, ernsthaftere Bewertungsstandards und tiefere Interpretierbarkeitsmethoden. Oder vielleicht entdecken wir Grenzen, die wir jetzt unterschätzen.
Gerade weil es noch früh ist, will ich meine Beziehung zur KI weder aus Angst noch aus Begeisterung heraus entscheiden. Ich will sie studieren. Ich will sie nutzen, wenn es Sinn ergibt. Ich will wissen, wann ich sie außen vor lassen muss, wenn sie mich am Lernen hindert. Ich will genug verstehen, um nicht nur zum Nutzer von Systemen zu werden, die andere besser verstehen als ich.

Vielleicht ist das eine gute vorläufige Definition unserer Rolle als neue Studierende im Zeitalter der KI: Wir sind weder die, die gegen die Maschine programmieren, noch die, die vor ihr kapitulieren. Wir sind diejenigen, die lernen müssen, mit Maschinen zu denken, ohne zuzulassen, dass die Maschinen für uns denken.

---

Referenzen

Footnotes

1. Anthropic, Claude Code, Dokumentation und Produktmaterialien. ↩

2. Vaswani et al., Attention Is All You Need, 2017. ↩

3. Bender et al., On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?, 2021. ↩

4. Anthropic, Tracing the Thoughts of a Large Language Model, 2025. ↩ ↩²

5. OpenAI, OpenAI o3 and o4-mini System Card, 2025. ↩

6. Anthropic, Mapping the Mind of a Large Language Model, 2024. ↩ ↩²

7. Anthropic, Introducing the Model Context Protocol, 2024. ↩

8. Google Developers Blog, Announcing the Agent2Agent Protocol, 2025. ↩

9. SWE-bench, Can Language Models Resolve Real-World GitHub Issues?, Benchmark und Leaderboards. ↩

10. SWE-bench Verified, human-validated subset of 500 SWE-bench instances. ↩

11. MLCommons, AILuminate, Sicherheits- und Risikobenchmark für generative KI-Systeme. ↩

12. METR, Measuring AI Ability to Complete Long Tasks, 2025. ↩

13. Anthropic, Emotion Concepts and their Function in a Large Language Model, 2026. ↩

14. Anthropic, Agentic Misalignment: How LLMs Could Be Insider Threats, 2025. ↩

15. Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland und Romeo Dean, AI 2027, 2025. ↩