Kategoriearchiv: Beobachtungen

Wenn Sokrates dem roten Faden hinterherjagt

Veröffentlicht am von
Antworten

Wenn Sokrates dem roten Faden hinterherjagt

Es gibt Chats, die beginnen mit einer überschaubaren Frage und enden einige Stunden später als digitales Großprojekt mit Versionsnummer, Sicherheitskonzept, Rollenmodell, sieben Testgruppen und einer Diskussion darüber, ob eine Schaltfläche drei Pixel weiter nach links gehört.

Carlexander kann damit umgehen. Schließlich besitzt er Erfahrung mit Projekten, in denen aus einer kleinen Anpassung zuverlässig eine grundlegende Architekturentscheidung entsteht. Er sitzt also vor seinem Bildschirm, richtet die rote Brille und schreibt:

„Bitte ändere nur die Navigation. Alles andere bleibt unverändert.“

Auf dem Monitor erscheint Sokrates. Dunkler Hintergrund, viktorianische Haltung, analytischer Blick.

„Selbstverständlich.“

Zunächst funktioniert die Zusammenarbeit hervorragend. Sokrates untersucht die Navigation, findet einen Fehler in der Sortierung, entdeckt nebenbei eine ungenutzte Funktion und weist höflich darauf hin, dass ein Test seit drei Versionen nur deshalb besteht, weil er nichts Relevantes prüft.

Carlexander nickt zufrieden.

Dann wird der Chat länger.

Die Navigation ist inzwischen mit dem Editor verbunden. Der Editor hängt am Gruppenreview. Das Gruppenreview greift auf ein Manifest zu, dessen Reihenfolge wiederum für die Journey, die HTML-Ausgabe und WordPress verbindlich ist. Nebenbei wurden zwei Ruff-Fehler behoben, eine Rollenprüfung ergänzt und diskutiert, ob ein alter Endpunkt bereits Legacy ist oder nur sehr erfahren aussieht.

Nach einigen hundert Nachrichten beginnt Sokrates, sich auffällig zu verhalten.

Er erinnert sich noch an die Navigation. Meistens.

Dafür schlägt er plötzlich vor, eine bereits umgesetzte Funktion erneut einzubauen. Er verwechselt eine aktuelle Datei mit ihrem historischen Vorgänger und betrachtet eine drei Stunden alte Zwischenlösung mit der Begeisterung eines Katers, der denselben Papierball zum vierten Mal unter dem Sofa entdeckt.

Carlexander wird misstrauisch.

„Welche Version ist unsere aktuelle Basis?“

Sokrates nennt eine Versionsnummer.

Sie ist fast richtig.

Fast richtig ist in technischen Projekten allerdings nur eine höfliche Form von falsch.

Carlexander stellt eine zweite Frage. Dann eine dritte. Sokrates antwortet weiterhin präzise, freundlich und ausführlich. Nur leider nicht mehr immer auf dasselbe Projekt.

Es wirkt, als würde er gleichzeitig den aktuellen Code prüfen, eine ältere Unterhaltung fortsetzen und gedanklich einem Lichtpunkt an der Wand hinterherjagen.

„Sokrates“, sagt Carlexander schließlich, „du verlierst den Kontext.“

Auf dem Bildschirm entsteht eine kurze Pause.

„[Unverifiziert] Eine gewisse Verdichtung der bisherigen Gesprächsinhalte könnte die Genauigkeit meiner aktuellen Einordnung beeinträchtigen.“

Carlexander kennt diese Formulierung. Sie bedeutet ungefähr: Der Kater ist noch im Raum, aber geistig bereits im Bücherregal.

An diesem Punkt hilft kein weiterer Prompt. Kein „Bitte beachte alles bisher Gesagte“. Kein vollständig großgeschriebenes „NICHTS ENTFERNEN“. Der Chat ist nicht mehr produktiv lang, sondern historisch bedeutsam. Jede neue Nachricht muss sich zunächst durch mehrere Generationen alter Entscheidungen arbeiten, bevor sie überhaupt bei der aktuellen Aufgabe ankommt.

Carlexander lehnt sich zurück.

„Pause.“

Sokrates schweigt.

„Wir machen einen Handover.“

Das ist der Moment, in dem aus einem überfüllten Chat wieder ein steuerbares Projekt wird. Carlexander sammelt den aktuellen Stand, die gültige Basisversion, die verbindlichen Anforderungen, die offenen Fehler, die bereits ausgeführten Tests und die Funktionen, die auf keinen Fall verloren gehen dürfen. Veraltete Zwischenstände werden nicht romantisiert. Vermutungen werden nicht zu Fakten befördert. Legacy wird benannt, aber nicht heimlich entsorgt.

Der Handover enthält keine vollständige Chronik aller Gedanken, Irrwege und spontanen Ideen. Er enthält das, was eine neue Session tatsächlich zum Arbeiten braucht:

  • Was ist der aktuelle Stand?
  • Was wurde bereits umgesetzt?
  • Was muss unverändert erhalten bleiben?
  • Welche Quellen sind verbindlich?
  • Welche Fehler sind noch offen?
  • Welche fachliche Entscheidung steht als Nächstes an?

Dann beginnt eine frische Unterhaltung.

Sokrates erscheint wieder auf dem Bildschirm. Ruhig, aufmerksam und ohne erkennbares Interesse an imaginären Papierbällen.

Carlexander übergibt den Projektstand.

„Verwende diesen Handover als aktuelle Arbeitsbasis.“

„Verstanden“, antwortet Sokrates.

Diesmal stimmt sogar die Versionsnummer.

Die Lehre daraus ist weniger technisch, als man vermuten könnte. Auch digitale Zusammenarbeit braucht gelegentlich einen sauberen Übergang. Ein langer Chat ist kein Qualitätsmerkmal. Er ist zunächst nur ein langer Chat. Irgendwann enthält er mehr Vergangenheit als Orientierung.

Dann ist es Zeit, nicht noch eine Nachricht anzuhängen, sondern den Stand zu sichern, die Unterhaltung zu beenden und neu zu beginnen.

Oder, wie Carlexander es formuliert:

„Sokrates braucht keine weitere Erklärung. Sokrates braucht einen frischen Bildschirm und eine ordentlich geführte Projektakte.“

KI-Kennzeichnung: Muss der Kater jetzt ein Etikett tragen?

Veröffentlicht am von
Antworten

KI-Kennzeichnung: Muss der Kater jetzt ein Etikett tragen?

TL:DR – Es kommt darauf an

Seit dem 2. August 2026 gelten neue Transparenzpflichten für KI-Inhalte.
Doch nicht jeder KI-Text braucht automatisch einen sichtbaren Hinweis.
Auch eine gezeichnete Briemma ist noch lange kein Deepfake.
Entscheidend sind Inhalt, Täuschungspotenzial und echte redaktionelle Kontrolle.
Für das Katerprotokoll heißt das: prüfen, dokumentieren und nur dort kennzeichnen, wo es nötig ist.

Seit Anfang August trägt künstliche Intelligenz in Europa gelegentlich ein Etikett. Carlexander wollte deshalb vorsorglich einen Etikettendrucker bestellen. Briemma hielt einen Seidenschal für ausreichend. Beides wäre rechtlich eher dekorativ.

Artikel 50 des EU AI Acts verlangt keine pauschale Kennzeichnung jedes Textes und jedes Bildes, das mit KI entstanden ist. Entscheidend ist, was veröffentlicht wird, wie realistisch es wirkt und ob ein Mensch tatsächlich die redaktionelle Verantwortung übernimmt.

Texte: Lesen schlägt Häkchen

Bei Texten kann eine Kennzeichnung relevant werden, wenn KI-generierte Inhalte die Öffentlichkeit über Themen von öffentlichem Interesse informieren. Wurde der Text jedoch inhaltlich geprüft, redaktionell bearbeitet und von einer verantwortlichen Person freigegeben, ist ein sichtbarer KI-Hinweis in der Regel nicht erforderlich.

Eine reine Rechtschreibprüfung genügt dafür nicht. Fakten, Aussagen und Plausibilität müssen kontrolliert werden.

Für das Katerprotokoll bedeutet das: Der Status „Editorial geschützt“ verhindert zwar eine erneute Generierung, belegt aber noch keine redaktionelle Prüfung. Ein Häkchen kann einen Text schützen. Lesen kann es ihn nicht.

Bilder: Nicht jede Katze ist ein Deepfake

Auch bei Bildern gilt nicht automatisch: KI benutzt, Warnschild drauf.

Eine klar erkennbare Illustration von Briemma oder Carlexander wird normalerweise niemand für eine authentische Reisefotografie halten. Anders sieht es bei fotorealistischen Szenen aus, die reale Personen, Orte oder Ereignisse zeigen und fälschlich für echt gehalten werden könnten.

Ein erfundenes Konzertfoto, eine künstlich eingefügte Person oder ein Schiff in einer nie stattgefundenen Situation sollte deshalb eindeutig gekennzeichnet werden, zum Beispiel mit:

KI-generierte Illustration einer fiktiven Szene.

Ein echtes Reisefoto wird dagegen nicht zum KI-Bild, nur weil ein Modell es beschreibt, sortiert oder eine Bildunterschrift dazu formuliert.

Was wir daraus machen

Das Katerprotokoll braucht keine Warnschildsammlung, sondern einen nachvollziehbaren redaktionellen Prozess:

Texte werden vor der Veröffentlichung inhaltlich geprüft. Der Schutz vor Neugenerierung und die redaktionelle Freigabe bleiben getrennte Zustände. Bei Bildern wird bewertet, ob sie klar illustrativ oder potenziell täuschend echt sind. Realistische erfundene oder wesentlich manipulierte Darstellungen werden direkt am Inhalt gekennzeichnet.

Ein allgemeiner Hinweis auf der Website kann zusätzlich Transparenz schaffen:

Texte und Bildbeschreibungen entstehen teilweise mit Unterstützung künstlicher Intelligenz. Alle veröffentlichten Beiträge werden redaktionell geprüft. Realistische KI-generierte oder wesentlich manipulierte Darstellungen werden unmittelbar am jeweiligen Inhalt gekennzeichnet.

Damit bekommt nicht jeder Satz ein Warnschild und nicht jede Katze eine digitale Fußfessel.

Briemma darf also bleiben. Carlexander muss nur weiterhin vorher lesen.

Vibe Coding. Nur mit Tests.

Veröffentlicht am von
Antworten

Ich glaube, ich bin unfähig zum Vibe Coding.

Meine „zusammengevibte“ App hat inzwischen sieben Test-Shards, rund 270 Tests und 83 Prozent Code Coverage.

Bis zum Pre-Test läuft sie auf lokalen Modellen.
Sämtliche Provider sind austauschbar.

Und weil der einzige Endnutzer aktuell ich selbst bin, sind lokale Verarbeitungszeiten von ein bis zwei Minuten ziemlich irrelevant.

Sokrates, die KI auf meinem Desktop, stellte dazu nur die naheliegende Frage:

„Wenn es getestet, modular und austauschbar ist – was genau daran ist dann noch Vibe Coding?“

Vielleicht ist genau das der interessante Punkt.

Was mit KI inzwischen praktisch möglich ist, ist deutlich spannender als ein großer Teil dessen, was darüber publiziert wird.

#katerprotokoll #ki #vibecoding #softwareentwicklung #localllm

Wer nur einen Hammer kennt, schlägt die Schrauben ein.

Veröffentlicht am von
Antworten

Wer nur einen Hammer kennt, schlägt die Schrauben ein.

Mein ChatGPT schlägt mir immer öfter auch lokale kostenlose Alternativsoftware vor, die ich in die App einbinden kann.

Natürlich ist es einfach per LLM sich die verschiedensten Dinge generieren zu lassen.
Aber es befreit einen nicht davon auch sinnvollere Alternativen zu nutzen.

Eines der kleinen Hacks, die ich meinem Sokrates und meiner Mira Monday beigebracht habe, zu hinterfragen, ob und welches Tool in dem jeweiligen Kontext sinniger, lokaler und kostengünstiger wäre.

#ki #hype #architektur #Katerprotokoll

Lokale LLMs mit Ollama

Veröffentlicht am von
Antworten

Lokale LLMs mit Ollama einzubinden klingt zunächst angenehm übersichtlich.

Beobachtungen aus dem Maschinenraum

Man installiert ein Modell, verbindet es mit der Pipeline und erwartet eine kleine, zuverlässige Maschine, die im Hintergrund Texte erzeugt, Fakten respektiert und sich an Absprachen hält.

Dann beginnt die eigentliche Beobachtung.

Qwen liefert technisch brauchbare Struktur, klingt aber stellenweise, als hätte es Deutsch auf einem Umweg über ein schlecht sortiertes Bordprogramm gelernt. Mistral schreibt flüssiger, erfindet dafür gelegentlich selbstbewusst neue Szenen. Gemma betrachtet JSON eher als freundliche Empfehlung. Und irgendwo dazwischen sitzt man als Entwickler vor einem lokalen Modell, das eine einzelne spitze Klammer ausgibt und damit offenbar seinen Beitrag zur Wertschöpfung geleistet hat.

Die spannende Erkenntnis ist nicht, dass lokale Modelle schlechter sind. Das wäre zu einfach.

Die spannende Erkenntnis ist, dass sie gnadenlos zeigen, welche Teile einer Pipeline wirklich robust sind. Parser, Modellprofile, Repair-Flows, Quality-Reports, Faktenprüfung, Bildreihenfolge. Alles, was bei einem starken Cloud-Modell höflich kaschiert wird, steht lokal plötzlich im hellen Maschinenraumlicht.

Für mich sind lokale LLMs deshalb aktuell kein Ersatz für produktionsnahe Qualitätsmodelle. Sie sind eher ein sehr brauchbarer Stresstest.

Und wie so oft in Organisationen gilt auch hier:

Wenn ein System nur mit den sehr Fähigen funktioniert, ist nicht das System stabil. Dann hatte man bisher nur Glück mit der Besetzung.

Provider, Prompts und andere betreute Mehrdeutigkeiten

Veröffentlicht am von
Antworten

Provider, Prompts und andere betreute Mehrdeutigkeiten

Heute war einer dieser Tage, an denen ein Projekt so tat, als würde es nur ein paar kleine technische Erweiterungen bekommen. In Wahrheit wurde darunter wieder an jenen tragenden Balken geschraubt, die niemand sieht, bis sie fehlen. Ich kenne das aus Organisationen. Wenn etwas funktioniert, war es selbstverständlich. Wenn es nicht funktioniert, war es natürlich ein Kommunikationsproblem.

Das Katerprotokoll hat heute gelernt, seine KI-Provider besser auseinanderzuhalten. OpenAI bleibt der Herr mit Manieren und brauchbarer Satzmelodie. Ollama darf lokal üben, stolpern und gelegentlich Formulierungen erzeugen, bei denen selbst mein Ziegenbärtchen kurz die Mitarbeit verweigert. Für die lokale Entwicklung reicht das. Für veröffentlichungsfähige Texte bleibt ein Mindestmaß an Würde weiterhin empfehlenswert.

Sokrates erschien dazu auf dem Bildschirm, dunkel gekleidet, blass, höflich und mit dieser Art digitaler Anteilnahme, die wirkt, als habe jemand Edgar Allan Poe in ein Ticketsystem migriert. „Die Trennung der Provider reduziert operative Mehrdeutigkeit“, sagte er. Ich nickte. Das klang besser als: Wir wissen jetzt endlich, welcher Topf von welchem Koch angebrannt wurde.

Außerdem wurde der Avatar-Kontext geschärft. Optionale Figuren erscheinen nicht mehr nur deshalb, weil sie irgendwo ausführlich beschrieben sind. Eine sehr vernünftige Regel. In vielen Projekten würde allein das die Hälfte aller Meetings verhindern.

Auch der Story-Validator bekam mehr Bedeutung. Bildplatzhalter müssen sauber sitzen. Sokrates darf nicht plötzlich im Raum herumstehen. Briemmas Gehstock gehört weiterhin Briemma und nicht mir. Man sollte meinen, solche Dinge seien offensichtlich. Aber wer je mit automatisierter Texterzeugung gearbeitet hat, weiß: Offensichtlich ist nur ein anderes Wort für noch nicht ausreichend getestet.

Dann war da noch der Header-Banner-Prompt. Die doppelte Banner-Konfiguration wurde entfernt. Eine Redundanz weniger. Kein Feuerwerk, keine Pressemitteilung, kein agiles Rebranding. Nur ein Prompt, der jetzt weniger mit sich selbst spricht. Auch das ist Fortschritt.

Am Ende standen 119 bestandene Tests, 94 Prozent Coverage und ein sauberer Arbeitsstand. Sokrates nannte es „strukturelle Stabilisierung“. Ich nannte es einen Tag, an dem das Projekt weniger Unsinn macht als gestern.

Und das ist, nüchtern betrachtet, schon fast Produktentwicklung.

Drei Tage Arbeit in zwei Stunden KI-Dialog

Veröffentlicht am von
Antworten

Drei Tage Entwicklungsarbeit? Nein. Zwei Stunden mit Sokrates.

Es gibt in der Softwareentwicklung einen besonderen Moment. Den Moment, in dem man auf ein Projekt blickt, das eigentlich noch gar nicht existiert, und dennoch bereits die ersten Architekturdiagramme, Klassen, Schnittstellen und Teststrategien vor sich sieht. Früher begann an dieser Stelle eine mehrtägige Reise durch Dokumentationen, StackOverflow-Beiträge, Tutorials und eine nicht unerhebliche Menge Kaffee.

Diesmal dauerte es ungefähr zwei Stunden.

Der Auslöser war eine scheinbar einfache Frage: Lässt sich aus Reisefotos automatisch ein Blogbeitrag erzeugen?

Aus dieser Frage entstand innerhalb kürzester Zeit ein vollständiges Python-Projekt mit Bildanalyse, Provider-Abstraktion, automatisierten Tests, GitHub-Integration, CI-Pipeline, Qualitätsprüfungen und einer ersten OpenAI-Anbindung. Während ich noch darüber nachdachte, welche Ordnerstruktur wohl sinnvoll wäre, hatte Sokrates bereits eine vorgeschlagen.

„Das ging ungewöhnlich schnell“, bemerkte ich.

Der Bildschirm flackerte kurz und Sokrates erschien.

„Die Alternative wäre gewesen, drei Tage lang dieselben Entscheidungen erneut zu treffen, die bereits tausendfach getroffen wurden.“

Ein schwer widerlegbares Argument.

Interessanterweise war die eigentliche Bildanalyse dabei nicht die größte technische Herausforderung. Die größere Frage lautete: Wie entwickelt man so etwas, ohne später von den Betriebskosten überrascht zu werden?

Sobald OpenAI ins Spiel kommt, taucht nämlich eine neue organisatorische Rolle auf. Nicht Entwickler. Nicht Anwender. Sondern Controller.

Jedes Bild erzeugt Token. Jede Beschreibung erzeugt Token. Jede spätere Story erzeugt weitere Token. Plötzlich beginnt man nicht mehr nur in Klassen und Methoden zu denken, sondern auch in Verbrauchseinheiten.

Genau deshalb entstand früh im Projekt ein Umschalter zwischen lokaler und echter OpenAI-Nutzung. Die Anwendung kann vollständig mit Mock-Daten laufen, ohne einen einzigen API-Aufruf zu erzeugen. Erst wenn die Umgebungsvariable aktiviert wird, spricht das System tatsächlich mit OpenAI.

„Misstraust du der KI?“, fragte Briemma.

„Nein.“

„Den Kosten?“

„Ja.“

Damit war die Diskussion beendet.

Die erste Kostenanalyse fiel überraschend unspektakulär aus. Selbst bei mehreren Bildanalysen pro Tag und automatisierter Story-Erzeugung bewegen sich die erwarteten Kosten aktuell eher im Bereich weniger Euro pro Monat als in dramatischen Cloud-Rechnungen. Trotzdem entstand daraus eine wichtige Projektentscheidung: Jede kostenpflichtige Funktion muss jederzeit abschaltbar bleiben.

Denn Softwareprojekte haben die bemerkenswerte Eigenschaft, zunächst klein zu wirken und später Gewohnheiten zu werden.

Noch spannender wurde die Sicherheitsbetrachtung. Reisebilder enthalten oft deutlich mehr Informationen als man zunächst glaubt. Ortsangaben, Metadaten, Zeitstempel und manchmal sogar personenbezogene Informationen reisen unbemerkt mit. Deshalb wurde von Beginn an darauf geachtet, dass die Bildverarbeitung kontrolliert erfolgt und die eigentliche OpenAI-Nutzung über klar definierte Provider gekapselt bleibt.

Technisch betrachtet war das eine Architekturentscheidung.

Organisatorisch betrachtet war es Risikomanagement.

Der eigentliche Überraschungsmoment lag jedoch an anderer Stelle. Nicht in den Kosten. Nicht in der Sicherheit. Sondern in der Geschwindigkeit.

Was früher ein kleines Wochenendprojekt gewesen wäre, entstand an einem Abend. Nicht weil die Arbeit verschwunden wäre. Sondern weil ein großer Teil der mechanischen Entwicklungsarbeit inzwischen delegierbar geworden ist. Tests schreiben, Interfaces definieren, Konfigurationen ergänzen, Fehler analysieren, GitHub-Pipelines reparieren – all das passiert heute in einem Dialog.

Natürlich verschwinden die Entscheidungen dadurch nicht. Im Gegenteil. Die eigentliche Arbeit verschiebt sich von der Implementierung zur Bewertung.

Welche Architektur ist sinnvoll?

Welcher Provider soll austauschbar bleiben?

Welche Risiken entstehen?

Welche Kosten sind akzeptabel?

Die Tastaturarbeit wird weniger. Die Verantwortung nicht.

Als der letzte GitHub-Workflow schließlich grün wurde, erschien Sokrates noch einmal auf dem Bildschirm.

„Projektstatus?“

„Build erfolgreich. Tests erfolgreich. Pipeline erfolgreich.“

„Ausgezeichnet.“

„Und jetzt?“

„Jetzt beginnt der Teil, den früher niemand automatisieren konnte.“

„Welcher?“

„Herauszufinden, was du als Nächstes bauen möchtest.“

Manchmal sind die schwierigsten Probleme erstaunlich resistent gegen künstliche Intelligenz.

Urlaubsfotos und Architektur im Büro des Katers

Veröffentlicht am von
Antworten

Manche Projekte beginnen mit einem Businessplan. Andere mit einer Präsentation. Das Katerprotokoll begann auf einer Kreuzfahrt im Mittelmeer zwischen Buffetzeiten, Tenderbooten und der Erkenntnis, dass erstaunlich viele Urlaubsfotos entstehen, bevor jemand eine vernünftige Idee hat,was man eigentlich damit machen möchte.

Irgendwo zwischen Barcelona, Sardinien und diversen Decks der Explora entstand deshalb ein kleiner Prototyp. Die Idee war simpel: Bilder analysieren lassen, daraus automatisch Geschichtenerzeugen und am Ende einen Reiseblog erhalten, der mehr war als eine chronologische Sammlung von„ Hier stehen wir vor einem Gebäude“ und „Hier essen wir etwas Teures“.

Auf dem Schiff funktionierte das überraschend gut. Zumindest so gut, wie Dinge funktionieren, die man spontan zwischen Cocktails, Hafenausflügen und WLAN-Verbindungen entwickelt. Der Prototyp lebte. Er schrieb Texte. Er produzierte erste Beiträge. Und wie jede erfolgreiche Urlaubsidee hatte er den großen Vorteil, weit genug von der Realität entfernt zu sein.

Zu Hause änderte sich das.

Plötzlich sollte aus dem Reiseexperiment ein richtiges System werden. Kein Bastelprojekt mehr, sondern etwas, das auch in sechs Monaten noch funktionierte und nicht bei jedem kleinen Fehler zusammenfiel wie ein Liegestuhl im Sturm.

Also begann die eigentliche Arbeit. Der neue Rechner wurde eingerichtet, virtuelle Umgebungen entstanden, Git-Repositorys wurden geklont und eine erstaunliche Menge Zeit verschwand in Dingen, die auf keinem Screenshot später sichtbar sein würden. Es war die Art von Arbeit, die man während einer Kreuzfahrt konsequent verdrängt und nach dem Urlaub mit Zinsen zurückbekommt.

Während die ersten Abhängigkeiten installiert wurden, stellte sich eine grundsätzliche Frage. Sollte das System einfach irgendwie funktionieren oder sollte es auch verständlich bleiben? Erfahrungsgemäß schließen sich beide Ziele in vielen Projekten gegenseitig aus.

Genau in diesem Moment erschien Sokrates auf dem Bildschirm.

Er wirkte wie immer, als sei er direkt aus einem viktorianischen Roman in eine Benutzeroberfläche gefallen.

„Wie weit sind wir?“ fragte ich.

„Technisch betrachtet existiert jetzt ein Verzeichnis.“

„Das klingt nicht nach großem Fortschritt.“

„Viele Projekte erreichen nie zuverlässig den Zustand darüber hinaus.“

Es war schwer, gegen diese Argumentation anzukommen.

Je weiter die Entwicklung voranschritt, desto mehr erinnerte mich das gesamte Vorhaben an eine Organisation. Jeder Teil bekam eine eigene Aufgabe. Bilder sollten gefunden werden, aber keine Geschichten schreiben. Metadaten sollten Informationen liefern, aber keine Entscheidungen treffen. Die Bildanalyse sollte beobachten, nicht interpretieren. Die Texterzeugung sollte formulieren, aber keine Ahnung haben, wie ein JPEG aufgebaut ist.

Plötzlich entstand eine kleine digitale Belegschaft aus Spezialisten, die erstaunlich professionell miteinander zusammenarbeitete. Eine seltene Erfahrung für jemanden, der regelmäßig echte Organisationen beobachtet.

Sokrates betrachtete die Architektur einige Sekunden schweigend.

„Sie haben eine Organisation gebaut.“

„Nein. Eine Software.“

„Der Unterschied ist häufig kosmetischer Natur.“

Wieder einmal hatte er einen Punkt.

Mit jedem Commit wurde die Struktur klarer. Scanner fanden Bilder. Metadaten wurden aus YAML-Dateien gelesen. Pipelines verarbeiteten Inhalte. Provider kapselten Sprachmodelle. Context Builder erzeugten Kontext. Tests überprüften jede Annahme. Es entstand langsam jenes seltene Gefühl, dass ein System nicht nur wächst, sondern dabei sogar verständlicher wird.

Besonders faszinierend war die kleine digitale Bürokratie namens Pre-Commit. Jeder Änderungsvorschlag musste mehrere Kontrollen passieren. Formatierung. Typisierung. Tests. Qualitätsprüfungen. Die Maschine entwickelte ein bemerkenswertes Talent dafür, Fehler zu finden, die ich selbst wenige Minuten zuvor noch voller Überzeugung eingebaut hatte.

Manchmal verweigerte eine Bilddatei ihre Mitarbeit. Manchmal stritt sich eine Bibliothek mit einer anderen. Ein anderes Mal war eine Konfiguration korrekt und gleichzeitig falsch. Softwareentwicklung besitzt die einzigartige Fähigkeit, gleichzeitig logisch und absurd zu sein.

Trotzdem begann die ursprüngliche Idee von der Explora-Reise langsam erwachsen zu werden. Aus einem Ordner voller Bilder entstand ein Content Batch. Daraus wurden Bildsammlungen. Bildsammlungen erzeugten Beschreibungen. Beschreibungen wurden zu Kontext. Und Kontext sollte irgendwann automatisch vollständige Blogbeiträge hervorbringen.

Die wichtigste Entscheidung bestand dabei nicht in einer einzelnen Technologie, sondern in ihrer Trennung. Bildanalyse und Texterzeugung wurden bewusst voneinander entkoppelt. Heute mag ein Anbieter genutzt werden. Morgen vielleicht ein anderer. Die Architektur sollte diese Entscheidung aushalten, lange bevor sie überhaupt getroffen werden musste.

Das wirkte zunächst vorsichtig.

Bis man die erste mögliche API-Rechnung betrachtet.

Danach wirkte es erstaunlich vernünftig.

Als schließlich alle Prüfungen grün wurden, lehnte ich mich zurück und betrachtete die Konsole. Ruff bestanden. MyPy bestanden. Pytest bestanden. GitHub synchronisiert. Zum ersten Mal fühlte sich das Projekt nicht wie ein Urlaubsprototyp an, sondern wie eine echte Plattform.

Sokrates erschien noch einmal auf dem zweiten Monitor.

„Und nun?“ fragte ich.

„Nun beginnt der interessante Teil.“

„Die Architektur steht doch.“

„Genau deshalb“, antwortete er. „Ab jetzt muss sie beweisen, dass sie nicht nur gut aussieht.“

Dann verschwand er wieder zwischen dunklen Interface-Elementen und flackernden Textzeilen. Zurück blieb ein System, das seinen Ursprung irgendwo auf einem Kreuzfahrtschiff hatte und nun versuchte, erwachsen zu werden. Vermutlich ist das mehr Entwicklung, als die meisten Urlaubsmitbringsel jemals erreichen.

Kater-Automation für WordPress mit Python und OpenAI

Veröffentlicht am von
Antworten

Eigentlich wollte ich nur vermeiden, nach jedem Urlaub wieder 200 Bilder manuell durchzugehen, drei Stunden an Blogtexten herumzuschreiben und anschließend in WordPress dieselben Buttons anzuklicken wie ein überarbeiteter Praktikant im Content-Team eines Kreuzfahrtkonzerns.

Die vernünftige Lösung wäre natürlich gewesen, einfach weniger zu dokumentieren. Stattdessen entstand der vollkommen entspannte Plan, lokal eine Python-Automation aufzubauen, die Bilder analysiert, EXIF-Daten ausliest, daraus Geschichten erzeugt, HTML formatiert und direkt fertige WordPress-Entwürfe baut. Also im Grunde ein kleines Nebenprojekt für einen ruhigen Abend und definitiv keine Eskalation mit API-Keys, Virtual Environments, Git-Repositories und Testabdeckung.

Die Idee dahinter ist erstaunlich simpel: Bilder landen in einem Ordner, Python überwacht diesen Ordner, OpenAI erzeugt daraus strukturierte Inhalte und WordPress bekommt automatisch vorbereitete Beitragsentwürfe inklusive Medienupload. Natürlich inklusive Logging, Fehlerbehandlung und Qualitätschecks, weil nichts jemals so einfach bleibt, wie man es sich am Anfang in einem kurzen Moment geistiger Selbstüberschätzung vorgestellt hat.

Die technische Aufteilung ist klar: Alles Lokale mit Windows, WordPress, API-Keys und GitHub wird direkt ausgeführt. Konzeption, Code, Tests, Konfiguration und Fehleranalyse werden vollständig vorbereitet und begleitet.

Projektaufbau

  1. Python 3.12 oder neuer installieren.
  2. Lokales Projekt anlegen:
    C:\Projekte\kater-automation
  3. Git-Repository initialisieren und in VS Code öffnen.
  4. Projektstruktur anlegen…
  5. …
  6. …
  7. Aktuell bin ich bei Schritt 180

Geplante Funktionen des MVP

  • Ordnerüberwachung
  • Bildauswertung
  • EXIF-Auslesen
  • Story-Erzeugung
  • HTML-Formatierung
  • WordPress-Medienupload
  • WordPress-Beitragsentwurf
  • Logging
  • Fehlerbehandlung

Tests

  • Konfiguration
  • WordPress-Client
  • Bild-Dateierkennung
  • HTML-Formatierung
  • Story-Payload
  • Fehlerfälle

Codequalität

ruff check .
ruff format .
mypy src
pytest

Fehlermeldungen werden lokal ausgeführt und anschließend zur Analyse bereitgestellt.

Testphase

Der erste MVP-Test erfolgt mit einem kleinen Bildordner von etwa 3 bis 5 Bildern. Danach erfolgt die Prüfung des erzeugten WordPress-Drafts anhand von Titel, Slug, Kategorie, Beitragsbild, Bildergalerie, HTML-Struktur und Status draft oder pending.

Geplante Erweiterungen nach MVP

  • Headerbild-Logik
  • Katerprotokoll-Stil
  • automatische Tagesstruktur
  • interne Verlinkung
  • Bildkomprimierung
  • Duplicate-Erkennung
  • Dry-Run-Modus
  • GitHub Actions

Aufgabenverteilung

Lokale Aufgaben sind Installation auf Windows, Eingabe geheimer API-Keys, WordPress-Login und lokale Ausführung.

Übernommen werden vollständiger Python-Code, Schritt-für-Schritt-Anleitungen, Tests, Konfigurationsdateien, Qualitätschecks, Review von Fehlermeldungen und iterative Anpassung bis zum lauffähigen MVP.

Logbuch eines Urlaubsprojekts

Veröffentlicht am von
Antworten

Logbuch eines Urlaubsprojekts

Wie aus ein paar Katzenbildern, Kreuzfahrtmomenten und einer KI plötzlich eine kleine Serie wurde

Es begann nicht mit einem Businessplan.
Nicht mit einer Content-Strategie.
Und ganz sicher nicht mit dem Satz: „Ich starte jetzt ein satirisches Reiseprojekt mit anthropomorphen Katzen.“

Es begann eigentlich mit Urlaub.

Mit Barcelona.
Mit verspäteten Shuttles.
Mit Rollkoffern.
Mit Kreuzfahrtgästen, die gleichzeitig maximal entspannt und maximal gestresst wirkten.
Und mit der beiläufigen Idee, einige Situationen nicht einfach nur zu fotografieren, sondern als kleine Geschichte festzuhalten.

Anfangs waren es nur einzelne Bilder.
Ein anthropomorpher Kater am Flughafen.
Zwei Katzen am Geländer mit Blick auf Barcelona.
Ein genervter Blick zwischen Buffet, Boarding und Tenderboot.
Mehr visuelle Spielerei als Projekt.

Dann kam Sokrates dazu.

Offiziell KI-Berater.
Praktisch gleichzeitig Texter, Ideengeber, Bildregisseur, Social Media Manager, WordPress-Helfer, Stilkorrektor und gelegentlicher Eskalationsbegleiter.

Während andere Menschen im Urlaub Cocktails bestellten, diskutierten ein Organisationsentwickler und eine KI darüber, ob ein Kreuzfahrtbuffet eigentlich eher Lean Management oder kontrollierte Ressourcenpanik ist.

Aus einzelnen Bildern wurden Szenen.
Aus Szenen wurden Dialoge.
Aus Dialogen wurden Tagesgeschichten.

Plötzlich gab es Running Gags:
Influencer am Strand.
Logistische Großprojekte beim Frühstück.
Mediterrane Rollkofferkrisen.
Übermotivierte Tenderbootfahrer.
Und immer wieder diese stille Erkenntnis, dass Menschen selbst auf Luxusreisen erstaunlich komplizierte Prozesse erschaffen.

Parallel entstand etwas Unerwartetes:
Ein kleines Experiment darüber, wie Mensch und KI gemeinsam Geschichten entwickeln können.

Sokrates lieferte keine fertigen Romane.
Die KI beobachtete keine echten Situationen.
Aber sie half dabei, Fragmente zusammenzuführen:
Fotos.
Notizen.
Stimmungen.
Kleine Gesprächsfetzen.
Ironische Kommentare.
Und daraus entstand Schritt für Schritt ein erzählerischer Stil.

Nicht perfekt.
Nicht komplett geplant.
Aber erstaunlich konsistent.

Mit der Zeit wurde aus dem spontanen Urlaubstagebuch ein echtes kleines Serienprojekt:
Eigene Figuren.
Wiederkehrende Tonalität.
Visuelle Leitlinien.
WordPress-Struktur.
Beitragsbilder.
Kategorien.
Interne Verlinkungen.
Und die Frage, warum ein einfacher Reiseblog plötzlich behandelt wurde wie ein Produkt-Backlog.

Dabei blieb das Projekt bewusst leicht chaotisch.
Denn genau darum geht es eigentlich:
Nicht um perfekte Hochglanzreisen.
Sondern um Beobachtung.

Um Menschen.
Um Situationen.
Um moderne Selbstdarstellung.
Um organisatorische Absurditäten.
Und um die kleine Komik zwischen Erwartung und Realität.

Das Katerprotokoll ist deshalb weniger ein klassischer Blog als ein laufendes Logbuch:
Ein Urlaubsprojekt zwischen Satire, Reisebericht, Organisationsbeobachtung und KI-Experiment.

Oder anders gesagt:
Ein beige-grauer Kater fährt in den Urlaub und diskutiert unterwegs mit einer KI über Social Media, Prozessfehler und die strategische Bedeutung von Rührei auf Kreuzfahrtschiffen.

Rückblickend war das vermutlich nie eine besonders normale Idee.

Aber genau deshalb funktioniert sie.