0918 | Weniger bauen, mehr schaffen: KI im Alltag der Entwickler

Lena Vogel: Herzlich willkommen zum Hacker News Podcast, ich bin Lena Vogel.

Felix Hartmann: Und ich Felix Hartmann. Und was uns heute verbindet, ist eine Frage, die sich durch fast alle Geschichten von heute zieht: Was bauen wir eigentlich in einer Welt, in der Agenten und Modelle immer mehr übernehmen? Reduktion, Disziplin, Tooling, Sicherheit – das ist der rote Faden.

Lena Vogel: Und ganz konkret fangen wir mit einer Behauptung an, die auf Hacker News ordentlich diskutiert wurde: Liam Nugents These, dass die wichtigste Produktentscheidung die ist, die man nicht trifft – nämlich was man nicht baut. Er zitiert darin McGovern, der sagt: Wenn man 80 bis 90 Prozent des Contents streicht, steigen die Verkäufe und der Support-Aufwand sinkt.

Felix Hartmann: Das klingt erstmal paradox, Lena. Weniger Inhalt, mehr Erfolg? Aber wenn man es als Diskussion liest, ist der Kern ganz simpel: Die meisten Produkt- und Content-Entscheidungen sind nicht neutrale Zusätze, sie schaffen Wartungsarbeit, Verwirrung, Support-Tickets. Jede Seite, die man nicht schreibt, muss niemand pflegen.

Lena Vogel: Genau, und in der Diskussion geht es nicht darum, dass Content per se schlecht ist, sondern dass die Entscheidung, etwas wegzulassen, die härteste und wertvollste ist. Es ist leicht, Features zu addieren. Es ist schwer, sie zu streichen. Und McGoverns Zahl – 80 bis 90 Prozent – ist die Art von Zahl, über die man streiten kann. Manche Kommentare sagen vermutlich: Das gilt für Marketing-Websites, nicht für Dokumentation. Andere: Genau deshalb funktioniert es, weil fast niemand den Mut dazu hat.

Felix Hartmann: Und das passt frappierend gut zu einem anderen Beitrag vom gestrigen Tag: Ein Detail-Blog zieht Bilanz nach einer „Tokenmaxxing“-Enttäuschung. Also der Versuch, Agenten einfach mit immer mehr Tokens, immer mehr Kontext zu füttern. Das Fazit: Es fehlen Primitives für Self-Driving Codebases. Die wertvollste Arbeit bleibt gute Ideen und Architektur.

Lena Vogel: Das ist im Grunde dieselbe Lektion auf einer anderen Ebene. Beim Content heißt es: Streichen schlägt Hinzufügen. Bei Agenten heißt es: Mehr Kontext schlägt nicht mehr Verstand. Die Enthusiasten, die glaubten, man könne Codebases einfach autonom fahren lassen, wenn man nur genug Tokens in das Fenster stopft, mussten feststellen, dass das nicht reicht. Was fehlt, sind die richtigen Bausteine – Primitives – auf denen solche Systeme überhaupt erst laufen können.

Felix Hartmann: Und die offene Frage, die der Blog aufwirft und die auch die Diskussion offenlässt: Welche Werkzeuge abstrahieren Agenten-Arbeit künftig sinnvoll? Also welche Schichten ergeben sich zwischen „roher LLM-Aufruf“ und „autonom wartende Codebase“? Es gibt darauf noch keine kanonische Antwort.

Lena Vogel: Die Diskussion gibt aber eine Richtung vor, und das fand ich interessant: Es geht weg von der Frage „Wie viel Rechenleistung und Kontext?“ hin zu „Wie gut ist die Architektur?“ Gute Ideen und gutes Design bleiben der Engpass – nicht die Tokens. Das entzaubert die Geschichte ein bisschen, und zwar auf eine erholsame Art.

Felix Hartmann: Und weil wir gerade bei Agenten-Praxis sind: Ein Diskutant bringt ein sehr konkretes Beispiel, wie man LLM-Urteile diszipliniert einsetzt. Die These lautet: LLM-Klassifikation ist eigentlich Feature Engineering. Man nutzt die Urteile des Modells nicht als endgültige Antwort, sondern als Features in einer logistischen Regression.

Lena Vogel: Das ist ein schöner Brückenschlag zur alten Welt. Statt dem Modell zu trauen, dass es „Ja, das ist Spam“ sagt, nimmt man das Urteil als eines von mehreren Signalen – und bekommt dadurch Kalibrierung, frei wählbare Schwellen und Interpretierbarkeit. Klassische ML-Leute in der Diskussion dürften zustimmen: Das ist der Weg, wie man unzuverlässige Klassifikatoren produktionsreif macht.

Felix Hartmann: Und noch ein Beispiel aus der Praxis, das zur gleichen Tone-Lage passt: mysetup.ai, eine Community, in der Leute ihre AI-Setups teilen. Die Kritik aus der Diskussion: Die Anmeldung lief nur über MCP und GitHub, manuelle Eingabe fehlte. Die wurde dann ergänzt. Aber es zeigt genau das Muster: Wer alles auf eine Abstraktion – hier MCP – setzt, schließt Leute aus.

Lena Vogel: Ja, das ist fast eine Fallstudie zu Nugents These. Die wichtigste Entscheidung war nicht „wie bauen wir den besten MCP-Flow“, sondern „was lassen wir weg – und wen schließen wir damit aus“. Das war dann offensichtlich eine falsche Reduktion, und sie wurde schnell korrigiert. Gut für sie.

Felix Hartmann: Und damit sind wir thematisch schon mittendrin bei Agenten-Werkzeugen. Denn die nächste Geschichte fragt genau, wie portabel die Arbeit von Agenten überhaupt ist: Skillsync, ein YC-W26-Startup, portiert AI-Agent-Sessions zwischen verschiedenen Agents. Also Chat, Reasoning, Tool-Calls – die ganze Session-Historie – via einer Rust-Engine namens txcript, zum Beispiel von Claude Code zu Codex oder zu Cursor.

Lena Vogel: Das ist ein Problem, das jeder kennt, der mit zwei oder drei Agenten arbeitet: Man hat in dem einen drei Stunden Kontext aufgebaut, Erkenntnisse, gedebuggte Stellen – und in dem anderen Tool fängt man bei null an. Skillsync sagt: Die Session ist ein Artefakt, das man exportieren und importieren kann. Und die Wahl von Rust für die Engine deutet an, dass es um Robustheit und Performance bei großen Session-Dateien geht, nicht um ein Wochenende-Script.

Felix Hartmann: In der Diskussion wird natürlich gefragt: Setzt sich Sitzungs-Portabilität überhaupt durch? Oder sperren sich die Anbieter bewusst dagegen, weil die Session gerade der Lock-in ist? Es gibt da keine Einigkeit. Die eine Seite sagt, das wird so selbstverständlich wie Git-Repositories: Ein offenes Format, das jeder Agent lesen kann. Die andere sagt, die Anbieter haben wenig Anreiz, ihr wertvollstes Asset – den Kontext – austauschbar zu machen.

Lena Vogel: Und dann gibt es noch die technische Skepsis: Wie viel Wert hat eine Session überhaupt, wenn sie den Kontext wechselt? Ein Tool-Call in Agent A ist vielleicht nicht eins zu eins in Agent B abbildbar, weil die Tools anders heißen oder anders funktionieren. Die Portierung ist nicht Kopieren, sondern Übersetzung – und Übersetzung kann Information verlieren. Das ist eine ehrliche Unbekannte.

Felix Hartmann: Bleiben wir bei Sprachen und Tooling, denn da gibt es eine Geschichte, die in den Diskussionen emotional aufgeladen war: Bend 2. Eine Sprache mit Lean-artigen Beweisen, also formal verifizierten Eigenschaften. Das Herzstück: ein LAWS.bend-Block, der AI-Bugs blockt – man beweist also Eigenschaften des Codes, statt nur Tests zu schreiben. Dazu C-Speed und GPU-Parallelität. Klingt fantastisch.

Lena Vogel: Klingt fantastisch – und genau deshalb gab es Ärger. Das Repository wurde auf genau einen Commit gesquasht. Und das löste Transparenz-Kritik aus. Die Frage der Kommentatoren: Wenn ihr formal verifizierte Software mit Beweisen anpreist, warum ist dann die Historie des Repositories unlesbar? Gerade bei einer Sprache, deren ganzes Verkaufsargument Vertrauen und Nachprüfbarkeit ist, ist ein unlesbarer Verlauf ein echtes Glaubwürdigkeitsproblem.

Felix Hartmann: Das ist ein guter Punkt, den man festhalten sollte: Es geht hier nicht um Böswilligkeit, sondern um Inkonsistenz. Man kann nicht für Beweisbarkeit werben und gleichzeitig die Auditierbarkeit der eigenen Entwicklung zerstören. Die Diskussion unterscheidet hier vermutlich zwischen „Technik interessant“ und „Verhalten der Macher merkwürdig“ – beides kann gleichzeitig stimmen.

Lena Vogel: Und die technische Substanz ist es ja auch wert, ernst genommen zu werden: Verifikation direkt in der Sprache, die Kompilierung auf C-Geschwindigkeit und GPU-Parallelität kombiniert. Wenn das hält, wäre das eine echte Antwort auf die Frage von vorhin – welche Primitives braucht man für Code, dem man vertrauen kann. Ein bewiesener Codeblock ist ein sehr starkes Primitive.

Felix Hartmann: Und wenn wir schon bei Modellen sprechen, die mehr mit weniger schaffen: PrismML hat Ternary Bonsai 2 27B veröffentlicht. Ternäre Gewichte – also drei statt 32-Bit-Werte – ein Modell, das mit nur 5,9 Gigabyte auf die Platte passt, 98,2 Prozent der Benchmarks von Qwen3.8-27B erreicht, 262K Kontext hat und unter Apache 2.0 steht.

Lena Vogel: Das ist wieder unser Thema: Weniger ist mehr. Man opfert Präzision in den Gewichten – drei Stattwörter statt Gleitkommazahlen – und gewinnt dafür einen Bruchteil an Speicherbedarf. 5,9 GB für ein 27B-Modell heißt, das läuft auf Hardware, auf der sonst höchstens ein 7B-Modell Platz hätte. Für die Diskussion heißt das: Der Deal ist, dass man Benchmarks nahezu hält und die Hardware-Anforderung massiv senkt.

Felix Hartmann: Und die Apache-2.0-Lizenz macht es zum Beispiel für lokale Setups interessant. Die offene Frage, die die Kommentatoren natürlich stellen werden: Wie sieht es mit den schwachen Stellen aus – Quantisierung kostet oft bei langen Ketten von Reasoning oder bei Randfällen der Sprachverständnis. 98,2 Prozent ist ein Durchschnitt, keine Garantie für jede Aufgabe. Aber der Zustand „nahezu gleich gut, ein Fünftel der Größe“ ist ein echtes Angebot.

Lena Vogel: Lassen Sie uns nun von Sprachen und Modellen zur Forschung kommen – und da gibt es eine Arbeit, die die Grundannahme „Modelle haben feste Gewichte“ hinterfragt. arXiv 2609.18842: Ein Infinite-Parameter-LLM, bei dem ein Hypernetwork die Gewichte live aus Interaktionsdaten erzeugt. Statt fester Gewichte gibt es ein Bayesian Online-Update.

Felix Hartmann: Das ist konzeptuell ein großer Sprung. Bisher: Man trainiert, dann friert man ein. Hier: Die Gewichte sind selbst das Ergebnis eines laufenden Updates aus den Interaktionen, die das Modell erlebt. Das Modell wird nie „fertig“. Bayesian heißt dabei: Es gibt nicht ein Gewicht, sondern eine Verteilung über Gewichte, die mit jedem neuen Datum nachgeschart wird.

Lena Vogel: In der Diskussion wird man zweierlei lesen: Begeisterung über die Eleganz – kein Fine-Tuning-Zyklus mehr, das Modell lernt kontinuierlich – und nüchterne Fragen: Wie skalierbar ist das? Bayesian Online-Updates bei Milliaraden-Parametern, wie teuer ist das pro Interaktion? Und wie verhindert man Drift, also dass das Modell durch unrepresentative Interaktionsströme langsam kippt? Das sind die Fragen, die derzeit ungelöst sind.

Felix Hartmann: Ein verwandtes Thema, auch in der Wissenschaft: Timothy Gowers, Fields-Medaillist, hat erklärt, warum er den Brief der Mathematiker gegen massenproduzierte LLM-Beweise nicht unterschrieben hat – obwohl er die Krise, die der Brief beschreibt, durchaus für real hält.

Lena Vogel: Das ist ein differenzierter Standpunkt, und die Diskussion lebt genau von dieser Differenz. Er sagt im Kern: Ja, die Flut automatisierter Beweise ist ein reales Problem für Begutachtung und Wert der mathematischen Literatur. Aber die konkrete Form des Briefes oder die Konsequenzen, die er fordert, überzeugen ihn nicht. Er unterschreibt also gegen das Problem, aber nicht für die Lösung.

Felix Hartmann: Das ist die Art von Zustimmung mit Vorbehalt, die man im Podcast schätzen sollte. Es ist ein Beispiel dafür, dass man eine Krise anerkennen und trotzdem ein bestimmtes Rezept ablehnen kann. Und es macht die Frage offener: Was wäre denn die richtige Antwort auf massenproduzierte LLM-Beweise? Bessere Begutachtungsprozesse? Andere Publikationsformate? Gowers liefert darauf in dem Text offenbar keine fertige Antwort.

Lena Vogel: Bleiben wir in der Forschung, aber wechseln in die Praxis: Der Economist berichtet, dass KI jetzt einige der besten menschlichen Prognostiker schlägt – also Leute, die als Superforecaster bekannt sind, die über Jahre demonstriert haben, dass sie politische und geopolitische Ereignisse besser vorhersagen als Average oder als Algorithmen.

Felix Hartmann: Und hier ist die HN-Diskussion bemerkenswert zurückhaltend. Erstens ist der Artikel paywalled, was den Zugang einschränkt. Zweitens zweifeln Kommentatoren an der Neuheit: Es gab schon früher Ergebnisse, die in diese Richtung deuteten – Modelle, die in Forecasting-Turnieren mit menschlichen Superforecastern mithalten konnten. Die Frage ist also eher „ist das jetzt endgültig bewiesen“ als „ist das überhaupt plausibel“.

Lena Vogel: Und drittens steckt in den Kommentaren die übliche methodische Vorsicht: Prognose-Turniere haben begrenzte Frageanzahl, begrenzte Zeithorizonte, und „einige der besten“ ist ein sehr weicher Ausdruck. Es ist kein „alle“, es ist kein „besser als jeder einzelne“. Wie belastbar so ein Ergebnis über die Turnier-Situation hinaus ist – das ist die eigentliche offene Frage.

Felix Hartmann: Und das führt uns perfekt zum nächsten Thema, denn es ist wieder ein Benchmark-Sieg, der die Frage aufwirft: Wie belastbar sind solche Siege? OpenAI hat Astra for Law veröffentlicht: GPT-6 Astra plus ein legaler Suchindex mit 230 Millionen URLs. Auf dem Vals-AI-Legal-Research-Benchmark erreicht es 54,0 Prozent, gegenüber 38,7 Prozent – also ein deutlicher Abstand.

Lena Vogel: Die Kombination ist hier das Interessante: Es ist nicht nur das Modell, sondern Modell plus Suchindex. Das ist wieder Architektur statt Rohmodell – passt zu unserem Thema vom Anfang. Der Suchindex über 230 Millionen URLs ist offenbar der entscheidende Hebel für Legal Research, weil Jurisprudenz abhängt von korrekten Zitaten und aktuellen Urteilen, nicht nur von Sprachverständnis.

Felix Hartmann: Die Diskussion wird natürlich fragen: Was misst der Vals-Benchmark genau? Ist es Retrieval-Fähigkeit, juristisches Denken, oder eine Mischung? Und wer sind die 38,7 Prozent – andere Modelle, Menschen, andere Systeme? Ohne diese Kontexte ist die 15-Prozent-Differenz schwer einzuordnen. Der generelle Konflikt in den Kommentaren ist der altbekannte: Benchmarks beweisen Leistung auf dem Benchmark, nicht notwendigerweise im Gerichtssaal oder in der Kanzlei.

Lena Vogel: Das ist die Frage, die am Ende dieses Themenblocks offen bleibt: Wie belastbar sind Benchmark-Siege wirklich? Und die ehrliche Antwort der Diskussion lautet: Sie sind ein Signal, kein Beweis. Genau wie in der Mathematik – ein Benchmark ist kein formal verifizierter Beweis der Behauptung „dieses Modell ist gut“.

Felix Hartmann: Perfekte Überleitung zur Sicherheit, denn dort geht es um das Gegenteil von Beweisbarkeit: um das, was schiefgeht, wenn Systeme kompromittiert werden. CrowdSec hat bestätigt, dass es im Mai 2026 einen Quellcode-Leak gab. Der wahrscheinliche Vektor war eine Tanstack-Kompromittierung – also vermutlich über die Lieferkette, über eine Abhängigkeit oder über eine Plattform, die CrowdSec nutzt.

Lena Vogel: Die gute Nachricht: Es gab keine Kundendaten, und die Tokens wurden rotiert. Die unbequeme Nachricht: Der Quellcode ist draußen. In der Diskussion wird das differenziert bewertet: Open-Source-Code ist ohnehin öffentlich, also ist ein Leak kein gleichermaßen katastrophales Ereignis wie bei closed source. Aber es enthüllt möglicherweise interne Details – Infrastruktur, private Repos, Kommentare – die einem Angreifer nützen können.

Felix Hartmann: Und die Lieferketten-Frage ist die zentrale. Tanstack-Kompromiss heißt: Nicht CrowdSec selbst wurde direkt angegriffen, sondern etwas in der Kette um CrowdSec herum. Das ist das Muster, das die ganze Diskussion prägt: Du bist so sicher wie die schwächste Abhängigkeit. Und mit Agenten, die massenhaft Code lesen, wird das Problem größer, nicht kleiner.

Lena Vogel: Das bringt uns zu einer übergreifenden Kritik aus der netmeister-Community: Ein Essay stellt fest, dass der eigentliche Engpass der Sicherheit nicht das Finden von Vulnerabilities ist, sondern das Patchen. Wir haben übermäßige Aufmerksamkeit auf Vulnerability-Finding – und das ist genau das, was LLMs gut können. Wir haben zu wenig Aufmerksamkeit auf das, was danach kommt: Die Organisation muss den Fix einspielen, testen, deployen.

Felix Hartmann: Das ist eine gesunde Korrektur der Debatte. Die Hype-Version lautet: KI findet alle Bugs, dann sind wir sicher. Die Essay-Version lautet: Selbst wenn KI jeden Bug findet, nutzt das nichts, wenn die Bugs nicht gepatcht werden. Und Patchen ist ein Organisationsproblem, ein Budget-Problem, ein Legacy-Problem. Kein Modell kann für dich das Legacy-Monolith-Upgrade durchziehen.

Lena Vogel: Und weil wir gerade bei Agenten und Sicherheit sind: Cloudflare hat eine security-audit-skill veröffentlicht – eine Coding-Agent-Skill, die mehrphasige Security-Audits durchführt und verifizierte, maschinenlesbare Funde ausgibt.

Felix Hartmann: Das ist interessant, weil es direkt zwei vorherige Punkte verbindet. Erstens: Primitives für Agenten-Arbeit. Eine Skill ist genau so ein Primitive – ein standardisierter Baustein, den man einem Agenten geben kann. Zweitens: Das „verifiziert und maschinenlesbar“ adressiert das netmeister-Problem. Ein Fund, der maschinenlesbar ist, kann direkt in einen Patch-Workflow fließen. Es verbindet Finden und Patchen, statt nur zu melden.

Lena Vogel: Die offene Frage, die die Diskussion hier stellt: Wie secure bleiben Lieferketten, wenn Agenten massenhaft Code lesen? Agenten, die fremden Code in Kontexte laden, vergrößern die Angriffsfläche für prompt injection über Code-Kommentare, über Readmes, über Commit-Nachrichten. Das ist noch ein junges Problemfeld, und die security-audit-skill ist ein Baustein der Antwort, aber nicht die ganze Antwort.

Felix Hartmann: Und mit Rate-Limits haben wir noch ein weiteres Stück der gleichen Geschichte: GitLab.com richtet seine Rate-Limits ab dem 19. Oktober 2026 nach Abo aus. Anonyme Nutzer bekommen 60 Requests pro Stunde. Der Grund ist laut der Diskussion vermutlich LLM-Scraping.

Lena Vogel: Das ist eine indirekte Folge der Agenten-Ära: Aufwändige automatisierte Zugriffe nehmen zu, weil Modelle und Agentenillionen von Requests erzeugen, um Daten zu holen. Die Plattformen reagieren mit Limits, die Nutzer nach Zahlungsfähigkeit unterscheiden. Die Diskussion fragt: Ist das eine gesunde Priorisierung oder schadet es Open Source, wo anonyme Zugriffe oft legitim sind – CI-Skripte, Tools, erste Experimente?

Felix Hartmann: Es ist wieder eine offene Frage ohne einfache Antwort. 60 Requests pro Stunde sind für einen Menschen großzügig, für einen Agenten fast nichts. Die Grenze zwischen „missbräuchliches Scraping“ und „legitime Automatisierung“ ist unscharf, und Rate-Limits sind ein grobes Instrument, um sie zu ziehen.

Lena Vogel: Lassen Sie uns zum Abschlussblock kommen, der sich eher mit Base-Layer-Infrastruktur beschäftigt – also mit Dingen, die man braucht, wenn man weniger bauen will. Flet 1.0: Cross-Platform-Apps für sechs Plattformen in reinem Python, mit über 150 Controls, basierend auf Flutter, Web via Pyodide und WASM.

Felix Hartmann: Das ist eine radikale Reduktion der Menge an Zeug, das man lernen muss, um eine App auf Mobile, Desktop und Web zu bringen. Ein Sprach-Stack, ein Framework, sechs Plattformen. Die Diskussion fragt natürlich: Was kostet diese Abstraktion? Für Leichtgewichtige Apps sicher attraktiv, für Performance-kritische oder tief integrierte Apps wohl nicht. Aber die Richtung – weniger Layer – passt exakt zu unserem Thema vom Anfang.

Lena Vogel: Und in die gleiche Kategorie gehört Vinix: Ein modernes Betriebssystem in V, das mit 100 MB RAM und 1 GB Disk auskommt, M1-Support hat und Alpine-Linux-Binaries nativ laufen lässt, ohne VM oder Emulation.

Felix Hartmann: Das ist bemerkenswert. Ein OS, das keine Emulation oder Virtualisierung braucht, um Linux-Binaries auszuführen, heißt: Es implementiert den Linux-Syscall-Interface nativ. Das ist der einzige Weg, wie man Linux-kompatibel werden kann, ohne den Kernel zu forken. Das spart enorm an Komplexität im Userspace – alle Tools von Alpine laufen einfach.

Lena Vogel: Und die Verschlankung auf 100 MB RAM und 1 GB Disk ist das Gegenteil der üblichen Entwicklung. Moderne Betriebssysteme schwellen auf Gigabytes an. Hier das Gegenteil: Minimale Requirements, die auf alten Hardware oder Embedded-Setups laufen können. Für die Diskussion ist es ein Beweis, dass Base-Layer-Software nicht automatisch fett werden muss.

Felix Hartmann: Und der dritte große Punkt dieser Kategorie: Servo. Ein Jahr gesponserte Entwicklung. Josh Bowman-Matthews hat acht neue Maintainer nominiert, 1150 Pull Requests reviewt und 92 Prozent der Neuling-Issues gefixt.

Lena Vogel: Das ist die andere Seite unseres Themas. Flet und Vinix zeigen, wie man mit weniger auskommt. Servo zeigt, wie man ein existierendes, komplexes Base-Layer-Projekt mit gezielter Finanzierung lebendig hält. 1150 PRs in einem Jahr ist ein massives Review-Volumen, und 92 Prozent der Neuling-Issues zu fixen heißt, dass Menschen, die zum ersten Mal beitragen, nicht hängen bleiben. Das ist der Kontrast zum Squash-Repo von Bend 2: Hier sieht man, wie Transparenz im Open-Source-Workflow funktioniert.

Felix Hartmann: Die offene Frage der Diskussion: Halten solche Base-Layer-Projekte den Alltagsstress langfristig? Servo beweist, dass Sponsoring funktioniert, wenn jemand die Koordination übernimmt. Aber es ist eine fragile Abhängigkeit von einzelnen Sponsoren. Vinix und Flet sind noch klein genug, dass einzelne Maintainer sie tragen können. Wie nachhaltig jedes dieser Modelle ist – das ist die ehrliche Unbekannte.

Lena Vogel: Und ein paar kürzere Storys von heute, die in diesen Block passen: Manticore Search hat eingebautes Auto-Chunking bei INSERT, mit fünf Strategien. Auf dem eigenen Manual ging recall@5 von 55 auf 83 Prozent.

Felix Hartmann: Das ist ein schönes Beispiel für „Primitives in der Praxis“. Statt dass jeder Nutzer selbst überlegen muss, wie er Dokumente für Retrieval zerlegt, macht die Datenbank es automatisch beim Einfügen. Chunking ist genau so ein Primitive, das viele Leute falsch machen – und das Einbauen in die Datenbank ist die richtige Abstraktionsebene.

Lena Vogel: Hister ist eine private Suchmaschine für besuchte Seiten und eigene Dateien, mit Browser-Extension und MCP-Server, 3,8k GitHub-Stars. Auch hier wieder: MCP-Server heißt, Agenten können darauf zugreifen, was es zum Beispiel für Coding-Agenten nützlich macht, die den Kontext haben wollen, was man selbst gelesen hat. Es ist im Grunde ein Baustein für Personal Context – ein weiteres Puzzle-Teil in unserer Primitives-Frage.

Felix Hartmann: Und flat.social wurde von pawelwentpawel neu gebaut: Eine 3D-Spatial-Meeting-App im Web, mit Three.js, LiveKit und Rapier, solo bootstrapped, Demo ist live. Das ist ein interessanter Kontrast zu den großen Plattformen – eine einzelne Person baut eine räumliche Meeting-Erfahrung im Browser, ohne Download, ohne Installation. Auch das ist in gewissem Sinne „weniger ist mehr“: kein Client, keine Installation, nur der Browser.

Lena Vogel: Und noch eine Infrastruktur-Story, die in den Kontext passt: GLM hat eine Produktions-Inferenz auf über 100.000 chinesischen Beschleunigern aufgebaut. Viel der Infra-Arbeit stammt vom GLM-5.3 Infra-Agent, und der Durchsatz liegt um Faktor 3 höher.

Felix Hartmann: Das ist bemerkenswert auf mehreren Ebenen. Erstens die schiere Hardware-Zahl. Zweitens die Zusammensetzung: Ein Agent hat einen erheblichen Teil der Infra-Arbeit gemacht. Das ist ein direktes Beispiel für das, was wir am Anfang besprochen haben – Agenten, die in komplexen Systemen arbeiten. Und es ist ein Beweis, dass es funktioniert: Faktor 3 Durchsatz ist keine Kleinigkeit.

Lena Vogel: Und damit sind wir bei unserem letzten Block, Am Rande: Centenarians und Self-Storage. Japan zählt erstmals über 100.000 Centenarians – 107.677 Menschen, 88 Prozent davon Frauen.

Felix Hartmann: Und dann kommt die unangenehme Wahrheit, die die Diskussion sure nicht übergangen hat: Ein Audit aus 2010 fand 230.000 ungeklärte registrierte Personen über 100. Das heißt, das Register war damals massiv überzählt – Menschen, die vermutlich längst gestorben waren, aber offiziell noch lebten. Das ist eine Erinnerung daran, dass Register gepflegt werden müssen, und dass Demografie-Statistiken nicht selbstverständlich korrekt sind.

Lena Vogel: Die 88 Prozent Frauen sind auch ein Datenpunkt, den man in der Diskussion reflektiert hat: Das ist global konsistent mit der höheren Lebenserwartung von Frauen, aber es ist ein großer Abstand. Die offene Frage, die man aus dieser Geschichte ziehen kann: Was sagt das über Demografie aus? Aging Society, Pflege, Rentensysteme – und die Datengrundlage, auf der man solche Fragen plant, muss sauber sein, sonst plant man auf Sand.

Felix Hartmann: Und die zweite Rand-Story ist eine ganz andere Art von Zahlen: Die USA besitzen rund 90 Prozent der globalen Self-Storage-Kapazität, erwirtschaften über 40 Milliarden Dollar Jahresumsatz und haben mehr Standorte als die genannten Fastfood-Ketten.

Lena Vogel: 90 Prozent der globalen Kapazität in einem Land, das nicht 90 Prozent der Weltbevölkerung stellt. Das ist eine außergewöhnliche Konzentration. Die Frage, die die Diskussion aufwirft: Was sagt das über Konsum aus? Über die Beziehung zu Besitz, zu Wohnraum, zu Lebensstil. Self-Storage ist im Grunde die Industrialisierung des Aufschubs von Entscheidungen: Statt Dinge loszulassen, lagert man sie aus.

Felix Hartmann: Es ist ein hübscher Gegenpol zu Japan. Beide Geschichten handeln im Kern von Ansammlung: In Japan sammeln sich Menschen mit hohem Alter, in den USA sammeln sich Dinge in Lagern. Beide Trends haben etwas mit Demografie und Konsum zu tun, aber auf sehr unterschiedliche Art.

Lena Vogel: Das war der heutige Durchgang. Die großen Themen des Tages – Reduktion als Strategie, Agenten-Werkzeuge, Modellforschung, Sicherheitsrealität, Base-Layer-Infrastruktur – und am Rande zwei Geschichten über Ansammlung.

Felix Hartmann: Danke fürs Zuhören, und bis morgen.