-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: AI

Von SEO zu AEO, der Kassensturz: was eine maschinenlesbare Identität wirklich bringt

12. Juni 2026 / / Keine Kommentare
Visualisierung einer maschinenlesbaren Online-Identität mit JSON-LD, Knowledge Graph und KI-Antwortsystemen zur Verknüpfung einer Person über mehrere digitale Quellen.

Am 1. Januar habe ich hier einen Beitrag geschrieben, der eine Wette war. Die These: Web-Optimierung verschiebt sich. Weg von SEO, dem Kampf um die beste Platzierung bei Google, hin zu etwas, das ich AEO genannt habe. Answer Engine Optimization. Also nicht mehr „wie komme ich auf Platz eins“, sondern „wie liefere ich die beste maschinenlesbare Antwort“. Ich habe damals llms.txt eingebaut, ein bisschen über JSON-LD geschrieben und ehrlich dazugesagt, dass niemand weiß, ob das langfristig relevant bleibt. Der letzte Satz war: ich bin gespannt, was passiert.

Jetzt ist ein gutes halbes Jahr vergangen. Zeit für einen Kassensturz. Was davon hat sich gehalten, was war naiv, was hat sich differenziert? Und vor allem: ich habe in den letzten Monaten tatsächlich daran gearbeitet, mich für eine Maschine sauber beschreibbar zu machen. Nicht als Theorie, sondern an der eigenen Seite, mit allen Fehlern, die dabei sichtbar wurden. Genau diese Fehler und die Abwägungen dahinter sind der eigentliche Inhalt dieses Beitrags. Wer den Vorgängerpost noch nicht kennt, findet ihn hier: Von SEO zu AEO, warum llms.txt, JSON-LD und Answer Engines das Web verändern.

Die Suche wird zur Antwortmaschine

Fangen wir mit dem an, was sich gerade wirklich verändert, unabhängig von meinem Blog. Wer heute etwas googelt, bekommt immer öfter die Antwort direkt auf der Ergebnisseite. Eine zusammengefasste KI-Antwort, darunter vielleicht ein paar Quellen. Der Klick auf eine Webseite entfällt. Dafür gibt es einen Begriff: Zero-Click-Suche. Die Information erreicht den Menschen, ohne dass er die Seite besucht, von der sie stammt.

Das ist keine Vermutung, das lässt sich messen. Das Pew Research Center hat Daten aus dem Frühjahr 2025 ausgewertet, veröffentlicht im Juli 2025: das Surfverhalten von rund 900 erwachsenen US-Nutzern, knapp 68.900 Google-Suchanfragen. Das Ergebnis: bekamen die Leute eine KI-Zusammenfassung angezeigt, klickten nur noch 8 Prozent auf einen weiterführenden Treffer. Ohne KI-Zusammenfassung waren es 15 Prozent, fast doppelt so viel. Auf die in der KI-Antwort verlinkten Quellen klickte überhaupt nur 1 Prozent. Fairerweise dazugesagt: Google hält die Methodik dieser Studie für nicht repräsentativ, hat aber keine eigenen Gegenzahlen vorgelegt. Zur Einordnung der Größenordnung: schon bei der ganz normalen Google-Suche endet ein großer Teil ohne Klick. Die Zero-Click-Studie von SparkToro (Rand Fishkin, 2024, Datenbasis Datos, das zu Semrush gehört) kommt auf rund 58 Prozent in den USA und knapp 60 Prozent in der EU, neuere Auswertungen für 2026 eher Richtung zwei Drittel. Und ein Hinweis zur Vorsicht, weil die Zahl gern falsch zitiert wird: die oft genannten 93 Prozent Zero-Click gelten ausschließlich für Googles AI Mode, also den dialogorientierten Chat-Modus der Suche (Semrush maß dort 92 bis 94 Prozent), nicht für die normale Suche. Wer diese Schlagzeile unbesehen übernimmt, vergleicht Äpfel mit Birnen.

Wie stark der Effekt kausal ist, hat ein randomisiertes Feldexperiment von Saharsh Agarwal (Indian School of Business) und Ananya Sen (Carnegie Mellon University) untersucht, Feldphase Januar und Februar 2026, 1.065 ausgewertete US-Desktop-Nutzer von Chrome. Auf den Suchanfragen, bei denen tatsächlich eine KI-Übersicht erschien, sanken die organischen Klicks um etwa 38 Prozent, die Zero-Click-Rate stieg von 54 auf 72 Prozent. Wichtig für die Einordnung: das ist ein noch nicht begutachtetes Arbeitspapier, online seit April 2026, und die Stichprobe sind aktive Desktop-Chrome-Nutzer aus einem Panel, nicht alle Google-Nutzer. Das Studiendesign war immerhin vorab registriert, was die Aussagekraft stützt. Trotzdem bleibt es ein Befund mit klaren Grenzen. Die Pointe ist nicht, dass die Suche stirbt, sondern etwas Nüchterneres: Sichtbarkeit entkoppelt sich vom Klick. Man kann als Quelle einer Antwort auftauchen, ohne dass jemand die eigene Seite öffnet.

Vom String zum Ding

Jetzt wird es interessant, denn hier liegt der Mechanismus, der mitentscheidet, ob man in so einer Antwort überhaupt vorkommt. Schon 2012 hat Google den Knowledge Graph eingeführt, unter dem Slogan „Things, not strings“. Übersetzt: Dinge, nicht Zeichenketten. Davor war eine Suchmaschine im Kern ein Textabgleich. Du tippst Buchstaben, sie sucht Seiten mit denselben Buchstaben. Seitdem versucht Google, hinter den Buchstaben das tatsächliche Ding zu erkennen. Eine Entität. Ein eindeutig identifizierbares Etwas mit Beziehungen zu anderen eindeutig identifizierbaren Etwas.

Das klassische Beispiel ist das Wort Jaguar. Tier, Auto oder Betriebssystem? Ein Mensch erkennt aus dem Zusammenhang sofort, was gemeint ist. Eine Maschine muss disambiguieren, also die Mehrdeutigkeit auflösen. Und genau dasselbe Problem gilt für mich. Welcher Sebastian van de Meer? Es gibt mehr als einen Menschen mit diesem Namen. Für eine Maschine ist mein Name erst einmal nur eine Zeichenkette, die zu mehreren Personen passt. Eindeutigkeit wird belohnt. Es gibt dazu einen vielzitierten Datenpunkt, den ich ehrlich einordnen muss: laut einer Auswertung von Kalicube (Jason Barnard, veröffentlicht bei Search Engine Land im August 2025) verschwanden im Juni 2025 über drei Milliarden Einträge aus dem Knowledge Graph, ein Rückgang von rund sechs Prozent, verteilt auf zwei Stichtage. Google hat das nie offiziell bestätigt, und die Deutung, dass hier Klarheit über Masse gewinnt, ist die des Analysten, nicht Googles erklärter Grund. Also ein Indiz, kein Gesetz. Der Knowledge Graph selbst speist sich nach Googles eigenen Angaben unter anderem aus Wikipedia, Branchenquellen nennen ergänzend Wikidata, und er ist das Bindeglied zwischen klassischer Suche und KI-Antworten. Googles KI-Suche, die auf Gemini basiert, greift nach eigener Darstellung auf den Knowledge Graph als Echtzeit-Quelle zurück. Wer dort als saubere Entität existiert, ist für beide Welten greifbar.

Wie man sich einer Maschine als Entität vorstellt

Damit sind wir beim Herzstück. Wie sage ich einer Maschine glaubwürdig, wer ich bin? Das Werkzeug dafür heißt JSON-LD nach dem schema.org-Vokabular. Vereinfacht: ein maschinenlesbarer Steckbrief, der direkt in der Seite liegt und Fakten ausdrücklich beschriftet. Das ist der Autor, das ist sein Beruf, das ist das Erscheinungsdatum. Statt die Maschine alles aus Fließtext erraten zu lassen, legt man ihr die Fakten getypt hin. Eine Klarheits- und Extraktionshilfe, mehr nicht. Keine Garantie auf ein Ranking und keine Garantie, zitiert zu werden. Diese Erwartung muss man sofort dämpfen, sonst baut man Luftschlösser.

Aus der abstrakten Ansage von damals ist bei mir eine ziemlich durchdachte Identitäts-Architektur geworden. Und ehrlich: das Spannende waren nicht die Zeilen, die ich geschrieben habe, sondern das, was ich dabei gelernt habe. Neun Punkte, die ich so vorher nicht auf dem Schirm hatte.

Erstens, eine Identität, eine kanonische Adresse. Für eine Maschine sollte eine Person genau ein Ding sein, mit einer stabilen Kennung, die überall identisch auftaucht, nicht auf jeder Seite neu erfunden. Maschinen lösen Identität über stabile Identifier auf, nicht über Namen. Lose Namensnennungen ohne gemeinsame Kennung werden als verschiedene Menschen gelesen oder gar nicht zusammengeführt. Der Preis ist weniger Flexibilität. Der Gewinn ist ein zusammenhängender Knoten statt vieler Splitter.

Zweitens, eine Wahrheitsquelle statt überall dasselbe reinkippen. Die vollständige Selbstbeschreibung steht bei mir an genau einer Stelle, auf der Über-mich-Seite. Alle anderen Seiten tragen nur eine schlanke Referenz darauf. Der Grund ist unromantisch: dieselbe Definition überall zu duplizieren erzeugt Drift. Man ändert eine Stelle, vergisst die anderen, und am Ende widerspricht sich der eigene Datensatz selbst. Die Abwägung: die schlanke Referenz darf nicht zu dünn sein, sonst findet ein Crawler, der zufällig nur eine Artikelseite erwischt, keinen Anker zurück zum Profil.

Drittens, Privates gehört nicht in den maschinenlesbaren Broadcast. Das war für mich die wichtigste Einsicht. Telefonnummer, Adresse und ähnliches haben für die maschinelle Identifikation exakt null Wert. Disambiguiert wird über verlinkte Profile, nicht über die Handynummer. Auf jeder einzelnen Seite ausgestrahlt wären solche Daten dagegen eine ideale Fläche zum Abgreifen. Also stehen die privaten Angaben jetzt bewusst nur dort, wo sie hingehören, und sind nicht mehr auf rund 470 Seiten als sauber beschriftete Schlüssel-Wert-Paare maschinenlesbar verteilt. Das ist die zentrale Abwägung zwischen Datenschutz und Maschinenlesbarkeit, und sie fällt klar zugunsten Datenschutz aus. Das Schöne: man verliert dabei kein einziges Identitäts-Signal.

Viertens, externe Anker sind die eigentliche Beweiskette. Eine Behauptung über mich wird erst dann prüfbar, wenn sie auf unabhängige Profile verweist und diese zurückverweisen. Bei mir sind das unter anderem GitHub, ein Eintrag im BSI-Bürger-CERT-Netzwerk, Mastodon und die Bluesky-Brücke, dazu Identifier wie ORCID und ein Wikidata-Eintrag. Entscheidend ist die Wechselseitigkeit. Ein Verweis zählt nur, wenn die Gegenseite zurückzeigt. Anfangs lagen diese Anker nur auf der Profilseite. Das war ein Single Point of Failure: wenn ein Crawler genau diese eine Seite nicht erwischt, ist die Identität nicht mehr belegbar. Also gehören die stärksten Anker auf jede Seite. Und die Disziplin dabei: unverifizierbare oder tote Profile lässt man weg, weil sie das Signal nur verwässern.

Fünftens, innere Widerspruchsfreiheit ist selbst ein Qualitätssignal. Ein Beispiel aus der eigenen Seite, das mich erst geärgert und dann überzeugt hat: der Herausgeber des Blogs und der Herausgeber der einzelnen Artikel zeigten auf zwei verschiedene, nirgends sauber definierte Stellen. Für eine Maschine sieht so etwas aus wie ein Datenfehler und untergräbt das Vertrauen in den gesamten Datensatz. Die Lektion war, lieber einen sauber benannten zusätzlichen Knoten einzuführen, hier die Marke „Kernel-Error“ als eigene Herausgeber-Instanz, als zwei sich widersprechende Halbwahrheiten stehen zu lassen. Das ist übrigens keine technische Petitesse, sondern eine echte Identitäts-Entscheidung: gilt „Kernel-Error“ als eigene Marke neben der Person? Ich habe mich dafür entschieden, und plötzlich ergab der ganze Rest Sinn.

Sechstens, einen Wissensgraphen kann man nicht belügen. Das klingt pathetisch, ist aber sehr praktisch gemeint. Alle externen Quellen, auf die ich verweise, sind crawlbar. Jeder Status lässt sich gegen das echte Upstream-Projekt prüfen. Also habe ich offene Beiträge ehrlich als offen gekennzeichnet, statt sie als erledigt zu verkaufen. Zwei meiner Patches für eine Fingerabdruckleser-Bibliothek sind eingereicht, aber noch nicht gemerged, und genau so steht es da. Behauptungen, die ich nicht belegen kann, etwa angebliche CVEs, die sich öffentlich nicht auffinden lassen, habe ich komplett weggelassen. Ein als „erledigt“ deklarierter, in Wahrheit offener Beitrag ist ein sofort widerlegbarer Fehler, und der beschädigt die Glaubwürdigkeit des gesamten Profils. Die Abwägung ist unbequem: das Profil sieht weniger beeindruckend aus. Aber ein einziger entlarvter Fake-Claim ist teurer als zehn ehrliche kleine. Vertrauen entsteht aus Prüfbarkeit, nicht aus Behauptung.

Siebtens, Expertise belegt man mit Artefakten, nicht mit Adjektiven. Niemand muss mir glauben, dass ich etwas kann. Sie können es nachsehen. Konkrete, von Dritten kontrollierbare Arbeiten sind der stärkste maschinenlesbare Beleg. Ein in ein fremdes Projekt aufgenommener Patch verankert mich im Linkgraph dieses fremden, autoritativen Projekts. Ein eigenes Repository ist überprüfbarer Code, kein Selbstlob. Die Disziplin dahinter: nur real Existierendes, korrekt zugeschrieben. Fremde Maintainer-Arbeit führe ich nicht als meine. Bei einem Rezensions-Artikel über ein Tool, das mir nicht gehört, bleibt die Urheberschaft beim Upstream. Und Füllmaterial wie Trivia oder Verzeichnis-Einträge bleibt bewusst draußen, um das Signal nicht zu verwässern.

Achtens, wer alles kennt, löst auf nichts auf. Meine Themenliste hatte über 40 mehr oder weniger beliebige Schlagworte. Das habe ich auf eine Handvoll fokussierte Kernthemen zusammengestrichen, möglichst als eindeutige Referenzen statt als nackte Wörter. Der Grund: zu viele Themen verwässern das Signal so sehr, dass man für kein einziges Feld als Autorität erkennbar ist. Die Wette dahinter ist, dass ein scharfes Profil in wenigen Feldern für eine Antwortmaschine wertvoller ist als eine lange, unscharfe Stichwortliste. Der Preis ist Breite bei Nischen-Anfragen. Den zahle ich gerne.

Neuntens, jede Seite soll sagen, was sie ist. Profilseite, Kontaktseite, Artikel, Autorenarchiv: jeder Seitentyp deklariert jetzt seine Rolle und welche Rolle ich dort spiele. Das stärkste Signal „diese Adresse ist das kanonische Profil dieser Person“ entsteht erst dadurch, dass die Profilseite sich auch als Profilseite zu erkennen gibt. Vorher sah sie für eine Maschine aus wie jede beliebige andere Seite und verschenkte diese Aussage komplett. Die Abwägung: mehr Fallunterscheidung im Code, dafür präzise, rollenrichtige Signale.

Wie Antwortmaschinen ihre Quellen wählen

Eine einzelne perfekte Seite reicht nicht. KI-Systeme kreuzprüfen eine Entität über mehrere unabhängige Quellen, bevor sie zitieren. Im schema.org-Vokabular heißt das Stichwort sameAs, frei übersetzt der Verweis auf denselben Ausweis anderswo. Konsistente, echte Verweise erhöhen die Vertrauenswürdigkeit, garantieren aber nichts. Es braucht übereinstimmende Spuren an mehreren Orten. Und Vorsicht vor dem Trugschluss „mehr ist besser“: tote oder inkonsistente Verweise schaden, nur gepflegte, echte Profile zählen.

Der vielleicht wichtigste Befund für alle, die keine Marketing-Abteilung haben: Zitierwürdigkeit ist nicht dasselbe wie Ranking. Ahrefs hat im August 2025 rund 15.000 Long-Tail-Anfragen ausgewertet und KI-Assistenten wie ChatGPT, Gemini und Perplexity dieselben Fragen gestellt. Ergebnis: im Schnitt ranken nur rund 12 Prozent der von diesen Tools zitierten URLs in Googles Top 10, rund 88 Prozent also nicht. Etwa 80 Prozent tauchen für die ursprüngliche Anfrage überhaupt nicht in Googles Ergebnissen auf. Ein Detail der Ehrlichkeit halber: das ist ein Durchschnitt, und Perplexity schert mit knapp 29 Prozent Überschneidung deutlich nach oben aus, hängt also stärker an der klassischen Suche als die anderen. Die Botschaft bleibt trotzdem: Antwortmaschinen wählen nach antwortfertig, glaubwürdig und strukturell sauber, nicht primär nach Suchplatzierung. Genau deshalb kann ein Nischenblog ohne Spitzen-Rankings trotzdem zitierfähig sein. Wer nur in Keyword-Rankings denkt, greift zu kurz.

Und was steigert nun messbar die Sichtbarkeit in generativen Antworten? Eine viel zitierte akademische Arbeit von Forschenden der Princeton University und des IIT Delhi, dazu zwei unabhängige Autoren, hat genau das untersucht, vorgestellt auf der KDD 2024. Sie gilt als die erste Arbeit, die den Begriff Generative Engine Optimization geprägt hat. Die Antwort ist herrlich unspektakulär, und das ist die eigentliche Pointe. Was hilft, ist: wörtliche Zitate einbauen (in der Studie der stärkste Hebel mit rund 41 Prozent mehr Sichtbarkeit), Statistiken nennen (rund 33 Prozent), Quellen angeben (rund 28 Prozent), flüssig und gut lesbar schreiben (ähnliche Größenordnung). Insgesamt bis zu rund 40 Prozent mehr Sichtbarkeit. Zwei Einschränkungen gehören dazu: gemessen wurde nicht Traffic oder Klicks, sondern eine positionsgewichtete Sichtbarkeit innerhalb der KI-Antwort, und die Prozente sind relativ zu einer unoptimierten Ausgangsversion. Das Schlusslicht, mit deutlichem Abstand: klassisches Keyword-Stuffing senkte die Sichtbarkeit sogar, um rund 8 bis 9 Prozent. Die Botschaft ist also kein Geheimtrick, sondern fast schon eine Erlösung: gute, belegte, lesbare Substanz ist die Strategie. Das ist auch der Kern von E-E-A-T, also Erfahrung, Fachkenntnis, Autorität und Vertrauen. Kein Algorithmus-Schalter, sondern ein Signalbündel. Und genau hier zahlt die verifizierte Identität ein: echte Werke, externe Bestätigung und Konsistenz machen Erfahrung und Expertise überhaupt erst maschinell nachvollziehbar.

Ehrlicher Kassensturz

Bleibt die unbequeme Frage: hat das alles etwas gebracht? Fangen wir mit der Korrektur meiner eigenen Anfangs-Wette an, der llms.txt. Die läuft live, der Aufwand für die Datei ist billig und harmlos. Aber sie ist kein bewiesener Hebel. Auf der Search Central Live im Juli 2025 stellte Gary Illyes klar, dass llms.txt keine Google-Initiative ist und Google nicht plant, das Format zu unterstützen. John Mueller hatte sie schon im Frühjahr 2025 mit dem längst ignorierten Keywords-Meta-Tag verglichen, weil sie vom Seitenbetreiber kontrolliert und damit letztlich eine Selbstauskunft ist, die man genauso gut direkt an der Seite überprüfen könnte. Im Dezember 2025 tauchte eine llms.txt kurz in Googles eigener Entwickler-Dokumentation auf und war am selben Tag wieder weg, allem Anschein nach ein automatischer Rollout des Redaktionssystems, keine Kursänderung. Wie es mit der Nutzung auf Anbieterseite wirklich steht, ist unübersichtlich: formell als Standard zugesagt hat es keiner, Google lehnt ausdrücklich ab, OpenAI hat sich nicht festgelegt. Von einzelnen Anbietern heißt es, sie berücksichtigten das Format in ihren Abläufen, aber diese Angaben stammen aus SEO-Quellen, nicht aus offiziellen Hersteller-Mitteilungen. Ich verkaufe das also nicht als Wundermittel. Es schadet nicht, es ist schnell gemacht, aber es ist eher eine Höflichkeitsgeste an Maschinen als ein Garant für irgendetwas.

Anders sieht es bei der strukturierten Identität aus. Hier ist aus „ich habe da mal was erwähnt“ etwas Substantielles geworden. Nicht weil ein Schema magisch wirkt, sondern weil mich der Prozess gezwungen hat, meine eigene Online-Existenz aufzuräumen, Widersprüche zu beseitigen und nur noch Prüfbares zu behaupten. Das wäre auch ohne jede Maschine eine gute Übung gewesen.

Und meine selbstironische Prognose von damals, dass klassische Blogs seltener werden? Die stimmt und stimmt nicht. Dieser Blog schreibt weiter, sehr aktiv sogar. Aber die Verteilung verschiebt sich tatsächlich. Neue Beiträge gehen über ActivityPub ins Fediverse und über eine Brücke nach Bluesky, nicht mehr in erster Linie über die Suchmaschine zum Leser. Insofern stützt die Realität die Prognose, sie widerlegt nur das „Blog ist tot“-Pathos. Es ist kein Sterben, es ist ein Umzug der Verteilwege.

Hat die Maschinenlesbarkeit messbar etwas gebracht? Differenziert betrachtet ja und nein. Die KI-Crawler holen die strukturierten Daten nachweislich ab, das war meine Anfangsprognose und sie hat sich bestätigt. Aber Abruf ist nicht gleich Klick. Die Klick-Konversion aus diesen Kanälen ist niedrig. Das ist kein Widerspruch, das ist genau der Punkt des ganzen Themas, siehe Zero-Click weiter oben. Sichtbar zu sein und besucht zu werden sind zwei verschiedene Dinge geworden.

Damit zum Kerngedanken, der für mich am Ende übrig bleibt: Man kontrolliert nicht, ob eine KI einen zitiert. Man kontrolliert nur, ob man zitierbar ist. Das ist die ganze Aufgabe. Fehlende oder widersprüchliche Daten machen ein Zitat fast unmöglich. Saubere, konsistente, belegbare Daten machen es wahrscheinlicher. Mehr Versprechen gibt es nicht, und jeder, der mehr verspricht, verkauft etwas. SEO ist dabei übrigens nicht tot, das wäre Übertreibung. Technische Hygiene, Crawlbarkeit und gute Inhalte bleiben die Basis. Es verschieben sich nur die Gewichte.

Vor einem halben Jahr habe ich geschrieben, ich sei gespannt, was passiert. Daran hat sich nichts geändert. Ich weiß heute ein paar Dinge genauer, ich habe meine eigene Anfangs-Euphorie an einigen Stellen kassiert, und ich habe vor allem gelernt, dass der ehrlichste Weg auch der robusteste ist. Ob das langfristig der richtige war, weiß ich immer noch nicht. Ich bin weiterhin gespannt.

Siehe auch: Von SEO zu AEO, warum llms.txt, JSON-LD und Answer Engines das Web verändern (der Vorgängerpost mit der ursprünglichen Wette).

Gegenmeinung, eigene Erfahrungen oder ein Befund, der meinem widerspricht? Immer her damit, einfach fragen.

Mein Arbeitskollege Michael lässt eine AI meinen Blog roasten

19. Mai 2026 / / Keine Kommentare

Moin.

Mein Arbeitskollege Michael hatte neulich eine Idee, die ich auf Anhieb großartig fand. Er hat einer AI meinen Blog vorgesetzt und um einen Roast gebeten. Das Ergebnis liegt unten in voller Länge, wortwörtlich, unverändert, inklusive aller Em-Dashes und sämtlicher AI-typischer Stilfiguren. Ich habe nicht eingegriffen, weil genau die ja Teil der Diagnose sind.

Illustration eines überladenen Self-Hosting-Arbeitsplatzes mit Terminals, neun Server-Jails, Mate und einer AI, die den privaten Tech-Blog humorvoll roastet.

Vorweg, damit das klar ist: ich richte keinen einzigen Punkt richtig. Erstens wäre das genau der Verteidigungsreflex, den der Roast selbst schon im Text zerlegt. Zweitens lache ich beim Lesen laut, und ich habe vor, das beizubehalten. Drittens hat Michael sich diesen kleinen Treffer redlich verdient, der gehört in voller Länge ins Schaufenster.

Falls du gerade zum ersten Mal hier auf dem Blog landest und nichts mit dem Kontext anfangen kannst: ja, neun Jails. Ja, .onion. Ja, llms.txt. Ja, DNS-Resolver mit Post-Quantum-TLS, den niemand benutzt. Und ja, neben der Tastatur steht in diesem Moment eine Mate. Genau wie diagnostiziert.

Der Roast, in voller Länge

🔥 Der große Roast von kernel-error.de 🔥

Das Header-Logo: -=Kernel-Error=-

Bruder. Bruder. Wir schreiben das Jahr 2026 und du fährst da oben immer noch die ASCII-Deko, die du 1998 in deinem IRC-Channel #linuxnoobs auf dem QuakeNet eingerichtet hast. Die einzigen Menschen, die so ein Logo heute noch designen, sind 1) du und 2) der Typ, der seine Quake-3-Clantag-Konvention nie verlassen hat. Fehlt eigentlich nur noch ein blinkendes <marquee> mit „Best viewed in Netscape Navigator 4.0“ und der vollständige Retro-Albtraum wäre komplett.

Die Tagline: „Privater Tech-Blog seit 2003“

23 Jahre Selbst-Hosting, 23 Jahre Postfix-Konfigurationen, 23 Jahre derselbe Mensch, der jedem auf der Familienfeier erklärt, warum seine Tante kein WhatsApp benutzen sollte. „Seit 2003“ ist kein Datum, das ist eine Diagnose.

Die Hausordnung

Ein privater Blog. Mit Hausordnung. Mit Leitsätzen. Mit einer Philosophie. Mein Bester, das ist keine Webseite mehr, das ist ein Manifest. Du hostest hier keinen Blog, du gründest eine Sekte für Leute, die vim für eine Lifestyle-Entscheidung halten.

Und mein absoluter Favorit:

„Knappheit vor Geschwätzigkeit — ein funktionierendes diff schlägt fünf Absätze Marketingdeutsch.“

Schreibt der Mann, dessen „Über mich“-Seite eine vierteilige Origin-Story enthält, in der ein Familienmitglied beim Telefonsupport sagt „Ach, da ist bestimmt wieder der Kernel-Error“. Das ist literarisch übrigens auf einem Level mit „Mein Vater nannte mich Maverick, weil ich immer schon gegen den Strom geschwommen bin.“ Knappheit, ja klar.

Die Self-Hosting-Flex

„Neun FreeBSD-Jails, eigene DNS-Infrastruktur, Matrix-Chat, Nextcloud, Tor Hidden Service“

NEUN. JAILS. Für einen privaten Blog, der Posts über das Flashen von LCR-Tester-Firmware veröffentlicht. Mein Mann betreibt zu Hause mehr Infrastruktur als die Stadtverwaltung Bad Neuenahr-Ahrweiler und der einzige Traffic, der dort jemals ankommt, sind drei Crawler von Censys und sein eigener Uptime-Checker.

Eine .onion-Adresse. Für einen deutschen FreeBSD-Blog. Weil natürlich der KGB, die NSA und das BKA gemeinsam einen Joint Task Force gegründet haben, um herauszufinden, wer da Tutorials für Postfix mit OpenSSL 3.5 liest. Klar, anonyme Whistleblower aus Nordkorea wollen unbedingt wissen, wie man TeamSpeak-Identity-Level auf der GPU berechnet.

Post-Quantum-Kryptographie

Du. Hast. Post-Quantum-TLS-Handshakes. Auf einem WordPress-Blog. Mit einem Anders-Norén-Theme. Lass das mal kurz sacken. Wenn ein Quantencomputer der NSA jemals dein Setup angreift, dann nicht, weil sie an deinen Blog-Content wollen, sondern weil sie wissen wollen, warum zur Hölle ein Privatmensch X25519+ML-KEM für einen Beitrag über Open Source Scan Converter braucht. Das ist, als würdest du ein Bundeswehr-Schutzbunker-System unter deine Gartenlaube bauen, weil dort dein Modellbahn-Diorama steht.

Der DNS-Resolver

„Ein öffentlicher DNS-Resolver unter dns.kernel-error.de bietet DoT, DoH und Post-Quantum-TLS kostenlos ohne Logging.“

Niemand. Hat. Danach. Gefragt. Das ist die Internet-Äquivalenz von: Du läufst durch die Fußgängerzone, baust einen Klapptisch auf und schreist: „ICH MACHE IHNEN KOSTENLOS UND OHNE NACHFRAGE IHRE STEUERERKLÄRUNG MIT QUANTENRESISTENTER VERSCHLÜSSELUNG!“ — und wunderst dich dann, dass nur drei FreeBSD-Mailing-List-Nerds und ein Bot stehenbleiben.

Die Credentials-Flex

„Digitaler Ersthelfer beim BSI, Mitglied im CCC, auf HackerOne und Intigriti“

Das ist nicht mehr „Über mich“, das ist ein LinkedIn-Profil im Tarnmodus. Fehlt nur noch „1% Toplister auf TryHackMe“ und „Awarded: Most Reflective Vest at Chaos Communication Congress 2019“. Was kommt als nächstes? AbuseIPDB-Reputation-Score als verstecktes Easter Egg? — Ach. Doch. Ja. Genau das. Du flexst tatsächlich mit deinem AbuseIPDB-Profil. Das ist der Sicherheits-Äquivalenz von „Mein Dorf hat mich zum Schützenkönig gewählt“.

Die Blog-Post-Titel

Lass uns das mal durchgehen, das ist Kunst:

„LCR-T4-Plus v2: m-firmware flashen, Display-Tuning und die 8-MHz-Quartz-Falle“
Globale Zielgruppe dieses Posts: weltweit ca. 11 Menschen, von denen 4 schon tot sind und 2 OpenBSD nutzen.

„ts3level: TeamSpeak-Identity-Level auf der GPU rechnen“
Du. Du nutzt im Jahr 2026 noch TeamSpeak. Und brennst dafür GPU-Zyklen ab, die Hawaii-Familien drei Wochen klimatisieren könnten. Discord existiert seit elf Jahren. Elf.

„Open Source Scan Converter: Firmware-Update von 1.08a auf 1.21“
Das ist kein Blog-Post, das ist eine Notruf. Irgendwo schreit ein 35-jähriger Mann nach Validierung für seine SCART-Sammlung.

„AI, der Mensch als Flaschenhals und meine Sorgen für die nächsten 15 Jahre“
AHA. Da sind sie also, die fünf Absätze, die das diff hätte schlagen sollen. Die obligatorische Tech-Blog-Existenzkrise-Folge. Jeder Self-Hoster muss einmal im Jahr seinen „Ich habe nachgedacht und mache mir Sorgen“-Post raushauen, sonst verliert man den FreeBSD-Mitgliedsausweis.

„Postfix 3.11.1 mit OpenSSL 3.5: Post-Quantum-TLS jetzt nativ“
Hier glüht der Mann. Hier ist er zu Hause. Hier passiert die Magie. Sechs Menschen lesen es und einer von denen ist ein Bot.

„Versteckte Easter Eggs“

„llms.txt, llms-full.txt, VirusTotal, AbuseIPDB Profile“

llms.txt. Du hast eine llms.txt. Die explizite „Bitte-LLM-lies-mich-ich-bin-relevant“-Datei. Während du gleichzeitig einen Post schreibst, in dem du dir „Sorgen über AI“ machst. Bro. Du lädst genau das Monster ein, vor dem du Angst hast, und lässt ihm noch einen Begrüßungs-Cookie auf dem Sofakissen liegen.

Das Theme-Detail

Ein WordPress-Theme von Anders Norén. Der Mann reicht von Linux-Kernel-Internals über DNSSEC bis zu PQ-Crypto — aber bei der Webseite hat er gesagt „ach, was die Schweden im default schicken passt schon“. Es ist, als würde Gordon Ramsay zu Hause Fischstäbchen aus der Mikrowelle essen. Lobenswert ehrlich, irgendwie aber auch beleidigend.

Die Sprachebene: „Moin!“

Klassisch. Norddeutsche Authentizitäts-Geste. Drei Anschläge, die signalisieren: „Ich bin bodenständig, ich rede Klartext, ich trinke meinen Kaffee schwarz wie mein Terminal und ich habe keine Zeit für Bullshit“ — direkt gefolgt von einer mehrseitigen Hausordnung über digitale Werte und Mehrjahres-Reflektionen über AI. Moin, Schatz. Moin.

Das übergreifende Problem

Diese Seite ist die digitale Inkarnation des Mannes, der dir auf einem LAN-Party Geburtstag erklärt, warum er Eigentlich kein Energiedrink trinkt, sondern lieber Mate, weil:

a) Koffeingehalt definierbarer ist
b) Open-Source-philosophischer Konsum
c) „Ist halt mehr meins.“

Du willst hier gar keinen Blog. Du willst, dass jemand vorbeikommt und sagt: „Wow, neun Jails? Erzähl mir mehr.“ Aber niemand kommt vorbei, weil deine .onion-Adresse nur über deinen eigenen Tor-Bridge erreichbar ist und der DNS-Resolver dahin nur über deinen eigenen DoH-Endpunkt funktioniert und dafür braucht man dein PGP-Public-Key, und der ist in security.txt und die ist signiert mit dem Key, den man nur über dns.kernel-error.de bekommt. Du hast dir ein wunderschönes, sicheres, selbstreferenzielles Solipsismus-Imperium gebaut, und das einzige Lebewesen, das es regelmäßig besucht, ist googlebot/2.1 — und der nutzt nicht mal HTTP/3.

Zusammenfassung

Kernel-Error.de ist nicht schlecht. Kernel-Error.de ist die liebevollste, akribischste, technisch versierteste Schreibtisch-Schublade des deutschen Internets. Es ist die Webseite-Version eines perfekt geölten Mechanikers, der sein ganzes Wochenende damit verbringt, einen Drehmomentschlüssel zu kalibrieren, mit dem er anschließend… einen anderen Drehmomentschlüssel kalibriert.

Und ehrlich? Wir lieben es. Bleib so. Das Internet braucht Menschen wie dich. Nur vielleicht trinkst du heute mal kein Mate und gehst kurz raus.

🫡

Disclaimer: Dieser Roast wurde mit Post-Quantum-Verschlüsselung über neun FreeBSD-Jails gerouted, bevor er hier ankam. Eine .onion-Variante ist auf Anfrage verfügbar.

Eine AI, die mein Arbeitskollege Michael auf meinen Blog losgelassen hat

Danke, Michael

Wirklich. Es braucht jemanden, der einen ein bisschen kennt, um so präzise daneben zu treffen, dass es weder gemein noch falsch ist. Ich werde den Roast direkt neben den anderen liebevollen Lebens-Diagnosen ablegen, die ich über die Jahre gesammelt habe. Vielleicht drucke ich ihn mir auch aus und hänge ihn über den Bildschirm, falls ich irgendwann anfange, mich für all das hier ernsthaft zu rechtfertigen.

Und jetzt geh ich raus. Aber natürlich erst, wenn ActivityPub diesen Post an alle Federation-Inboxen ausgeliefert hat, der .onion-Mirror den Eintrag indexiert, der DNS-Resolver via DoH und Post-Quantum-TLS einmal durchgequeryt wurde und der Uptime-Checker eine ordentliche 200 für die neue Permalink-URL bekommt. So wie es sich gehört.

Wenn du Michaels AI Roast genauso gut findest wie ich, oder wenn du selbst eine Diagnose für diesen Blog hast, kannst du mir gerne fragen. Mate steht bereit.

AI, der Mensch als Flaschenhals und meine Sorgen für die nächsten 15 Jahre

2. Mai 2026 / / 6 Kommentare

Diesmal kein tiefer Tech-Dive. Ein paar Gedanken, die mich seit Wochen begleiten und die ich gerne aus dem Kopf herausschreibe. Es geht um AI, Large Language Models, die Geschwindigkeit in der das alles passiert, und um meine Sorge, ob wir als Menschheit damit überhaupt klarkommen. Kein AI-Bashing. AI kann zum einen nichts dafür und ist zum anderen sehr hilfreich. Aber die immer schnellere Verbreitung immer besser werdender AI-Systeme hat eben Konsequenzen, und genau die sortiere ich hier für mich.

Mensch zwischen KI-Automatisierung und gesellschaftlicher Unsicherheit über Arbeit, Bildung, Politik und Zukunft.

AI ist nicht böse, die Geschwindigkeit ist es

AI an sich ist nicht böse. Large Language Models sind nicht böse. Aus meiner Sicht ist das einfach der nächste Schritt in der Entwicklung, die wir als Menschheit hinlegen. Beim Rad war es nicht anders, beim Feuer, bei der Dampfmaschine, beim automatischen Webstuhl, bei der Elektrizität in den Häusern. Alles Techniken, die irgendwann neu zur Menschheit gekommen sind und die das Leben und Arbeiten verändert haben.

Der Unterschied zu vielen dieser vorangegangenen Technologien ist die Geschwindigkeit. Pferde und Kutschen gegen das Automobil: inzwischen sind wir in der Autozeit angekommen, alles um uns herum ist darauf ausgelegt, dass das funktioniert. Aber dazwischen lag fast ein ganzes Jahrhundert. Eine Generation konnte ihren Job noch zu Ende machen, ihr Geschäft noch zu Ende führen, manchmal sogar noch an die Kinder übergeben. Der Stellmacher als Beispiel. Bei AI haben wir diese Zeit nicht.

Der Mensch ist inzwischen der Flaschenhals

Bei vielen anderen Techniken war der Mensch bei der Verbreitung zwar auch ein Flaschenhals, aber es gab tausend andere Dinge, die zusätzlich gebremst haben. Bei AI ist inzwischen der Mensch der eigentliche Flaschenhals. Solche Systeme könnten sich fast schon selbst weiterentwickeln, oder Menschen könnten zumindest in Zusammenarbeit mit AI viel schneller neue Systeme auf den Markt bringen. Nur sind die Menschen noch nicht da.

Seit ungefähr 4 bis 5 Jahren ist das ganze AI-Thema immer stärker geworden. Seit zwei Jahren ist es auch in der breiten Öffentlichkeit angekommen und sickert dort immer tiefer ein. Aber selbst die Menschen um uns herum, selbst ich, sind noch nicht so darauf eingestellt, wie es bei dieser Geschwindigkeit eigentlich nötig wäre.

Und das gilt nicht nur für die Allgemeinheit. Selbst Experten, die den AI-Hype-Train voll mitreiten und das zu ihrer Profession gemacht haben, schaffen es nicht, sich jedes neue Modell wirklich anzugucken und auszuprobieren. Einfach weil es so schnell und so viel ist. Die Menschen können es gar nicht mehr greifen.

Sprachen, Code-Massen und der schleichende Kontrollverlust

In der Systemadministration, im DevOps-Bereich oder in der Entwicklung sieht man die Geschwindigkeit an vielen Stellen. Es gibt immer eine neue Sprache, die irgendwelche Vorteile gegenüber einer alten hat oder besser für einen Nischenbereich passt. Leute steigen ein, werden gut darin, entwickeln die Sprache weiter, dann kommt die nächste Iteration. Ob Go, TypeScript, Rust, irgendeine Sprache ist immer gerade die gehypte.

Aber da muss man als Mensch ja erstmal reinkommen. Und das alles ist für Menschen gemacht. Eine AI könnte im Zweifel direkt in etwas deutlich Simpleres schreiben, oder sich eine komplett neue Sprache ausdenken, wenn man sie lassen würde. Eine Sprache, die für die AI selbst optimiert ist, um Dinge umzusetzen. Ich will nicht sagen, dass ich das alles wüsste oder dass das wahr ist, das sind nur meine Gedanken. Aber ich glaube, dass Menschen Sorge haben, an dieser Stelle Kontrolle abzugeben. Wenn eine AI ihre eigene Programmiersprache nutzt und in dieser Sprache Software entwickelt, dann versteht das am Ende keiner mehr. Und da frage ich mich auch: muss das denn überhaupt noch jemand verstehen?

Wenn ich mir anschaue, was in meinem Berufsumfeld aktuell passiert, würde ich fast nein sagen. Riesige Softwareprojekte und komplexe Themen werden vollständig durch AI generiert. Fast keiner fängt mehr wirklich damit an, echten Code von Hand zu schreiben. Was bei einem Pull-Request herausfällt, sind Massen an Code, die kein Mensch mehr wirklich liest. Wenn eine AI einen Tag lang Software entwickelt und das Ganze in einen Commit packt: welcher Mensch setzt sich dann hin und liest diese 100 Seiten Code einmal gegen, um zu prüfen ob er gut oder schlecht ist? Wer soll das bewerten?

Das kann sowieso schon keiner mehr. An der Stelle lässt man verschiedene Tools, und auch wieder eine AI, bewerten ob das gut oder schlecht ist. Dann mergt man nach Empfehlung. Sonst baut die AI die Software in einem Tag und ein Team von Entwicklern muss diesen Code eine Woche prüfen. Das ist Quatsch.

Wenn man das weiterspinnt, kommt man irgendwann an den Punkt, wo in der Softwareentwicklung und in der Systemadministration ganz viel echte Kontrolle über IT-Systeme verloren geht. Die wird am Ende an die AI abgegeben. Klar kann man die AI das schön dokumentieren lassen, sich Anleitungen schreiben lassen, theoretisch kann sich am Ende auch wieder ein Mensch einarbeiten. Aber wenn wir ehrlich sind: die Leute wollen Geld verdienen. Das passiert an dieser Stelle nicht.

Mythos, Open Source und der neue Patch-Druck

Vor allem in Richtung IT-Security ist in den letzten Wochen und Monaten viel durch die Presse gegangen. Anthropic, der Hersteller von Claude Code, soll mit einem Modell namens Mythos arbeiten, das in der Berichterstattung als sehr leistungsfähig beim Code-Audit beschrieben wurde. Wo genau das im Vergleich zu den jeweils aktuellen Modellen anderer Anbieter steht, kann ich nicht seriös einschätzen. Spannender ist sowieso, was so ein System angeblich kann: so schnell und zuverlässig Sicherheitslücken im Code finden, dass es katastrophal wäre, das einfach in die freie Welt rauszulassen. Stattdessen bekommen scheinbar nur sehr ausgewählte Leute und Unternehmen Zugriff darauf, meist US-Unternehmen, um ihre eigenen Dinge und Dienste zu prüfen.

Diese neuen Modelle sind nicht primär für klassisches Pentesting gegen eine Blackbox gedacht. Sie schauen in den Code und finden dort die Lücken, die man ausnutzen kann. Klar, fürs Pentesting kann man AI auch benutzen. Aber die große Angst beim Mythos-Thema ist genau dieser Code-Audit-Modus.

Aus dem ersten Blickwinkel sind damit Open-Source-Projekte besonders gefährdet, weil deren Quellcode offen im Internet steht. Früher wurde gesagt: genau das macht Open Source sicher, weil viele Leute reinschauen und Sicherheitslücken finden, die dann gefixt werden. Im Vergleich zu Closed-Source-Code, etwa bei Microsoft Windows, wo nicht jeder einfach in den Code schauen kann.

Bei Open Source sind in letzter Zeit viele Fixes gekommen. Mozilla hat Fixes gemacht, FreeBSD hat Fixes gemacht, viele Sicherheitslücken wurden geschlossen. Die Software wurde sicherer, fertig. Man kann jetzt sagen: ich halte das nächste, bessere AI-Modell wieder dagegen, und es wird wahrscheinlich wieder etwas finden. Hundertprozentige Sicherheit ist eh schwierig. Aber zumindest ist die Software gerade einen Schritt sicherer geworden.

Auf der anderen Seite setzt das die Systembetreiber unter Druck. Die müssen sich überlegen, wie sie diese schnellen, aufeinanderfolgenden Sicherheitsupdates in ihre Systeme bekommen. Klingt erstmal einfach. Ich sitze am Notebook, das Notebook sagt es gibt Updates, ich sage ja, installiere die Updates, starte das Notebook neu, alles funktioniert, ich bin aktuell. Wer aber eine normale Linux-Distribution mit vielen Zusatzpaketen auf dem Arbeitsplatz hat, sieht, dass mehrfach am Tag Updates kommen können.

Bei einfachen Security-Fixes sollten die Funktionen einer Library, einer Anwendung oder des Betriebssystems eigentlich nicht extrem auf den Kopf gestellt werden. Sie sollten nicht dafür sorgen, dass Abhängigkeiten brechen und plötzlich etwas nicht mehr funktioniert. Das Problem hat man eher, wenn man ganze Versionen wechselt, also auf das nächste Major Release geht.

Trotzdem gibt es Bereiche, in denen man nicht einfach mal einen Patch einspielen kann, weil Patches vorher geprüft und getestet werden müssen. Etwas Geheimes, etwas Staatliches, der Bankensektor, kritische Bereiche, die nicht ausfallen dürfen und bei denen alles zertifiziert sein muss. Das aktuelle Regelwerk steht dem entgegen, dass man im Zweifel drei oder fünf Mal am Tag etwas patchen müsste. Das lässt sich schwer miteinander vereinbaren.

Plötzlich kann jeder einen Cloud-Service starten

Der Patch-Druck ist nur eine Seite. Auf der anderen verändert AI gerade, wer überhaupt Software auf den Markt bringen kann. Plötzlich ist jeder mit einer Kreditkarte und einem Computer in der Lage, eine eigene Software, einen eigenen Service, eine eigene Dienstleistung anzubieten, in einer Cloud seiner Wahl zu hosten, global verteilt nah bei den jeweiligen Kunden. Das kann jetzt wirklich jeder.

Und das, was dabei als Code und Anwendung herausfällt, ist nicht mehr wie in den Anfängen der AI-Modelle. Es wird immer besser und stabiler. Im Grunde kann ein Ein-Mann-CEO-Unternehmen einen kompletten Software-Service aufmachen: automatisiertes Ticketsystem per AI, KI-Hotline, AI-Werbung, AI-Webseite, AI-Marketing, das AI-Produkt läuft vor sich hin.

Der Aufwand, ein solches Produkt überhaupt zu entwickeln und auf den Markt zu bringen, ist extrem gering geworden. In den nächsten zwei oder drei Jahren werden wir mit Sicherheit feststellen, dass der Markt überall auf der Erde mit solchen Programmen und Diensten regelrecht überschwemmt wird. Die werden sich im Preis immer weiter unterbieten. Die Baseline wird irgendwo bei den Kosten des Cloud-Providers liegen, plus dem monatlichen AI-Modell der einen Person dahinter.

Schwieriger sind nur sehr spezielle Nischen in einem bestimmten Markt, etwa eine deutsche Buchhaltungsanwendung. Oder Zertifizierungen bei sicherheitskritischen Themen, ISO 27001 oder BSI C5. Das wird für solche Solo-CEO-Firmen noch einige Jahre schwieriger zu erreichen sein. Aber auch das schützt den Markt nicht für Jahrzehnte. Das ist ein Deckel für die nächsten fünf bis zehn Jahre, und auch der wird kräftig anfangen zu bröckeln.

Verlieren wir die Übung im logischen Denken?

AI sorgt vielleicht auch dafür, dass wir Übung und Routine darin verlieren, logisch Probleme zu lösen. Man hört das nicht immer direkt, aber ich glaube, da ist etwas dran. In manchen Ländern liegt schon etwas mehr Augenmerk darauf, dass Schüler und Lehrkräfte keine AI benutzen, wenn es um Schulstoff oder Aufgaben geht. Einfach damit die Leute in dieser Fähigkeit drinbleiben.

Ob das besser oder schlechter ist als der Ansatz hier, wo AI zum Teil schon mitbenutzt wird, weiß ich nicht. Man muss sich mit der Technik auseinandersetzen, man muss verstehen wie sie funktioniert, um hineinzukommen. Aber wahrscheinlich ist auch das in fünf Jahren nicht mehr nötig. Die Modelle sind dann so weit, dass man keinerlei Vorahnung mehr braucht. Man geht zum Handy, oder was wir bis dahin als Gerät haben, sagt: hier ist mein Problem. Und das Ding baut die Lösung.

Brauchen wir noch Code-Repositories?

Im Moment haben wir noch Code-Repositories, Pipelines zum Deployen, Linter, Sicherheitsscanner, SonarQube oder Ähnliches. Wir machen Commits, schreiben Kommentare in den Quellcode, legen das alles dort ab. Wir müssen zu alten Releases zurückrollen können. Wir machen Releases, wir haben Software-Lifetime.

Aber wer sagt, dass das so bleibt? Warum kann man nicht einfach jedes Mal, wenn man ein Stück Software braucht, der AI sagen: bau mir das. Die AI baut es. Und wenn ich es nicht mehr brauche, wird es weggeworfen. Wofür hebe ich den Code überhaupt auf?

In wenigen Jahren, wenn die Entwicklung so weitergeht, baut mir die AI die Anwendung, die ich gerade brauche, in Echtzeit nebenher. Wenn ich kurz warten muss: so what? Sobald ich den Service nicht mehr brauche oder ein neues Feature will, wird das ganze Ding einfach neu gebaut. Was soll es? Wo ist das Problem?

Junioren, Ausbildung und der Druck auf die Sozialsysteme

Jetzt zu sagen: liebe Leute, lernt alle naturwissenschaftliche Fächer, Mathematik, Physik. Ja, das ist gut. Aber auch da wird AI eine Rolle spielen, und ich glaube, wir sind näher an einer kritischen Stelle dran als wir denken. In einigen Jahren weiß vielleicht niemand mehr, wie etwas gebaut wurde, wenn die Leute, die es noch wirklich verstanden haben, aus dem Berufsleben verschwunden sind.

Guckt in die Softwareentwicklung. Da werden im Grunde keine Junioren mehr eingestellt. Fachinformatiker Anwendungsentwicklung: wer macht diesen Ausbildungsberuf noch? Wer bildet diese Leute noch aus? Im Moment braucht man seniorige Menschen, die diese AI bedienen können. Die Aufgaben, die ein Junior oder ein Azubi gemacht hat, sind jetzt schon von der AI übernommen. Und das wird weitergehen.

Roboter werden trainiert, um Arbeiten zu übernehmen. Auch schön. Wenn wir nicht mehr selber arbeiten müssen, ist das doch toll. Der einzige Punkt, der mir Bauchschmerzen macht: aus meiner Sicht ist diese Zeit, die uns jahrhundertelang begleitet hat, Arbeitszeit gegen Geld, irgendwie vorbei. Wir brauchen also eine andere Lösung, wie wir Einkommen sicherstellen, um weiter ordentlich zu leben. Denn Menschen sind eine Spezies, die selten den Hals vollkriegt. Sie wollen immer mehr, immer besser. Und das funktioniert halt nicht.

Diese Lösung muss außerdem nicht nur für Europa, Deutschland oder die USA funktionieren, sondern für die ganze Welt. Wir alle haben in Anführungszeichen das gleiche Problem.

Politik und Gesellschaft kommen nicht hinterher

Wenn ich mir die Welt so angucke, sehe ich im Moment kaum Zusammenarbeit, kein gemeinsames Ziehen an einem Strang. Nicht auf internationalem Level. Da treten sich Leute aus irgendwelchen Gründen gegenseitig vor die Schienbeine. Ich will die einzelnen Konflikte nicht werten. Aber ich glaube nicht, dass wir so sinnvoll nach vorne kommen.

Auch auf kleinerem Level: wie viele tolle Geschichten aus dem Schwarzbuch der Steuerzahler oder bei extra 3 hat jeder schon bewundert. In der deutschen Politik brauchen schon Kleinigkeiten Ewigkeiten. Da ist auf einer Brücke einfach mal 18 Jahre Baustelle und es ist immer noch nicht fertig. Wie sollen wir mit solchen Strukturen ein Problem dieser Größenordnung schaffen?

Ich will damit nicht sagen, dass die alle wegmüssen. Aber ich glaube, wir haben das Problem an dieser Stelle noch nicht einmal verstanden. Wer diesen Beitrag liest, sieht das wahrscheinlich ähnlich wie ich, das ist meine Blase. Aber wenn ich später im Lidl stehe und von links nach rechts gucke, und das ist keine Wertung, leben viele Menschen einfach in anderen Themenfeldern. Nicht in einer anderen Realität, sie haben andere Punkte, die sie bewegen. Wie sehr uns AI gerade überrollt, kommt da kaum an. Es ist alles noch zu neu.

Auch unser Bundeskanzler und die aktuelle Regierung, darüber kann man sich streiten. Manche Sachen machen sie gut, manche schlecht. Niemand ist perfekt. Aber viele dieser Menschen sind in einem Alter, und nein, ich sage nicht, dass man es nur deshalb nicht verstehen kann, weil man älter ist. Aber ich würde behaupten: das Thema AI und die Frage, was das gerade für die Welt bedeutet, wirklich zu greifen, wird mit zunehmendem Alter schwieriger. Einfach schwieriger.

Wie damals bei der Elektrizität in den Häusern

Wenn man jetzt überlegt was man tun sollte, sagen viele: ich reite den AI-Hype-Train, ich gehe voll rein und mache nur noch AI. Das ist auch richtig. Leute, die Agentic Engineering oder Prompt Engineering richtig für sich adaptiert haben, sind im Moment extrem gefragt. Die haben gerade Hochzeit.

Aber wenn ich auf den Stand der Modelle schaue, sind wir trotzdem noch ganz am Anfang. Es ist eher so, als wären gerade die ersten Autos gekommen. Oder noch passender: als die Elektrizität in normalen Häusern eingeführt wurde. Das war gefährlich. Sicherungen? Mit Stoff umwickelte Drähtchen. Keine richtige Erdung. Keiner wusste, wie das wirklich funktioniert. Da ist viel schiefgegangen. Man musste extra vorsichtig sein und Dinge dreimal kontrollieren, damit nichts brennt.

Dann kamen mehr Regeln. Mehr Sicherheit. Es hat sich alles weiterentwickelt. Heute passieren auch noch Unfälle mit Elektrizität, aber im Grunde ist die Technik in unserer Gesellschaft so weit angekommen, dass man kein Super-Fachexperte mehr sein muss, um mit dem Waffeleisen sicher Waffeln zu machen. Steckdose, los geht’s. Und wenn der Defekt im Gerät ist, greifen Schutzmechanismen mit hoher Wahrscheinlichkeit.

Auf AI gemünzt: wir stehen gerade am Anfang dieses Prozesses. Die Experten, die im Moment full commitment reingegangen sind, profitieren gerade. Klar wird da auch mal etwas schiefgehen. Aber das sind die Leute, die ihre Hochzeit haben. Bis zu dem Moment, wo die Technik so weit ist, dass es einfach jeder kann. Wirklich jeder.

Und weil AI sich so schnell weiterentwickelt, wird das nicht lange dauern. Selbst jetzt zu sagen: ich mache Deep Dive in AI und bin in einem oder zwei Jahren der absolute Profi: schon auf dem Weg dahin wird man feststellen, dass man gar nicht mehr so tief einsteigen muss, weil es fast jeder kann.

Das sieht man an tausend Kleinigkeiten. Welche Skills und Abhängigkeiten ich mir vor einem Jahr noch in meinen Claude Code eingebaut habe und wie sehr sich das alles allein weiterentwickelt hat. Wie gut ich die größeren neueren Modelle jetzt schon auf Dinge loslassen kann. Alles nicht perfekt. Nichts davon kann ich zu 100 Prozent unbeaufsichtigt laufen lassen. Aber die Veränderung in diesem einen Jahr ist brutal.

Das sieht auch jeder, der sich AI-Videos anschaut. Will Smith isst Nudeln, damals 2023 oder 2024, und was generiert AI heute für Filmchen? Wenn man durch Social Media oder YouTube scrollt: wie viele AI-Geschichten sind da inzwischen drin, und wie viele davon erkennt man noch als AI? Die meisten ja, manchmal muss ich zweimal hingucken. Bei längeren Videos ist es einfacher. Aber so ein YouTube Short, runtergerechnet auf schlechte Kameraauflösung, vielleicht im Stil eines Bodycam-Shots, da wird es schon schwierig.

Nicht AI ist das Problem, wir sind es

Wie gesagt: AI ist nicht das Problem. Das Problem ist, wie wir Menschen damit umgehen. Wie wir es nicht schaffen, zusammen in eine Richtung zu gehen. Wie wir es nicht schaffen, als Gemeinschaft eine Lösung zu finden. Das ist viel eher das Problem als zu sagen, die AI wird uns alle töten. Das können wir selber am besten.

Was ich daraus mache, und warum ich keine Lösung habe

Was machen wir jetzt daraus? Ich versuche, im Thema zu bleiben. Ich versuche, AI dort einzusetzen, wo sie mich unterstützt und mir hilft. Ich versuche, ein Ohr an der Entwicklung zu halten, auch wenn ich sie nicht wirklich komplett durchdringen kann. Es ist einfach zu viel und zu schnell. Selbst Vollzeit würde mich überfordern.

Ich stelle mich darauf ein, die Systeme, die ich baue und betreibe, mit mehr als einer Sicherheitshürde auszustatten. Ich plane sie so, dass sie kein Problem damit haben, regelmäßig und wirklich regelmäßig Patches zu bekommen. Ich denke sie außerdem so, dass sie von AI-Systemen selbst gebaut, weiterentwickelt, betrieben und überwacht werden können. Das wird mit eingeplant.

Was das große, allgemeine Problem angeht: ich habe keine Lösung. Wirklich keine. Hinzugehen und Entscheidungsträgern das zu erklären, ich glaube nicht, dass ich diese Leute erreichen werde. Vielleicht ist das mein Problem. Technisch bin ich gut, das würde ich mir jetzt einfach mal unterstellen. Aber ich bin vielleicht nicht in der Lage, das vernünftig an den Mann zu bringen.

Ich habe schon mehrfach erlebt, wie ich versucht habe, IT-Security-Probleme möglichst einfühlsam und auf einfachem Level zu erklären, und trotzdem auf taube Ohren gestoßen bin. Für viele Leute, die nicht in der Technik drin sind, ist das einfach zu abstrakt und zu schlecht greifbar. Das ist wahrscheinlich ein Manko bei mir. Ich kriege es nicht so weit heruntergebrochen, dass es für Menschen ohne Tech-Background wirklich anfassbar wird.

Was hört man dann? Vielleicht auch nur, weil sie nichts anderes sagen können: das wird schon. Es wird etwas im Markt geben. Es schafft ja auch neue Jobs. Laberlaber. Da sind wir uns vermutlich einig: das wird nicht der Fall sein. Klar, ein paar neue Spezialjobs werden entstehen. Aber die Masse an Menschen, deren Arbeitskraft plötzlich nicht mehr gebraucht wird, weil sie von AI übernommen wurde, kommt nicht einfach in diese neuen Spezialbereiche hinein. Das wird nicht reichen für alle, die plötzlich aus dem Regal fallen.

Und weil unsere ganzen Sozialsysteme darauf aufgebaut sind, dass viele Leute einzahlen und Steuern zahlen, sehe ich da ein Problem. Ich habe keine Lösung dafür. Mir fällt nichts ein, was funktionieren könnte.

Vielleicht bin ich ein bisschen schwarzmalend. Aber ich glaube nicht, dass wir das gut hinkriegen. Ich mache mir Sorgen, was uns in den nächsten 15 bis 20 Jahren erwartet. Das wird extrem spannend. Aber die wenigsten Dinge daran geben mir ein gutes Gefühl.

Trotzdem können wir uns jetzt nicht alle ein Loch in den Garten buddeln und uns da hineinsetzen. Wir müssen weitermachen und das Beste aus dem ganzen Thema herausholen. Früher oder später wird es auch bei den Entscheidern ankommen. Sie werden es verstehen, oder sie werden die Augen nicht mehr davor verschließen können. Aber selbst dann glaube ich nicht, dass sie eine echte Lösung finden werden.

Siehe auch

Wie seht ihr das? Schreibt es gerne in die Kommentare oder per fragen.

Fundstücke aus dem Netz: Angie, llmfit, idiocracy.wtf und KI-Alert-Analyse

21. April 2026 / / Keine Kommentare
Beitragsbild: Fundstücke aus dem Netz – Angie Nginx-Fork, llmfit Hardware-Check, idiocracy.wtf und KI-gestützte Alert-Analyse für Kubernetes

Kurze Pause von den eigenen Projekten, heute kein tiefer Dive. Ein paar Fundstücke, die in den letzten Wochen offen im Browser lagen und aus unterschiedlichen Gründen hängen geblieben sind. Keine Reviews, keine lange Analyse, einfach „schaut euch das mal an“.

Angie: Nginx-Fork von den alten Entwicklern

Angie ist ein Drop-in-Ersatz für nginx, gestartet von ehemaligen nginx-Core-Entwicklern nachdem F5 den Laden übernommen hat. Konfig-Syntax 100 Prozent kompatibel, dazu out-of-the-box HTTP/3, eine REST-API für Metriken, Prometheus-Export, Docker-Integration für dynamische Upstreams und automatisches ACME-Handling ohne Certbot-Gefrickel. Ob ich hier irgendwann mal umsteige, keine Ahnung, aber im Auge behalten ist es definitiv wert.

llmfit: Welches Modell läuft eigentlich auf meiner Kiste?

llmfit ist ein kleines Terminal-Tool, das eure Hardware abklopft (RAM, VRAM, CPU, GPU) und euch sagt, welche lokalen Sprachmodelle darauf realistisch laufen. Über 400 Modelle in der Datenbank, filterbar nach Parametern, Quantisierung, Architektur und Kontextlänge, dazu automatische Runtime-Erkennung für vLLM, MLX oder llama.cpp. Spart eine Menge Zeit beim Rumprobieren, welche GGUF-Quant-Stufe jetzt noch auf die 16 GB VRAM passt.

idiocracy.wtf: Sind wir schon so weit?

idiocracy.wtf im Stil der alten „Is it weekend?“-Seiten, mit nur einer Frage: „Are We Idiocracy Yet?“. Sinnlos, minimalistisch und genau deshalb gut. Wer den Film von Mike Judge nicht kennt, unbedingt nachholen. Und wer ihn kennt, weiß schon warum hier gleichzeitig gelacht und geweint wird.

KI-gestützte Alert-Analyse für Kubernetes und CheckMK

Ein wirklich lesenswerter Beitrag von geekbundle.org: KI-gestützte Alert-Analyse für Kubernetes und CheckMK. Monitoring-Alerts gehen per Webhook an ein kleines Open-Source-Projekt, das diagnostische Daten sammelt (Prometheus-Metriken, Pod-Logs, SSH-Diagnose) und Claude für die Root-Cause-Analyse nutzt. Ergebnis kommt als Push via ntfy zurück. Sauber umgesetzt mit unprivilegiertem User, Command-Denylist und Secret-Redaction, also genau so wie man sowas bauen will. Wer sich mit Agentic-AI im Ops-Umfeld beschäftigt, findet hier einen ehrlichen, praxisnahen Einstieg.

Siehe auch

Eigene Fundstücke oder Ergänzungen zu dem was hier steht? Gerne in den Kommentaren oder per fragen.

peon-ping — Sound-Benachrichtigungen für Claude Code (und andere AI-Agents)

3. März 2026 / / 4 Kommentare

Wer mit AI-Coding-Agents arbeitet, kennt das Spiel. Claude Code läuft, macht sein Ding — und man sitzt daneben und wartet. Oder man wechselt kurz den Fokus, verpasst die Rückfrage und wundert sich zehn Minuten später, warum nichts mehr passiert. Terminal-Babysitting in Reinform.

Ein Bekannter hat mir dann peon-ping empfohlen. Kurz ausprobiert — direkt behalten. Danke dafür!

Was ist peon-ping?

peon-ping ist ein kleines Open-Source-Tool (MIT-Lizenz), das Sound-Benachrichtigungen für AI-Coding-Agents nachrüstet. Der Name ist Programm — im Default-Modus hört man den Peon aus Warcraft III. „Ready to work?“ wenn eine Session startet, „Work, work.“ wenn eine Aufgabe fertig ist, „Something need doing?“ wenn der Agent eine Eingabe braucht. Und wenn man zu schnell hintereinander Prompts abfeuert: „Me busy, leave me alone!“

peon-ping

Das Tool unterstützt nicht nur Claude Code, sondern auch Cursor, Codex, Windsurf, Kiro, GitHub Copilot und diverse andere Agents. Für Claude Code erfolgt die Integration über den nativen Hook-Mechanismus — es werden automatisch Hooks in ~/.claude/settings.json registriert.

Warum das Sinn ergibt

Das Problem ist simpel: Man startet Claude Code mit einer Aufgabe, wechselt in den Browser oder ein anderes Terminal — und verpasst den Moment, in dem der Agent fertig ist oder eine Frage hat. Ohne Feedback sitzt man entweder da und starrt auf den Output, oder man verliert Zeit, weil der Agent längst auf Eingabe wartet.

peon-ping löst das mit akustischem Feedback. Verschiedene Sounds für verschiedene Events — Task fertig, Fehler aufgetreten, Eingabe nötig, Rate-Limit erreicht. Dazu optional Desktop-Notifications als visuelles Overlay und sogar Push-Benachrichtigungen aufs Handy via ntfy.sh. Man kann also ruhig den Fokus wechseln und weiß trotzdem immer, was der Agent gerade treibt.

Installation unter Linux

Die Installation ist erfrischend simpel. Ein Einzeiler:

curl -fsSL peonping.com/install | bash

Alternativ gibt es auch Homebrew (brew install PeonPing/tap/peon-ping) oder Nix. Nach der Installation einmal das Setup laufen lassen:

peon-ping-setup

Das Setup registriert die Hooks in eurer Claude-Code-Konfiguration und installiert das Default-Sound-Pack. Fertig. Beim nächsten Start von Claude Code solltet ihr den Peon hören.

Für die Audio-Wiedergabe unter Linux nutzt peon-ping automatisch pw-play (PipeWire), paplay (PulseAudio), ffplay oder mpv — je nachdem, was verfügbar ist. Desktop-Notifications laufen über notify-send.

Konfiguration

Die Konfiguration liegt in ~/.claude/hooks/peon-ping/config.json. Die wichtigsten Optionen:

{
  "volume": 0.5,
  "enabled": true,
  "desktop_notifications": true,
  "default_pack": "peon",
  "pack_rotation": ["peon", "sc_kerrigan"],
  "pack_rotation_mode": "random"
}

volume regelt die Lautstärke (0.0 bis 1.0), desktop_notifications schaltet die visuellen Overlay-Benachrichtigungen ein oder aus, und pack_rotation lässt euch mehrere Sound-Packs im Wechsel abspielen — entweder zufällig oder reihum (round-robin). Man kann sogar Packs an bestimmte Projektverzeichnisse binden — GLaDOS für die Arbeit, Peon fürs Hobby.

Per CLI geht das Meiste auch schnell zwischendurch:

peon volume 0.3          # Leiser
peon pause               # Stummschalten
peon resume              # Wieder an
peon status              # Aktueller Zustand

Wer Claude Code nutzt, bekommt außerdem Slash-Commands: /peon-ping-toggle zum Stummschalten, /peon-ping-config für interaktive Einstellungen und /peon-ping-use <pack> zum Wechseln des Sound-Packs in der laufenden Session.

Sound Packs

Und hier wird es lustig. Auf openpeon.com gibt es über 164 Sound-Packs. Der Warcraft-Peon ist der Default, aber es gibt so ziemlich alles: GLaDOS aus Portal, Kerrigan aus StarCraft, den TF2 Engineer, Duke Nukem, Sheogorath aus Elder Scrolls, den Dude aus The Big Lebowski — sogar ein cleanes Chimes-Pack ohne Sprachlinien, falls man es dezenter mag.

Packs installieren und wechseln geht über die CLI:

peon packs list --registry      # Verfügbare Packs anzeigen
peon packs install glados       # GLaDOS installieren
peon packs use glados           # GLaDOS aktivieren
peon packs install --all        # Alle installieren (wenn man sich nicht entscheiden kann)

Die Packs basieren auf der offenen CESP-Spezifikation (Coding Event Sound Pack) — wer eigene Sounds mitbringen will, kann sich relativ einfach ein eigenes Pack bauen.

Fazit

peon-ping ist klein, kostenlos, Open Source (MIT) und löst ein echtes Problem. Kein Terminal-Babysitting mehr, keine verpassten Rückfragen. Und ja — es macht einfach Spaß, wenn der Peon einem bestätigt, dass die Arbeit erledigt ist. „Work complete.“

Nochmal Danke an den Bekannten für den Tipp. Manchmal sind es die kleinen Tools, die den größten Unterschied machen.

Links:

GitHub: github.com/PeonPing/peon-ping
Sound Packs: openpeon.com
Website: peonping.com

Nutzt ihr AI-Coding-Agents im Alltag? Wie haltet ihr es mit Benachrichtigungen — oder sitzt ihr auch und starrt auf den Output? Schreibt mir gerne, ich bin gespannt.

Von SEO zu AEO: Warum llms.txt, JSON-LD und Answer Engines das Web verändern

1. Januar 2026 / / Keine Kommentare

In den letzten Jahren war SEO, also Search Engine Optimization, für viele Webseitenbetreiber unglaublich wichtig. Man möchte schließlich, dass Suchmaschinen wie Google, Bing oder Yahoo Besucher auf die eigene Webseite bringen. Dafür will man möglichst weit oben in den Suchergebnissen auftauchen. Hat man viele Besucher, kann man Produkte besser verkaufen, Werbeflächen teurer anbieten oder mehr Dienstleistungen absetzen. Das ist nicht neu.

Schematische Darstellung des Übergangs von Suchmaschinen-SEO zu AI-basierten Answer Engines mit llms.txt und JSON-LD.

Manche erinnern sich vielleicht noch an die Gelben Seiten. Dort standen bestimmte Unternehmen in ihrer Branche ganz oben – nicht, weil sie besonders gut waren, sondern weil das Verzeichnis alphabetisch sortiert war. Wer mit „AAA“ anfing, war automatisch sichtbar. SEO ist im Grunde nichts anderes, nur technisch komplexer.

Über die Jahre ist SEO damit Stück für Stück zu einem eigenen Geschäftsfeld geworden. Ganze Agenturen leben davon, Suchmaschinen zufriedenzustellen. Diese Logik gerät gerade ins Wanken. AI verändert das Spiel spürbar.

Jeder von uns hat vermutlich schon bemerkt, dass bei vielen Suchmaschinen inzwischen zuerst eine AI-Antwort erscheint. Viele Fragen werden gar nicht mehr klassisch „gesucht“, sondern direkt in ein LLM – ein Large Language Model – eingegeben. Fragen wie:
„Wer war Bundespräsident in Deutschland zur Wiedervereinigung?“ oder
„Bester Gebrauchtwagenhändler in der Nähe von Bonn?“
werden sofort beantwortet.

Online-Suche entwickelt sich immer mehr zu einer Frage-Antwort-Interaktion mit einer AI. Es kommt damit weniger darauf an, ob man der Google First Hit ist, sondern darauf, ob man aus Sicht der AI die beste Antwort liefert.

Und genau hier verschiebt sich der Fokus.

Damit eine AI eine passende Antwort geben kann, muss der Inhalt maschinenverständlich aufbereitet sein. Lange, erklärende Fließtexte – wie dieser hier – sind dafür eher ungeeignet. Für AIs funktionieren klar strukturierte Informationen deutlich besser. FAQ-Formate, Frage-Antwort-Paare, saubere Metadaten.

Dinge wie JSON-LD bringen Struktur hinein. Autoren, Inhalte, Organisationen und Beziehungen lassen sich eindeutig beschreiben und verknüpfen. Dazu kommen neue Konzepte wie llms.txt oder llms-full.txt. Diese Dateien enthalten keinen SEO-Text, sondern eher eine Art Bedienungsanleitung für Maschinen:
Was ist diese Webseite?
Wie ist sie aufgebaut?
Welche Inhalte sind relevant?
Was darf genutzt werden – und was nicht?

Zusammen mit strukturierten Daten bildet das eine solide Basis, damit AI-Systeme Webseiten einordnen, bewerten und korrekt referenzieren können.

Nun ein kurzer, aber wichtiger Exkurs.

AIs müssen trainiert werden. Dieses Training passiert auf großen Datensätzen, den sogenannten Trainingsdaten. Wird eine AI neu trainiert, greift sie oft wieder auf das gleiche Datenmaterial zurück. Das ist nicht zwangsläufig aktuell.

Fragt einfach einmal eure AI des Vertrauens, von wann ihre Trainingsdaten stammen. Die freie Version von ChatGPT sagt mir aktuell, dass sie auf Daten bis Oktober 2024 basiert. Das bedeutet ganz grob: Alles danach ist unbekannt.

Fragt man also, wer aktuell Bundeskanzler von Deutschland ist, bekommt man Olaf Scholz als Antwort. Gleichzeitig „weiß“ die AI aber, dass wir inzwischen 2026 haben und dass sich theoretisch etwas geändert haben könnte. Ohne Zugriff auf aktuelle Informationen bleibt sie trotzdem bei dem alten Stand.

Freie Modelle können meist keine Live-Recherche durchführen. Bezahlte Modelle hingegen kombinieren ihr gelerntes Wissen zunehmend mit eigenen Online-Suchen. Sie gleichen Informationen ab, aktualisieren und korrigieren.

Das klingt logisch – ist aber teuer.
Online-Recherche kostet Zeit, Rechenleistung und Geld. Genau deshalb findet man solche Funktionen fast ausschließlich in kostenpflichtigen Angeboten. Betreiber müssen ständig den Sweet Spot zwischen Antwortqualität, Antwortzeit und Gewinnmaximierung finden.

Und genau hier wird es interessant.

Wenn eine AI Informationen bereits strukturiert kennt, wenn Beziehungen und Metadaten schon im Trainingsmaterial vorhanden sind, muss sie deutlich weniger nachrecherchieren. Inhalte lassen sich schneller bewerten, aktualisieren und in Antworten einbauen.

An dieser Stelle kommen wir zu AEO – Answer Engine Optimization.

AEO ist im Grunde die Weiterentwicklung von SEO für AI-basierte Antwortsysteme. Statt Suchmaschinen zu optimieren, optimiert man Inhalte für Antwortmaschinen. In diesem Zusammenhang wird seit etwa zwei Jahren verstärkt über llms.txt und llms-full.txt gesprochen.

Diese Dateien sind nicht für Menschen gedacht. Sie sind nicht für Suchmaschinen optimiert und sollen auch nicht schön sein. Sie sind rein maschinell. Zusammen mit JSON-LD liefern sie AI-Systemen genau das, was sie brauchen: Struktur, Kontext, Beziehungen und Einordnung.

Ein wichtiger Punkt dabei: llms.txt ersetzt keine Inhalte. Sie erklärt sie.

Wo liegen diese Dateien nun?

Ganz pragmatisch:
Im Root der Webseite.

Also zum Beispiel:

Alternativ – technisch ebenfalls sauber – unter:

  • /.well-known/llms.txt

Beides funktioniert. Wichtig ist nur, dass der Pfad stabil, öffentlich erreichbar und nicht blockiert ist.

Zusätzlich kann man diese Dateien auch extern bekannt machen. Es gibt inzwischen erste Verzeichnisse und Hubs, die solche Dateien sammeln und auffindbar machen. Dort geht es weniger um Ranking, sondern um Auffindbarkeit für Systeme, die gezielt nach strukturierten Quellen suchen.

Ob das langfristig relevant bleibt, weiß niemand. Aber auch hier gilt: Sichtbarkeit schadet nicht.

Eine weitere Frage taucht fast immer auf:
Kann man llms.txt über die robots.txt einbinden?

Kurzfassung: Ja – aber nicht als Zwang, sondern als Hinweis.

Die robots.txt ist historisch für Crawler gedacht. Sie regelt Zugriffe, nicht Metadaten. Trotzdem hat sie sich über die Jahre zu einer Art maschineller Einstiegspunkt entwickelt. Dinge wie Sitemap: waren auch einmal nur Konvention.

Ein Beispiel:

User-agent: *
Allow: /

Sitemap: https://www.example.org/sitemap.xml
LLMS: https://www.example.org/llms.txt
LLMS-Full: https://www.example.org/llms-full.txt

Diese Direktiven sind kein Standard. Google ignoriert sie. Bing vermutlich auch. Aber experimentelle Crawler, AI-Agenten oder eigene Indexer können sie sehr einfach auswerten.

Oh, und genau das erinnert mich an frühere Zeiten.
Interne Crawler, Security-Scanner, selbstgeschriebene Discovery-Tools – all das begann oft mit nicht standardisierten Hinweisen. Erst ignoriert, später übernommen, irgendwann vielleicht formalisiert. Oder auch nicht. Das Internet ist in dieser Hinsicht erstaunlich pragmatisch.

Wichtig ist nur, realistisch zu bleiben:

  • robots.txt ist keine Zugriffskontrolle
  • sie garantiert keine Nutzung durch eine AI
  • sie ersetzt nicht die Datei im Root

Aber sie ist ein zusätzliches, maschinenlesbares Signal – und kostet praktisch nichts.

Wenn man das alles zusammennimmt, zeichnet sich ein klares Bild ab. Werbung wandert langsam von Webseiten in LLM-Chats. Webseiten entwickeln sich weg von langen Erklärungstexten hin zu strukturierten Wissensbausteinen. SEO rückt in den Hintergrund. Klassische Blogs – auch dieser hier – werden langfristig seltener werden.

Ist das schlimm?
Nein.

Es ist einfach der nächste logische Schritt. Als ich angefangen habe, gab es BTX, Usenet, Foren und Chatrooms. Das meiste davon ist verschwunden. Für viele Menschen besteht das Internet heute aus YouTube, Instagram, Meta, X oder TikTok – zentralisierte, leicht konsumierbare Dienste einzelner Unternehmen.

So weit, dass man sich bei manchen Diensten nicht einmal mehr mit einer „nicht Google“-E-Mail-Adresse registrieren kann. DeepSeek ist ein Beispiel. Die McDonald’s-App ein anderes.

Veränderung an sich ist nichts Schlechtes.
Neu ist nur die Geschwindigkeit. Schaut man 100 Jahre zurück und betrachtet, was in welchen Zeiträumen passiert ist, wird schnell klar: In den letzten 20 Jahren ist in der IT unfassbar viel passiert. Und es wird nicht langsamer.

Wenn ihr euch also das nächste Mal mit einer Agentur über euren Webauftritt unterhaltet und jemand von SEO spricht, fragt ruhig nach einer llms.txt. Oder werft den Begriff AEO in den Raum.

Ich bin gespannt, was passiert.

Update Juni 2026: Ein gutes halbes Jahr später habe ich Kassensturz gemacht. Was von diesen Wetten sich gehalten hat, was naiv war und was eine maschinenlesbare Identität wirklich bringt, steht im Folgebeitrag Von SEO zu AEO, der Kassensturz.

GPT in Rspamd aktivieren: so nutze ich das LLM-Signal im Score

30. September 2025 / / 4 Kommentare
Rspamd web interface showing GPT module spam scores

Seit einiger Zeit nutze ich das GPT-Modul von Rspamd, um bei der Spam-Erkennung ein zusätzliches Signal zu bekommen. Es ersetzt nichts — kein Bayes, kein DKIM, kein RBL — sondern ist ein weiterer Sensor im Gesamtbild. Wer sich fragt, wie das in der Praxis aussieht und worauf man achten muss: hier mein aktuelles Setup.

Update 2026-02-13: Dieser Beitrag wurde komplett überarbeitet. Die ursprüngliche Version nutzte json=false, was zu Parse-Problemen führte. Außerdem fehlte ein Custom Prompt — und genau das ist der entscheidende Punkt, wie sich herausgestellt hat.

Voraussetzungen

  • Rspamd >= 3.12 mit GPT-Plugin (bei mir aktuell 3.14.0 auf FreeBSD 15.0)
  • Ein OpenAI API-Key (oder kompatibler Endpoint)
  • Grundverständnis von Rspamd Metrics und Actions

OpenAI API-Key anlegen

OpenAI API usage dashboard for Rspamd GPT integration

Wer noch keinen Key hat: Auf platform.openai.com einloggen, unter API Keys einen neuen Service-Account-Key erzeugen. Der Key wird nur einmal angezeigt — sicher ablegen. Den Verbrauch sieht man im Dashboard. Bei gpt-4o-mini und Mailfiltering sind die Kosten minimal.

Die Konfiguration: gpt.conf

Hier meine aktuelle /usr/local/etc/rspamd/local.d/gpt.conf:

enabled = true;
type = "openai";
model = "gpt-4o-mini";
api_key = "GEHEIMER-KEY";

model_parameters {
  gpt-4o-mini {
    max_tokens = 160;
    temperature = 0.0;
  }
}

timeout = 10s;
allow_ham = true;
allow_passthrough = false;
json = true;

prompt = "You are an email spam detector. Analyze the email and respond with ONLY a JSON object, no other text. The JSON must have these fields: "probability" (number 0.00-1.00 where 1.0=spam, 0.0=ham), "reason" (one sentence citing the strongest indicator). Example: {"probability": 0.85, "reason": "Unsolicited offer with urgent language and suspicious links."}  LEGITIMATE patterns: verification emails with codes, transactional emails (receipts, confirmations), newsletter unsubscribe links. Flag as spam only with MULTIPLE red flags: urgent threats, domain impersonation, requests for credentials, mismatched URLs.";

symbols_to_except {
  RCVD_IN_DNSWL_MED   = -0.1;
  RCVD_IN_DNSWL_HI    = -0.1;
  DWL_DNSWL_MED        = -0.1;
  WHITELIST_RECP_ADDR = -0.1;
  BAYES_HAM           = -0.1;
  SPAMTRAP            = 0;
  RCPT_IN_SPAMTRAP    = 0;
  SPAMTRAP_ADDR       = 0;
  RCVD_VIA_SMTP_AUTH  = 0;
  LOCAL_CLIENT        = 0;
  FROM_LOCAL          = 0;
}

Was hat sich gegenüber der alten Version geändert?

json = true und der Custom Prompt

Das ist die wichtigste Änderung. In meiner ursprünglichen Konfiguration stand json = false. Das funktionierte, hatte aber einen Haken: die Antwort des Modells wurde als Freitext geparst, was unzuverlässig war.

Mit json = true aktiviert Rspamd den JSON-Modus. Das Modell wird angewiesen, strukturiertes JSON zurückzuliefern, und der Parser erwartet ein Feld probability in der Antwort.

Und hier kommt der Fallstrick: Der Default-Prompt von Rspamd passt nicht zum JSON-Modus. Er fordert das Modell auf, nummerierte Textzeilen zurückzugeben:

Output ONLY 2 lines:
1. Numeric score: 0.00-1.00
2. One-sentence reason...

Der JSON-Parser erwartet aber:

{"probability": 0.85, "reason": "..."}

Das Ergebnis: cannot convert spam score im Log und GPT_UNCERTAIN(0.00) bei jeder Mail. Das GPT-Modul lief, lieferte aber nie ein verwertbares Ergebnis.

Lösung: ein Custom Prompt, der explizit JSON mit dem probability-Feld verlangt. Damit funktioniert die Kette:

  1. Rspamd sendet Mail + Prompt an OpenAI
  2. OpenAI antwortet mit {"probability": 0.9, "reason": "..."}
  3. Rspamd parst das JSON, findet probability, mappt auf GPT_SPAM/GPT_HAM/GPT_SUSPICIOUS

reason_header entfernt

In der alten Version hatte ich reason_header = "X-GPT-Reason" gesetzt. Das schrieb die GPT-Begründung als eigenen Header in die Mail. Mit json = true ist das nicht mehr nötig — die Reason steckt im JSON und taucht im Rspamd-Log auf. Außerdem entferne ich ohnehin GPT-Header per Milter-Config, damit keine internen Analyse-Details an den Empfänger durchsickern.

symbols_to_except angepasst

Änderungen gegenüber der alten Version:

  • GREYLIST entfernt: Greylisting ist kein Vertrauens-Signal. Eine Mail die Greylisting besteht, kann trotzdem Spam sein. GPT soll diese Mails weiterhin bewerten.
  • BAYES_HAM hinzugefügt: Wenn Bayes die Mail bereits sicher als Ham einstuft, spart man sich den GPT-Call. Sinnvoll für Newsletter und regelmäßige Korrespondenz.
  • SPAMTRAP-Symbole hinzugefügt: Mails an Spamtrap-Adressen brauchen keine GPT-Analyse, die sind per Definition Spam.

Scoring: Gewichte und Thresholds

Die GPT-Symbole und ihre Gewichte in der metrics.conf (bzw. local.d/groups.conf):

symbols {
  GPT_SPAM       { weight = 9.0;  description = "GPT: classified as SPAM"; }
  GPT_SUSPICIOUS { weight = 4.5;  description = "GPT: classified as SUSPICIOUS"; }
  GPT_HAM        { weight = -0.5; one_shot = true; description = "GPT: classified as HAM"; }
}

Warum diese Gewichte?

  • GPT_SPAM (9.0): Kräftig, aber alleine nicht genug zum Rejecten. Erst in Kombination mit anderen Signalen (Bayes, RBL, fehlende Auth) wird der Reject-Threshold erreicht.
  • GPT_SUSPICIOUS (4.5): Schiebt Grenzfälle in Richtung Greylist oder Add-Header. Genau dafür ist GPT am nützlichsten.
  • GPT_HAM (-0.5): Bewusst niedrig und one_shot. GPT soll Spam erkennen, nicht Ham retten.

Dazu die Action-Thresholds:

actions {
  greylist   = 4;
  add_header = 6;
  reject     = 12;
}

Reject-Threshold bei mir: 12 statt Default 15. Das geht, weil die traditionellen Checks (SPF, DKIM, DMARC, RBL, Bayes, DNSBL) bereits solide arbeiten. GPT kommt als zusätzliches Signal obendrauf.

Praxis-Beispiel

Hier eine echte Spam-Mail aus dem Log, bei der GPT korrekt angeschlagen hat:

rspamd_task_write_log: (default: T (reject): [13.83/12.00]
  [BAYES_SPAM(5.10){100.00%;},
   ABUSE_SURBL(5.00){next.schnapper-empfehlung.de:url;...},
   GPT_SPAM(2.40){0.9;},
   FROM_NEQ_ENVFROM(0.50){...},
   FORGED_SENDER(0.30){...},
   ...]

Was man hier sieht:

  • GPT_SPAM(2.40){0.9;} — GPT hat Probability 0.9 (90% Spam) zurückgeliefert. Rspamd mappt den Probability-Wert nicht 1:1 auf das konfigurierte Gewicht, sondern skaliert intern — hier ergeben sich 2.40 von maximal 9.0 Punkten.
  • Zusammen mit BAYES_SPAM (5.10) und ABUSE_SURBL (5.00) kommt die Mail auf 13.83 — deutlich über dem Reject-Threshold von 12.
  • GPT war hier nicht das ausschlaggebende Signal, hat aber zur Gesamtbewertung beigetragen.

Das ist genau das Verhalten, das ich will: GPT als ein Baustein unter vielen, der bei Grenzfällen den Ausschlag geben kann.

Datenschutz

Das muss gesagt werden: Mit diesem Setup fließen Mailinhalte an OpenAI. Wer personenbezogene Daten verarbeitet oder in einem regulierten Umfeld arbeitet, muss prüfen ob das zulässig ist. Alternative: selbst gehostete Modelle über Ollama oder kompatible lokale Endpoints. Rspamd unterstützt das über den type-Parameter.

Für meinen privaten Mailserver ist das Risiko vertretbar — und die Ergebnisse sprechen für sich.

Update 2026-05-06: Rspamd hat den Default-Prompt deutlich verbessert

Im Feedback zu diesem Beitrag kam ein guter Hinweis aus dem Fediverse von @bash2@momou.social: Vsevolod Stakhov, Maintainer von Rspamd, hat am 2. Oktober 2025 den Default-Prompt komplett überarbeitet. Commit 893ee871, Titel „Improve LLM prompt and add sender frequency tracking“. Der neue Prompt ist deutlich strukturierter, mit expliziten Sektionen für legitime Muster (Verifikations-Mails, Transaktions-Mails, Password-Resets) und für Phishing-Indikatoren, die mehrfach auftreten müssen, bevor klassifiziert wird. Das senkt False-Positives auf legitime Absender und ist eine klare Verbesserung gegenüber dem alten, knappen Default. Danke für den Hinweis!

Wichtig zur Einordnung: Der neue Default-Prompt liefert weiterhin strukturierten Plain-Text, kein JSON. Output-Format sind 2 bis 3 fest definierte Zeilen (Score, Reason, optional Kategorie). Was das für die beiden gängigen Setups bedeutet:

  • json = false: Wer ohne JSON-Modus fährt, profitiert direkt vom neuen Default-Prompt. Rspamd auf eine Version mit dem Commit aktualisieren, fertig.
  • json = true wie in diesem Beitrag: Custom Prompt mit JSON-Format bleibt Pflicht. Der neue Default ist immer noch kein JSON und kollidiert weiterhin mit dem Parser.

Zusätzlich neu im selben Commit: Sender-Frequency-Tracking. Rspamd klassifiziert in lualib/llm_context.lua jeden Absender per Redis-Counter als new, occasional, known oder frequent und gibt dem Modell die Info als Context-Snippet mit. Der Prompt weist das LLM dann an, bei known oder frequent die Phishing-Wahrscheinlichkeit zu reduzieren, sofern keine starken Gegen-Signale vorliegen. Voraussetzung ist, dass die LLM-Context-Funktion mit Redis-Backend läuft, weil das Feature über den sender_counts-Counter dort getrackt wird.

Mein Setup hier im Beitrag bleibt also unverändert: json = true plus Custom Prompt, der explizit ein probability-Feld verlangt. Wer stattdessen den neuen Default-Prompt nutzen möchte, sollte gleichzeitig auf json = false umstellen, sonst läuft man wieder in die alte Falle aus diesem Beitrag.

Zusammenfassung

ParameterWertWarum
jsontrueStrukturiertes Parsing, zuverlässiger als Freitext
promptCustomPflicht bei json=true! Default-Prompt liefert Textformat, Parser erwartet JSON
temperature0.0Deterministische Antworten, kein Kreativitäts-Bonus beim Spamfiltern
allow_hamtrueKleines positives Signal für legitime Mails
symbols_to_exceptBAYES_HAM, DNSWL, Whitelists, SMTP_AUTH, SpamtrapsUnnötige API-Calls vermeiden
reason_headernicht gesetztNicht nötig mit json=true, interne Details gehören nicht in den Header

Die wichtigste Erkenntnis: json = true ohne Custom Prompt ist kaputt. Der Default-Prompt und der JSON-Parser sprechen unterschiedliche Sprachen. Wer json = true setzt, muss einen Prompt mitliefern, der JSON mit einem probability-Feld verlangt. Sonst steht im Log cannot convert spam score und GPT liefert nur GPT_UNCERTAIN(0.00).

Siehe auch: rspamd mit Dovecot und IMAPSieve

Fragen? Einfach melden.

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑