Ich hatte denselben Gedanken, also habe ich damit in nanochat experimentiert. Zum Beispiel hier sind 8 Agenten (4 Claude, 4 Codex), jeder mit 1 GPU, die nanochat-Experimente durchführen (versuchen, den Logit-Softcap ohne Regression zu löschen). Die Zusammenfassung ist, dass es nicht funktioniert und es ein Chaos ist... aber es sieht immer noch sehr schön aus :) Ich habe ein paar Setups ausprobiert: 8 unabhängige Solo-Forscher, 1 Chefwissenschaftler, der 8 Junior-Forschern Aufgaben gibt, usw. Jedes Forschungsprogramm ist ein Git-Branch, jeder Wissenschaftler forked es in einen Feature-Branch, Git-Arbeitsbäume für Isolation, einfache Dateien für die Kommunikation, Docker/VMs vorerst aus Einfachheitsgründen überspringen (ich finde, dass Anweisungen ausreichen, um Interferenzen zu verhindern). Die Forschungsorganisation läuft in tmux-Fenster-Gittern interaktiver Sitzungen (wie Teams), sodass es schön anzusehen ist, ihre individuellen Arbeiten zu sehen und "übernehmen" zu können, wenn nötig, d.h. kein -p. Aber okay, der Grund, warum es bisher nicht funktioniert, ist, dass die Ideen der Agenten einfach von Anfang an ziemlich schlecht sind, selbst bei höchster Intelligenz. Sie denken nicht sorgfältig über das Experimentdesign nach, sie führen ein bisschen unsinnige Variationen durch, sie erstellen keine starken Baselines und blenden die Dinge nicht richtig ab, sie kontrollieren nicht sorgfältig für Laufzeit oder Flops. (Nur als Beispiel, ein Agent hat gestern "entdeckt", dass die Erhöhung der versteckten Größe des Netzwerks den Validierungsverlust verbessert, was ein völlig spurious Ergebnis ist, da ein größeres Netzwerk im unendlichen Datenregime einen niedrigeren Validierungsverlust haben wird, aber dann trainiert es auch viel länger, es ist unklar, warum ich darauf hinweisen musste). Sie sind sehr gut darin, jede gegebene gut definierte und beschriebene Idee umzusetzen, aber sie generieren sie nicht kreativ. Aber das Ziel ist, dass Sie jetzt eine Organisation (z.B. eine "Forschungsorganisation") und ihre einzelnen Agenten programmieren, sodass der "Quellcode" die Sammlung von Eingabeaufforderungen, Fähigkeiten, Werkzeugen usw. und Prozessen ist, die sie ausmachen. Zum Beispiel ist ein tägliches Standup am Morgen jetzt Teil des "Org-Codes". Und die Optimierung des nanochat-Vortrainings ist nur eine der vielen Aufgaben (fast wie eine Bewertung). Dann - gegeben eine beliebige Aufgabe, wie schnell generiert Ihre Forschungsorganisation Fortschritte darauf?

Mit der bevorstehenden Flut an Nachfrage nach Tokens gibt es erhebliche Möglichkeiten, das zugrunde liegende Speicher- und Rechenmodell *genau richtig* für LLMs zu orchestrieren. Die grundlegende und nicht offensichtliche Einschränkung besteht darin, dass man aufgrund des Chip-Fertigungsprozesses zwei völlig unterschiedliche Pools von Speicher erhält (auch mit unterschiedlichen physischen Implementierungen): 1) On-Chip SRAM, das unmittelbar neben den Recheneinheiten liegt, das unglaublich schnell, aber von sehr geringer Kapazität ist, und 2) Off-Chip DRAM, das eine extrem hohe Kapazität hat, dessen Inhalte man jedoch nur durch einen langen Strohhalm saugen kann. Darüber hinaus gibt es viele Details der Architektur (z. B. systolische Arrays), Numerik usw. Das Design des optimalen physischen Substrats und dann die Orchestrierung von Speicher und Rechenleistung über die obersten Volumen-Workflows von LLMs (Inference-Prefill/Decode, Training/Fine-Tuning usw.) mit dem besten Durchsatz/der besten Latenz/$ ist wahrscheinlich das interessanteste intellektuelle Rätsel von heute mit den höchsten Belohnungen (\cite 4.6T von NVDA). All das, um viele Tokens schnell und günstig zu erhalten. Arguably ist der Workflow, der am meisten zählen könnte (Inference-Decode *und* über lange Token-Kontexte in engen agentischen Schleifen), derjenige, der gleichzeitig am schwersten zu erreichen ist, von den ~beiden Lagern dessen, was heute existiert (HBM-first NVIDIA-nah und SRAM-first Cerebras-nah). Wie auch immer, das MatX-Team ist A++-Klasse, daher ist es mir eine Freude, eine kleine Beteiligung zu haben, und herzlichen Glückwunsch zu der Finanzierung!

CLIs sind super spannend, gerade weil sie eine "Legacy"-Technologie sind, was bedeutet, dass KI-Agenten sie nativ und einfach nutzen, kombinieren und über das gesamte Terminal-Toolkit mit ihnen interagieren können. Z.B. bitte deinen Claude/Codex-Agenten, dieses neue Polymarket-CLI zu installieren und nach beliebigen Dashboards, Schnittstellen oder Logik zu fragen. Die Agenten werden es für dich erstellen. Installiere auch das Github-CLI und du kannst sie bitten, im Repo zu navigieren, Probleme, PRs, Diskussionen und sogar den Code selbst zu sehen. Beispiel: Claude hat dieses Terminal-Dashboard in ~3 Minuten erstellt, mit den Märkten mit dem höchsten Volumen und der 24-Stunden-Änderung. Oder du kannst es zu einer Web-App machen oder was auch immer du willst. Noch leistungsfähiger, wenn du es als Modul größerer Pipelines verwendest. Wenn du irgendeine Art von Produkt oder Dienstleistung hast, denke: Können Agenten darauf zugreifen und sie nutzen? - Sind deine Legacy-Dokumente (für Menschen) zumindest im Markdown-Format exportierbar? - Hast du Skills für dein Produkt geschrieben? - Kann dein Produkt/Dienstleistung über CLI oder MCP genutzt werden? - ... Es ist 2026. Baue. Für. Agenten.