Vibe Coding in der Redaktion: Vom Prototyp in den Betrieb

Von /
Grober Prototyp-Block und fertiges Modul mit Prüfsiegel – Vibe Coding vom Prototyp in den Betrieb

Mit Vibe Coding bauen sich Journalisten und Produktteams eigene Werkzeuge, oft in weni­gen Stunden. Damit aus einem gelun­ge­nen Prototyp ein verläss­li­ches Tool für den Redaktionsalltag wird, braucht es mehr als einen funk­tio­nie­ren­den Klickpfad. Wir zeigen, wie Sie Eigenbauten sauber an Redaktionssystem und DAM anbin­den.

Anfang Oktober beschrieb t3n, wie Produktteams mit KI klick­bare App-Prototypen bauen, bevor über eine Entwicklung entschie­den wird. Der Beitrag hält zugleich fest, ein solcher Prototyp »ersetzt keine geprüfte Architektur und keine Sicherheitsprüfung für den produk­ti­ven Betrieb«. An dieser Schwelle stehen auch Redaktionen, die erste Eigenbauten im Einsatz haben.

Vibe Coding bezeich­net das Erstellen von Software per Prompt: Man beschreibt einer KI, was das Programm tun soll, statt den Code selbst zu schrei­ben. Nieman Lab erwar­tete in seinen Prognosen für 2026, dass Innovation in Redaktionen zuneh­mend von Journalisten kommt, die ihre Werkzeuge nun selbst bauen können. Der Autor, ein Technologe bei Google Labs, sieht solche Apps vor allem für Nischen und kleine Gruppen, ausdrück­lich nicht als Ersatz für die etablierte Produktentwicklung.

Auch auf Managementebene wächst das Interesse. Im Trendreport 2026 des Reuters Institute stufen 44 Prozent der befrag­ten Medienmanager KI für Programmierung und Produktentwicklung als »sehr wich­tig« ein, 16 Prozentpunkte mehr als im Vorjahr. Befragt wurden 280 Führungskräfte aus 51 Ländern und Territorien; reprä­sen­ta­tiv ist die Erhebung nach Angaben der Autoren nicht.

Was bedeutet das konkret?

Eigenbauten entste­hen dort, wo Standardsoftware eine Lücke lässt: ein Werkzeug, das Daten für eine inter­ak­tive Grafik aufbe­rei­tet, eine Übersicht über Termine aus der Planung oder ein Skript, das Bildunterschriften im DAM ergänzt. Pete Pachal von The Media Copilot nennt als Beispiel eine Webseite, die Waldbranddaten in Datawrapper-taug­li­che Sechseckkarten umwan­delt, und verweist dazu auf einen Beitrag des DW-Innovationsteams. Zugleich beschreibt er die Lücke zwischen »this works« und »this works every day«.

Für Redaktionen heißt das:

  • Die Datenquelle entschei­det: Solange ein Tool mit expor­tier­ten Testdaten arbei­tet, bleibt es ein Experiment. Sobald es direkt auf Redaktionssystem oder DAM zugreift, wird es Teil der Systemlandschaft.
  • Einzelnutzung ist nicht Teamnutzung: Was einer Person hilft, darf hake­lig sein. Nutzt ein ganzes Ressort das Werkzeug unter Zeitdruck, muss es zuver­läs­sig laufen.
  • Wissen hängt an Personen: Wer ein Tool per Prompt gebaut hat, kennt den Code oft selbst nicht im Detail. Ohne Dokumentation lässt es sich kaum weiter­ent­wi­ckeln.

Wie Vibe Coding den Weg in den Betrieb findet

Pachal stellt fest, dass solche Projekte meist Einzelstücke blei­ben, und empfiehlt eine feste Abfolge: vom Prototyp über Prüfung und Überarbeitung bis zum Start. Aus Integrationssicht kommen drei Punkte hinzu.

Kontrollierte Schnittstellen statt Direktzugriff: Eigenbauten soll­ten weder direkt in Datenbanken schrei­ben noch mit persön­li­chen Logins arbei­ten, sondern über doku­men­tierte APIs und eigene tech­ni­sche Benutzer ange­bun­den werden. Bei WoodWing Studio und WoodWing Assets bieten sich Webhooks an: Das System meldet ein Ereignis, etwa einen Statuswechsel oder ein neues Bild, und ein sepa­ra­ter Dienst reagiert darauf. Das Kernsystem bleibt unver­än­dert, die Logik des Eigenbaus lässt sich getrennt testen, versio­nie­ren und austau­schen.

Wiederkehrende Aufgaben nicht doppelt bauen: Viele Prototypen lösen Standardaufgaben wie Übersetzung, Verschlagwortung oder Benachrichtigungen. Hier lohnt der Abgleich, ob ein gepfleg­ter Workflow die Aufgabe bereits abdeckt, bevor ein weite­res Einzeltool in Betrieb geht.

Klare Zuständigkeiten: Für jedes Werkzeug im Regelbetrieb muss fest­ste­hen, wer es fach­lich verant­wor­tet, wer es tech­nisch betreut und was passiert, wenn es ausfällt.

Unsere Empfehlung

Bremsen Sie die Experimentierfreude nicht, aber geben Sie ihr einen Rahmen:

  • Sandbox bereit­stel­len: Eine Testumgebung mit Beispieldaten erlaubt Prototypen, ohne Produktivsysteme zu berüh­ren.
  • Übergabekriterien fest­le­gen: Definieren Sie, ab wann ein Prototyp in den Betrieb wech­selt, etwa wenn mehr als ein Team ihn nutzt oder er auf Echtdaten zugreift. Ab dann gehö­ren Code-Review, Sicherheitsprüfung und Dokumentation dazu.
  • Andockpunkte defi­nie­ren: Legen Sie fest, über welche Schnittstellen Eigenbauten an Redaktionssystem und DAM ange­bun­den werden dürfen, und verge­ben Sie dafür eigene tech­ni­sche Benutzer mit mini­ma­len Rechten.
  • Bestand pfle­gen: Führen Sie eine einfa­che Liste aller Eigenbauten mit Zweck, Verantwortlichem und Status. Werkzeuge, die niemand mehr nutzt, werden abge­schal­tet.

So unter­stützt aaroon

Den Weg vom Prototyp in den Betrieb bieten wir mit ao.Services als Dienst an: Redaktionen reichen ihren Prototyp ein, wir machen ihn prozess­reif und betrei­ben ihn als siche­ren, über­wach­ten und geprüf­ten Prozess, ange­bun­den an WoodWing Studio oder WoodWing Assets. Der Dienst arbei­tet mit dem KI-Account, den Ihr Haus mitbringt, und unter­stützt die gängi­gen KI-Anbieter.

Vibe Coding verkürzt den Weg zur ersten Version. Ob daraus ein Werkzeug für den Redaktionsalltag wird, entschei­det die Anbindung an die bestehen­den Systeme.

Quellen

Wie können wir Sie unter­stüt­zen?

Kostenloses Erst-Gespräch

Lassen Sie uns gemein­sam prüfen, wo in Ihren Kommunikations‑, Marketing- oder Unternehmensprozessen konkrete Effizienzpotenziale liegen.

– Henning Bartens, Co-CEO

Termin verein­ba­ren


Strukturiert. Ehrlich. Informativ.

Nach oben scrollen