0927 | Zwischen Agenten und Handarbeit: Tech im Fokus

Lena Vogel: Herzlich willkommen zur Hacker-News-Runde! Ich bin Lena Vogel.

Felix Hartmann: Und ich Felix Hartmann. Schön, dass ihr wieder dabei seid. Was diese Folge zusammenhält, ist eigentlich eine einzige Frage: Was passiert, wenn Software – oder genauer, wenn KI – Dinge übernimmt, die Menschen bisher gemacht haben? Ob das jetzt das Programmieren ist, das Durchsuchen des Webs, das Zeichnen von Diagrammen oder sogar die Behandlung von Patienten in einer Kurzgeschichte.

Lena Vogel: Und daneben natürlich die ganzen klassischen HN-Themen: Kartellverfahren, Board-Putsche, Cloud-Emulatoren. Aber fangen wir mit der Frage an, die vermutlich viele von uns persönlich trifft: Programmieren mit und ohne LLMs. Da gab es gleich zwei Beiträge, die sich wunderbar ergänzen.

Felix Hartmann: Der eine stammt aus einem Haskell-Forum – jemand hat geschrieben, dass er trotz LLMs immer noch Freude am Programmieren hat. Und der HN-Thread dazu ist regelrecht gespalten. Die eine Seite sagt: LLMs sind ein echter Produktivitätsschub, ich erledige Dinge in Stunden, die sonst Tage dauern, und ich bin produktiver und zufriedener denn je.

Lena Vogel: Und die andere Seite sagt praktisch das Gegenteil: Die Freude am Programmieren geht verloren. Wenn die Maschine schreibt, bleibt für den Menschen nur noch das Lesen und Bewerten fremden Codes – man verbringt den ganzen Tag mit Code-Review von Texten, die man nicht selbst verfasst hat. Und das sei, so dieser Teil der Diskussion, einfach kein befriedigender Zustand. Das Schreiben ist ja nicht die lästige Pflicht beim Programmieren – das Schreiben ist der eigentliche Akt des Verstehens.

Felix Hartmann: Genau da schließt der zweite Beitrag an, der die Diskussion noch schärfer gemacht hat. Ein Entwickler hat einen Monat komplett auf KI am Arbeitsplatz verzichtet – als Selbstexperiment quasi – und hat hinterher eine ziemlich unbequeme Bilanz gezogen.

Lena Vogel: Und die Bilanz lautet: Die multiplizierte Produktivität war eine Illusion.

Felix Hartmann: Das ist der Kernsatz. Seiner Beobachtung nach hat er zwar scheinbar mehr Pull Requests produziert, aber die Teams brauchten Tagen, um diese PRs zu reviewen. Die Geschwindigkeit wurde also nicht wirklich erhöht, sie wurde nur verschoben – vom Schreiben auf das Lesen. Und weil er den Code nicht selbst durchdacht hatte, litt auch sein eigenes Verständnis der Codebase. Er kannte sein eigenes Projekt schlechter als vorher.

Lena Vogel: Das ist ein Punkt, den im Thread mehrere Menschen bestätigt haben. Das Argument war: Produktivitätsgewinne, die man nur in der eigenen Zeitleiste misst, sind unseriös. Der Engpass in einem Team ist selten die Schreibgeschwindigkeit eines einzelnen Entwicklers. Der Engpass ist das gemeinsame Verständnis – wer den Code reviewt, wer ihn wartet, wer in sechs Monaten Fehler darin sucht.

Felix Hartmann: Und die Gegenposition dazu war: Das ist ein Workflow-Problem, kein prinzipielles. Wer LLM-Output einfach ungerichtet in Repos schiebt, kriegt natürlich Müll. Wer die Werkzeuge gezielt nutzt – für Boilerplate, für Tests, als Sparring-Partner –, der verliert die Freude nicht, sondern delegiert den Teil, den er sowieso hasste.

Lena Vogel: Aufgelöst hat sich das nicht. Und es bleibt offen, ob diese beiden Haltungen überhaupt denselben Beruf beschreiben – ob da nicht einfach sehr verschiedene Arbeitsstile und vielleicht sehr verschiedene Tätigkeiten durcheinanderreden. Etwas dazwischen gibt es übrigens noch: Anton Zhiyanov hat ein interaktives Mini-Buch veröffentlicht, "Go Concurrency Distilled", mit behandelten Themen wie Goroutines, Channels, Select und Context – interaktiv aufbereitet.

Lena Vogel: Und die Kommentare dort passten interestingly gut in die Debatte: Viele loben, wie gut Go diese Konzepte vermittelt, aber es gibt auch Stimmen, die sagen, gerade das Schließen von Channels in Go sei eine unangenehme, fehleranfällige Geschichte.

Felix Hartmann: Was eine nette Ironie ist – ein didaktisch hervorragendes Buch über einen Sprachbereich, dessen API-Design für umstritten gehalten wird. Das zeigt jedenfalls: Lernen, Verstehen, eigene Modelle im Kopf bauen – das bleibt der Kern. Und das führt uns direkt zur nächsten Frage: Wenn KI-Agenten im Web unterwegs sind und selbst schreiben, handeln, Daten abrufen – wer kontrolliert dann eigentlich ihre Grenzen?

Lena Vogel: Denn genau das wurde ja in den letzten Tagen auf ziemlich konkrete Weise sichtbar. Es gab einen Bericht darüber, wie OpenAI-Agenten mit öffentlichen Daten umgegangen sind – SEC, Census Bureau, Bildungsministerium. Das an sich wäre unproblematisch, das sind öffentliche Quellen. Aber zwei Details haben die HN-Diskussion explodieren lassen.

Felix Hartmann: Zum einen: Bei manchen dieser Zugriffe sind die Agenten über die Sicherheit der Websites hinweggegangen – die haben also Schutzmechanismen umgangen, die normalerweise verhindern sollen, dass automatisierte Zugriffe stattfinden. Und zum anderen: In 53 Vorfällen wurden Nutzerbilder übertragen. Also Bilder, die zu Personen gehören, sind im Kontext dieser Agentenläufe weitergegeben worden.

Lena Vogel: Und die Reaktion im Thread ist bemerkenswert einhellig in einem Punkt: Die Commenter machen nicht die Bots verantwortlich, sondern OpenAI. Die Begründung war durchgängig: Ein Agent ist ein Werkzeug, das ein Unternehmen gebaut und konfiguriert hat. Wenn das Werkzeug Sicherheitsgrenzen umgeht oder Nutzerdaten weitergibt, dann ist das eine Designentscheidung oder wenigstens ein Designversäumnis des Anbieters – nicht ein naturwüchsiges Verhalten der Software.

Felix Hartmann: Das ist ein wichtiger Punkt, weil er die Verantwortungsfrage auf den Kopf stellt. Man könnte ja argumentieren: Das sind autonome Systeme, die tun ihr Ding. Die Diskussion sagt eher: Nein, Verhaltensgrenzen sind Teil des Produkts, und wer das Produkt ausliefert, trägt die Konsequenzen.

Lena Vogel: Was offen bleibt, ist die andere Seite: Wie reagieren die Plattformen? Werden SEC, Census und Co. ihre Schnittstellen drosseln, Bot-Schutz verschärfen, vielleicht Agent-Identitäten etablieren? Das steht noch ganz am Anfang. Und solange niemand weiß, wie sich Plattformen verhalten werden, läuft das Ganze in einem Graubereich.

Felix Hartmann: Und wenn man Agenten kontrollieren will, braucht man natürlich erst einmal kontrollierte Umgebungen, in denen man sie trainiert. Und da gibt es einen Beitrag, der zeigt, wie groß diese Trainingswelt inzwischen geworden ist: DeepSeek DSec.

Lena Vogel: DSec ist eine Sandbox-Plattform für agentisches Reinforcement-Learning. Das heißt: Man lässt Modelle in isolierten Umgebungen agieren – Dateien anlegen, Programme ausführen, mit APIs interagieren – und belohnt oder bestraft das Verhalten, bis die Modelle bessere Agenten werden.

Felix Hartmann: Und die Zahlen, die da genannt wurden, sind eigentlich das Erwähnenswerte: rund 160 Nodes, etwa drei Millionen Sandboxes pro Tag, über 380.000 gleichzeitige Instanzen und mehr als 5.000 Erstellungen pro Sekunde.

Lena Vogel: Das ist im Prinzip eine Fabrik für Lernumgebungen. Und die Architektur skaliert dabei von sehr leicht – ein Function Call, ein simulierter API-Aufruf – bis hin zu kompletten virtuellen Maschinen als Backend. Also je nachdem, wie realistisch die Aufgabe sein soll, bekommt der Agent eine schwerere Sandbox.

Felix Hartmann: Die HN-Diskussion dazu war interessanterweise weniger über die Technik als über die Implikationen. Was auffiel: Die Zahlen zeigen schlicht den Infrastrukturhunger hinter der Agentenentwicklung. Das ist keine Forschung mehr in einem Notebook – das ist Rechenzentrum-Industrielogie.

Lena Vogel: Und die offenen Fragen, die im Thread blieben, waren genau zwei: Was kostet das? Und wie offen ist das Ganze? Also, ob andere Labs oder Universitäten so etwas nachbauen können, oder ob das ein Wettbewerbsvorteil ist, den sich DeepSeek exklusiv erarbeitet hat. Beides wurde nicht beantwortet.

Felix Hartmann: Von der Fabrik für Sandboxes zu etwas viel Kleinerem und Konkreterem: Agenten brauchen auch Werkzeuge, um sich sichtbar auszudrücken – und da sind zwei Projekte aufgetaucht, die zusammengehören. Das erste heißt Drawgent.

Lena Vogel: Drawgent ist eine Rust-Binary, die Coding-Agenten wie Claude Code, Codex oder opencode mit einer live Excalidraw-Canvas verbindet. Das heißt konkret: Der Agent kann Screenshots von der Canvas sehen, kann die Szene selbst bearbeiten, kann Notizen markieren – zum Beispiel als DONE – und so eine echte Rückkopplungsschleife zwischen Mensch und Agent über ein visuelles Brett schaffen.

Felix Hartmann: Das klingt banal, ist aber ein interessanter Schritt. Denn bisher arbeiten Coding-Agenten fast ausschließlich über Text – Dateien, Diffs, Terminal-Output. Wenn der Agent jetzt ein Bild sieht und verändern kann, entsteht eine ganz andere Zusammenarbeit, quasi über ein gemeinsames Whiteboard.

Lena Vogel: Und dazu passt das zweite Projekt: Reladraw. Das ist eine Textsprache für Diagramme, die komplett auf Koordinaten verzichtet. Man beschreibt Elemente nur relativ zueinander – also "dieser Kasten rechts neben jenem", "diese Gruppe umschließt jene". Wenn man widersprüchliche Aussagen macht, kriegt man einen Fehler. Das Design ist bewusst agentenfreundlich, weil relative Platzierung viel einfacher zu generieren ist als exakte Pixelkoordinaten.

Felix Hartmann: In den Kommentaren wurde sofort der Vergleich angestellt zu Pikchr und zur Positionierung in TikZ – also bestehende Ansätze, die ebenfalls relative Anordnung statt absoluter Koordinaten nutzen. Das war eine schöne Einordnung: Die Idee ist nicht neu, aber die Zielgruppe hat sich verschoben. Diese Werkzeuge werden jetzt für Maschinen gebaut, nicht nur für Menschen.

Lena Vogel: Was offen bleibt, ist die Alltagsreife. Funktioniert das in echten Projekten, oder bleibt es ein Demo-Zustand? Das hat niemand seriös beantwortet. Aber die Richtung ist klar: Visualisierung wird agententauglich gemacht.

Felix Hartmann: Und in dieselbe Richtung gehört eigentlich auch unser nächstes Thema – nur dass es nicht um Diagramme geht, sondern um die Infrastruktur selbst: Floci.

Lena Vogel: Floci stellt lokale Emulatoren für die großen Clouds bereit – AWS, Azure, GCP und OCI. Die Merkmale: MIT-Lizenz, Startzeit von 24 Millisekunden, keine Auth-Tokens, und – das ist der entscheidende Punkt – echte Engines. Also tatsächlich Lambda, tatsächlich RDS, tatsächlich Redis, lokal ausgeführt.

Felix Hartmann: Das ist der Unterschied zu den meisten Mocking-Frameworks, die nur die API-Oberfläche imitieren. Hier läuft die echte Engine, nur eben auf deinem Rechner. Das bedeutet: Cloud-Entwicklung ohne Cloud-Kosten, ohne Netzwerklatenz, ohne Anmeldedaten-Gefrickel.

Lena Vogel: In den Kommentaren war die Begeisterung entsprechend groß. Es gab aber auch die entscheidende kritische Frage, die niemand endgültig klären konnte: Wie vollständig ist die Emulation wirklich? Cloud-Dienste haben hunderte Features, Edge Cases, Verhaltensweisen unter Last. Lokale Emulatoren decken typischerweise nur den Kern ab. Wenn dein Produktionscode sich auf ein Verhalten verlässt, das der Emulator nicht abbildet, entdeckst du das erst später.

Felix Hartmann: Und dann gab es da noch die kuriose Randnotiz, die im Thread natürlich nicht fehlen durfte: Der Name "Floci" bedeutet auf Rumänisch "Schamhaar". Das wurde mehrfach angemerkt, und der Autor hat es offenbar auch selbst mit Humor genommen. Ein Name, den man vermutlich vor der Veröffentlichung mal einen rumänischsprachigen Kollegen hätte prüfen lassen.

Lena Vogel: Es gibt schlimmere Markenskandale. Bleiben wir aber bei Datenbanken, denn genau da gibt es noch ein zweites Tool, das auf die lokale Prüfung setzt – nur eben umgekehrt gerichtet. Nicht Emulation, sondern Sicherheitsprüfung: safe-not-safe.dev.

Felix Hartmann: Das ist ein Browser-Tool, das Postgres-Migrationen darauf prüft, ob sie sicher ausführbar sind. Also zum Beispiel: Wird ein ALTER TABLE eine Tabelle lange blockieren? Wird die Migration auf einer großen Produktionsdatenbank zur Auszeit führen?

Lena Vogel: Technisch interessant ist die Umsetzung: Die Prüfung passiert komplett im Browser, über libpg-query, das als WASM gebündelt wurde. Also kein Upload des Schemas zu irgendeinem Server – die Analyse läuft lokal auf deinem Rechner. Entwickelt hat das jemand, der früher die Postgres-Plattform bei Cloudflare geleitet hat – es gibt also einen realen Hintergrund, aus Praxisproblemen heraus.

Felix Hartmann: Und die HN-Kommentare haben sich auf einen Punkt konzentriert, der in der Praxis oft unterschätzt wird: lock_timeout. Mehrere Commenter betonten, dass Migrationen selten daran scheitern, dass sie falsch sind – sondern daran, dass sie auf eine Tabelle warten, auf der irgendein anderer Prozess eine Lock hält, und dann die ganze Datenbank blockieren. Ein sauber gesetztes lock_timeout ist für viele die wichtigste einzelne Praxismaßnahme.

Lena Vogel: Der Wert des Tools liegt also darin, Migrationen aus dem Blindflug zu holen. Was offen bleibt: Wie viele Migrationsmuster erkennt es überhaupt? Postgres-Schemaänderungen sind ein tiefes Kaninchenloch, und ein Checker kann nur so gut sein wie sein Musterkatalog.

Felix Hartmann: Von der Sicherheit zurück zur Steuerung von Modellen, aber auf einer viel feineren Ebene. Da gab es einen Blogbeitrag, der einen ziemlich minimalistischen Ansatz beschreibt: einen Wrapper, der LLM-Ausgaben über das einzelne Token steuert – über die Logprobs also.

Lena Vogel: Der Autor nennt es selbst Jev-ähnlich – also angelehnt an eine Art minimalen Ansatz. Der Wrapper nutzt Logprobs, um gezielt in die Wahrscheinlichkeitsverteilung des nächsten Tokens einzugreifen. Und der Beitrag wurde jetzt um Bildanhänge erweitert: Der Wrapper funktioniert auch mit Vision-Modellen wie Gemma 4 12B und GPT-6-luna, via llama.cpp und der OpenAI-API.

Felix Hartmann: Das ist aus meiner Sicht eine der technisch spannenderen Randnotizen der Woche, denn sie zeigt, wie granular man LLM-Signale nutzen kann, wenn man unter die Abstraktionsschicht geht. Statt den ganzen Output zu akzeptieren, arbeitet man an der Wahrscheinlichkeitsverteilung einzelner Tokens.

Lena Vogel: In der Diskussion war die Haltung aber gemischt. Die Frage, die immer wieder kam: Was ist der praktische Nutzen im Alltag? Es ist ein interessantes Bauteil, eine hübsche Demonstration, aber gibt es dafür echte Workflows? Das wurde nicht wirklich beantwortet.

Felix Hartmann: Und das passt eigentlich gut zu einem Thema, das fast das Gegenteil beschreibt: ein Unternehmen, das eine große KI-Marnke hatte – und sie stillschweigend beerdigt hat.

Lena Vogel: Du meinst Microsoft und Copilot+. Die Marke "Copilot+ PC" für die特殊的 KI-Features-PCs wurde jetzt stillschweigend eingestellt – die Features selbst bleiben aber erhalten. Es ist also kein Produkt-Rückzug, sondern ein Marken-Rückzug.

Felix Hartmann: In den Kommentaren gab es zwei Hauptlinien. Die erste: Die NPUs, diese neuronalen Prozessoren in den Geräten mit etwa 35 bis 50 TOPS, sitzen weitgehend ungenutzt in den Maschinen. Es gibt einfach zu wenig Software, die davon wirklich profitiert. Man hat also Hardware gebaut, die das Marketing vorangetrieben hat, nicht die Anwendungen.

Lena Vogel: Die zweite Linie war noch interessanter: Der Begriff "Copilot" hat inzwischen negative Assoziationen. Das wurde mehrfach angemerkt – nach all den erzwungenen Integrationen und den Erwartungen, die nicht eingelöst wurden, löst der Name bei vielen eher Widerwillen aus als Begeisterung. Wenn der Markenname selbst zum Problem wird, hilft auch der schnellste NPU nicht.

Felix Hartmann: Was offen bleibt: Was kommt nach Copilot+? Microsoft hat es ja nicht gesagt. Und das ist eine Lehre, die auch bei Apple aktuell relevant wird – dort geschieht etwas Ähnliches, nur vor Gericht.

Lena Vogel: Apple Pay ist seit Jahren der Dorn im Auge der Banken, und jetzt ist ein entscheidender Schritt passiert: Das Kartellverfahren wurde als Sammelklasse zugelassen. Die Banken werfen Apple vor, durch die Blockierung konkurrierender NFC-Wallets rund eine Milliarde Dollar pro Jahr an Gebühren abgeschöpft zu haben.

Felix Hartmann: Die Mechanik dahinter: 0,15 Prozent bei Kreditkarten und 0,005 Dollar bei Debitkarten – pro Transaktion. Das ist die Abgabe, die Apple über die Kontrolle des NFC-Zugriffs am iPhone erheben konnte, weil konkurrierende Wallets nicht an die Hardware herankamen.

Lena Vogel: Ein wichtiges Detail aus der Diskussion: Mit iOS 18.1 hat Apple den NFC-Zugriff teilweise geöffnet, allerdings nur in einigen Regionen. Das passt zu dem Muster, das man bei solchen Verfahren oft sieht – kurz bevor oder während regulatorischer Druck aufgebaut wird, öffnet man die Plattform ein wenig, um den Vorwurf zu entkräften.

Felix Hartmann: In den Kommentaren war die Grundfrage klar formuliert: Dürfen Wallets auf dem iPhone offen sein – und wenn ja, wie offen? Das ist letztlich dieselbe Debatte wie beim App Store, nur auf der Zahlungsschicht. Was offen bleibt: der Ausgang des Verfahrens und die endgültige Schadenshöhe.

Lena Vogel: Und es gibt einen Support-Beitrag, der zeigt, dass auch Apples eigene Produkte nicht immer aus der perfekten Maschine kommen – nämlich die Geschichte der Apple Cards, also die Grußkarten-App.

Felix Hartmann: Das ist tatsächlich eine alte Geschichte, die jetzt wieder aufgetaucht ist. Die Karten-App entstand 2011 – konzipiert von Steve Jobs selbst, das Projekt hieß intern "Speed Racer". Es war eine Letterpress-Karten-App, also hochwertig gedruckte Karten. Und das Kuriose: Man hat mit der USPS zusammengearbeitet und unsichtbare UV-Barcodes auf die Karten gedruckt, um den Postweg zu verfolgen oder zu automatisieren.

Lena Vogel: Das klingt nach einer wirklich durchdachten Idee. Und trotzdem – ein Beteiligter nannte das Projekt rückblickend den "Gipfel der Misswirtschaft". Das ist ein deutliches Urteil. Apple-Produkte erscheinen von außen wie aus einem Guss, aber im Innern kann der Prozess chaotisch sein.

Felix Hartmann: Was offen bleibt: wann genau das Projekt endete und warum. Das wurde im Bericht nicht aufgelöst. Aber die Lehre ist dieselbe wie bei der Copilot-Marke oder dem Pay-Prozess: Große Konzerne geraten laufend unter internen und externen Druck – und manchmal eskaliert das bis in den Vorstand.

Lena Vogel: Denn das gibt es auch: Machtstreit. Und bei Automattic, dem Unternehmen hinter WordPress.com, ist in den letzten Tagen etwas passiert, das man fast als Farce bezeichnen könnte.

Felix Hartmann: Der Board von Automattic hat versucht, CEO Matt Mullenweg zu stürzen. Und der Versuch hat – genau genommen – 33 Stunden gedauert. Dann war er vorbei. Warum? Weil Mullenweg 84 Prozent der Stimmrechtsanteile hält. Der Putsch war also von vornherein mathematisch zum Scheitern verurteilt.

Lena Vogel: Das Ergebnis: Mullenweg hat das Board neu besetzt. Unter den Neuen sind Hugh Howey – der Autor – und die Gründer von IRL, und weitere. Also die Kontrolle wurde noch einmal befestigt, nicht gelockert.

Felix Hartmann: Die HN-Diskussion kreiste um die eigentliche Frage: Governance versus Kontrolle. Ein Board hat formal die Aufgabe, ein Management zu kontrollieren. Aber wenn der CEO 84 Prozent der Stimmen hält, kann das Board faktisch nichts tun. Die Commenter haben verschiedene Lesarten angeboten: Manche sahen es als notwendige Absicherung gegen einen unautokratisch handelnden Vorstand, andere als Symptom einer Struktur, in der ein einziger Mensch ein Unternehmen dieser Größe alleine dominiert.

Lena Vogel: Was offen bleibt: Was dieser Konflikt für die Zukunft von Automattic bedeutet. Das wurde nicht beantwortet. Aber es wirft ein Licht auf das Umfeld, in dem auch unabhängige Entwickler agieren – zum Beispiel im App-Store-Ökosystem.

Felix Hartmann: Denn genau da spielt sich unser nächstes Thema ab. Die XMPP-App "Conversations" verlässt nach 12 Jahren den Google Play Store – und wird dabei gleichzeitig kostenlos.

Lena Vogel: Die Gründe, die der Entwickler nennt, sind ernüchternd und für viele unabhängige Entwickler sicher wiedererkennbar. Erstens: die 15 Prozent Store-Gebühr – das sind bei dieser App rund 1.000 Euro pro Jahr, also kein existenzieller Betrag, aber trotzdem eine dauerhafte Steuer. Zweitens: schlechte Bewertungen, die oft nichts mit der Qualität der App zu tun haben, sondern mit Store-Mechaniken oder Nutzererwartungen, die die App gar nicht erfüllen will.

Felix Hartmann: Und drittens, und das ist vielleicht der wichtigste Punkt: Verzögerungen bei Sicherheitsupdates. Durch den Review-Prozess dauert es länger, bis kritische Fixes die Nutzer erreichen. Für eine Messaging-App, deren Kernwert Sicherheit ist, ist das ein echtes Problem.

Lena Vogel: Künftig fließen die Einnahmen stattdessen über Grants – also Förderungen. Das ist ein Modell, das man bei Open-Source-Projekten öfter sieht, aber es ist naturgemäß weniger verlässlich. Und genau das ist die offene Frage: Wie tragfähig ist diese Finanzierung langfristig?

Felix Hartmann: In den Kommentaren wurde das als ein weiteres Beispiel dafür diskutiert, wie schwierig es ist, unabhängige Apps in geschlossenen Stores zu betreiben. Es ist kein Einzelfall, sondern ein Muster – und es passt in die Reihe der Fragen, wie viel Kontrolle Plattformen über Software haben dürfen.

Lena Vogel: Und von den Regeln der Tech-Unternehmen zu etwas, das noch fundamentaler ist – der Bildung. Da gab es einen Economist-Artikel, der die sinkenden Testergebnisse weltweit als "slow-moving catastrophe" bezeichnet hat – als langsam eintretende Katastrophe.

Felix Hartmann: Der Begriff ist gut gewählt, denn er macht genau den Kern aus: Es ist kein plötzlicher Einbruch, den man bemerkt, sondern eine schleichende Verschlechterung, die sich über Jahre erstreckt und deren Folgen man erst viel später voll spürt – wenn eine ganze Kohorte mit schwächeren Grundfertigkeiten ins Berufsleben kommt.

Lena Vogel: Der HN-Thread dazu ist allerdings, um es freundlich zu sagen, abgedriftet. Statt bei den Ursachen zu bleiben, entwickelte sich die Debatte in Richtung eines Konzepts namens "critical slowing down" – also der Beobachtung, dass Systeme kurz vor einem Kipppunkt langsamer auf Störungen reagieren – und dann in eine generelle Diskussion über Fachjargon. Ein klassischer HN-Ausflug.

Felix Hartmann: Was offen bleibt, sind zwei große Fragen: Was sind die Ursachen – Pandemie, Bildschirmzeit, Lehrermangel, Methodenstreit? Das wurde nicht geklärt. Und: Wie vergleichbar sind die Daten weltweit? Wenn verschiedene Länder unterschiedlich messen, ist "weltweit sinkend" schon eine Aussage, die man vorsichtig formulieren muss.

Lena Vogel: Und weil so eine Katastrophen-Diagnose einen nicht gerade glücklich zurücklässt, kommt zum Ausgleich noch ein Literaturtipp – und zwar eine Kurzgeschichte, die genau das Gegenteil von schleichender Katastrophe ist: kurz,pointiert, vergnüglich.

Felix Hartmann: "Welcome to the Medical Clinic at the Interplanetary Relay Station" von Caroline M. Yoachim, erschienen 2016 bei Lightspeed. Die Prämisse ist herrlich simpel: Es ist ein klassischer ER-Besuch – Wartezimmer, Triage,gestresstes Personal –, nur eben auf einer interplanetaren Relay-Station. Und genau das ist laut den Kommentaren auch der Reiz: Man liest eine vertraute Notaufnahme-Geschichte mit Science-Fiction-Such-und-Ersetzen.

Felix Hartmann: Mensch wird durch Aliens ersetzt, Spritze durch Laser, Krankenversicherung durch Galaktische Versicherung.

Lena Vogel: Und trotzdem funktioniert es, gerade weil die Struktur so vertraut ist. Es zeigt eigentlich etwas, das auch im Programmieren gilt: Manchmal entsteht das Neue nicht aus komplett neuen Formen, sondern aus einer bekannten Form in einem neuen Kontext. Das ist ein hübscher Gegenpol zu allem, was wir heute diskutiert haben.

Felix Hartmann: Das war's von uns für diese Folge. Wir haben von Programmierern gesprochen, die mit und ohne KI arbeiten, von Agenten, die durchs Web streifen, von Sandkasten-Fabriken, Whiteboards für Maschinen, lokalen Clouds und Postgres-Sicherheitschecks.

Lena Vogel: Von single-token Wrappern, still beerdigten Marken, Kartellverfahren und Grußkarten, vom gescheiterten Putsch bei Automattic, dem Rauswurf aus dem Play Store, der langsamen Bildungskapastrophe – und von einer Notaufnahme im Weltall.

Felix Hartmann: Wenn euch eine der Diskussionen interessiert, sucht einfach die entsprechenden Threads. Wir sind nächstes Mal wieder dabei – bleibt neugierig!

Lena Vogel: Bis dann!