Und wieder melde ich mich gut gelaunt und überhaupt nicht gefrustet aus dem Maschinenraum. Heute: Wie meine site()->index()-Abfragen meine Seite fast gekillt hätten. Und ich wie immer selbst daran schuld gewesen bin.

Aber von vorne.

Vielleicht war es keine gute Idee, an ein, zwei Abenden bei Trakt nachzupflegen, welche Serien ich alles schon gesehen habe. Denn das hat mich auf Ideen gebracht. Zum Beispiel: Ich könnte ja dann auch gleich alle Serien und alle Filme auf gesonderten Seiten ausgeben. Und bei Serien könnte ich ja auch noch, einfach weil es so schön ordentlich ist, die Staffeln sortieren und den Serien zuordnen.

Und wenn ich schon dabei bin: Das Ganze könnte ich doch langsam über APIs aufbauen. Klar, die Watchdaten sind nur so halb akkurat, weil ich erst ab diesem Zeitpunkt angefangen habe, Serien sauber zu tracken. Aber ganz ehrlich: Ein bisschen Unschärfe ist immer noch besser als gar keine Daten.

Und wenn ich dann schon ungefähre Watchdaten habe, kann ich ja auch direkt Watchlog-Einträge erzeugen. Wer weiß, wofür die noch gut sind.

Die Konsequenz? Plötzlich hatte meine Seite über 8.000 Watchlog-Einträge. Und über 8.126 Episoden und Filme. Mit einer Watchdauer von sage und schreibe 8,5 Monaten! Aber darum soll es hier gar nicht gehen. Manche Statistiken sollte man vielleicht einfach nicht berechnen.

Worum es geht: Ich hatte plötzlich keine kleine, gemütliche Seite mehr. Sondern ein leicht zickiges Monstrum, das morgens, wenn die Botschwärme aufwachen, meinen Server zuverlässig in die Knie zwingt.

Und schuld daran war natürlich ich.

Ich habe für jede kleine Anzeige von Content einfach site()->index() benutzt. Bedeutet: Immer erst einmal die komplette Website laden, alles durchscannen, tausende Seitenobjekte bauen und dann 99,9 Prozent davon wieder wegwerfen. Klassisches Beispiel:

„Gib mir alle Seiten, filtere Reviews raus, sortiere nach Datum und zeig mir die neuesten fünf.“

Das funktioniert. Aber eben nur so lange, wie die Seite klein ist.

Mit wachsendem Content wurde das zum Problem. Nicht, weil Kirby schlecht ist, sondern weil ich bequem war. „Hol alles, filter später“ ist einfach, aber teuer.

Was ich jetzt stattdessen mache:

Ich scanne die Inhalte genau einmal, ziehe mir daraus nur die relevanten IDs und speichere diese als Cache. Und danach arbeite ich nur noch mit diesem vorbereiteten Datensatz. Keine globalen Scans mehr pro Request, sondern ein vorbereiteter, günstiger Zugriff.

Das habe ich inzwischen umgesetzt für:

• Tag-Lookups
• Film- und Serienverzeichnisse
• Watchlog-Beziehungen
• den Home-Feed
• meine Stories-Rail

Das Prinzip ist immer gleich: einmal berechnen, dann cachen.

Dann kam die nächste „gute“ Idee: Prewarming. Also Seiten im Hintergrund vorladen, damit sie für euch schneller da sind. Klingt erstmal sinnvoll.

War es auch. Nur habe ich es natürlich übertrieben.

Ich habe das Prewarming als Self-Requests direkt bei normalen Seitenaufrufen eingebaut. Bedeutet: Ein Request erzeugt mehrere neue Requests auf sich selbst. Solange wenig Traffic da ist, geht das gut. Sobald aber Bots anfangen, parallel meine Seiten zu crawlen, kippt das System.

Und genau das ist passiert.

Bots wie GPTBot, AhrefsBot oder SemrushBot haben parallel angefangen, vor allem die Suche aggressiv abzuklappern. Gleichzeitig liefen meine eigenen Prewarm-Requests. Ergebnis: Alle Worker belegt, nichts geht mehr.

Deshalb habe ich jetzt zwei Dinge geändert:

Die Suche ist für Bots gesperrt
Prewarming passiert nur noch minimal, aktuell nur für die Startseite
Alles andere beobachte ich erstmal.

Die eigentliche Erkenntnis aus der ganzen Geschichte ist aber ziemlich simpel:

site()->index()ist nicht falsch, solange man es nicht übertreibt, so wie ich ich.

Wenn man es bewusst für globale Aufgaben nutzt, ist alles gut. Wenn man es aber im Frontend bei jedem Request mehrfach benutzt, während die Seite wächst und komplexer wird, dann baut man sich ziemlich zuverlässig einen Flaschenhals.

Ich musste innerlich lachen, als ich mich dabei erwischt habe, ernsthaft zu denken, dass meine kleine Kirby-Seite jetzt erst einmal feature-complete ist. Das war wirklich ein ernsthafter, ehrlicher Gedanke. Vollkommen unironisch.

Und trotzdem kenne ich mich ja schon auch ein bisschen und habe mich schon beim Denken über mich gewundert und deshalb die letzten Tage wieder etwas im Maschinenraum rumgeschraubt:

Ich habe jetzt meine Tags-Seite versucht zu durchhirnen und aufzubohren. Denn: Ich hasse es, Inhalte zu vertaggen. Aber: Ich finde es auch unglaublich hilfreich, wenn ich es denn mal gemacht habe, um schnell Sachen wiederzufinden.

Was ich dabei gemerkt habe: Selbst wenn es niemanden interessieren sollte, gebe ich mir bei den Bookmarks viel mehr Mühe, wenn ich die hier auf hnz.io reinhaue, als wenn ich sie bei Obsidian ablege oder in die Notiz-App paste. Die gefühlte Öffentlichkeit zwingt mich zu Struktur. Und das finde ich tatsächlich hilfreich.

Ich habe jetzt ein zweigliedriges Tag-System eingeführt. Ich wähle im Artikel einfach die Kategorie aus, Kirby zeigt mir die entsprechenden (vorher angelegten) Unterkategorien an und ich muss nur noch Häkchen setzen. Ich glaube, das bekomme ich hin.

Gleichzeitig habe ich zusammen mit Chatty (Codex mit GPT-5.4) eine Taxonomie-Seite gebaut: Jeder Tag hat jetzt (wie bei WordPress) einen Beschreibungstext und für die Suche noch Synonyme. Damit es egal ist, ob man bei mir nach llm, ki, ai oder so etwas sucht.

Diese Daten habe ich genutzt, um meine Tag-Seite aufzubohren, sodass sie für mich wirklich nützlich ist. Da steht jetzt erst einmal die neue Struktur mit Hauptkategorie und Unterkategorie.

Außerdem lasse ich dort meine Orte und Locations durchsuchbar ausgeben sowie alle Regie-Leute und Haupt-Casts von Serien und Filmen, die ich getrackt habe.

Teilweise nutze ich dafür auch einfach die Loupe-Suche, um Inhalte anzuzeigen. Also eigentlich für alles, was kein klassisches Thema oder Tag ist.

Dabei habe ich gemerkt: Ich muss da noch einmal ran und das besser auf meine Bedürfnisse zuschneiden. Und ich hoffe wirklich, dass ich es so umgebaut habe, dass auch andere gut damit klarkommen.

Denn, in aller Kürze: Ich habe viele Inhalte doppelt. Gefühlt und tatsächlich.

Wenn ich einen Film logge, wird der als Watchlog automatisiert importiert. Wenn ich dazu einen längeren Text schreiben will oder nur einen Kommentar, lege ich einen entsprechenden Post an und sage dem Artikel: Bitte zeige bei der Rezension die Watchcard an. Das hier ist zum Beispiel eine Rezension von mir mit einer zugeordneten Watchcard. Und das die entsprechende Watchcard.

Das führt dazu, dass bei einer Suche wie "Starfleet Academy" sowohl meine Rezensionen als auch die Watchcards aufgetaucht sind. Relevant sind aber eigentlich nur die Rezensionen, weil dort alles aus der Watchcard enthalten ist – plus meine mal mehr, mal weniger sinnvollen Gedanken.

Also: Watchcards ausblenden, wenn ein verknüpfter Text existiert.

Das gleiche Problem habe ich bei Tags. Wenn ich die Watchcard vertagge und später noch einen Beitrag schreibe, habe ich plötzlich doppelte Inhalte unter einem Tag: Watchcard und Rezension.

Das will ich nicht manuell lösen. Ich kenne mich. Das mache ich nicht.

Also habe ich auch hier eine Regel eingebaut: Wenn Inhalte verknüpft sind (Card + Content), werden die Tags übernommen und die Watchcard fliegt aus den Übersichten raus. Wie zum Beispiel hier. Man sieht nur noch die Rezensionen und Artikel – nicht mehr die Watchcards.

Ich muss mal schauen, ob ich mein Tag-Management GitHub-fähig bekomme oder ob das wieder viel zu speziell auf mein Hirn und dieses Projekt zugeschnitten ist.

Wen’s generell interessiert: Ich habe jetzt meine einfachen Plugins für die Sharecard, Exif-Import und AI-Text veröffentlicht.

Manchmal merkt man erst, wie langsam eine Website geworden ist, wenn man sie selbst aufruft und plötzlich Zeit hat, sich einen Kaffee zu holen.

Genau so ging es mir mit meiner Seite hier: Die Startseite brauchte plötzlich bis zu sechs Sekunden, bis überhaupt etwas passierte. Um mich nicht falsch zu verstehen: bis der erste HTML-Response kam. Danach liefen CSS, JavaScript und Bilder völlig normal durch. Das Problem lag also ziemlich offensichtlich vor dem Browser, irgendwo auf dem Server.

Sechs Sekunden sind nicht nur für einen Androiden, sondern generell im Web eine Ewigkeit. Also habe ich mir Chatty dazugeholt, um mir beim Debuggen zu helfen.

Die Ausgangslage war schnell klar: Der erste Request auf hnz.io/ hing. Danach ging alles zügig weiter. Das spricht meistens dafür, dass der Server beim Rendern der Seite lange beschäftigt ist.

Mein erster Reflex war die klassische Performance-Lösung: Caching.

Der erste Versuch: Staticache

Kirby hat von Haus aus schon ein Caching-Modul an Board, ich habe mich aber zusätzlich noch für Staticache entschieden. Das berechnet im ebsten Fall eine Seite bis zur nächsten Änderung einmal vor und gibt dann die Vorberrechnete Version an die Browser weiter.

Zusätzlich habe ich die gzip-Komprimierung eingeschaltet. Gzip ist eine Technik, mit der Textantworten wie HTML oder CSS kleiner gemacht werden, bevor sie übertragen werden. Das spart Bandbreite und beschleunigt die Übertragung.

Der erste Test brachte allerdings eine kleine Überraschung: Die Startseite brauchte immer noch mehrere Sekunden.

Wenn Caching nicht hilft

Das war der Punkt, an dem klar wurde, dass der Cache gar nicht das eigentliche Problem löst.

Wenn eine Seite trotz Cache mehrere Sekunden braucht, dann passiert eines von zwei Dingen:

• Entweder der Request landet gar nicht im Cache.
• Oder der Request muss trotzdem noch viel dynamische Logik ausführen.

Raten bringt an dieser Stelle nichts. Also haben Chatty und ich angefangen zu messen.

Ein kleiner Performance-Schalter

Ich wollte eine möglichst leichte Lösung, etwas, das direkt auf dem Server mitläuft und nur dann aktiv ist, wenn ich es brauche und habe ich einen kleinen Schalter eingebaut.

Wenn man die Seite mit ?perf=1 aufruft und eingeloggt ist, schreibt die Anwendung Performance-Daten in ein Log. Zusätzlich erscheinen Timing-Informationen im HTTP-Header, die ich dann im Browser anzeigen kann.

Gemessen wurden drei Dinge:

• Bootstrap: der Start von PHP und Kirby
• Renderzeit: das eigentliche Erzeugen der HTML-Seite
• Gesamtzeit: alles zusammen

Zusätzlich habe ich kleine Marker eingebaut, mit denen man bestimmte Stellen im Code messen kann. Wenn ein Snippet oder eine Funktion auffällig langsam ist, taucht sie im Log sofort auf.

Das Ganze ist im Grunde ein sehr einfacher Profiler. Nicht besonders elegant, aber extrem hilfreich.

Die Spur führt ins Rendering

Die Messungen zeigten ziemlich eindeutig, wo die Zeit verloren ging und zwar, und das hat mir ungemein geholfen, nich im Netzwerk, DNS oder im TLS-Handshakke. Die ganze Zeit ging für das PHP-Rendering der Seite drauf: Der Server war mehrere Sekunden damit beschäftigt, die Startseite zu berechnen, bevor überhaupt etwas an den Browser geschickt wurde.

Damit war klar, dass wir uns meine Templates und Snippets anschauen müssen. War ja irgendwie auch klar.

In Kirby sind Snippets kleine wiederverwendbare Template-Blöcke. Man kann sie sich wie Komponenten vorstellen, die HTML generieren.

Viele kleine Verzögerungen

Die Logs zeigten ein interessantes Muster: Der heftigste Block war die Liste der Beiträge auf der Startseite. Das Snippet, das die Feed-Karten erzeugt, brauchte mehrere Sekunden.

Innerhalb dieses Blocks tauchten immer wieder ähnliche Zeitwerte auf. Viele einzelne Schritte lagen jeweils bei ungefähr 300 Millisekunden.

Das klingt erstmal nicht dramatisch, aber wenn ein Feed zehn Beiträge hat und jeder Beitrag mehrere solcher Schritte ausführt, summiert sich das schnell auf mehrere Sekunden.

Ein Beispiel waren Social-Links aus dem IndieConnector. Dabei handelt es sich um Funktionen, die automatisch prüfen, ob ein Beitrag auf Mastodon oder Bluesky veröffentlicht wurde und welche URL dazu gehört. Die hatte ich mal auf die Schnelle eingebaut. Und nun ja.

Man sollte nichts auf die Schnelle einbauen.

Niemals.

Zwar ist die Auflösung auf einer Detailseite völlig okay. Im Feed bedeutet sie aber, dass dieselben Informationen mehrfach berechnet werden.

Dazu kamen kleine Dinge wie Bild-Fallbacks oder Kommentarzählungen, die ebenfalls für jeden Beitrag erneut ausgeführt wurden. Teilweise mehrfach.

Der entscheidende Schritt

Die Lösung bestand letztlich darin, zwei verschiedene Kontexte sauber zu trennen: Die Startseite ist ein Listing. Sie zeigt viele Beiträge gleichzeitig. In diesem Kontext muss alles möglichst leichtgewichtig sein.

Eine Detailseite dagegen zeigt nur einen einzigen Beitrag. Dort kann man sich mehr Rechenzeit leisten.

Also habe ich einige Funktionen im Feed bewusst abgeschaltet oder vereinfacht.

• Social-Links werden im Listing nicht mehr komplett aufgelöst.
• Kommentarzahlen greifen auf bereits berechnete Metriken zurück.
• Einige Bildlogiken wurden reduziert.

Die Detailseiten behalten weiterhin die vollständige Funktionalität.

Das Ergebnis ist eine klare Trennung: Der Feed bleibt schnell, während Detailseiten alle Informationen anzeigen.

Und Chatty hat dabei geholfen, die kritischen Stellen zu identifizieren und die Messungen sauber auszuwerten.

Ein kleiner Nebeneffekt

Während wir ohnehin am Feed gearbeitet haben, habe ich auch die Bildgrößen angepasst.

Die Startseite lädt jetzt kleinere Vorschaubilder. Große Originale werden erst geladen, wenn man sie tatsächlich öffnet.

Das reduziert Bandbreite und sorgt dafür, dass der Browser weniger Arbeit beim Layout hat. Der eigentliche Performance-Gewinn kam aber weiterhin vom Server.

Was ich aus der Geschichte gelernt habe

Die wichtigste Lektion ist überraschend simpel:

• Performanceprobleme löst man nicht durch Rumratwn, sondern durch Messungen Und die Spurensuche hat echt Spaß gemacht, war mein erstes Mal.
• Caching ist hilfreich, aber kein Allheilmittel. Wenn der Flaschenhals im Rendering liegt, muss man verstehen, was genau dort passiert.
• Oft sind es nicht große, offensichtliche Probleme, sondern viele kleine Kosten pro Eintrag.
• Baue niemals auf die schnelle irgendetwas ein, ohne dir vorher Gedanken zu machen oder es zumindest zu testen.

Die letzten Wochen habe ich wieder im Hintergrund an meinem Kirby rumgeschraubt. Oder besser gesagt: rumschrauben lassen. Ich habe Codex mit meinem Visual Studio Code getestet und mal geschaut, wie dieses Vibe Coding so funktioniert. Und ich muss sagen: Zunächst wirkt es wie Zauberei, im Laufe des Projekts wird es dann etwas ernüchternder. Es fühlt sich eben an wie die Arbeit mit einer LLM, die schneller den Kontext verliert, als einem lieb ist, und ab und an schöne Dinge halluziniert. Im Endeffekt ging es trotzdem viel schneller als gedacht.

Mein ursprüngliches Ziel, das Layout komplett konsistent neu aufzuziehen, habe ich dabei allerdings etwas aus den Augen verloren. Manche Rundungen unterscheiden sich noch, manche Schriftgrößen stimmen noch nicht ganz. Aber ich bin auf jeden Fall auf einem guten Weg. Und ja, die Seite sieht jetzt anders aus. Beim ursprünglichen Layout habe ich mich noch stark an meiner alten micro.blog-Seite orientiert. Mit der Zeit und dem ganzen Rumfrickeln passiert es bei mir automatisch, dass ich mich Schritt für Schritt davon emanzipiere.

Was ich eigentlich noch gar nicht einbauen wollte, jetzt aber schon live ist, ist das Medientracking. Da habe ich mich natürlich auch wieder inspirieren lassen.

Felix hat auf seiner Seite einen River aufgesetzt, in den er alles reinschmeißt, was er gut findet oder konsumiert. Thomas hat mit seinem Recorder zwar eine andere Umsetzung, aber ein ähnliches Konzept. Das Leben zu loggen finde ich spannend. Auswertungen und Charts zu generieren finde ich ebenfalls großartig. Und jetzt gibt es das auch hier: Den Medienstrom.

Ich wollte mich dabei am IndieWeb orientieren, bin aber ehrlich gesagt noch in der Findungsphase. Es gibt jetzt die Bookmarks, in die alles reinkommt, was ich so lese und für veröffentlichenswert halte. Dann gibt es das Watchlog mit Videos für YouTube, Filme und Serien. Und schließlich noch den Audiofeed, in den ich alles werfe, was ich gerade höre. All das läuft jetzt im Medienstrom zusammen, den man auch, ich weiß zwar nicht genau warum, als RSS abonnieren kann.

Warum bin ich noch in der Findungsphase? Weil sich das für mich gerade so anfühlt, als wären das gleichzeitig auch Favoriten. Die Trennschärfe fehlt mir noch. Wenn alles klappt, sollen Einbindungen hier als Reposts gesehen werden. Eigentlich sollen sie das auch sein. Oder sind es doch Favoriten, weil ich auf einen bestimmten Text hinweisen möchte oder auf einen besonders guten Tröt? Ich bin da gerade selbst noch etwas verwirrt und hoffe, dass ich das alles so offen gebaut habe, dass ich es bei Bedarf schnell wieder umbauen kann.

Da ich mein eigenes Hirn aber gut kenne und weiß, dass es gerne den Weg des geringsten Widerstands geht, habe ich mir ein paar Prozesse ausgedacht, mit denen Inhalte automatisiert hier landen können. Oder zumindest ohne großen Aufwand.

Filme tracke ich über Letterboxd. Die bieten einen wirklich vernünftigen RSS-Feed an, in dem sogar schon eine TMDB-ID steht. Darüber kann ich mir über die TMDB-API noch zusätzliche Daten zu dem Film ziehen. Ein Importscript sorgt per Cron dafür, dass regelmäßig nachgeschaut wird und neue Filme automatisch hier auf der Seite erscheinen.

Bei Serien nutze ich trakt.tv und dessen API. Dort bewerte ich schnell eine Folge, die ich gesehen habe, und durch ein Importscript landet sie dann auch hier. Wenn ich noch schnell einen Kommentar schreiben möchte, geht das ebenfalls. Und wenn ich den Eintrag später auf die Startseite heben will, klappt das auch noch. Wie zum Beispiel hier.

Ganz automatisch funktioniert auch der Import über meinen RSS-Service Miniflux. Wenn ich dort einen Artikel markiere, habe ich hier einen Endpunkt eingerichtet, der die Daten per POST übergeben bekommt und dann entsprechend darstellt.

Und für den Rest habe ich mir tatsächlich Kurzbefehle auf meinem iPhone gebaut. Das Einrichten war ein ziemlicher Pain. Aber irgendwie hat es funktioniert. Und zwar sogar besser, als ich am Anfang erwartet hatte. Die Kurzbefehle nehmen einfach die URL aus der Zwischenablage, geben mir die Möglichkeit, einen Kommentar zu schreiben, und fragen dann ab, ob der Beitrag im entsprechenden Segment oder auch auf der Startseite veröffentlicht werden soll. So bekomme ich YouTube und Vimeo hier rein und generell Bookmarks, die ich nicht in meinem Feedreader finde.

Bei Podcasts habe ich es mir ehrlich gesagt etwas einfacher gemacht. Ich nutze die App Pocket Casts, die viele Verzeichnisse noch einmal selbst spiegeln. Die Daten hole ich mir dann einfach von dort. Falls ihr euch also fragt, warum meine Podcasts auf Pocketcast.com verlinken und nicht irgendwo anders: Das ist keine Empfehlung für die App oder sogar Werbung, es macht für mich einfach das Teilen leichter.

Deshalb habe ich jetzt auch drei Kurzbefehle. Einen für den Audiostream, einen für Bookmarks und einen für das Watchlog. Über „Teilen“ ist dann schnell ein Beitrag hier angelegt, der zumindest niemanden stört. Und mich freut.

Wenn ich etwas gar nicht schreiben würde, schreibe ich’s lieber mit LLMs, besonders da, wo Barrierefreiheit dranhängt. Nicht, weil ich es nicht könnte, sondern damit nichts liegen bleibt: Alt-Texte, Meta-Descriptions, diese stillen Pflichtfelder, die am Ende irgendwie auch wichtig sind, aber dafür auch noch einmal richtig viel Zeit kosten können, ohne das der eigentliche Beitrag davon auf den ersten Blick profitiert.

Aus dieser … nenne ich es einmal … Faulheit ist ein kleines Kirby-Plugin entstanden, das zwei Dinge zuverlässig erledigt: barrierefreie Alt-Texte für Bilder und sachliche Meta-Descriptions für Seiten. Auf Knopfdruck direkt im Panel.

Ich gebe dem Modell den vollen Kontext, setze Length-Guards und formatiere die Antwort passgenau: ca. 110 Zeichen für Alt, ca. 160 für Meta. Optional kann das Plugin das Bild als Data-URL mitschicken („Vision“), damit die KI nicht im luftleeren Raum rät.

Warum klappt das so erstaunlich gut? Weil Kirby Inhalte und Mediendaten wunderbar strukturiert. Alle Bild-Metadaten liegen in Sidecar-Contentdateien neben der Bilddatei, z. B. mein-foto.jpg.txt. Menschenlesbar, versionierbar, und serverseitig perfekt als Prompt-Kontext nutzbar.

Damit das sauber bleibt, habe ich zwei kleine Helfer daneben gelegt. Mein Plugin sync-meta hält Felder synchron, die sowohl in der Seiten-Contentdatei (default.txt) als auch in den Bild-Sidecars (bild.jpg.txt) vorkommen. Zum Beispiel liegt die Bildunterschrift bei einem Beitrag mit nur einem Bild in der Contentdatei, nicht in der Sidecar. Hintergrund ist, dass mein System historisch gewachsen ist und sich die Anforderungen, je besser ich Kirby kennenlerne, auch immer wieder anpassen.

Das Plugin exif-import sorgt dafür, dass Sidecars nicht leer starten: Beim Upload lese ich optional EXIF/IPTC aus und fülle Datum, Ort, Kamera, ggf. Caption vor – was immer das Asset hergibt. Danach muss die KI nicht mehr raten, sie ergänzt.

Der Generierungs-Flow ist bewusst serverseitig: Das Panel schickt nur IDs. Das Backend sammelt Kontext (Seitentitel, Teaser, Text, Bild-Captions, optional Geodaten), ergänzt auf Wunsch das Bild selbst und nutzt zentral gepflegte, nüchterne Prompts. Ton und Stil kann ich global in der config.php oder je Blueprint feinjustieren.

Wenn der Kontext zu dünn ist, breche ich ab, statt Floskeln zu produzieren. Und wenn ich „zu faul“ bin, drücke ich guten Gewissens auf „Vorschlagen“ – besser ein kurzer KI-Text als gar keiner. Genau dafür ist das da.

Am Ende schreibe ich weiterhin gern selbst, aber ich finde es sehr angenehm, Sachen zu automatisieren, die sonst aus Zeitgründen wegfallen würden. Barrierefreiheit profitiert (Alt-Texte sind da!) und mein Kopf bleibt frei für die Teile, die wirklich menschliche Aufmerksamkeit brauchen.