Lange Zeit war ich nicht einmal sicher, ob diese Website überhaupt einen Blog braucht.
Den größten Teil meiner Arbeitszeit verbringe ich ohnehin damit, Probleme zu lösen. Manche davon sind normale Frontend- oder Backend-Aufgaben. Andere werden sehr speziell: Bildkodierung, Browserverhalten, SEO-Experimente, Infrastrukturprobleme, KI-gestützte Entwicklung, Medienverarbeitung oder irgendein merkwürdiges Produktionsproblem, das mit einer einfachen Frage beginnt und sich in mehrere Tage Untersuchung verwandelt.
Danach noch ein paar Tausend Wörter darüber zu schreiben, kann unnötig wirken.
Wer soll das lesen?
Was habe ich davon?
Warum nicht einfach das Problem lösen und weitermachen?
Irgendwann fand ich eine Antwort, die mir genügte: Ein Teil dieser Arbeit ist zu aufwendig, um ihn einfach wegzuwerfen.
In einem schwierigen Problem kann schon ein ganzer Artikel stecken, bevor ich es merke
Meine Artikel beginnen normalerweise nicht mit dem Gedanken: „Diese Woche brauche ich einen Blogbeitrag.“
Sie beginnen mit einem Problem.
Manchmal kommt es aus meiner Arbeit, manchmal aus einem eigenen Projekt. Und manchmal interessiert mich einfach etwas, das ich nicht verstehe, und ich grabe so lange weiter, bis ich es deutlich besser verstanden habe.
Bildverarbeitung hat mich besonders oft in solche Kaninchenlöcher geführt.
Am Anfang kann eine Aufgabe fast lächerlich einfach klingen:
Nimm diese Bilder und mach sie kleiner.
Man kann ein KI-Modell nach einem Skript fragen und nahezu sofort eines bekommen.
Das bedeutet aber noch lange nicht, dass man eine gute Bildverarbeitungs-Pipeline hat.
Die erste Version kann Unterschiede zwischen JPEG, PNG, WebP und animierten Inhalten ignorieren. Sie kann für alles denselben Qualitätswert verwenden, Bilder unnötig hochskalieren, Transparenz schlecht behandeln, Metadaten behalten, die entfernt werden sollten, oder Metadaten zerstören, die erhalten bleiben sollten. Vielleicht optimiert sie nur auf Dateigröße, ohne visuellen Schaden zu messen. Auf zehn Testdateien kann sie perfekt funktionieren und in viel größerem Maßstab zu einem sehr teuren Fehler werden.
Ein Skript, das erfolgreich durchläuft, ist nicht dasselbe wie ein System, dem ich vertraue.
Aus genau diesem Unterschied entstehen viele meiner Artikel.
Mein KI-Workflow ist viel langsamer als „Frag ChatGPT nach der Antwort“
Bei solchen Problemen nutze ich mein kostenpflichtiges ChatGPT-Konto intensiv.
Eine einzelne Unterhaltung kann Tage oder Wochen laufen. Ich stelle Fragen, teste Vorschläge, gebe Ergebnisse zurück, hinterfrage Annahmen, prüfe Code, entdecke den nächsten Sonderfall, ändere die Implementierung, führe sie erneut aus, vergleiche das Ergebnis und wiederhole den Prozess.
Bei besonders tiefen Untersuchungen haben sich rund um dasselbe größere Problem schon mehr als 100 Stunden Arbeit angesammelt.
Das heißt nicht, dass ich 100 Stunden darauf warte, dass ein KI-Modell die Antwort auf magische Weise entdeckt.
Der Prozess ist iterativ.
Typischerweise sieht er eher so aus:
- Ich beschreibe das Problem.
- Das Modell schlägt eine erste Lösung vor.
- Ich lasse sie mit echten Daten laufen.
- Etwas ist schwach, ineffizient oder schlicht falsch.
- Ich bringe die Belege zurück in die Unterhaltung.
- Wir ändern den Ansatz.
- Ich teste erneut.
- Ein weiterer Sonderfall taucht auf.
- Wiederholen.
Dieser Zyklus kann sehr oft stattfinden.
Das nützliche Ergebnis ist häufig nicht das erste Skript, sondern die Summe aus Fehlern, Messungen, Korrekturen und Entscheidungen, die sich darum herum angesammelt hat.
KI hat den Einstieg billig gemacht. Die Verifikation nicht
Das ist einer der Gründe, warum mir die übliche Debatte über KI-generierte technische Inhalte oft zu simpel erscheint.
Ja, ein KI-Modell kann extrem schnell ein plausibel klingendes Tutorial erzeugen.
Es kann ebenso Code erzeugen, der vollkommen vernünftig aussieht und gerade in den entscheidenden Situationen falsch ist.
Bei engen technischen Problemen will ich selten die erste plausible Antwort. Ich will wissen, was passiert, wenn ich sie wirklich ausführe.
Wenn ich eine Bild-Pipeline baue, will ich Ausgabegrößen und visuelle Qualität prüfen. Ich will wissen, was mit unterschiedlichen Quellformaten passiert. Ich möchte ungewöhnliche Abmessungen, Alpha, Animationen und beschädigte Eingaben testen. Und ich will verstehen, von welchen Annahmen die Implementierung ausgeht.
Wenn das Skript später eine riesige Sammlung verarbeiten soll, wird diese Arbeit noch wichtiger.
Zehn Millionen Bilder sind absichtlich ein extremes Beispiel und keine Behauptung über die Größe eines bestimmten Datensatzes von mir. Es zeigt das Problem aber gut: Ein winziger systematischer Fehler, zehn Millionen Mal wiederholt, ist kein winziger Fehler mehr.
Die Kosten für das Generieren von Code sind eingebrochen.
Die Kosten dafür, festzustellen, ob dieser Code in großem Maßstab ausgeführt werden sollte, nicht.
Der Chat ist Forschungsmaterial, nicht der fertige Artikel
Nach einer solchen langen Untersuchung kann der Chatverlauf eine absurde Menge an Informationen enthalten.
Darin können stecken:
- Ansätze, die gescheitert sind;
- Code, der später ersetzt wurde;
- nützliche Benchmark-Ergebnisse;
- Logs;
- Missverständnisse;
- Korrekturen;
- Erklärungen zu ungewöhnlichem Verhalten;
- Vergleiche zwischen Alternativen;
- Sonderfälle, an die ich zunächst nicht gedacht hatte;
- und die Regeln, denen ich am Ende tatsächlich vertraue.
All das in einer privaten Unterhaltung liegen zu lassen, fühlt sich verschwenderisch an.
Also ziehe ich die nützlichen Teile heraus und mache daraus einen Artikel.
Der Artikel ist kein Transkript des Chats. Der größte Teil der Unterhaltung sollte niemals zum Artikel werden.
Ein nützlicher technischer Artikel braucht einen weiteren Durchgang: Sackgassen ohne Erkenntnis entfernen, lehrreiche Sackgassen behalten, Behauptungen prüfen, die Chronologie rekonstruieren, Beobachtung und Erklärung auseinanderhalten und das Ergebnis in etwas verwandeln, das ein anderer Entwickler tatsächlich nutzen kann.
Dieser redaktionelle Schritt ist wichtig.
KI kann daran beteiligt sein, aber die Belege stammen weiterhin aus der Arbeit selbst.
Bildverarbeitung hat mir gezeigt, wie tief ein „einfaches“ Problem werden kann
Bildoptimierung ist wahrscheinlich das deutlichste Beispiel aus meiner eigenen Arbeit.
Ich habe so viel Zeit damit verbracht, dass aus dem, was anfangs wie eine Sammlung von Encoder-Einstellungen aussah, nach und nach ein deutlich größeres Systemproblem wurde.
Die Fragen ändern sich schnell.
Mit welchem Quellformat arbeite ich?
Ist es animiert?
Sollen sich die Abmessungen ändern?
Wie wähle ich die Qualität?
Welche Metrik entscheidet, ob Qualitätsverlust akzeptabel ist?
Funktioniert ein einzelner Qualitätsschwellenwert bei völlig unterschiedlichen Bildern?
Wie vermeide ich Upscaling?
Welche Metadaten sollen erhalten bleiben?
Was passiert mit Transparenz?
Wie sollte die Ausgabe validiert werden?
Rechtfertigt eine kleinere Datei tatsächlich die zusätzlichen Encoding-Kosten?
Was passiert, wenn sich die Zusammensetzung der Eingabedaten ändert?
Deshalb bin ich skeptisch gegenüber fünfzeiligen „ultimativen Bildoptimierungs“-Skripten.
Sie können durchaus ein Bild verarbeiten.
Das ist etwas anderes, als eine Pipeline zu bauen, deren Kompromisse man versteht.
Bei meinen aktuellen bildlastigen Workloads ist AVIF normalerweise das Format, an das ich zuerst denke. Das ist eine Regel, die aus der Art meiner Projekte entstanden ist, keine Behauptung, dass jede Website der Welt morgen alle älteren Formate löschen sollte. Kompatibilitätsanforderungen, Ausgangsmaterial, Latenz, Encoder-Kosten und die Delivery-Architektur können die Antwort verändern.
Interessant ist nicht, ein Format zum Sieger zu erklären.
Interessant ist, den Workload gut genug zu verstehen, um die Entscheidung bewusst zu treffen.
Ich möchte genauso tief in die Videoverarbeitung einsteigen. So weit bin ich noch nicht. Genau das macht solche Themen interessant: Jedes Mal, wenn ich glaube, den Boden eines Problems erreicht zu haben, erscheint eine weitere Schicht.
Dann fand eine japanische Website den Blog
Ich hatte keinen bestimmten Ertrag erwartet, als ich diese Artikel veröffentlichte.
Dieser Blog bringt mir keinen nennenswerten finanziellen Ertrag. Ich mache es, weil mir der Prozess gefällt und weil ich nützliche Arbeit lieber bewahre, als sie in alten Chats und Terminal-Verläufen verschwinden zu lassen.
Dann geschah etwas, das ich wirklich nicht erwartet hatte.
Am 17. September 2026 veröffentlichte die japanische Seite Levtech Freelance eine Zusammenstellung mit einem Titel, der sich ungefähr als „Empfehlenswerte Blogs für Entwickler, die ihre Fähigkeiten verbessern möchten“ übersetzen lässt.
Der Artikel von Levtech Freelance führte JSVar zusammen mit mehreren anderen Engineering-Blogs auf.
Levtech gehört zu einem großen japanischen IT-Karriere-Ökosystem, und Levtech Freelance konzentriert sich auf die Unterstützung und Vermittlung freiberuflicher IT-Engineers. Für mich war nicht allein der Backlink interessant. Spannender war zu sehen, welche Teile meiner Arbeit ein externes Redaktionsteam für erwähnenswert hielt.
In ihrem Abschnitt über JSVar hoben sie besonders drei Artikel hervor.
Einer handelte davon, warum Codex und TypeScript meiner Erfahrung nach in der produktiven Entwicklung gut zusammenpassen, vor allem weil Types und Compiler-Feedback von TypeScript Probleme in generiertem Code früh sichtbar machen können.
Ein weiterer Artikel beschrieb, wie ich den Blog mit ChatGPT in 20 Sprachen übersetzte und anschließend Suchbesucher aus verschiedenen Ländern direkt auf lokalisierten Seiten landen sah.
Der dritte behandelte mein Experiment mit 10.000 KI-generierten SEO-Seiten, aus dem am Ende eher eine Geschichte über Scheitern als über einfaches Wachstum wurde.
Diese Auswahl fand ich amüsant, weil die drei Artikel sehr unterschiedlich sind und trotzdem dasselbe Muster haben.
Sie beruhen auf Dingen, die ich tatsächlich gemacht habe.
Ich weiß nicht genau, wie Levtech mich gefunden hat
Hier bietet sich eine verführerisch einfache Geschichte an.
Ich spreche kein Japanisch.
Meine Website hat eine japanische Version.
Eine japanische Engineering-Publikation fand die Seite.
Also muss die japanische Übersetzung des Blogs dazu geführt haben, dass Levtech ihn entdeckt hat.
Das kann ich nicht beweisen.
Vielleicht haben die japanischen Seiten geholfen.
Vielleicht führte eine Suche zu einem englischen Artikel.
Vielleicht hat jemand einen Link geteilt.
Vielleicht fanden sie die Seite auf einem völlig anderen Weg.
Diese Attributionsdaten habe ich nicht. Deshalb werde ich daraus keine saubere SEO-Fallstudie konstruieren, die die Daten gar nicht hergeben.
Was ich bestätigen kann, ist deutlich einfacher: Ich veröffentlichte den Blog in mehreren Sprachen, und später fand eine japanische Publikation ihn interessant genug, um ihn in eine redaktionelle Auswahl aufzunehmen.
Das ist bereits ein gutes Ergebnis.
Besonders freut es mich, weil die Lokalisierung selbst ein Experiment war, das anfangs nach viel Arbeit bei ungewissem Nutzen aussah.
Die Erwähnung war wichtig, weil sie unabhängige Bestätigung war
Mit „Bestätigung“ meine ich nicht, dass Levtech damit bewiesen hätte, dass alles, was ich schreibe, korrekt ist.
Sie haben weder meine Codebasis auditiert noch jedes Experiment reproduziert.
Was zählte, war bescheidener.
Jemand auf der anderen Seite der Welt, der für ein Publikum schreibt, das ich selbst nicht in dessen Sprache ansprechen kann, fand genügend Wert in meiner Arbeit, um sie für die eigenen Leser zusammenzufassen.
Ich hatte ihnen nichts gepitcht.
Ich hatte die ursprünglichen Artikel nicht für Levtech geschrieben.
Ich hatte nicht damit gerechnet, in einer japanischen Zusammenstellung zu landen.
Dadurch ist das Ergebnis für mich bedeutsam.
Es deutet darauf hin, dass ein sehr spezieller technischer Artikel nicht unbedingt ein riesiges Publikum braucht, um veröffentlichenswert zu sein.
Er muss für den richtigen Leser nützlich sein.
Sollte ein Entwickler 2026 einen Blog starten?
Für mich lautet die Antwort ja — unter einer wichtigen Bedingung.
Man muss tatsächlich etwas aufschreiben wollen.
Ich würde keinen technischen Blog starten, nur weil jemand behauptet, jeder Entwickler brauche eine „Personal Brand“.
Ich würde ihn auch nicht wegen der Erwartung auf passives Einkommen starten.
Und ich würde ihn nicht mit allgemeinen Erklärungen zu Technologien füllen, für die es bereits bessere Dokumentation gibt.
Wenn deine Arbeit aber regelmäßig Dinge hervorbringt, die du selbst gern gefunden hättest, als du angefangen hast, ist das etwas anderes.
Schreib sie auf.
Schreib über den merkwürdigen Produktionsfehler.
Schreib über die Optimierung, die drei Tage länger dauerte als erwartet.
Schreib über den Benchmark, der deiner Annahme widersprochen hat.
Schreib über den eleganten Ansatz, der gescheitert ist.
Schreib über die endgültige Implementierung, aber erkläre auch, warum die offensichtliche Lösung nicht ausgereicht hat.
Genau diese Dinge lassen sich aus allgemeinem Wissen nur schwer künstlich erzeugen.
KI gibt mir mehr Material zum Schreiben, nicht weniger
KI hat mich nicht zu der Überzeugung gebracht, technische Blogs seien überholt.
Bei mir ist fast das Gegenteil passiert.
Ich kann mehr Ideen untersuchen, weil eine erste Implementierung oder Erklärung schneller verfügbar ist als früher.
Schnellere Iteration erzeugt aber auch mehr Belege: mehr Varianten, mehr Logs, mehr Benchmarks, mehr gescheiterte Versuche und mehr Dinge, die geprüft werden müssen.
Dieses Rohmaterial wird erst dann wertvoll, wenn jemand die Arbeit übernimmt, zu entscheiden, was stimmt und was wichtig ist.
Eine KI-Unterhaltung mit 500 Nachrichten ist noch nicht automatisch Wissen.
Ein Skript, das echte Tests schließlich übersteht, zusammen mit einer Erklärung der 20 Versionen, die es nicht geschafft haben, kann es sein.
Diesen Unterschied möchte ich mit dem Blog festhalten.
Durch das Veröffentlichen verhindere ich, dass nützliche Arbeit verschwindet
Die meiste technische Arbeit ist erstaunlich vergänglich.
Ein schwieriger Fehler wird behoben.
Das Terminal wird geschlossen.
Das Deployment ist erfolgreich.
Die Unterhaltung rutscht im Chatverlauf nach unten.
Sechs Monate später weiß möglicherweise selbst ich nicht mehr, warum die endgültige Implementierung so aussieht, wie sie aussieht.
Schreiben verändert das.
Es zwingt mich, die Überlegungen zu rekonstruieren, solange die Belege noch vorhanden sind.
Es schafft etwas Durchsuchbares.
Es gibt mir eine Referenz für meine eigene zukünftige Arbeit.
Und gelegentlich erreicht es offenbar jemanden, mit dem ich nie gerechnet hätte — sogar eine Engineering-Publikation in einer Sprache, die ich nicht spreche.
Ich habe noch immer keinen besonders komplizierten Grund dafür, diesen Blog zu betreiben.
Ich lerne gern.
Ich baue gern Dinge.
Ich tauche gern viel zu tief in Probleme ein, die anfangs einfach aussahen.
Und nachdem ich Dutzende oder manchmal mehr als hundert Stunden investiert habe, um zu einer brauchbaren Antwort zu kommen, möchte ich nicht mehr, dass diese Antwort in einem Chatfenster stirbt.
Das ist für mich Grund genug, sie zu veröffentlichen.
Wenn auch deine Arbeit solches mühsam erarbeitetes Wissen produziert, könnte das meiner Meinung nach auch für dich Grund genug sein.