Juni 2026: Worüber ich geschrieben habe – und warum

Im Juni habe ich nach einer langen Pause wieder auf diesem Blog geschrieben. Ich hatte die Website neu aufgebaut und den Ablauf für die Veröffentlichung verändert. Etwa zur selben Zeit startete ich ProductLog. In den Artikeln dieses Monats erklärte ich, warum ich beides gebaut hatte und wie ich es nutzen wollte.

Beim Wiedereinstieg wollte ich mehr von den Entscheidungen und Schwierigkeiten hinter meinen Projekten zeigen. Dazu gehörten der Aufbau von ProductLog und die Frage, warum camiler.org trotz Traffic keinen Umsatz erzielte. Auch darüber, welche Arbeit mir beim Einsatz von KI blieb, schrieb ich. Hinzu kam ein persönlicherer Text über meine Alltagsgewohnheiten.

Das Veröffentlichen sollte weniger Mühe machen

Die alte WordPress-Installation zu pflegen war so aufwendig geworden, dass mir die Lust am Schreiben vergangen war. Auf dem Blog war lange nichts erschienen. Als ich die Website im Juni neu aufbaute, änderte ich auch den Veröffentlichungsprozess.

In meinem Artikel über den Wechsel von WordPress zu Nuxt erklärte ich, dass ich mehr als das Framework ausgetauscht hatte. Auch die Themen, über die ich schreiben wollte, hatten sich verändert. Einige der Installations- und Konfigurationsanleitungen, die ich früher verfasst hatte, interessierten mich nicht mehr.

Listen mit Befehlen wurden leichter auffindbar. Mir war deshalb wichtiger geworden, zu erklären, warum ich eine bestimmte Liste zusammengestellt hatte. Ich wollte zeigen, wo sie geholfen hatte, für welche Lösung ich mich entschieden hatte und welche Versuche gescheitert waren. Der neue Blog sollte meine Projekte, Entscheidungen und Fehlschläge zeigen. Technische Anleitungen hielt ich weiterhin für nützlich. Ich fragte mich aber, warum ich Zeit in die Pflege eines Artikels investieren sollte, der lediglich Befehle auflistete.

Früher hatte ich gezögert, über Markdown und Git zu veröffentlichen. Dateien vorbereiten, Bilder verwalten, Links korrigieren, Änderungen committen und pushen: All das erschien mir als zusätzliche Arbeit, die zwischen mir und einem Artikel stand. Ein KI-Assistent, der mich bei diesen Schritten unterstützte, veränderte diese Abwägung. Ich konnte eine Idee erklären und mir bei der Ausarbeitung des Textes helfen lassen. Die fertige Seite und die tatsächlichen Aussagen im Text musste ich weiterhin selbst prüfen.

Vor der Wiedereröffnung der Website im Juni überarbeitete ich auch ältere Artikel. Erst im August prüfte ich mein Inhaltsportfolio in einer eigenen Durchsicht. Davon berichtet der Migrationsartikel heute ebenfalls. Diese spätere Arbeit gehörte nicht zu den Vorbereitungen für meine Rückkehr zum Blog im Juni.

Am Ende des Artikels schrieb ich, dass sich erst mit der Zeit zeigen würde, ob ich mit dem neuen Aufbau häufiger und ausführlicher schreiben würde. Der erste Gewinn war bescheidener: Die Infrastruktur stand dem Schreiben weniger im Weg.

Ein Ort für die Arbeit zwischen zwei Veröffentlichungen

Der Blog eignet sich für einen Gedanken, der Raum braucht. Ich wollte aber nicht jede kleine Änderung an einem Projekt hierherbringen. Verschwinden sollten diese Änderungen auch nicht.

So erklärte ich, warum ich ProductLog zunächst für mich selbst gebaut hatte. Für mehrere Projekte wollte ich festhalten können, was ich veröffentlicht, welche Entscheidungen ich verworfen und was ich aus welchem Grund geändert hatte. Auch zwischen zwei Veröffentlichungen findet Arbeit statt. Ich wollte darüber schreiben können, ohne jede kleine Änderung als Geschichte inszenieren zu müssen, die Aufmerksamkeit auf sich zieht.

ProductLog hatte keine externe Finanzierung, und ich konnte ihm ungefähr eine Stunde pro Tag widmen. Ich war der erste Nutzer. Wenn ich bei der Nutzung auf ein Hindernis stieß, wurde daraus ein konkretes Problem, das ich beheben konnte. Dass ich auch künftige Projekte dokumentieren wollte, gab mir einen Grund weiterzumachen. Das war allerdings noch kein Beleg dafür, dass die Plattform bestehen würde oder dass andere Menschen sie brauchten.

Die weiteren ProductLog-Artikel dieses Monats beschäftigten sich mit dem Risiko dieser Offenheit. Ich baute eine Plattform, auf der Menschen ihre Arbeit verständlicher erklären konnten. Dieselbe Dokumentation konnte es einem Wettbewerber erleichtern, meine Absichten zu verstehen.

Daraus entstand mein Artikel über offene Dokumentation und unfertige Pläne auf ProductLog. Ich konnte die Überlegungen hinter einer Entscheidung erklären, ohne jedes Detail eines noch ungeprüften Plans offenzulegen. In der ersten Fassung hatte ich mich über das Kopieren zu bestimmt geäußert; in späteren Überarbeitungen schränkte ich diese Aussagen ein. Die Frage bleibt: Wie viel muss ich offenlegen, damit ein Leser nachvollziehen kann, was ich gelernt habe?

Mehr produzieren heißt auch mehr verstehen müssen

Bei Projekten, die ich allein betrieb, etwa ProductLog, kam ich mit KI schneller voran. Ich nutzte die Werkzeuge fast täglich. Den entstandenen Code musste ich trotzdem verstehen.

Mein Artikel über Verständnisschulden entstand aus der Lücke zwischen funktionierendem Code und einem System, das ich erklären konnte. Der Code konnte kompilieren und die Tests bestehen. Trotzdem verstand ich vielleicht nicht gut genug, warum eine Entscheidung getroffen worden war oder welche Folgen eine Änderung haben würde.

Wenn ich allein arbeite, gibt es keinen zweiten Menschen, der automatisch über das Wissen verfügt, das mir fehlt. Nehme ich den Vorschlag des Agenten an, muss ich einem späteren Problem selbst nachgehen. Deshalb schrieb ich im Juni darüber, vor dem Programmieren die Absicht festzuhalten und den Zweck des übernommenen Codes erklären zu können. Mehr zu produzieren bedeutete auch, die Verantwortung dafür zu übernehmen.

Im Unternehmen wirkte sich die veränderte Kapazität auf eine andere Entscheidung aus. In meinem Artikel über Einstellungen, die gar nicht erst stattfinden beschrieb ich, wie sich manche Projekte mit dem bestehenden Team beginnen ließen, für die wir früher auf ein neues Budget und ein zusätzliches Team gewartet hätten. Die Begründung für eine neue Stelle konnte sich ändern, ohne dass ein Mitarbeiter entlassen wurde.

Diese Beobachtung stammte aus dem Unternehmen, in dem ich Entscheidungen traf. Sie war keine Messung der Veränderungen auf dem gesamten Arbeitsmarkt. Forschung, die ich später ergänzte, erweiterte die Diskussion. Mein Ausgangspunkt im Juni war etwas, das ich im Unternehmen sehen konnte und das Entlassungszahlen allein nicht zeigten: Welche Arbeit können wir inzwischen beginnen, ohne jemanden einzustellen?

Was Reichweite noch nicht erklärt

Die Zahlen meines Juni-Rückblicks auf camiler.org waren beachtlich: ungefähr eine Million Suchimpressionen pro Monat, mehr als zehntausend Klicks und null US-Dollar Umsatz. Das waren die damals festgehaltenen Ergebnisse des Projekts, nicht seine heutige Leistung.

In meinem Bericht über das Experiment mit programmatischer SEO erklärte ich, dass die von mir aufgebaute Daten- und Veröffentlichungspipeline die Website in den Suchergebnissen sichtbar machen konnte. Meine Erwartung, Werbeeinnahmen zu erzielen, hatte sich nicht erfüllt. Der AdSense-Antrag war abgelehnt worden. Ein Platz in den Suchergebnissen beantwortete noch nicht die Frage, welches Erlösmodell bei diesem Traffic funktionieren könnte.

Auch in den Artikeln über KI-Sichtbarkeit prüfte ich, was mir ein Diagramm sagen konnte. In meiner Analyse von Bings Citation Share versuchte ich, zwei Arten von Daten auseinanderzuhalten: die direkt erhobenen Daten zu den von mir betreuten Websites und Sichtbarkeitswerte auf Basis ausgewählter Suchanfragen. Dann passten die Google-Daten nicht zu meiner Erklärung, dass Seiten im Moment einer Anfrage live abgerufen würden.

In dem Folgeartikel, in dem ich meine Theorie korrigierte, musste ich Beobachtung und Erklärung trennen. Entfernte Inhalte schienen in KI-Ergebnissen früher an Sichtbarkeit zu verlieren als in der Suche. Aus demselben Bericht ließ sich nicht genau ableiten, wie das geschah. Im ursprünglichen Text hatte ich außerdem geschlossen, dass Google einen eigenen KI-Index nutze. Diese Aussage schränkte ich bei einer späteren Überarbeitung ein: Dass die Sichtbarkeit in der Suche später sank als in den KI-Ergebnissen, bewies nicht, wie das System intern aufgebaut war.

Der Blog war zurück; meine Alltagsgewohnheiten waren es nicht

Neben diesen Berichten über meine Arbeit zog „Ein Sieg, mehrere Niederlagen“ eine ganz andere Bilanz. Nach sechs Jahren ohne Zigaretten hatte ich wieder angefangen zu rauchen und dann erneut aufgehört. Als ich den Artikel schrieb, hatte ich seit zwei Monaten nicht geraucht. Ich hatte aber zugenommen, ging nicht regelmäßig spazieren und nahm die Geige kaum noch in die Hand.

Ich hatte ProductLog gestartet, die Website neu aufgebaut und wieder mit dem Schreiben begonnen. Diese Fortschritte zeigten nicht, dass ich besser auf mich achtete. Eine Lösung hatte ich in dem Artikel noch nicht. Die neue Website und das neue Produkt glichen nicht aus, was in meinem Alltag zu kurz kam.

Wenn ich die Juni-Artikel heute zusammen lese, sehe ich: Ich schrieb ebenso viel über die Fragen, die nach dem Erreichten offenblieben, wie über die Arbeit selbst.