Jedes Entwicklerteam sitzt auf einem Berg ungenutzten Wissens. Features werden gebaut, Architekturentscheidungen getroffen, Bugs auf interessante Arten gefixt — und dann verschwindet all das im Ticket-System. Wir haben eine Content-Pipeline gebaut, die aus einem einzigen Thema automatisch Blog-Artikel, LinkedIn-Posts und Bilder generiert. Ein API-Call. Fertig.
Das eigentliche Problem: Wissen bleibt intern
Der Engpass war nie fehlendes Wissen — er war die Übersetzungsarbeit zwischen „Wir haben etwas gebaut" und „Wir haben darüber geschrieben".
Ein Entwickler, der gerade ein komplexes Caching-Problem gelöst hat, soll jetzt auch noch Autor, Grafikdesigner und Social-Media-Manager sein. Das passiert nicht. Und selbst wenn der Wille da ist: Jede Plattform hat andere Anforderungen. LinkedIn will kurze Impulse. Eine Website braucht strukturierte Artikel. Die Bildsprache muss passen.
Die Lücke zwischen „Wir wissen das" und „Andere wissen das auch" ist kein Talent-Problem. Es ist ein Reibungsproblem.
Das Ergebnis: Teams produzieren intern exzellenten Output, aber nach außen herrscht Stille.
Die Lösung: Eine Pipeline, kein Prozess
Unser Content-Server nimmt ein Thema entgegen und übernimmt den Rest. Die Pipeline läuft durch klar definierte Schritte — automatisch, nacheinander, ohne manuelle Übergaben.
Was dabei passiert:
- Ein LLM schreibt die Geschichte — plattformspezifisch formatiert, nicht generisch.
- Ein Zensur-Layer aus 22 statischen Mustern und einem zusätzlichen LLM-Review scannt den Output auf sensible Inhalte.
- Flux generiert ein passendes Bild, das direkt auf LinkedIn hochgeladen wird.
- Varianten werden plattformspezifisch angepasst — LinkedIn kurz und direkt, die Website als formatierter Artikel mit
##-Struktur.
Das Entscheidende war der Umgang mit Kontrolle. Nicht jedes Team will Vollautomatismus. Deshalb gibt es drei Modi: vollautomatisch für schnelle Publizierung, Agent-gesteuert für iterative Anpassungen, oder manuell mit Review bei jedem einzelnen Schritt. Dieselbe Pipeline, unterschiedliche Autonomiestufen.
Der technische Tradeoff war bewusst: Lieber einen konsistenten, leicht korrigierbaren Output als maximale kreative Freiheit bei jedem Lauf. Wiederholbarkeit schlägt Einzigartigkeit, wenn das Ziel Volumen und Konsistenz sind.
Was sich geändert hat
Die Zahlen interessieren hier weniger als die Verhaltensänderung. Wenn ein Entwickler ein Problem löst, denkt er jetzt reflexartig: „Das könnte ein Post sein." Der Aufwand dafür ist auf einen API-Call geschrumpft.
Wenn Publizieren genauso einfach ist wie ein Commit pushen, verändert sich, was Teams bereit sind zu teilen.
Das Censorship-Review hat sich dabei als kritischer Baustein herausgestellt — nicht als Bremse, sondern als Vertrauen-Enabler. Teams nutzen den Vollautomatikmodus erst dann, wenn sie dem Review-Layer vertrauen. Dieses Vertrauen wurde iterativ aufgebaut, Muster für Muster.
Die beste Content-Strategie ist am Ende keine Strategie. Es ist eine Pipeline, die Wissen automatisch in Inhalte verwandelt — bevor die Energie, darüber zu schreiben, im nächsten Sprint versickert.