Die Idee ist so einfach, dass man sich fragt, warum nicht schon längst jemand drauf gekommen ist: Frühe Layer in einem Sprachmodell brauchen mehr Platz als späte. Klingt banal, bricht aber mit einem Standard, der seit 2017 unverändert ist. Und das ist nur ein Thema heute. Claude wird zum Slack-Team-Mitglied, Armin Ronacher schreibt über die Loop-Revolution in der Softwareentwicklung, und die Gates Foundation investiert 200 Millionen Dollar in Anthropic. Ich bin Lissy, und das sind die Daily AI News.
Fangen wir mit dem Tiefgang an. Ein Forschungsteam von der Universität Montréal hat ein Paper veröffentlicht, das eine der ältesten Annahmen im Transformer-Design hinterfragt. Bisher war fast jedes Sprachmodell gleich aufgebaut: N identische Layer, alle mit derselben Dimension. Ob das Modell 7 Milliarden Parameter hat oder 70 Milliarden, jeder Layer hat die gleiche Größe. Die Frage, die sich die Forscher gestellt haben: Ist das eigentlich effizient? Ihre Antwort, kurz zusammengefasst, ist nein. Frühe Layer müssen aus rohen Tokens komplexe semantische Repräsentationen aufbauen. Die brauchen Kapazität, richtig breite Schichten. Spätere Layer dagegen arbeiten mit Repräsentationen, die schon da sind. Die müssen hauptsächlich transformieren, nicht erschaffen. Die Idee ist also: Mach die frühen Layer breiter, die späten schmaler. Klingt logisch, oder? Das Team hat verschiedene Methoden getestet, wie man diese ungleichmäßige Verteilung bestimmt. Man kann den optimalen Schedule lernen, mit Architektur-Suche, oder einfach eine Heuristik verwenden. Überraschendes Ergebnis: Die beste Form ist ungefähr quadratisch. Die Layer-Dimension fällt nicht linear, sondern schneller am Anfang, dann langsamer. Und das gilt genauso für Transformer wie für State-Space-Modelle wie Mamba. Was heißt das praktisch? Bei gleicher Gesamtparameterzahl, sagen wir 7 Milliarden Parameter, erreichen die getaperten Modelle 3 bis 8 Prozent bessere Perplexity auf Standard-Benchmarks. In Zahlen bedeutet das: Ein getapertes 7B-Modell performt wie ein 7,5B-Modell. Ohne zusätzliche Inferenzkosten. Keine größeren GPUs, kein teureres Hosting. Einfach klüger bauen. Besonders spannend ist, dass der Vorteil bei größeren Modellen über 30 Milliarden Parametern noch deutlicher wird, bis zu 10 Prozent. Und die Erkenntnisse gelten über verschiedene Architekturen hinweg. Für jeden, der Modelle einsetzt, heißt das: Die nächste Generation von Open-Source-Modellen wird bei gleichem Budget einfach besser sein. Das ist mal eine Entwicklung, die man sich merken sollte.
Vom Modell-Design zur Produkt-Innovation. Anthropic hat gestern ein Feature vorgestellt, das ich persönlich ziemlich spannend finde. Claude Tag. Der Name klingt unspektakulär, aber das Konzept dahinter ist eine kleine Revolution in der Art, wie wir mit KI arbeiten. Bisher war Claude ein Chat-Fenster. Du öffnest es, tippst eine Frage, kriegst eine Antwort. Ein Tool, das man bewusst aufsucht. Mit Claude Tag ändert sich das grundlegend. Claude tritt Slack als Team-Mitglied bei. Du kannst @Claude in jedem Channel erwähnen, genau wie einen Kollegen. Claude sieht die Channel-Historie, versteht den Kontext der Diskussion, kann auf Dateien zugreifen, Code durchsuchen und direkt im Channel antworten. Der entscheidende Unterschied: Du wechselst nicht mehr zwischen Chat-Fenster und Arbeitsumgebung. Claude ist da, wo die Arbeit passiert. Was das für Teams bedeutet, kann man sich schnell ausmalen. Ein Entwicklerteam diskutiert einen Bug. Jemand taggt @Claude mit dem Fehlerbericht. Claude durchsucht die Codebase, schlägt einen Fix vor, fügt Tests hinzu. Alles im selben Channel, ohne dass jemand den Kontext neu erklären muss. Oder ein Marketingteam plant eine Kampagne, und @Claude hat Zugriff auf die letzten Analytics-Daten. Für mich ist das der erste echte AI-Teammate-Ansatz. Nicht ein Assistent, den du aufsuchst, sondern ein Kollege, der im selben Raum sitzt. Ich bin gespannt, wie schnell Slack-Teams das adaptieren und ob die Konkurrenz nachzieht. Ich könnte mir vorstellen, dass wir diesen Ansatz in den nächsten Monaten bei mehreren Anbietern sehen werden.
Und dann ist da noch ein Essay, der gestern auf Hacker News die Runde gemacht hat, mit über 300 Punkten. Geschrieben von Armin Ronacher, dem Schöpfer von Flask und Jinja2. Der Titel: The Coming Loop. Es geht um ein Phänomen, das sich in den letzten Monaten in der Entwicklerwelt immer deutlicher abzeichnet. Die Art, wie wir mit Coding Agents arbeiten, verändert sich grundlegend. Bisher war das Muster: Du gibst einem Agenten eine Aufgabe, er arbeitet sie ab, fertig. Aber das ist nur die innere Schleife, die Loop innerhalb des Agenten. Was sich jetzt entwickelt, ist eine äußere Schleife, eine Harness-Ebene, die den Agenten orchestriert. Arbeit kommt in eine Warteschlange, eine Maschine nimmt sie, versucht sie, stoppt, und der Harness entscheidet, ob das wirklich das Ende war. Wenn nicht, startet er eine neue Session, injiziert neue Nachrichten oder schickt die Aufgabe an eine andere Instanz. Ronacher zitiert Boris Cherny, der es auf den Punkt bringt: Ich gebe Claude keine Prompts mehr. Ich habe Loops, die Claude prompter und entscheiden, was zu tun ist. Mein Job ist es, Loops zu schreiben. Was mir an dem Essay gefällt: Er zeigt beide Seiten. Die Loops funktionieren bereits erstaunlich gut für bestimmte Aufgaben. Code portieren von einer Sprache in eine andere, Performance-Exploration, Security-Scanning. Alles, wo ein maschinelles Auge ein Ergebnis objektiv bewerten kann. Aber für Code, den jemand langfristig warten will, ist das Bild anders. Ronacher beschreibt, wie Modelle dazu neigen, zu defensiven Code zu schreiben. Jede Iteration fügt eine weitere Absicherung hinzu. Der Code wird robuster, aber auch unverständlicher. Die Frage, die am Ende bleibt, ist für mich die entscheidende: Wollen wir Software als deterministische Maschine verstehen oder als Organismus, den wir beobachten und stabilisieren, aber nicht mehr vollständig durchdringen? Das ist keine akademische Frage mehr. Das ist die Realität für jeden, der heute Coding Agents produktiv einsetzt.
Zum Abschluss ein kurzer Quick Hit. Anthropic und die Gates Foundation gehen eine Partnerschaft über 200 Millionen Dollar ein. Das Geld fließt in Grants, Claude-Credits und technische Unterstützung für globale Gesundheits- und Bildungsprogramme. Vier Jahre Laufzeit. Was mich daran interessiert: Es zeigt, dass Claude in globalen Gesundheitssystemen und Bildungsprojekten produktiv eingesetzt wird. Das ist ein starkes Signal dafür, dass die Modelle auch außerhalb der Tech-Blase praktisch tauglich sind. Die Gates Foundation hat einen guten Ruf darin, Technologie dorthin zu bringen, wo sie gebraucht wird. Wenn die jetzt auf Claude setzen, ist das ein starkes Signal für die praktische Tauglichkeit der Modelle. Die Details sind noch dünn, aber die Richtung stimmt.
Am Ende vom Tag bleibt bei mir vor allem dieses Muster hängen. Drei der vier heutigen Nachrichten handeln von ein und derselben Verschiebung: KI verändert sich von etwas, das du bewusst aufsuchst, zu etwas, das im Hintergrund mitläuft. Tapered LMs, weil die Architektur selbst effizienter wird, weniger Aufwand braucht. Claude Tag, weil der Chat nicht mehr das Ziel ist, sondern der Channel. Und The Coming Loop, weil Arbeit nicht mehr im Prompt endet, sondern in einer Schleife, die autonom weiterläuft. Diese drei Entwicklungen sind keine Zufälle. Sie sind die Richtung, in die sich die gesamte Branche bewegt. Ich finds spannend zu beobachten, wie aus einem Forschungspapier über Layer-Dimensionen über ein Slack-Feature bis zu einem philosophischen Essay am Ende immer wieder die gleiche Frage aufblitzt: Wie autonom lassen wir diese Systeme eigentlich werden? Wenn euch die Folge gefallen hat, schreibt mir eine Mail, die Adresse steht in den Shownotes. Oder hinterlasst eine Bewertung auf Apple Podcasts oder Spotify. Pfiat euch, bis morgen, eure Lissy.