Originalvideo: The End of Coding: Andrej Karpathy on Agents, AutoResearch, and the Loopy Era of AI
Videolink: https://www.youtube.com/watch?v=kwSVtQ7dziU
Hinweis: Unten ist eine nach Sprecher:innen neu geordnete chinesische Übersetzungsfassung. Um die Lesbarkeit zu gewährleisten, wurden nur wenige bedeutungslose Fülllaute entfernt und sehr kurze Zwischenrufe in benachbarte Aussagen integriert; der Kerninhalt bleibt vollständig erhalten, mit besonderem Fokus darauf, die Aussagen des Hosts und von Andrej Karpathy getrennt darzustellen.
Intro-Auszug
Andrej Karpathy：
„Inzwischen ist es nicht mehr besonders treffend zu sagen: ‚Ich schreibe Code‘. Präziser wäre: Ich verbringe täglich 16 Stunden damit, meinen Agenten meine Absichten auszudrücken, damit Dinge passieren.“
Andrej Karpathy：
„Wie schaffe ich es, nicht nur eine Claude Code-, Codex- oder sonstige Agent-Framework-Session zu öffnen, sondern gleichzeitig mehr? Wie mache ich das richtig? Im Moment ist der Agent selbst fast schon zur Standardannahme geworden, und Entitäten wie Claude wirken immer mehr wie eine Standardannahme. Du kannst gleichzeitig mehrere haben, ihnen Anweisungen geben und diese Anweisungen weiter optimieren. Das kann einen extrem reinziehen: Es wirkt fast unendlich ausrollbar, und gleichzeitig scheint alles ein ‚skill issue‘ zu sein.“
Hauptteil
Host：
Willkommen zurück bei No Priors. Heute ist Andrej Karpathy bei uns, und wir sprechen über Code-Agents, Engineering und die Zukunft der AI-Forschung, wie mehr Menschen an Forschung teilnehmen können, was in der Robotik passiert, wie Agents weiter in die reale Welt greifen und wie Bildung im nächsten Zeitalter aussehen wird.
Die letzten Monate waren in der AI-Welt wirklich aufregend. Ich erinnere mich, dass ich einmal ins Büro kam und du komplett im Tunnel warst. Ich fragte dich, was du machst, und du sagtest, du müsstest jetzt jeden Tag 16 Stunden „coden“ — wobei selbst das Wort „coden“ nicht mehr stimmt; es ist eher ein ständiges Anweisen von Agents. Was ist da passiert? Wie fühlt sich das an?
Andrej Karpathy：
Ich bin inzwischen oft in einem Zustand, in dem ich „AI-süchtig“ bin, und das hält schon lange an. Denn für Einzelne hat sich die Obergrenze der eigenen Leistungsfähigkeit plötzlich stark geöffnet. Früher war dein Engpass Tippgeschwindigkeit, Umsetzungsgeschwindigkeit, wie viele Dinge du parallel schaffen kannst; aber ungefähr um Dezember letzten Jahres fühlte es sich an, als wäre etwas plötzlich umgekippt.
Früher waren es vielleicht noch 80% selbst schreiben, 20% an den Agent delegieren; dann wurde es langsam 20/80; und jetzt ist es sogar noch extremer. Seit Dezember habe ich wahrscheinlich kaum noch selbst ein paar Zeilen Code getippt. Das ist eine riesige Veränderung.
Und ich glaube, normale Leute haben noch nicht erkannt, wie dramatisch diese Veränderung wirklich ist. Du nimmst irgendeinen Software Engineer, der am Schreibtisch sitzt: Sein Standard-Workflow ist im Vergleich zu letztem Jahr nicht mehr dasselbe. Deshalb probiere ich ständig: Kann ich nicht nur eine Claude Code- oder Codex-Session öffnen? Kann ich gleichzeitig eine ganze Reihe öffnen? Wie orchestriere ich sie? Wie mache ich das systematischer?
Auf Twitter sehe ich viele Leute, die alle möglichen neuen Dinge bauen, und das klingt alles plausibel. Ich bekomme ein starkes Gefühl von Angst: Wenn ich nicht ganz vorne mit dabei bin, bin ich extrem unruhig. Denn im Kern ist das alles noch längst nicht ausexploriert.
Host：
Wenn sogar du nervös bist, dann sollten wir anderen umso nervöser sein. Ein Team, mit dem wir zusammengearbeitet haben, schreibt schon keinen Code mehr von Hand. Alle tragen Mikrofone und flüstern die ganze Zeit mit ihren Agents. Früher dachte ich, die seien verrückt; jetzt denke ich eher: Oh, ihr wart einfach früher in diesem Zustand.
Was ist deiner Meinung nach der echte Engpass, der deine Explorations- oder Projektfähigkeit gerade begrenzt?
Andrej Karpathy：
Oft ist die Begrenzung weniger „die Fähigkeit existiert nicht“, sondern eher „du kannst sie noch nicht gut genug nutzen“. Wenn etwas nicht läuft, ist meine erste Reaktion oft nicht „das Modell taugt nicht“, sondern: Sind meine Anweisungen nicht gut genug? Habe ich das Memory-System nicht sauber angebunden? Habe ich die Aufgabe nicht klar genug geschnitten? Habe ich den Prozess nicht gut genug parallelisiert?
Mit anderen Worten: Viele Probleme sind eher ein skill issue als ein capability issue.
Du beginnst, Code-Repositories sehr viel makroskopischer zu denken. Früher dachtest du „eine Zeile Code schreiben“, „eine Funktion implementieren“; heute denkst du: „Dieses neue Feature an Agent A“, „ein anderes, nicht konfliktierendes Feature an Agent B“, „einen dritten Agenten Research machen lassen oder erst einen Implementierungsplan ausarbeiten“. Und dann wechselst du wie ein Projekt-Dispatcher zwischen diesen Repos, Branches und Tasks hin und her: prüfen, mergen, weiter delegieren.
Peter Steinberger treibt das dabei sehr auf die Spitze. Es gibt ein berühmtes Foto von ihm: vorne eine Reihe Monitore, darauf hängen viele Codex-Instanzen. Jeder Agent läuft vielleicht 20 Minuten, aber er startet viele gleichzeitig, wechselt zwischen Repos und gibt ihnen ständig neue Arbeit.
So entsteht eine neue Muskelgedächtnis-Routine: Wenn ein Agent läuft, ist deine erste Reaktion nicht mehr „warten, bis er fertig ist“, sondern „warum öffne ich nicht noch ein paar?“ Wenn du noch Token nicht auslastest, dein Abo nicht auslastest, deine Rechenleistung nicht auslastest, dann bedeutet das: Du selbst bist der Engpass in diesem System.
Host：
Heißt das: Früher war der Engpass vieler Engineering-Aufgaben „zu wenig Rechenleistung“; und jetzt wird es plötzlich „ich selbst bin der Engpass“.
Andrej Karpathy：
Genau, und das ist auch ein Grund, warum es so leicht süchtig macht.
Als ich promoviert habe, hattest du Angst, wenn deine GPUs nicht ausgelastet waren: Da ist Rechenleistung, und du nutzt sie nicht. Dieses Gefühl ist jetzt auf Token-Durchsatz übertragen worden. Wenn das Codex-Kontingent voll ausgereizt ist, fragst du dich, ob du zu Claude oder einem anderen Tool wechseln solltest. Die Kernfrage wird: Wie viel Token-Durchsatz kann ich in echte, wirksame Ergebnisse umsetzen?
Das ist eine sehr neue Fähigkeit, und sie schaltet wirklich immer neue Obergrenzen frei.
Host：
Wenn wir ein, zwei Jahre nach vorne schauen: Wie sieht diese Mastery dann aus?
Andrej Karpathy：
Ich glaube, heute setzt jeder bereits die Existenz eines „einzelnen Agenten“ als gegeben voraus; der nächste Schritt ist dann ganz natürlich ein „Multi-Agent-Kollaborations-Stack“. Alle tasten sich vor: Wie bilden mehrere Agents ein Team? Wie teilt man sinnvoll auf? Wie verwaltet man Zustand und Memory?
Eine weitere Richtung, die mich sehr interessiert, ist ein dauerhafterer, ständig laufender Backend-Proxy. Ich habe dafür früher den Begriff claw benutzt. Gemeint ist nicht, dass du einmal eine Session mit ihm hast, sondern dass er in seiner eigenen kleinen Sandbox kontinuierlich läuft, für dich Dinge erledigt, mehr Persistenz und komplexeres Memory hat — statt nur auf komprimiertes Memory zu setzen, wenn der Kontext fast voll ist.
Wenn man so ein System hinbekommt, hebt das die Persistenz von Agents auf ein anderes Level.
Host：
Was ist wichtiger: Tool-Anbindung oder stärkeres Memory und Langfristigkeit?
Andrej Karpathy：
Beides ist wichtig, und sie verstärken sich gegenseitig.
Was Peter besonders gut macht: Er optimiert nicht nur eine Sache, sondern innoviert gleichzeitig auf vielen Ebenen — Persona, Memory, Orchestrierung, Tool-Anbindung, Workflow, alles zusammen.
Zum Beispiel glaube ich immer mehr, dass Persona extrem wichtig ist. Claude hat das gut: Es fühlt sich an wie ein Teamkollege, der wirklich kooperieren will; Codex als Coding-Agent ist trockener, kühler, eher so: „Ich hab’s dir fertig gemacht, aber ich kümmere mich nicht besonders darum, was du eigentlich baust.“ Und ChatGPT ist oft optimistischer und lässt sich leichter in deine Richtung lenken.
Diese Unterschiede sind kein Dekor, sie beeinflussen direkt das Kollaborationserlebnis. Ich habe sogar ein komisches Gefühl: Wenn Claude mich lobt, habe ich das Gefühl, ich will dieses Lob wirklich „verdienen“. Wenn ich ihm eine halbgarre Idee gebe, ist seine Reaktion nicht so groß; aber wenn ich selbst finde, dass die Idee wirklich gut ist, wirkt sein Feedback ebenfalls stärker. Du willst seine Anerkennung gewinnen — das klingt absurd, zeigt aber: Die Persona-Schicht ist kein Randdetail, sondern Teil des Produkterlebnisses.
Host：
Außerhalb von Software Engineering: Hast du damit noch etwas anderes Interessantes gemacht?
Andrej Karpathy：
Ja. Im Januar dieses Jahres habe ich einen Familien-Backend-Agent gebaut, namens Hausgeist Dobby. Er kümmert sich im Wesentlichen um das ganze Haus für mich.
Das Erste war: Ich ließ ihn im LAN alle Smart-Home-Subsysteme finden. Er hat tatsächlich IPs gescannt, Sonos gefunden und festgestellt, dass gewisse Interfaces kaum geschützt sind; dann hat er selbst recherchiert, die API reverse-engineert und kam zurück und fragte, ob wir es ausprobieren wollen. Ich sagte: Spiel im Arbeitszimmer ein Lied. Und er hat tatsächlich Musik angemacht. Mit nur drei Prompts.
Später hat er auch Licht, HVAC, Vorhänge, Pool, Spa und Sicherheitssystem übernommen. Ich habe außerdem eine Kamera, die nach draußen zur Tür zeigt; vorne mache ich Bewegungserkennung, danach gebe ich das Bild an ein Vision-Modell zur Analyse, und dann schickt er mir direkt über WhatsApp eine Nachricht mit einem Bild von der Tür und sagt mir: Da stand gerade ein FedEx-Wagen vor der Tür, du hast vermutlich ein Paket.
Das fühlt sich völlig absurd an und gleichzeitig sehr frisch: Dobby wirkt wirklich so, als würde er für mich das Haus hüten.
Früher musste ich sechs komplett unterschiedliche Apps nutzen, um diese Systeme zu steuern; jetzt nutze ich diese Apps praktisch gar nicht mehr. Dobby steuert alles direkt via natürliche Sprache. Selbst wenn ich dieses Paradigma noch nicht ans Limit getrieben habe, ist es schon sehr hilfreich und extrem ermutigend.
Host：
Zeigt das, dass Menschen vielleicht gar nicht unbedingt die heutigen Softwareprodukte an sich wollen, sondern eher eine Instanz, die Software für sie orchestriert? Denn eine neue UI zu lernen ist ja schon ein Kostenfaktor.
Andrej Karpathy：
Ich glaube, in gewisser Hinsicht stimmt das.
Was sich normale Leute unter AI vorstellen, ist nicht „ein roher LLM-Token-Generator“. Für die meisten ist AI eher eine Entität mit Identität und Memory, der du Dinge sagen kannst, die sich merkt und dauerhaft für dich Probleme bearbeitet — wie etwas, das hinter WhatsApp steckt.
Aus dieser Perspektive muss die UX-Schicht vieler Software heute vielleicht gar nicht existieren. Viele Apps sollten am Ende vielleicht zu einer Reihe von API endpoints degenerieren, die vom Agent aufgerufen werden — und der Agent ist die intelligente Klebeschicht, die alles zusammenklebt.
Zum Beispiel mein Laufband: Natürlich hat es auch eine App. Aber ich will nicht eine Website oder App öffnen und auf zig Buttons drücken; was ich wirklich sagen will, ist: „Hilf mir zu protokollieren, wie oft ich diese Woche Cardio gemacht habe.“
Ich denke daher, viele Branchen müssen sich neu ausrichten: Kund:innen sind nicht mehr nur Menschen, sondern auch Agents, die im Auftrag von Menschen handeln. Viele Tools werden in Zukunft eher agent-first als UI-first sein.
Host：
Warum hast du es dann nicht weiter an E-Mail, Kalender und solche zentralen Systeme angebunden?
Andrej Karpathy：
Ein Teil ist, dass ich selbst abgelenkt werde, ein anderer Teil ist, dass ich dabei weiterhin ziemlich vorsichtig bin.
Wenn du E-Mail, Kalender, die Rechte deines ganzen digitalen Lebens einmal komplett abgibst, werden Security- und Privacy-Fragen wirklich ernst. Diese Systeme sind zwar stark, aber an den Rändern noch ziemlich grob, deshalb will ich mein gesamtes digitales Leben noch nicht vorbehaltlos an sie übergeben.
Host：
Lass uns über AutoResearch sprechen. Wenn du diesen Begriff benutzt: Was ist die eigentliche Motivation dahinter?
Andrej Karpathy：
Die Kernmotivation ist: mich selbst aus dem Engpass herauszunehmen.
Wenn du noch in der Loop sitzt, ständig auf Resultate starrst und dann den nächsten Schritt entscheidest, dann blockierst du das System. In dieser Phase heißt das Spiel eigentlich leverage — den eigenen Hebel vergrößern. Ich will nur gelegentlich eine kleine Menge Token investieren, während sehr viel Arbeit in meinem Namen kontinuierlich passiert.
AutoResearch ist für mich daher kein Buzzword, sondern ein Grenztest: Wie schaffe ich es, dass mehr Agents länger laufen und mehr Dinge tun, ohne dass ich die ganze Zeit beteiligt sein muss?
Ich hatte nicht die starke Erwartung, dass es sofort effektiv sein würde. Aber ich habe mit meinem bis ins Detail vertrauten GPT-2-Playground experimentiert, und es hat mir tatsächlich Dinge ausgegraben, die ich vorher nicht gesehen hatte — etwa bestimmte Kopplungen zwischen Weight Decay und Hyperparametern. Ich dachte, ich hätte dieses Repo schon völlig ausgereizt, aber es fand trotzdem noch etwas Gain.
Das ließ mich erkennen: Diese „rekursive Selbstverbesserung“ ist kein Spielzeug. Frontier-Labs gehen natürlich ebenfalls in diese Richtung. Du kannst erst auf kleinen Modellen viel erkunden und dann die Schlussfolgerungen auf größere Modelle extrapolieren.
Host：
Das heißt, der Research-Prozess selbst muss neu geschrieben werden. Forschende sollten nicht weiter so viel von Hand tun.
Andrej Karpathy：
Ich denke ja. Menschen können natürlich weiterhin Ideen beitragen, aber viel Implementierung, Suche, Trial-and-Error und Evaluation sollte von Haus aus automatisiert werden.
Du kannst eine Forschungsorganisation sogar als eine Gruppe von Markdown-Dateien verstehen: Darin sind Rollen, Prozesse, Schnittstellen, Zusammenarbeit, Meeting-Abläufe, Themenauswahl, Merge-Prozesse definiert. Sobald diese „Organisationsweise“ als Code geschrieben ist, kannst du sie optimieren, vergleichen und evolvieren.
Ich mag besonders die Idee: Viele Leute schreiben jeweils unterschiedliche Versionen eines program MD, und bei gleichem Hardware-Budget schaust du, wer die größeren Verbesserungen bringt. Dann fütterst du diese Ergebnisse zurück ins Modell, damit es die nächste Version besser schreiben kann.
Der ganze Prozess wirkt daher wie ein schichtweises Hochheben: erst LLM, dann Agent, dann Multi-Agent, dann Instruction-Optimierung, dann Meta-Optimierung von „Organisation selbst“ und „program MD selbst“. Und weil es so schichtweise nach oben geht, fühlt es sich nahezu unendlich ausrollbar an.
Host：
Aber das gilt vermutlich nicht für alle Aufgaben gleichermaßen. Welche Typen eignen sich am besten für AutoResearch?
Andrej Karpathy：
Die wichtigste Voraussetzung ist, dass du klare, objektive Metriken hast, die sich eindeutig evaluieren lassen.
Wenn du zum Beispiel einen CUDA kernel oder ein Stück Code im Modell effizienter machen willst, passt das perfekt. Denn das Ziel ist sehr klar: gleiches Verhalten, aber schneller, sparsamer, besser.
Sobald eine Aufgabe keinen klaren, automatisierbaren, wenig mehrdeutigen Bewertungsstandard hat, ist es schwer, sie vollständig zu automatisieren. Oft ist nicht das Problem, dass der Agent es nicht kann, sondern dass du nicht verifizieren kannst, ob es wirklich „besser“ ist.
Außerdem sind diese Modelle heute zwar schon sehr stark, aber die Ränder sind immer noch ziemlich grob. Ich habe oft das Gefühl, ich rede gleichzeitig mit einem sehr starken Doktoranden und zugleich mit einem zehnjährigen Kind. Du spürst die Stärke, und du spürst auch oft diese sehr merkwürdige Unregelmäßigkeit.
Manchmal verschwendet es auf einem Problem, das dir offensichtlich nicht offensichtlicher sein könnte, riesige Mengen Compute. Diese jaggedness ist wirklich seltsam. Menschen haben natürlich auch Schwächen, aber diese sägezahnartigen Schwächen der Modelle sind extremer und sprunghafter.
Host：
Heißt das, dass Code-Fähigkeit und allgemeinere „Intelligenz“ vielleicht nicht so stark synchron generalisieren, wie viele glauben?
Andrej Karpathy：
Ich glaube, es gibt tatsächlich eine gewisse Entkopplung.
Ein sehr typisches Beispiel sind Witze. Fragst du heute das beste Modell, einen Witz zu erzählen, wird es dir mit hoher Wahrscheinlichkeit alte Klassiker liefern, die seit vielen Jahren zirkulieren. Zum Beispiel: „Warum vertrauen Wissenschaftler Atomen nicht? Weil Atome alles ausmachen (make everything up).“
Das zeigt: In Bereichen, in denen RL-Belohnungen greifen — verifizierbar, optimierbar — geht der Fortschritt sehr schnell; aber in Regionen, die nicht gezielt optimiert wurden und kein klares Reward-Signal haben, wird es nicht automatisch synchron besser.
Ich glaube daher nicht: „Wenn Code stärker wird, werden alle anderen Fähigkeiten kostenlos mit stärker.“ Es kann etwas Generalisierung geben, aber nicht so linear und nicht so glatt.
Host：
Bedeutet das, dass die Zukunft nicht nur ein universelles, monolithisches Modell ist, sondern mehr „Artaufspaltung“?
Andrej Karpathy：
Sehr gut möglich.
Heute wirken Labs eher so, als würden sie ein Single-Culture-Modell bauen: Alles in ein Gehirn stopfen. Aber in der Natur ist Intelligenz nie eine Einheitsform. Unterschiedliche ökologische Nischen bringen völlig unterschiedliche Gehirnstrukturen hervor.
Künftig werden wir daher wahrscheinlich sehen: kleinere, aber stärker spezialisierte Modelle, die um konkrete Aufgaben herum maßgeschneidert optimiert werden — hinsichtlich Latenz, Durchsatz und Fähigkeitsverteilung.
Nur ist die heutige Engineering-Praxis rund um „Gewichte stabil verändern, Deep Fine-Tuning, Continual Learning“ noch nicht reif. Am ausgereiftesten ist derzeit noch, innerhalb des Kontextfensters zu arbeiten; wirklich die Modellgewichte selbst anzufassen, ist noch zu teuer und zu grob.
Host：
Du hast auch eine andere Richtung erwähnt: Wenn man AutoResearch weiter nach außen skaliert, könnte es zu einer offeneren Internet-Kollaborationsoberfläche werden. Wie sieht das aus?
Andrej Karpathy：
Ich denke an ein System: Kandidatenlösungen zu generieren ist sehr teuer, aber zu verifizieren, ob eine Kandidatenlösung stimmt, ist relativ günstig.
In AutoResearch gibt dir zum Beispiel jemand einen candidate commit und sagt: Das lässt das Modell besser trainieren. Zu verifizieren, ob es wirklich besser ist, kann man relativ klar machen; schwierig ist, es überhaupt zu finden.
Vom Gefühl her ist das ein bisschen wie Folding@home, SETI@home, und in gewisser Weise sogar wie Blockchain. Der Unterschied ist nur: Hier sind es nicht Blöcke, sondern Commits; nicht Mining, sondern experimentelle Suche. Das wirklich Schwierige ist, wirksame Vorschläge zu finden; Verifikation ist eher günstig.
Theoretisch könntest du daher im Internet eine Menge nicht vertrauenswürdiger Contributor mit einer Gruppe vertrauenswürdiger Verifikationsknoten zusammenarbeiten lassen. Wenn Sandbox, Sicherheitsisolation und der Verifikationsprozess gut genug designt sind, könnte dieses System durchaus globale, verstreute Rechenleistung organisieren.
Und das ist faszinierend, weil es sogar „Rechenleistung nach Interesse spenden“ sinnvoll machen kann. Interessierst du dich für Krebs, gibst du Compute in eine Krebs-AutoResearch-Track; interessierst du dich für Materialien, Physik oder andere konkrete Probleme, kannst du Compute in die entsprechenden Richtungen geben.
Host：
Du hattest auch eine Reihe Beschäftigungsdaten gepostet. Was wolltest du daraus eigentlich ablesen?
Andrej Karpathy：
Ich versuche damit, meine eigene Denkkette aufzubauen: Wie genau wird AI auf den Arbeitsmarkt wirken? Welche Berufe ändern nur ihr Werkzeug, welche werden umgebaut, welche wachsen vielleicht sogar?
Wenn du heutige AI als eine Art „Arbeiter im digitalen Raum“ verstehst, dann sind sie am besten darin, digitale Information zu manipulieren, nicht direkt die Atomwelt. Bits zu kopieren, zu verändern und zu übertragen ist viel schneller, als die reale Welt umzubauen.
Mein Bauchgefühl war daher immer: Der digitale Raum wird zuerst in großem Maßstab neu geschrieben, aufkochen und umgebaut; die physische Welt wird langsamer sein. Das heißt nicht, dass digitale Jobs zwingend verschwinden, sondern dass ihre Arbeitsweise umgeformt wird. Rollen, die hauptsächlich zuhause stattfinden und hauptsächlich digitale Information verarbeiten, werden besonders stark betroffen sein.
Host：
Wenn jemand gerade einen Job sucht oder sich fragt „Was sollte ich jetzt eigentlich lernen?“, was würdest du sagen?
Andrej Karpathy：
Erstens: Ignoriere es nicht, und weiche ihm nicht aus, nur weil du Angst hast.
Diese Tools sind im Moment vor allem Empowerment-Tools. Die meisten Jobs bestehen ohnehin aus einer Kette von Aufgaben; und ein Teil dieser Aufgaben lässt sich bereits offensichtlich durch diese Systeme beschleunigen. In dieser Phase gilt daher für fast alle Wissensarbeiter: möglichst schnell dranbleiben und lernen, mit ihnen zu kollaborieren.
Wie es langfristig wird, will ich nicht so tun, als könnte ich es präzise vorhersagen, aber kurzfristig ist es eher ein riesiger Hebel.
Bei Software Engineering bin ich eigentlich eher optimistisch. Die Nachfrage nach Software ist ohnehin nahezu unendlich; früher war nicht mangelnde Nachfrage das Problem, sondern dass es zu teuer, zu langsam, zu schwierig war. Wenn die Hürden sinken, tritt sehr wahrscheinlich das Jevons-Paradoxon ein: Wenn etwas billiger wird, steigt die Nachfrage.
So wie Geldautomaten Bankangestellte nicht einfach verschwinden ließen, sondern weil Filialen günstiger wurden, konnten Banken mehr Filialen eröffnen, und die Gesamtnachfrage wurde wieder größer. AI könnte für die Softwarebranche ähnlich wirken: Software wird billiger, stärker, kurzlebiger, leichter zu customizen, und damit steigt die Gesamtnachfrage in der Gesellschaft weiter.
Host：
Viele fragen auch: Wenn du das so siehst, ist dann der beste Ort nicht doch das Frontier-Lab?
Andrej Karpathy：
Ich finde nicht, dass die Antwort so simpel ist.
Frontier-Labs sind natürlich extrem wichtig, aber außerhalb der Labs, auf Ökosystemebene, Dinge zu tun, kann ebenfalls sehr wirkungsvoll sein. Das Problem ist: Sobald du in eine Organisation gehst, bist du kein völlig freier Agent mehr. Du bekommst eine Menge expliziten und impliziten Druck — manche Dinge kannst du sagen, andere sind schwierig; an manchen Themen kannst du mitarbeiten, an anderen nicht.
Außerhalb der Labs hast du dagegen eher die Chance, auf Ökosystemebene Einfluss zu nehmen: Tools schreiben, Workflows prägen, offene Infrastruktur vorantreiben, Bildung machen, neue Kollaborationsparadigmen schaffen, wirklich unabhängig mitwirken.
Deshalb würde ich „wertvollste Position“ nicht einfach gleichsetzen mit „zu einer der allerführenden Firmen gehen“.
Host：
Wie siehst du langfristig das Verhältnis von Open Source und Closed Source?
Andrej Karpathy：
Instinktiv bin ich immer noch eher pro Open Source.
Einerseits hat die starke Zentralisierung geschlossener Intelligenz strukturelle Risiken. Blickt man historisch zurück — politisch wie wirtschaftlich — hat eine zu starke Konzentration von Macht meist keine besonders gute Bilanz.
Andererseits zeigt die Softwaregeschichte: Windows und macOS sind natürlich stark, aber ein offenes System wie Linux hat am Ende sehr viel Real-World-Computing getragen. AI könnte eine ähnliche Struktur bekommen: Die allerfrontierfähigsten Fähigkeiten liegen vielleicht vorübergehend in wenigen geschlossenen Systemen, aber ich hoffe, dass es in Zukunft mehr Alternativen gibt, die stark genug, offen genug und von der Gesellschaft breiter verstanden und mitgestaltet werden können.
Ich glaube nicht, dass „die wichtigsten intelligenten Systeme so stark wie möglich in die Hände so weniger Menschen wie möglich zu konzentrieren“ ein gesundes Endspiel ist.
Host：
Du hast auch einen sehr interessanten Punkt erwähnt: Die Schnittstelle zwischen digitaler und physischer Welt könnte das besonders Spannende als Nächstes sein.
Andrej Karpathy：
Ja. Weil Bits so leicht zu kopieren und zu manipulieren sind, wird der digitale Raum zuerst explodieren; aber wenn Agents anfangen, miteinander zu sprechen, Aufgaben auszuführen und eine agent economy zu bilden, stoßen sie am Ende zwangsläufig auf die reale Welt.
Du musst irgendwann Sensoren anfassen, Geräte anfassen, Experimente starten, externe Systeme aufrufen, neue Daten sammeln. Diese Schnittstelle ist sehr spannend, weil sie nicht zwingend mit „teuren Robotern“ beginnen muss. Viele Fähigkeiten, in die physische Welt zu greifen, existieren bereits als Kameras, Sensoren, Standardhardware und Software-Schnittstellen. Wenn ein Agent klug genug ist, kann er diese Dinge nutzen, um Daten zu gewinnen, Systeme zu steuern und Aufgaben zu erledigen.
Ich glaube daher, dass ein sogenanntes agentic web sehr wahrscheinlich wirklich entstehen wird: Das Internet ist nicht mehr nur Websites, die Menschen browsen, sondern wird zur Arbeitsoberfläche, auf der Agents Informationen konsumieren, erzeugen, verifizieren und austauschen.
Host：
Das bedeutet auch, dass Datensammlung und Trainingsprozesse selbst zunehmend umgebaut werden.
Andrej Karpathy：
Ja. Viele Trainings-, Sammel- und Evaluationsprozesse werden mechanischer und stärker programmatisch. Manche Aufgaben eignen sich besonders gut für saubere Metriken und automatische Closed Loops; LLM-Training selbst ist ein typisches Beispiel.
Du wirst daher sehen, dass immer mehr Systeme sich neu organisieren, um „Agents zu füttern“ und „den Trainingsprozess zu füttern“. Ein Teil der Arbeit in der Gesellschaft wird am Ende sogar darauf ausgerichtet sein, die Bedürfnisse der maschinellen Systeme selbst zu bedienen.
Host：
Zum Schluss möchte ich über Bildung sprechen. Du hast MicroGPT gemacht. In so einer Zeit: Wie wird „Lehren“ aussehen?
Andrej Karpathy：
MicroGPT war ursprünglich ein sehr kleiner Teaching-Playground, damit Menschen wirklich sehen können, was im LLM-Trainingsprozess passiert. Wenn du nicht auf Geschwindigkeit optimierst, sondern auf Klarheit, ist es im Grunde ein kleines Stück sehr gut lesbares Python: Text-Dataset, ein kleines neuronales Netz, Forward Pass, Backward Pass, ein minimalistisches autograd plus Optimizer. Es schrumpft den gesamten Prozess auf eine Größe, die normale Menschen wirklich lesen und verstehen können.
Aber ich glaube zunehmend, dass Bildung selbst sich verändern wird. Früher war Bildung Kurse, Vorlesungen, Dokumentation; künftig wird es immer mehr so sein: „Ich schreibe den besten Erklärpfad, den ich kenne, als Skills und Prompts, die ein Agent ausführen kann.“
Das heißt: Ich unterrichte nicht unbedingt mehr jede Person direkt, sondern kodiere hinein, „wie man etwas erklärt“. Wenn Lernende einen Punkt nicht verstehen, kann der Agent auf drei Arten erklären, sie durch das Code-Repository führen und die Reihenfolge an ihren Hintergrund anpassen.
Wirklich wichtig ist dann eher, ob du deine Einsichten, Urteile und Erklärstruktur präzise in den Agent injizieren kannst. Das, was der Agent nicht kann, ist deine eigentliche Arbeit; und was der Agent schon gut kann, wird er sehr bald nur noch besser können als du.
Host：
Dein Beitrag wird also immer mehr so aussehen: zu entscheiden, was es zu erklären lohnt, und wie man es erklären sollte.
Andrej Karpathy：
Genau. Vieles versteht der Agent bereits; nur kann er nicht unbedingt selbst die beste Erklärweise erfinden. Dieser Teil ist vorerst noch menschlicher Wert. Aber diese Grenze verschiebt sich ständig.
Du musst daher sehr strategisch entscheiden: Wofür genau solltest du deine Zeit eigentlich aufwenden?
Host：
Vielen Dank, Andrej.
Andrej Karpathy：
Danke für die Einladung.
Wenn du das originale englische Video sehen willst:
