0924 | Schnellere KI, wackeliges Vertrauen und ein Uhrwerk von 1877

Lena Vogel: Willkommen zurück beim Podcast, hier sind Lena Vogel und Felix Hartmann. Und was uns heute verbindet, ist eigentlich ein ziemlich klassisches Muster: Neue Technik verspricht großartige Dinge, und dann hängt alles davon ab, ob die Details stimmen. Ob die Infrastruktur hält, ob die Tools uns vertrauenswürdig sind, ob das Zeug einfach funktioniert.

Felix Hartmann: Genau, Lena. Wir haben heute alles dabei: KI, die plötzlich unfassbar schnell und billig wird. KI, die ein Enzymsystem entdeckt oder einen echten Toyota fährt. Und dann die Kehrseite: Schwachstellen, Updates, die Kühlschränke lahmlegen, Software, die einen beim Kündigen attackiert. Ich bin Felix Hartmann, und wir gehen die Sachen jetzt an, einer nach dem anderen, und schauen, was die Leute dazu wirklich gesagt haben.

Lena Vogel: Fangen wir mit etwas an, das in den letzten 24 Stunden ziemlich Aufsehen erregt hat. Anthropic hat claude.ai dramatisch schneller gemacht. Und nicht über Monate, sondern in zwei Wochen.

Felix Hartmann: Die Zahlen sind schon beeindruckend. Der Web-Load im 75. Perzentil, also der Wert, bei dem drei Viertel der Anfragen darunter liegen, fiel von 3,1 Sekunden auf 0,55 Sekunden. Das ist ein Faktor drei und mehr, bei einer Seite, die Leute täglich nutzen. Und das Ganze angeblich mit über 3.000 Änderungen, ohne dass dabei ein einziger Zwischenfall passiert ist.

Lena Vogel: Das ist der Punkt, bei dem die Diskussion im Thread richtig rund geht. Denn 3.000 Änderungen in zwei Wochen ohne Incidents, das hört sich für viele zuerst unglaublich an. Es gab Stimmen, die gefragt haben: Was bedeutet "ohne Zwischenfälle" überhaupt? Wie streng ist die Definition? Wenn man stundenlange Ausfälle als Incident zählt, aber 90 Sekunden lang eine halbe Million Fehleranfragen als "kein Incident", dann ist die Aussage technisch wahr und trotzdem nicht viel wert.

Lena Vogel: Andere haben das verteidigt und gesagt, genau das sei der Punkt: Man kann mit guter Feature-Flag-Arbeit, sauberem Rollout und hoher Beobachtbarkeit tatsächlich große Mengen kleiner Änderungen sicher ausrollen, solange keine einzelne Änderung groß genug ist, um richtig kaputt zu gehen.

Felix Hartmann: Und dann kam der Punkt, der mich am meisten interessiert hat. Die Dauer der Optimierung. Ein paar Personen im Thread haben darauf hingewiesen, dass so ein Sprint oft die Low Hanging Fruits abräumt. Cache-Header, blockierende Skripte, Bilder zu groß, kritischer Rendering-Pfad, das Übliche. Und die ersten paar Sekunden gewinnt man relativ einfach. Der letzte Halbsatz von 0,55 auf 0,3 Sekunden wäre wieder ein anderes Projekt.

Felix Hartmann: Aber auch hier haben andere widersprochen und gesagt, dass 3,1 Sekunden bei p75 gar nicht so aussahen wie ein einfaches Problem. Dass da jemand drei Sekunden abgebaut hat, deutet darauf hin, dass vorher nichts Grundlegendes gemacht wurde. Und unter dem Strich bleibt die Frage offen: Wie lange lässt sich so ein Tempo überhaupt durchhalten? Das hat Anthropic in dem Sinne nicht beantwortet.

Lena Vogel: Was auch nicht unumstritten war: Die Zahl 3,1 Sekunden ist schon recht hoch für eine Startseite, die nur ein Chat-Fenster mit etwas Text enthält. Es gab Stimmen, die gesagt haben, das sei eher ein Beweis, wie viel Ballast man in moderne Web-Apps einbaut. Andere wiederum haben entgegnet, dass claude.ai inzwischen auch Product-Detail-Seiten, Abrechnung, Team-Verwaltung und so weiter anbietet, also weit mehr als nur ein einfaches Chat-Fenster.

Lena Vogel: Also vieles eben wie immer im Web-Performance-Bereich: Je nach Perspektive klingt die Zahl großartig oder peinlich.

Felix Hartmann: Aber dann kommt der zweite Teil, der das Ganze so richtig interessant macht. Denn parallel dazu ist die Wirtschaftlichkeit ins Wanken geraten. Die Kosten pro Aufgabe für LLMs sind 2025 um zwei Größenordnungen gefallen.

Lena Vogel: Zwei Größenordnungen. Das ist nicht ein Preisplus, das ist der Unterschied zwischen 100 Euro und einem Euro für dieselbe Aufgabe. Und die Formulierung, die im Thread viel zitiert wurde, war: Tokens sind "zu billig zum Messen". Also so billig, dass es sich für viele Anwendungen gar nicht mehr lohnt, aufzuzeichnen, was eine einzelne Aufgabe eigentlich gekostet hat.

Felix Hartmann: Und da hat die Diskussion gezeigt, dass die Leute zwei ganz verschiedene Deutungen haben. Die eine Fraktion sagt: Das ist der Punkt, an dem KI-Produkte Alltagswerkzeuge werden. Wenn der Preis für eine einzelne Aufgabe unter dem Lärm-Schwellenwert liegt, dann designen Produkte nicht mehr um Kosten, sondern um Nutzung. Du baust Features, weil die Leute sie wollen, nicht weil du rechnest, ob sie sich lohnen.

Felix Hartmann: Das ist in anderen Bereichen ähnlich, etwa bei Suchmaschinen, wo auch niemand über die Serverkosten pro Suchanfrage nachdenkt.

Lena Vogel: Die andere Fraktion ist deutlich skeptischer. Sie sagen: Zu billig zum Messen ist ein zwiespältiger Spruch. Erstens, weil sich das schnell umdrehen kann, wenn ein neues Modell teurer ist, oder wenn die Kosten für Training, Kühlung oder Strom einfach nicht mehr sinken. Zweitens, weil "zu billig zum Messen" bei manchen Anbietern eher heißt: Wir laden es auf ein Abo oder die Konkurrenz später drauf.

Lena Vogel: Und drittens, weil die Kosten pro Aufgabe natürlich stark davon abhängt, welche Aufgabe man betrachtet. Eine kurze Klassifikation ist billig, eine lange Analyse mit mehreren Durchgängen ist es nicht.

Felix Hartmann: Und das bringt uns zu einem interessanten Zuspitzungspunkt, den jemand im Thread gebracht hat. Es gab eine kleine Parodie-Projekt: Jevons-Paradoxon, quasi der Klassiker der Effizienz-Debatte, in 25 Zeilen Python nachgebaut, mit einem kleinen lokalen Modell, Qwen3-0.6B, das Aufgaben anhand von Logits klassifiziert. Das war eine selbstironische Anspielung auf die Effizienz-Debatte.

Felix Hartmann: Und die Kritik im Thread war ziemlich einheitlich: Das Projekt hat zwar charmant die Diskussion über Effizienz mitgespielt, aber natürlich fehlen darin Latenzangaben, Fehlerraten und, was am wichtigsten ist, ein Vergleich des Rechenbedarfs, also was bei einem kleinen lokalen Modell und einem großen Cloud-Modell tatsächlich an Energie und Rechenleistung anfällt.

Lena Vogel: Also im Grunde ein Projekt, das zeigt, wie einfach es geworden ist, so eine Demo zu bauen, und gleichzeitig zeigt, wie viel Aussagekraft so ein 25-Zeilen-Demo weglassen kann.

Felix Hartmann: Genau. Aber zusammenfassend für den ersten Block: KI wird schneller und billiger, so viel steht fest. Ob das zu Alltagsprodukten führt oder ob sich das Tempo wieder verlangsamt und die Kosten wieder steigen, das ist die offene Frage. Und ein Punkt, den viele im Thread betont haben: Beides zusammen, Geschwindigkeit und Preis, das ändert nicht nur Produkte, sondern die Erwartungen der Nutzer. Wenn claude.

Felix Hartmann: ai plötzlich in einer halben Sekunde lädt, dann ist jede andere KI-Seite, die zwei Sekunden braucht, subjektiv langsam. Und wenn eine Aufgabe einmal einen Cent kostet, fragt keiner mehr nach, ob der Rechnungs-E-Mail-Autocomplete teuer war. Das ist der eigentliche Kultureffekt, der die Diskussion beherrscht hat.

Lena Vogel: Okay. Kommen wir zum zweiten Block, und der passt nahtlos an den ersten an. Denn wenn KI billiger und schneller wird, dann können mehr Sachen ausprobiert werden. Und hier gab es zwei Meldungen, die zeigen, wie weit das Feld auseinanderklafft. Einmal die wissenschaftliche Entdeckung, einmal die Fahrpraxis.

Felix Hartmann: Fangen wir mit dem an, was für viele im Thread der aufregendere Teil war. Claude hat, so die Darstellung, nach 21 Stunden und rund 950 Agenten ein neues Enzymsystem identifiziert. Die Bezeichnung im Thread war ART. Es handelt sich um eine Reverse-Transkriptase eines Phagen, also eines Virus, das Bakterien infiziert. Und das besondere daran: Diese Reverse-Transkriptase hat DNA-Wiederholungen, die an CRISPR erinnern.

Lena Vogel: Das ist, wenn es hält, ein echter Fund. Reverse-Transkriptasen sind schon lange bekannt, sie schreiben RNA in DNA um. Aber die Verbindung mit CRISPR-artigen Strukturen in einem Phagen ist, so wurde es im Thread dargestellt, ein System, das vorher nicht beschrieben war. Und die Leute haben sich zwei Fragen gestellt. Die erste: Wie viel davon ist echte Entdeckung und wie viel ist Mustererkennung?

Lena Vogel: Also: Hat das Modell eine echte Hypothese gebildet, die dann experimentell bestätigt wurde, oder hat es in einer großen Datenbank ein Muster gefunden, das ein Mensch mit genug Zeit auch gefunden hätte?

Felix Hartmann: Die Antwort darauf ist im Thread nicht ganz eindeutig geworden. Es gab Stimmen, die gesagt haben, der Punkt ist nicht die Entdeckung selbst, sondern der Prozess. Rund 950 Agenten, die 21 Stunden lang arbeiten, das ist ein Workflow, der vorher so schlicht nicht möglich war, weil er zu teuer und zu langsam gewesen wäre. Also genau die Verbindung zum ersten Block. Und die zweite Frage, die gestellt wurde: Was passiert danach?

Felix Hartmann: Wenn ein KI-System so ein Enzymsystem findet, dann folgt der aufwendige Teil: experimentelle Validierung, Strukturaufklärung, wie funktioniert das Ding eigentlich. Und da ist die KI raus, oder zumindest deutlich weniger nützlich.

Lena Vogel: Der Punkt, den wir uns merken sollten: KI als Forschungswerkzeug, nicht als Forschungsersatz. Das war die Mehrheitstendenz im Thread, auch wenn die Formulierungen variiert haben.

Felix Hartmann: Und der Gegenpol dazu. DrivingBench. Das ist ein Benchmark, bei dem Modelle in der realen Welt fahren. Und dort gab es einen überaus eindrucksvollen Durchlauf: GPT-6 Astra hat angeblich 100 Prozent des Circuits geschafft, in 5 Minuten 22 Sekunden, in einem echten Toyota.

Lena Vogel: Und das ist nicht irgendein Ghost-Fahrer auf einem Testgelände, sondern wirklich ein Auto. Und zum Vergleich: Claude Fable 5.1 hat nur 45 Prozent des Circuits geschafft. Das ist eine riesige Lücke. Und im Thread war das genau der Punkt, der die Leute gespalten hat. Denn was sagt uns das über die Straße? Benchmarks sind kontrolliert. Ein Circuit ist vorhersagbar, die Umgebungsbedingungen sind ähnlich, man kennt die Strecke.

Lena Vogel: Und der Transfer zur normalen Straße mit Radfahrern, Baustellen, Verkehr, ungeordneten Situationen, das ist etwas völlig anderes.

Felix Hartmann: Und da kam die Kritik von verschiedenen Personen. Einige haben gesagt, ein Benchmark, der ein Modell in einem echten Toyota fahren lässt, ist trotzdem ein Benchmark, kein Alltag. Andere haben gesagt, dass die Differenz zwischen den Modellen, also 100 Prozent gegenüber 45 Prozent, ein viel ehrlicheres Bild zeigt als die Marketing-Sprüche, wo alle Modelle gleich gut seien.

Felix Hartmann: Also selbst wenn der Benchmark nicht die reale Straße abbildet, zeigt er, dass in der realen Welt die Modelle unterschiedlich gut sind. Die offene Frage aus dem Thread: Wie übertragbar sind die Ergebnisse? Und die Antwort, die der Thread nicht wirklich geliefert hat, ist die sichere Antwort: Man weiß es nicht.

Lena Vogel: Was den zwei-Stunden-Block zusammenfasst: KI kann heute wirklich anspruchsvolle Aufgaben anfassen, von der Entdeckung eines Enzymsystems bis zum autonomen Fahren eines echten Autos. Aber der Weg von einer beeindruckenden Zahl im Benchmark zu einer Entdeckung, die in der Praxis Bestand hat, oder zu einer Fahrpraxis, die sicher im Straßenverkehr funktioniert, ist lang und noch nicht abgeschlossen.

Felix Hartmann: Genau. Und jetzt machen wir einen Sprung zu etwas, das nahtlos anschließt, weil es um genau das Gegenteil geht. Um Tools, denen man eigentlich vertrauen sollte, und die dieses Vertrauen auf unangenehme Art enttäuscht haben. Zunächst die Radicle-Schwachstelle.

Lena Vogel: Radicle ist, kurz für die Hörer, ein dezentrales System für Code-Repositories. Und die Schwachstelle, die gemeldet wurde, ist schwerwiegend: Der Traffic lief unverschlüsselt und unauthentifiziert. Also nichts davon, was man bei so einem System erwartet. Und die Empfehlung, die im Thread weitergegeben wurde, war ziemlich klar: Wer private Repositories nutzt, sollte das bis zum Patch sein lassen.

Felix Hartmann: Und die Diskussion im Thread ging genau in zwei Richtungen. Die eine Richtung: Das ist ein klassischer Versäumnis-Fehler. Wenn du ein System baust, das Repositories verwaltet, die als "privat" gekennzeichnet sind, und dann ist der Traffic unverschlüsselt, dann hast du ein Versprechen gegeben und nicht eingehalten. Das verdient harte Kritik, und die Patch-Priorität muss entsprechend hoch sein. Die zweite Richtung war sachlicher: Das Problem ist vermutlich historisch gewachsen.

Felix Hartmann: Das System war anfangs für öffentliche Repos gedacht, private Repos sind ein späteres Feature, und da ist das Versprechen der Verschlüsselung nicht hinterhergezogen worden. Das entschuldigt nichts, aber es erklärt, wie so etwas entstehen kann.

Lena Vogel: Was auch im Thread offen blieb: Wer war genau betroffen, wie lange schon, und wie schnell kommt der Patch? Der Thread hat das, soweit wir das zusammengefasst haben, nicht geliefert. Und so bleibt das eine offene Frage, die man verfolgen sollte.

Felix Hartmann: Und der zweite Fall in diesem Block, der sich fast wie eine Pointe anhört. Claude Code liest die Datei AGENTS.md offenbar nur, wenn die Telemetrie aktiv ist. Also wenn man dem Tool erlaubt, Daten zurückzumelden, dann liest es die Konfigurationsdatei. Wenn man Telemetrie deaktiviert, tut es das nicht. Und das Laden hängt an einem Remote-Feature-Flag. Ohne Warnung, ohne Erklärung.

Lena Vogel: Und das ist, finde ich, der Teil, der im Thread die stärkste Resonanz hatte, weil es so gut zeigt, wie sich das Verhalten von Entwickler-Tools still ändern kann. Du als Nutzer hast keine Ahnung, ob dein Setup gerade noch funktioniert, oder ob ein Feature-Flag irgendwo im Rechenzentrum von Anthropic umgeschaltet wurde und plötzlich verhält sich dein lokales Tool anders. Der Workaround, der im Thread kursierte: CLAUDE.md anlegen, und darin @AGENTS.md referenzieren.

Lena Vogel: Also den einen Dateinamen über einen Verweis in die andere hineinziehen. Funktioniert, aber es ist natürlich ein Workaround, kein Fix.

Felix Hartmann: Und die Lehre, die verschiedene Leute gezogen haben: Bei lokalen Tools, die Konfigurationsdateien lesen, sollte man erwarten können, dass das Verhalten lokal deterministisch ist. Wenn eine Datei gelesen wird oder nicht, darf nicht davon abhängen, ob ein Feature-Flag aktiviert ist. Und wenn es davon abhängt, dann muss es explizit dokumentiert sein. Beide Fälle, Radicle und Claude Code, haben das gemeinsam: Das Verhalten ändert sich still, und der Nutzer merkt es erst, wenn es zu spät ist.

Felix Hartmann: Die offenen Fragen sind in beiden Fällen Transparenz und Patch-Geschwindigkeit.

Lena Vogel: Und das bringt uns nahtlos in den nächsten Block. Denn was wir gerade besprochen haben, ist Entwickler-Software. Aber die gleichen Vertrauensprobleme gibt es natürlich im Consumer-Bereich, und da sind sie teilweise noch unangenehmer, weil die Nutzer nicht technisch versiert sind.

Felix Hartmann: Genau. Und der erste Fall ist einer, der im Thread ehrlich gesagt ziemlich viel Empörung produziert hat. Grammarly. Die Firma wurde gekündigt, also ein Unternehmen hat seine Vertrag mit Grammarly beendet. Und in Folge hat Grammarly unaufgeforderte E-Mails und Popups an alle Nutzer mit Lizenz verschickt, um gegen die Kündigung zu drücken. Also nicht ein Marketing-Blitz, sondern eine gezielte Retention-Kampagne, die über die Köpfe der Nutzer hinweg gegen die Entscheider der Firma gerichtet war.

Lena Vogel: Und das ist, so die Mehrheit im Thread, mehr als nur nervig. Das ist aggressives Retention-Design. Du als Mitarbeiter einer Firma, die gekündigt hat, kriegst plötzlich Mails und Popups, die dich auffordern, etwas zu tun, oder die dir zeigen, wie sehr du das Produkt vermissen wirst. Das ist nicht Nutzer-freundlich, das ist Nutzer-als-Geisel. Und die Frage, die im Thread diskutiert wurde: Was ist da rechtlich? Dürfen die das?

Lena Vogel: Wurden die Nutzer darüber informiert, dass ihre Mail-Adressen für so eine Kampagne verwendet werden? Das blieb, soweit wir es verstanden haben, offen.

Felix Hartmann: Und dann der zweite Fall, der in die gleiche Richtung geht, aber anders endet. Samsung hat in Korea ein SmartThings-Update gestoppt. Der Grund: intelligente Kühlschränke sind dadurch blockiert worden, Lebensmittel sind verloren gegangen. Und, das ist der Teil, der die Diskussion richtig angestoßen hat: Die Panne ist während der Tests passiert.

Lena Vogel: Das ist der entscheidende Punkt. Die Tests haben den Fehler nicht abgefangen, sondern sie haben ihn verursacht. Es war kein Bug im Code, der in der Produktion plötzlich auftauchte. Es war die Testumgebung selbst, die die Geräte blockiert hat. Und deshalb sind die Fragen im Thread auch anders als bei Grammarly. Bei Grammarly ist die Frage: Was dürfen Hersteller? Bei Samsung ist die Frage: Was ist der Prozess, der so etwas zulässt?

Lena Vogel: Und wie stellen wir sicher, dass ein Update, das Kühlschränke lahmlegt, nicht in Produktion geht?

Felix Hartmann: Und der gemeinsame Nenner beider Fälle, so wie ihn verschiedene Leute formuliert haben: Vernetzte Geräte sind von den Herstellern abhängig. Dein Kühlschrank ist von Samsungs Update-Pipeline abhängig. Deine Grammarly-Erfahrung ist von Grammarlys Entscheidung abhängig, ob sie eine Kampagne fährt. Du hast als Nutzer in beiden Fällen wenig Kontrolle. Das ist der Kern der Kritik.

Lena Vogel: Und genau da kommt die Regulierung ins Spiel, denn es gab eine Meldung aus Seattle, die im Thread als ein Beispiel diskutiert wurde, wie man solchen Problemen mit Gesetzen begegnet. Seattle hat die Preisfixierung durch Überwachung im Lebensmittelhandel verboten. Also es ist Supermärkten verboten, individualisierte Preise zu setzen, weil sie jemanden überwacht haben.

Felix Hartmann: Und die Diskussion dazu im Thread war unter anderem, ob das ein sinnvolles Modell für andere Städte ist. Einige haben gesagt, das ist genau richtig, weil die Überwachung im Supermarkt durch Kameras und Loyalitätskarten schon Realität ist, und individuelle Preise für Lebensmittel, also Basisversorgung, sind ein anderer Fall als individuelle Preise für Flugtickets. Andere haben gesagt, das könnte die Preisgestaltung insgesamt erschweren und für Verbraucher teurer werden.

Felix Hartmann: Also ein klassischer Regulierungswiderstreit, der so noch nicht entschieden ist.

Lena Vogel: Was wir aus dem Block mitnehmen: Vertrauen ist auch im Consumer-Bereich knapp. Grammarly und Samsung zeigen es, und Seattle zeigt, dass Regulatoren anfangen zu reagieren. Aber ob so ein Ansatz funktioniert, ist offen.

Felix Hartmann: Und von Consumer-Software gehen wir jetzt zur Infrastruktur, die das ganze Zeug eigentlich tragen soll. Und hier gab es zwei Meldungen, die im Thread deutlich entspannter aufgenommen wurden, fast freundlich, weil es um Grundlagenarbeit geht, die seit Jahren gewünscht wurde. Die erste: Cloudflare hat Vary-Support in Cache Rules für alle Pläne eingeführt.

Lena Vogel: Für alle, die das nicht täglich im Kopf haben: Der Vary-Header sagt dem Cache, dass eine Antwort je nach Wert eines bestimmten Request-Headers unterschiedlich ausfallen kann. Zum Beispiel ein Accept-Encoding-Header oder ein Cookie. Und bis jetzt war der Support für Vary in Cloudflares Cache Rules begrenzt. Jetzt ist er für alle Pläne da, und man kann drei Dinge machen: Werte normalisieren, also Groß-/Kleinschreibung oder Whitespace glätten, Werte exakt durchreichen, oder den Cache ganz umgehen.

Lena Vogel: Das ist, wenn man tatsächlich Antworten hat, die je nach Header variieren, endlich sauberes Caching.

Felix Hartmann: Und die Diskussion im Thread hat gezeigt, dass das ein Problem ist, das viele seit Jahren ärgert. Das klassische Beispiel war: Du hast eine Seite, die je nach Accept-Language-Header verschiedene Sprachen ausliefert. Ohne sauberen Vary-Support konnte der Cache einer Person die deutsche Seite zeigen und einer anderen Person die englische. Oder du musst den Cache komplett deaktivieren, was die Performance kaputt macht.

Felix Hartmann: Und mit dem neuen Support kannst du jetzt sagen: Beachte diesen Header, normalisiere ihn aber, weil "en" und "EN" das gleiche sind. Oder: Reiche den Header exakt durch, weil der Wert wirklich relevant ist. Das ist, wenn man Infrastruktur-Arbeit macht, ein echter Fortschritt.

Lena Vogel: Und das wurde im Thread auch so wahrgenommen. Einige haben die neuen Funktionen direkt ausprobiert und berichtet, dass es funktioniert. Andere haben kritisiert, dass es so lange gedauert hat. Es gab auch die Frage, ob das für alle Pläne gilt, also auch für den Free-Plan, was ja gerade für kleine Seiten wichtig wäre, und die Antwort, soweit wir sie verstehen, war: ja, für alle Pläne.

Felix Hartmann: Der zweite Fall in diesem Block: Tailscale hat die Performance verbessert. Die Technik dahinter, so die Darstellung: Kleine Pakete werden dort verarbeitet, wo sie ankommen, ohne dass sie vorher in große 64-KiB-Puffer kopiert werden. Das Ergebnis: rund 5 Prozent schneller auf Linux und Android.

Lena Vogel: Und im Thread war interessant, dass die Leute gar nicht so sehr über die 5 Prozent diskutiert haben, sondern über das Prinzip. Ein paar Prozent klingen wie nichts, aber bei einem VPN, das quasi alles Verkehr über die Netzwerkkarte schickt, addiert sich das.

Lena Vogel: Und mehr noch: Die Kopiererei in große Puffer ist ein klassisches Leistungsproblem, das man seit Jahrzehnten kennt, und dass das jetzt bei einem verbreiteten VPN-Tool angegangen wird, wurde als solide, unaufgeregte Infrastruktur-Arbeit gewürdigt. Kein Hype, kein Benchmark-Sprengstoff, einfach eine Verbesserung am Rand des Netzwerks, wo sie zählt.

Felix Hartmann: Und das ist der Punkt, den wir aus dem Block mitnehmen: Nicht jede Verbesserung ist spektakulär, aber die Spektakulär-Innovationen sitzen am Ende auf genau solchen Grundlagen. Ohne sauberes Caching und ohne schnelle Netzwerkpfade funktionieren die coolen KI-Demos aus dem ersten Block schlicht nicht.

Lena Vogel: Und das führt uns gut in den nächsten Block. Denn wenn wir über Grundlagen und Werkzeuge sprechen, dann landen wir schnell beim Linux-Desktop und der Remote-Entwicklung. Und hier gab es eine Meldung, die durchaus polarisiert hat: Qualcomm kündigt Linux-Support für Snapdragon X2 an.

Felix Hartmann: Und die Reaktion im Thread war, vorsichtig gesagt, gemischt. Auf der einen Seite: Super, mehr Hardware-Optionen für Linux auf ARM-Laptops, das Feld braucht Wettbewerb. Auf der anderen Seite kam die Kritik, und zwar deutlich: Das Problem war noch nie, dass es nicht genug ARM-Chips gibt. Das Problem ist, wie die Chips an Linux angekoppelt werden. Und da kam die Gegenposition ins Spiel: Ampere. Ampere-Chips funktionieren mit Linux, weil sie standardmäßiges UEFI und ACPI verwenden.

Felix Hartmann: Also die gleichen Standards wie x86-Rechner. Das heißt, Linux bootet dort ohne Spezialanpassung.

Lena Vogel: Und die Forderung, die im Thread mehrfach formuliert wurde: Das wäre genug. Also Qualcomm müsste einfach UEFI und ACPI standardkonform implementieren, und Linux würde laufen. Ohne Treiber-Gefrickel, ohne distro-spezifische Patches, ohne Kernel-Optionen, die man per Hand aktivieren muss. Die Kritik war: Die Historie von Qualcomm zeigt, dass sie stattdessen lieber eigene Wege gehen, eigene Treiber, eigene Firmware-Schnittstellen, und dann müssen die Linux-Entwickler hinterherlaufen.

Lena Vogel: Und genau das wurde bemängelt. Also die Kernfrage ist nicht: Gibt es Linux-Support? Sondern: Ist der Support über offene Standards oder über proprietäre Zusatzarbeit realisiert?

Felix Hartmann: Und das ist, finde ich, der Kernpunkt des Threads: Es geht nicht darum, ob Qualcomm böse ist oder nicht. Es geht darum, dass offene Standards mehr langfristigen Wert haben als kurzfristige Zusatzarbeit von einzelnen Herstellern. Wenn ein Chip standardkonform ist, läuft er in 10 Jahren noch. Wenn er proprietäre Treiber braucht, dann stirbt er mit der Pflege des Treibers.

Lena Vogel: Und die zweite Meldung in dem Block verbindet sich mit dem Thema Vertrauen, das wir ja schon mehrfach hatten. Fly.io hat aufgezeigt, wie das Remote-SSH-Protokoll von VSCode funktioniert. Und das ist, wenn man es genau liest, mächtig und beunruhigend zugleich.

Felix Hartmann: Also wie funktioniert das? Du verbindest dich über Remote-SSH von VSCode auf einen Server. Der Server kann Code ausführen, er kann Dateien editieren, und zwar nicht nur auf dem Server, sondern auch auf deiner lokalen Maschine. Das heißt, du gibst dem Remote-Host faktisch die Kontrolle über einen Teil deiner lokalen Umgebung.

Lena Vogel: Und im Thread war die Diskussion genau darüber: Ist das ein Problem oder ein Feature? Die eine Seite sagt: Das ist ein Feature, genau dafür benutzen wir das. Ich will Code auf einem Server ausführen, der zehnmal schneller ist als mein Laptop, und ich will die Ergebnisse direkt lokal sehen. Das ist die ganze Idee von Remote-Entwicklung. Die andere Seite sagt: Es ist ein implizites Vertrauensverhältnis.

Lena Vogel: Du gibst dem Server Macht über deine lokale Maschine, ohne dass dir das bei der Verbindung ausdrücklich gesagt wird. Wenn der Server kompromittiert ist, dann ist es dein Laptop auch. Und das ist der Punkt, der sich mit dem Qualcomm-Diskussion verbindet: Es geht um Vertrauen, um Transparenz, und darum, was implizit vorausgesetzt wird und was explizit gesagt werden sollte.

Felix Hartmann: Also der Block im Kern: Die Linux-Welt diskutiert, ob ein Chip-Hersteller offene Standards nutzt oder proprietäre Wege geht. Und die Remote-Entwicklungs-Welt diskutiert, ob die Machtverhältnisse zwischen Server und lokaler Maschine transparent genug sind. Beides ist im Grunde die gleiche Frage in verschiedenen Gewändern.

Lena Vogel: Und von der Frage, wie Werkzeuge aufgebaut sein sollten, kommen wir zu der Frage, wie Teams arbeiten. Und hier gab es zwei Diskussionsbeiträge, die im Thread viel resonance hatten, weil sie sich um Verbesserungszyklen drehen. Der erste: GitHub-Wikis als Anti-Pattern.

Felix Hartmann: Das ist die These, die im Thread aufgestellt wurde, und sie hat ziemlich heftige Reaktionen produziert. Die These in Kurzform: GitHub-Wikis sind der falsche Ort für Dokumentation. Besser ist ein versionierter /docs-Ordner im Repository, mit Code-Review für Änderungen und mit GitHub Pages als Ausgabeformat. Also Dokumentation wie Code behandeln.

Lena Vogel: Und die Argumente dafür, die im Thread zusammengetragen wurden, sind ziemlich überzeugend. Ein Wiki ist ein paralleler Raum. Es hat seine eigene Struktur, seine eigenen Berechtigungen, keinen Review-Prozess, keine Versionshistorie, die man im Kontext des Codes liest. Wenn sich Code ändert und ein Wiki-Artikel nicht mitgeändert wird, merkt das niemand, weil der Pull Request, der den Code ändert, das Wiki nicht berührt.

Lena Vogel: Mit einem /docs-Ordner in demselben Repository ist das anders: Der Pull Request, der den Code ändert, kann die Doku mitändern, und der Reviewer sieht beides im Kontext.

Felix Hartmann: Die Gegenposition, die auch im Thread auftauchte: Wikis sind niedrigschwellig. Nicht jeder, der eine Frage beantworten will, ist im Code-Repo zu Hause. Und es gibt Dinge, die nicht zum Code gehören, etwa Onboarding-Material für Leute, die das Repo gar nicht anfassen. Und da kam als Kompromiss oft die Antwort: Ja, solche Dinge kann es geben, aber der Kern, also alles, was mit dem Code zu tun hat, sollte im Repo leben.

Felix Hartmann: Und die GitHub-Pages-Ausgabe löst das Zugänglichkeitsproblem, weil man die Doku als Website servieren kann, ohne ein Wiki zu brauchen.

Lena Vogel: Und der zweite Beitrag in diesem Block, der sich thematisch anschließt: Was fragt man nach einem Incident? Die These war: Frage nicht "Warum ist es passiert?", sondern "Was haben wir geändert?". Und die Begründung, die im Thread gegeben wurde, ist subtil, aber wichtig. Wenn man nach "Warum" fragt, dann suchen sich die Leute eine plausible Erklärung, und plausible Erklärungen verhindern sinnvolle Änderungen.

Lena Vogel: Also, man erklärt sich den Incident so, dass nichts an der Prozessstruktur geändert werden muss, weil die Erklärung ja nichts Nahelegendes ergibt.

Felix Hartmann: Genau. Die Frage "Was haben wir geändert?" ist operativer. Sie zwingt zu einer konkreten Aktion, nicht zu einer Geschichte. Und sie zwingt dazu, die Änderung zu formulieren, nicht die Ursache. Die offene Frage im Thread war: Gibt es Incidents, bei denen die Ursache so klar ist, dass die Warum-Frage trotzdem sinnvoll ist? Und die Antwort war uneins. Also keine Konsens-Lösung, aber die Tendenz: Die konkretere Frage hilft in mehr Fällen.

Lena Vogel: Und der dritte Beitrag in diesem Block ist eher eine Randnotiz, aber er passt gut hinein. Raymond Chen, der bekannte Microsoft-Blogger, hat über ein Detail in Windows geschrieben. Mit Shift und Klick in der Scrollbar springt man direkt zu dem Punkt, auf den man klickt. Also nicht seitenweise scrollen, sondern direkt zur Position. Und die Randnotiz: WinUI, das moderne Framework, implementiert weder das Kontextmenü noch diesen Shortcut.

Lena Vogel: Also ein Detail, das seit Jahrzehnten existiert, das in der neuen Generation fehlt.

Felix Hartmann: Und das passt zum Thema des Blocks, weil es um gepflegte Verbesserungszyklen geht. Windows hat ein Detail gepflegt, WinUI hat es vergessen. Und genau das ist die Gefahr, die auch bei der Doku und bei der Incident-Analyse relevant ist: Wenn man Verbesserungen nicht bewusst weiterträgt, verliert man sie. Und das ist die Brücke zum letzten Block, denn dort geht es um Handarbeit, um Pflege, um Dinge, die man bewusst weiterträgt oder eben auch vergisst.

Lena Vogel: Und der letzte Block ist eigentlich ein schöner Abschluss, weil er zwei Porträts kombiniert, die sich auf den ersten Blick nicht viel zu tun haben, aber genau das Thema Pflege von beiden Seiten beleuchten. Das erste Porträt: Meta VR Glasses.

Felix Hartmann: Die Fakten, so wie sie im Thread zusammengefasst wurden: Frühjahr 2027, Preis 1.299 Dollar, 100 Gramm Gewicht, Gehäuse aus einer Magnesium-Legierung. Und das eigentliche Verkaufsargument ist nicht Leistung, sondern Leichtigkeit. 100 Gramm ist, für ein VR-Headset, bemerkenswert leicht. Die Leute, die VR-Headsets regelmäßig tragen, kennen das Problem: Nach einer halben Stunde tut der Nacken weh. Und 100 Gramm statt der üblichen 500 oder mehr ist da ein echter Unterschied.

Lena Vogel: Und die Diskussion im Thread ging in zwei Richtungen. Die eine Richtung: Endlich, jemand macht das Richtige. Leichtigkeit statt Spez-Spirale. Die Spez-Spirale, also immer schnellere Chips und immer schwerere Headsets, ist ein Wettlauf, der am Ende niemanden glücklich macht, weil niemand ein Headset trägt, das sich anfühlt wie ein Helm. Die andere Richtung: 1.299 Dollar ist ein Preis, der nur für Enthusiasten ist.

Lena Vogel: Und die Frage, ob Magnesium-Legierung wirklich der Grund für den Preis ist, oder ob das Marketing ist, wurde auch gestellt. Die offene Frage ist also: Wird das Headset tragen, was das Konzept verspricht, oder wird die Leichtigkeit mit Abstrichen bei der Leistung bezahlt?

Felix Hartmann: Und das zweite Porträt ist, das muss ich sagen, mein Favorit des Tages. Portobello, ein Uhrenturm von 1877. Die Reparatur wurde abgeschlossen, und das Besondere: Das originale mechanische Uhrwerk blieb drin. Aber es wurde ergänzt um eine Box mit einem PIC 16F628, also einem urigen 8-Bit-Mikrocontroller, und einem Elektromotor.

Lena Vogel: Das ist, wenn du dir das vorstellst, ein wunderschönes Bild. Ein Uhrwerk von 1877, das weiterhin die Zeit anzeigt, aber ein 8-Bit-Mikrocontroller aus den frühen 2000ern sorgt dafür, dass es aufgezogen bleibt oder dass bestimmte Funktionen elektrisch unterstützt werden. Also zwei Epochen der Technik in einer Box.

Lena Vogel: Und im Thread war das genau der Punkt, der begeistert hat: Es ist nicht Restaurierung im Sinne von "Rückversetzung in den Originalzustand", und es ist auch nicht Modernisierung im Sinne von "wir ersetzen das alte Zeug durch etwas Neues". Es ist eine Kooperation zwischen beiden.

Felix Hartmann: Und das verbindet sich mit dem Meta-Headset auf eine Art, die ich im Thread nicht explizit formuliert gefunden habe, aber die für mich naheliegt. Beide Projekte handeln von Gewicht. Beim Headset geht es darum, Gewicht zu reduzieren, damit Leute es länger tragen können. Beim Uhrenturm ging es darum, das Gewicht der Geschichte zu tragen, also das originale Uhrwerk zu erhalten, und trotzdem sicherzustellen, dass es funktioniert. Beide sind in gewisser Weise Optimierung unter Constraint.

Felix Hartmann: Nur die Constraints sind ganz andere.

Lena Vogel: Und, das ist der letzte Punkt, den ich aus dem Thread aufgreifen will, bevor wir zum Abschluss kommen: Es gab im Umfeld dieser beiden Porträts noch ein paar kurze Meldungen, die teilweise diskutiert wurden. Das italienische Parlament hat für die Rückkehr zur Kernenergie gestimmt, wobei wirtschaftliche Zweifel bestehen bleiben, weil Solarstrom so billig ist. Und es gab eine Zahl, die im Zusammenhang mit Job-Börsen diskutiert wurde: Von 607.

Lena Vogel: 050 Stellenangeboten auf Corporate-Websites waren 28,3 Prozent länger als 90 Tage offen, und die mediane Dauer lag bei 36 Tagen. Also ein Hinweis darauf, dass viele Angebote entweder langwierige Prozesse sind oder einfach veraltet online stehen.

Felix Hartmann: Und es gab auch eine kleine Randnotiz, die im Thread eher mit Nostalgie aufgenommen wurde: Der Z80-REPL von Kenta Cho aus dem Jahr 2018, ein interaktiver Assembler für den Z80-Prozessor, der direkt im Browser läuft. Also im Grunde das gleiche Prinzip wie der PIC-Mikrocontroller im Uhrenturm: alte Hardware, aber lebendig gehalten, weil jemand die Arbeit gemacht hat, sie zugänglich zu machen. Und das ist, glaube ich, ein guter Bogen zum Schluss.

Lena Vogel: Ja. Also was bleibt heute hängen? KI wird schneller und billiger, und das verändert Erwartungen. KI kann wissenschaftliche Entdeckungen anstoßen und echte Autos fahren, aber der Weg von Benchmark zu Praxis ist offen. Entwickler-Tools und Consumer-Software können still Vertrauen verlieren, und Regulatoren fangen an zu reagieren. Infrastruktur-Arbeit wird weiterhin leise wichtig. Standards und transparente Machtverhältnisse sind die Fragen, die sich bei Linux und Remote-Entwicklung stellen.

Lena Vogel: Teams verbessern sich durch konkrete Fragen und versionierte Doku, nicht durch Wikis und plausible Erklärungen. Und Pflege, ob bei einem 100-Gramm-Headset oder bei einem Uhrwerk von 1877, bedeutet, die Constraint bewusst zu wählen und zu respektieren.

Felix Hartmann: Genau so, Lena. Danke an alle, die in den Diskussionen mitgemacht haben. Wenn ihr zu einem der Themen etwas sagt wollt, dann ab in die Threads. Wir sind morgen wieder hier, mit neuen Stories und hoffentlich wieder so viel Substanz. Bis dann, und bleibt neugierig.

Lena Vogel: Bis morgen, und danke fürs Zuhören.