CosmoCode Blog – Detlef Hüttemann

KI klaut unseren Traffic, und wir holen ihn uns mit KI zurück

huettemann@cosmocode.de (Detlef Hüttemann) — Thu, 24 Sep 2026 00:00:00 GMT

Wir spüren den Traffic-Rückgang deutlich. Dreißig bis vierzig Prozent weniger Besuche sind kein Ausschlag, das ist ein Bruch. KI-basierte Antworten nutzen unsere Inhalte, ohne dass jemand unsere Seiten besucht. Verhindern können wir das nicht. Aber wir haben uns gefragt, ob wir genau diese Technologie nutzen können, um gegenzusteuern.

Was wir aktuell ausprobieren, ist kein schnellerer Reporting-Zyklus, sondern etwas anderes: Wir verknüpfen KI mit den echten Suchdaten, Inhalten und der Änderungshistorie einer Website, um Einsichten zu bekommen, deren Fragen wir früher gar nicht gestellt hätten. So können wir nicht nur Änderungen dokumentieren, sondern rückwirkend bewerten, ob sie wirklich etwas gebracht haben.

Fragen stellen, wenn sie entstehen

Suchmaschinenoptimierung war immer ein iterativer Prozess. Man analysiert die Sichtbarkeit einer Website, identifiziert Schwächen, nimmt Änderungen vor und schaut einige Wochen oder Monate später, was daraus geworden ist.

Das Problem dabei ist, dass solche Analysen vorbereitet werden müssen. Daten müssen gesammelt, Berichte definiert und Auswertungen programmiert werden. Neue Fragen bedeuten neuen Aufwand. Und häufig merkt man erst im laufenden Prozess, dass man eigentlich etwas ganz anderes wissen möchte.

Genau an dieser Stelle verändert KI für uns die Arbeitsweise. Wir müssen Analysefragen nicht mehr im Voraus festzurren. Wir können sie dann stellen, wenn sie sich aus einer konkreten Beobachtung heraus ergeben und können sie dann auf die vorhandene Historie anwenden.

Dafür verbinden wir die Daten der Google Search Console mit den Inhalten und Strukturen einer Website. Bei dateibasierten Systemen können zusätzlich Änderungen aus der Git-Historie einfließen, bei datenbankbasierten Systemen die jeweiligen Änderungsprotokolle. Das LLM einer KI-Anwendung bekommt so einen holistischen Blick auf die Inhalte und kann Zusammenhänge erkennen, die wir nicht oder nur mit viel Rechercheaufwand sehen.

Vom Befund zum To-do

Analysen helfen uns allerdings nur, wenn wir daraus etwas tun können. Das System sucht deshalb gezielt nach Verbesserungspotenzialen: Offensichtliche Schwächen, aber auch weniger sichtbare Chancen. Seiten, die knapp vor den vorderen Positionen stehen, Themen, die noch nicht gut genug beantwortet sind, Kannibalisierungen oder veraltete Inhalte.

Daraus entstehen To-dos, die nach der Umsetzung wieder in die Historie einfließen. Diese Spur ist nicht in erster Linie für uns gedacht, sondern für das System selbst. Es kann später nachvollziehen, warum etwas geändert wurde, was danach passiert ist und wie sich Kennzahlen entwickelt haben. So entsteht eine Erfahrungsbasis, auf die das System bei künftigen Analysen zurückgreifen kann.

Wann funktioniert ein neuer Artikel?

Ein Beispiel hat uns besonders deutlich gezeigt, was dadurch möglich wird. Wir wollten eine Frage beantworten, die uns eigentlich schon immer begleitet: Wann kann man überhaupt beurteilen, ob ein neuer Artikel funktioniert? Wann ist er im Index? Wann kommen die ersten Impressionen und Klicks? Ab wann sind Daten belastbar genug, um Entscheidungen zu treffen? Die Search Console liefert einzelne Datenpunkte, aber keine direkte Antwort darauf.

Das LLM hat selbstständig eine Kohortenanalyse erstellt. Alle neuen Webseiten wurden automatisch mit dem Median der gleich alten Seiten verglichen – so konnten wir sehen, ob sich ein Artikel besser, schlechter oder im Rahmen entwickelt.

Neu war für uns dabei weniger das statistische Verfahren an sich, sondern wie schnell die KI die passende Analyse für unsere Fragestellung ausgewählt und umgesetzt hat … und wie einfach sich diese Analyse anpassen lässt, wenn wir andere Schwerpunkte setzen wollen.

Wie es weitergeht

Die nächste Herausforderung liegt für uns darin, die Analyse mit der Struktur der Website zu verbinden. Gute Websites bilden fachliche Zusammenhänge ab und verwenden unterschiedliche Dokumenttypen und semantische Modelle. Diese Semantik muss verstanden und technisch angebunden werden. Nicht nur zum Lesen, sondern perspektivisch auch, um freigegebene Änderungen gezielt zurückzuschreiben.

Daran arbeiten wir gerade mit unserem Werkzeug Trailmarks. Aktuell setzen wir es vor allem auf eigenen Websites ein. Im nächsten Schritt wollen wir die gewonnenen Erfahrungen auf unsere TYPO3-Projekte übertragen.

Tarifrechner testen mit PICT

huettemann@cosmocode.de (Detlef Hüttemann) — Mon, 15 Jun 2026 00:00:00 GMT

Finanzprodukte wie beispielsweise Versicherungen berechnen Beiträge mit komplexen mathematischen Verfahren. Je nach Produkt fließen mehr oder weniger viele Einflussgrößen in die Berechnung ein, um unterschiedliche Risiken angemessen zu berücksichtigen. Wenn diese Berechnungsverfahren in Softwarelösungen implementiert werden, müssen die Algorithmen gegen die fachlichen Vorgaben getestet werden. Das stellt Softwareingenieure vor eine besondere Herausforderung, denn Berechnungsfunktionen verhalten sich häufig nicht überall stetig im mathematischen Sinne. Schon geringe Änderungen an den Eingabewerten können größere Änderungen an den Prämien hervorrufen.

Funktionen mit Sprüngen

Die Ursache liegt häufig im Modell der Produktentwicklung. Versicherungsprodukte werden von Aktuaren oft zunächst mit Excel entwickelt. In Excel ist es vergleichsweise einfach, das Verhalten von Parametern über Lookup-Tabellen zu definieren. Diese Lookups sind mathematisch betrachtet Stützstellen einer Funktion. Der Lookup in Excel entspricht dann häufig einer Treppenfunktion. Warum ist das wichtig? Als Softwaretester liegt es nahe, ein konsistentes Verhalten einer Anwendung zu erwarten. Wenn ich das Verhalten der Anwendung an den Extremwerten und in der Mitte teste, könnte ich erwarten, dass sie sich auch an den Zwischenwerten entsprechend gutartig verhält. Genau das ist bei einem stützstellenbasierten Ansatz mit Excel-Lookup-Algorithmen aber nicht zwingend der Fall. Zusätzlich wird es komplexer, wenn solche Variablen im Excel-Algorithmus mit Bedingungen verknüpft werden, wie zum Beispiel:

Wenn Tarifgruppe > 100 und Schadenquote > 1 dann Tarifgruppe -= 10

Mit Tests nach Gefühl kommt man hier nicht weiter. Das macht man ja sowieso nie — oder man nennt es exploratives Testen. Ohne Kenntnis des tatsächlichen Algorithmus lassen sich die neuralgischen Parameterkombinationen, bei denen die Berechnungsfunktion ihr Verhalten ändert, nicht zuverlässig vorhersagen. Die Testabdeckung muss entsprechend hoch angesetzt werden. Testen ist allerdings teuer. Besonders bei Ende-zu-Ende-Tests ist die Durchführungsdauer hoch. Eine Automatisierung der Testdurchführung kann zwar den Personaleinsatz beim Testen reduzieren, erhöht aber die Last auf dem System. Auch das verursacht Kosten. Da das Testen in einen Projektrahmen eingebettet ist, führt eine längere Testdauer außerdem zu einer verlängerten Projektdauer und damit zu Zusatzkosten durch die längere Bereithaltung des Projektteams. Während sich die Werte einer einzelnen Variablen noch vergleichsweise gut bestimmen lassen, zum Beispiel durch Extraktion der Wertetabellen aus den Lookups, ist das Zusammenspiel mehrerer Variablen deutlich schwieriger zu überschauen. Eine Analyse des Referenzrechners in Bezug auf abhängige Variablen ist mit KI zwar gut machbar, löst das Problem aber nicht vollständig. Denn im Soll-Ist-Vergleich zwischen Referenzsystem und dem zu testenden System bleibt das Testsystem eine Blackbox, die durch bewusste oder unbewusste Programmierentscheidungen ein anderes Verhalten aufweisen kann.

Paarweise unabhängige Kombinationen – PICT

Ein ökonomischer Weg, eine sinnvolle Testabdeckung in den Parameterkombinationen zu erreichen, ist das PICT-Verfahren. PICT steht für Pairwise Independent Combinatorial Testing. Der Begriff beschreibt den Ansatz recht genau: Ausgehend von den Testwerten der Einzelparameter sorgt das PICT-Verfahren dafür, dass für je zwei Parameter alle Wertekombinationen dieser beiden Parameter abgedeckt sind. Da ein Testdatensatz nicht nur die beiden jeweils betrachteten Parameter enthalten muss, sondern auch die übrigen Parameter, entstehen automatisch auch bestimmte 3er- und 4er-Kombinationen. PICT ersetzt damit nicht die fachliche Teststrategie. Es hilft aber, eine große Menge möglicher Eingabekombinationen systematisch auf eine kleinere, besser handhabbare Menge von Testfällen zu reduzieren.

Beispiel

Ein Beispiel soll das PICT-Verfahren verdeutlichen. Nehmen wir ein Versicherungsprodukt, beispielsweise eine Hausratversicherung, mit den prämienrelevanten Einflussgrößen Laufzeit, Wohnfläche, Schmuck und einem Bonusrabatt. Wir halten die Problemgröße bewusst klein, um die kombinatorische Entwicklung intuitiv einschätzen zu können. Für jeden dieser Parameter legen wir die zu testenden Werte fest.

Parameter und Werte des Beispiels

Laufzeit: 1, 3, 5 Jahre
Wohnfläche: 30 qm, 50 qm, 100 qm, 200 qm
Schmuck mitversichert im Wert von: 0 €, 100 €, 1.000 €
Bonusrabatt: ja, nein Rechnerisch ergeben sich 72 Kombinationen. Eine vollständige Abdeckung hätte also 72 Testdatensätze.

Parameterpaare und deren Kombinationen

Das PICT-Verfahren betrachtet nun alle Parameterpaare und sorgt dafür, dass in diesen Paaren jeweils alle Wertekombinationen abgedeckt sind. Laufzeit hat 3 Werte, Wohnfläche 4 Werte. Für die Kombination Laufzeit × Wohnfläche ergeben sich also 12 Kombinationen. Bricht man dies für alle Parameterpaare herunter, kommt man auf 53 Paar-Kombinationen. Das ist allerdings noch naiv gerechnet, weil die übrigen Parameter in realen Testdatensätzen bereits mitverteilt werden und dadurch mehrere Paar-Kombinationen gleichzeitig abgedeckt werden können.

Datenpacking im PICT-Verfahren

Das PICT-Verfahren versucht nun, die Kombinationen in gemeinsame Testdatensätze zu packen. Das Ergebnis sind in diesem Beispiel 14 dicht gepackte Testdatensätze.

14 PICT-Testfälle bei 72 rechnerischen Kombinationen: In diesem kleinen Beispiel hat das noch keine große praktische Bedeutung. Interessant wird es, wenn wir mehr Werte oder mehr Parameter zulassen. Der Einfachheit halber nehmen wir an, dass alle Parameter genau 10 Werteausprägungen haben. Ein Testlauf des PICT-Verfahrens zeigt, dass die Zahl der PICT-Testdatensätze bei der weiteren Hinzunahme von Parametern nur moderat anwächst.

In der Praxis wächst die Zahl der Testfälle bei paarweiser Abdeckung meist deutlich langsamer als die vollständige kartesische Produktmenge. Das ist der entscheidende wirtschaftliche Vorteil des Verfahrens: Jeder zusätzliche Parameter erhöht den Testumfang, aber nicht in dem Maße, wie es bei einer vollständigen Kombination aller Werte der Fall wäre.

Die grüne Linie in der folgenden Grafik zeigt die Summe aller 2-er Kombinationen. die blaue Linie zeigt die Anzahl der pairwise Kombinationen, die rote Linie die Anzahl der 3-wise.

Auf der horizontalen Achse ist die Anzahl der Parameter eingetragen.

3-wise und Sub-Models

Wenn bekannt ist, dass die Parameterabhängigkeiten im Wesentlichen von mehr als zwei Parametern abhängen, kann das Verfahren entsprechend erweitert werden — mit dem Preis steigender Testfallzahlen. Anstatt hierbei alles auf 3-wise umzustellen, kann man über Sub-Models das 3-wise-Verhalten für einzelne Parametergruppen erzwingen:

# PICT-Beispiel: Versicherungsprodukt mit 7 Parametern
# Standard: paarweise Kombinationen über alle Parameter
# Aufruf z. B.: pict versicherung.txt /o:2
Laufzeit: 1 Jahr, 3 Jahre, 5 Jahre
Wohnfläche: 30 qm, 50 qm, 100 qm, 200 qm
Schmuck: 0 EUR, 100 EUR, 1000 EUR
Bonusrabatt: ja, nein
Zahlweise: monatlich, vierteljährlich, jährlich
Selbstbeteiligung: 0 EUR, 150 EUR, 300 EUR
Tarifvariante: Basis, Komfort, Premium

# Für die beitragsrelevanten Kernparameter wird zusätzlich 3-wise Coverage erzwungen.
{ Laufzeit, Wohnfläche, Schmuck, Selbstbeteiligung } @ 3

Damit werden weiterhin alle Parameter grundsätzlich paarweise kombiniert. Für die definierte Gruppe aus Laufzeit, Wohnfläche, Schmuck und Selbstbeteiligung wird zusätzlich sichergestellt, dass alle 3er-Kombinationen innerhalb dieser Gruppe abgedeckt sind. Das ist besonders hilfreich, wenn fachlich bekannt ist, dass bestimmte Parameter gemeinsam auf die Prämie wirken, man aber nicht den gesamten Testraum auf 3-wise anheben möchte.

Negative Tests mit ungültigen Werten

PICT eignet sich nicht nur für gültige Kombinationen, sondern kann auch bei negativen Tests helfen. Damit sind Testfälle gemeint, bei denen bewusst ungültige oder fachlich fehlerhafte Werte verwendet werden, um die Validierung des Systems zu prüfen. Bei einem Versicherungsprodukt könnte das zum Beispiel eine negative Wohnfläche, eine Laufzeit von 0 Jahren oder ein nicht erlaubter Schmuckwert sein. Solche Werte können in PICT mit einer Tilde ~ gekennzeichnet werden:

Laufzeit: 1 Jahr, 3 Jahre, 5 Jahre, ~0 Jahre
Wohnfläche: 30 qm, 50 qm, 100 qm, 200 qm, ~-10 qm
Schmuck: 0 EUR, 100 EUR, 1000 EUR, ~-500 EUR

Der Vorteil dieser Kennzeichnung ist, dass PICT ungültige Werte kontrolliert behandelt. In der Regel wird pro Testfall nur ein negativer Wert verwendet. Das ist wichtig, weil ein Testfall mit mehreren ungültigen Eingaben oft schwer auszuwerten ist: Wenn gleichzeitig die Laufzeit, die Wohnfläche und der Schmuckwert falsch sind, ist nicht mehr eindeutig erkennbar, welche Validierung genau fehlgeschlagen ist. Negative Tests sollten deshalb bewusst sparsam eingesetzt werden. Sie ersetzen keine vollständige Validierungsstrategie, können aber sehr gut helfen, typische Fehleingaben systematisch in die generierten Testfälle aufzunehmen.

Gewichtung von Werten

Nicht alle Werte sind in der Praxis gleich wichtig. Manche Tarifvarianten werden besonders häufig verkauft, bestimmte Laufzeiten kommen öfter vor, und einzelne Kombinationen sind geschäftlich relevanter als andere. PICT ermöglicht es, solche Werte zu gewichten. Eine Gewichtung wird direkt hinter dem Wert angegeben:

Tarifvariante: Basis, Komfort, Premium (3)
Zahlweise: monatlich (2), vierteljährlich, jährlich

In diesem Beispiel wird Premium stärker bevorzugt als Basis oder Komfort. Ebenso wird die monatliche Zahlweise häufiger berücksichtigt als die anderen Zahlweisen. Das bedeutet allerdings nicht, dass PICT daraus eine exakte statistische Verteilung erzeugt. Die Gewichtung beeinflusst die Auswahl der Werte, aber das eigentliche Ziel bleibt weiterhin die kombinatorische Abdeckung. Gewichtung ist besonders dann sinnvoll, wenn bestimmte Werte im Test stärker sichtbar sein sollen, ohne dass man dafür eigene Sondertestfälle schreiben möchte. Sie kann helfen, realistischere Testdaten zu erzeugen, etwa wenn ein Produkt in der Praxis überwiegend mit bestimmten Optionen abgeschlossen wird. Gleichzeitig sollte man Gewichtung nicht mit fachlicher Priorisierung verwechseln: Kritische Kombinationen sollten weiterhin explizit modelliert werden, zum Beispiel über Sub-Models mit höherer Teststärke oder über zusätzliche manuelle Testfälle.

Ausschluss ungültiger Kombinationen

Ein Testmodell enthält oft Kombinationen, die theoretisch möglich wären, fachlich aber keinen Sinn ergeben. Solche Kombinationen sollten nicht als Testfälle erzeugt werden, weil sie das Ergebnis verfälschen und unnötigen Aufwand verursachen. PICT erlaubt deshalb den Ausschluss ungültiger Kombinationen über Constraints. Ein Beispiel: Ein hoher Schmuckwert ist möglicherweise nur in der Premium-Variante erlaubt.

IF [Schmuck] = "1000 EUR" THEN [Tarifvariante] = "Premium";

Oder: Ein Bonusrabatt soll erst ab einer längeren Laufzeit möglich sein.

IF [Bonusrabatt] = "ja" THEN [Laufzeit] <> "1 Jahr";

Solche Regeln sorgen dafür, dass PICT keine fachlich unzulässigen Testfälle erzeugt. Das ist besonders wichtig, wenn Testfälle später automatisiert ausgeführt oder an Fachbereiche zur Abnahme gegeben werden. Ein Testfall, der in der Realität gar nicht vorkommen darf, ist sonst schwer zu bewerten: Scheitert er wegen eines Fehlers im System oder weil der Testfall selbst ungültig ist? Wichtig ist aber die Unterscheidung zwischen „ungültig“ und „ungewöhnlich“. Eine kleine Wohnfläche mit einem Premiumtarif mag selten sein, kann aber fachlich durchaus erlaubt sein. Eine solche Kombination sollte nicht ausgeschlossen werden. Constraints sollten nur dort verwendet werden, wo eine Kombination tatsächlich fachlich verboten ist. Ein vollständiger Ausschnitt aus einer PICT-Datei könnte dann so aussehen:

Laufzeit: 1 Jahr, 3 Jahre, 5 Jahre
Wohnfläche: 30 qm, 50 qm, 100 qm, 200 qm
Schmuck: 0 EUR, 100 EUR, 1000 EUR
Bonusrabatt: ja, nein
Zahlweise: monatlich, vierteljährlich, jährlich
Selbstbeteiligung: 0 EUR, 150 EUR, 300 EUR
Tarifvariante: Basis, Komfort, Premium
IF [Schmuck] = "1000 EUR" THEN [Tarifvariante] = "Premium";
IF [Bonusrabatt] = "ja" THEN [Laufzeit] <> "1 Jahr";
IF [Tarifvariante] = "Basis" THEN [Selbstbeteiligung] <> "0 EUR";

Durch solche Ausschlüsse wird das Modell fachlich genauer. PICT erzeugt dann nicht einfach beliebige Kombinationen, sondern Kombinationen, die innerhalb der definierten Geschäftsregeln gültig sind.

Typischer Ablauf in einem Testprojekt

In einem konkreten Testprojekt beginnt die Arbeit nicht mit PICT selbst, sondern mit der fachlichen Analyse des Tarifrechners. Zunächst müssen die relevanten Eingabeparameter bestimmt werden. Danach werden für jeden Parameter sinnvolle Werteklassen gebildet: Grenzwerte, typische Standardwerte, fachliche Sonderfälle und Werte unmittelbar vor oder nach einem Sprung in der Berechnungslogik.

Im nächsten Schritt werden fachliche Einschränkungen ergänzt. Nicht jede theoretisch mögliche Kombination darf auch im Testmodell vorkommen. Ungültige Kombinationen werden daher über Constraints ausgeschlossen. Für besonders kritische Parametergruppen kann zusätzlich eine höhere Kombinationsstärke definiert werden.

Erst danach werden mit PICT die eigentlichen Testdaten erzeugt. Diese Testdaten können anschließend gegen den Referenzrechner, zum Beispiel einen Excel-Rechner, ausgeführt werden. Die dort berechneten Sollwerte werden dann mit den Ergebnissen des Zielsystems verglichen. Auf diese Weise entsteht ein nachvollziehbarer Soll-Ist-Vergleich zwischen fachlicher Referenz und technischer Implementierung.

Grenzen des Verfahrens

PICT reduziert die Anzahl der Testfälle, aber nicht die Verantwortung für ein gutes Testmodell. Die Qualität der erzeugten Testfälle hängt wesentlich davon ab, ob die richtigen Parameter ausgewählt, passende Werteklassen gebildet und fachliche Abhängigkeiten korrekt modelliert wurden.

Das Verfahren ersetzt außerdem keine Grenzwertanalyse, keine fachlichen End-to-End-Szenarien und keine gezielten Regressionstests für bereits bekannte Fehler. Gerade bei Tarifrechnern bleiben zusätzliche Tests an fachlich relevanten Schwellenwerten wichtig, weil dort die größten Sprünge in der Berechnung auftreten können.

PICT ist deshalb am stärksten, wenn es als Baustein einer umfassenden Teststrategie eingesetzt wird: Es sorgt für eine systematische kombinatorische Abdeckung, während fachliche Analyse, Grenzwerttests und Regressionstests die inhaltliche Tiefe ergänzen.

Fazit

PICT ist kein Ersatz für fachliches Testdesign, aber ein sehr nützliches Werkzeug, um aus vielen Eingabeparametern eine überschaubare und dennoch systematische Menge von Testfällen zu erzeugen.

Gerade bei Tarifrechnern, deren Verhalten durch Lookup-Tabellen, Bedingungen und Sonderregeln geprägt ist, hilft das Verfahren dabei, relevante Parameterkombinationen nicht nur zufällig, sondern nachvollziehbar abzudecken.

Wichtig ist dabei, dass das PICT-Modell sorgfältig erstellt wird. Die Auswahl der Parameter, die Bildung sinnvoller Werteklassen, der Ausschluss fachlich ungültiger Kombinationen und die gezielte Erhöhung der Teststärke für kritische Parametergruppen entscheiden darüber, wie aussagekräftig die generierten Testfälle am Ende sind.

In einem Folgeartikel zeige ich an einem konkreten Beispiel, wie PICT in der Praxis zusammen mit einem Excel-Rechner eingesetzt werden kann: von der Modellierung der Eingabeparameter über die Generierung der Testdaten bis zum Vergleich der berechneten Ergebnisse mit dem Zielsystem.

Hello again, World

huettemann@cosmocode.de (Detlef Hüttemann) — Tue, 26 May 2026 00:00:00 GMT

Wenn man die Geburt eines Blogs üblicherweise mit einem „Hello World“-Post begrüßt, wie sollte dann der Titel für einen wieder ins Leben gerufenen Blog lauten? Vielleicht: „Hello again, World“?

Viele Jahre lang hatten wir auf unserer Website einen Blog. Er brachte auch durchaus guten Traffic. Als wir vor einigen Jahren unsere Homepage relauncht haben, haben wir uns allerdings entschieden, den Blog nicht zu übernehmen.

Der Hintergrund war, dass viele der alten Artikel zwar in hohem Maße SEO-relevant waren, zugleich aber auch alt und inhaltlich nicht mehr auf dem Stand, den wir heute vertreten würden.

Das ist nicht unbedingt das beste Aushängeschild: Wenn ein möglicher Interessent oder Neukunde ausgerechnet über einen veralteten Artikel auf uns aufmerksam wird, entsteht womöglich ein Eindruck, zu dem wir heute nicht mehr stehen würden.

Was uns ohne Blog gefehlt hat

Bei unserem kürzlich stattgefundenen Seminar in Lübbenow haben wir beschlossen, den Blog wieder zu reaktivieren.

Denn uns fehlt ein wichtiger Aspekt der Öffentlichkeitsarbeit: ein Ort, an dem wir nicht ganz so formell auftreten müssen wie in Referenzen oder Case Studies. Ein Ort, an dem wir freier erzählen können — über Entwicklungen in unserer Firma, über unser Team oder über Technologien, die wir gerade einsetzen.

Natürlich ist damit auch die Hoffnung verbunden, den einen oder anderen Leser zu erreichen — und vielleicht auch den einen oder anderen Interessenten.

Vielleicht stehen wir in ein paar Jahren wieder vor dem Problem veralteter Inhalte. Der Unterschied ist: Inhalte zu identifizieren, zu prüfen und entsprechend zu markieren, wird inzwischen deutlich einfacher. Schon heute lassen sich solche Aufgaben mit KI-Agenten unterstützen. In fünf Jahren werden vermutlich noch einmal ganz andere Werkzeuge zur Verfügung stehen, um Inhalte zu auditieren, einzuordnen und bei Bedarf zu aktualisieren.

Warum nicht einfach LinkedIn?

Als wir den Blog seinerzeit gestrichen hatten, gab es auch die Idee, stattdessen stärker in anderen Medien über uns zu berichten: auf sozialen Plattformen, über Medium oder über LinkedIn.

LinkedIn ist eine Plattform mit Relevanz. Aber es ist eben auch ein durchoptimiertes System, das — wie alle sozialen Plattformen — die Aufmerksamkeit der Akteure vermarktet.

Auf LinkedIn spielen wir alle nach denselben Regeln. Wir strampeln uns ab, um in möglichst vielen Feeds zu erscheinen. Und dazu gehört auch, immer mehr und immer kräftiger strampeln zu müssen, wenn die anderen auf LinkedIn dasselbe tun — notfalls mit automatisierten Posts, die von KI geschrieben werden.

LinkedIn ist als Nutzer- oder Konsumentenplattform durchaus brauchbar. Als Produzent geht es dort aber irgendwann nicht mehr nur um kluge Inhalte, sondern auch um Dauerfeuer.

Ein eigener Ort für eigene Gedanken

Wenn ich mir schon viele Gedanken über ein Thema mache und an der schriftlichen Ausarbeitung feile, dann empfinde ich es als angemessener, diesen Text in einem Rahmen zu veröffentlichen, der uns gehört: auf unserer eigenen Bühne.

Natürlich stehen auch Blogposts in einem Aufmerksamkeitswettbewerb — nämlich dem der Suchmaschinen und KI-Content-Aggregatoren. Aber in meinem privaten Blog habe ich den Eindruck gewonnen, dass sich guter Content immer noch lohnt und dass er auch gelesen wird. Meine anfängliche Skepsis, dass LLMs die Inhalte lediglich als Knowledge scrapen, um daraus eigene Inhalte zu formen, und nur noch Bots, aber keine Menschen mehr auf die Blogs gehen, hat sich nicht bestätigt. Noch nicht.

Happy Rebirth, CosmoBlog

Also versuchen wir es mit einem neuen Blog auf CosmoCode.

Happy Rebirth, CosmoBlog. Hereinspaziert, liebe Welt.