Automatisierung galt lange als Entwicklerthema: Wer einen wiederkehrenden Prozess digitalisieren wollte, brauchte ein Ticket, ein Budget und einen Platz in der Roadmap. Ein aktuelles Beispiel aus der Redaktion von t3n deutet auf eine Verschiebung hin. Dort hat ein Team einen KI-Agenten in Alltagssprache erstellt – also ohne klassische Programmierung, allein über Beschreibungen dessen, was passieren soll. Das Ergebnis: Der Agent legt heute mehr als 80 Prozent der Werbeaufträge an.

Mehr Details nennt die Meldung nicht. Trotzdem ist der Fall aufschlussreich, weil er einen Prozesstyp trifft, den praktisch jedes mittelständische Unternehmen kennt: strukturierte, regelbasierte Dateneingaben, die viel Zeit kosten und wenig fachliche Entscheidung erfordern.

Was mit Vibe Coding gemeint ist

Unter Vibe Coding versteht man das Erstellen funktionierender Software durch natürlichsprachliche Anweisungen an ein KI-Modell, statt durch das Schreiben von Code. Die Person beschreibt das gewünschte Verhalten, prüft das Ergebnis und schärft die Beschreibung nach, bis der Ablauf stimmt.

Ein KI-Agent wiederum ist mehr als ein Chatbot: Er führt Arbeitsschritte aus – liest Eingaben, wendet Regeln an, schreibt Daten in ein System. Die Kombination aus beidem ist der eigentliche Hebel. Nicht das Modell, das Texte formuliert, sondern das Modell, das einen definierten Prozess wiederholbar abarbeitet.

Warum die Auftragsanlage ein guter Einstiegsfall ist

Dass ausgerechnet die Anlage von Werbeaufträgen automatisiert wurde, passt zu einem Muster, das sich in vielen Unternehmen findet. Solche Prozesse haben typischerweise Eigenschaften, die Automatisierung begünstigen:

  • Sie laufen häufig und nach weitgehend gleichen Regeln ab.
  • Die Eingangsdaten sind zwar unstrukturiert formuliert, aber inhaltlich begrenzt.
  • Das Zielsystem erwartet ein festes Datenformat.
  • Fehler fallen schnell auf und lassen sich korrigieren.

Entscheidend ist der letzte Punkt. Ein Agent, der 80 Prozent der Fälle übernimmt, ersetzt den Menschen nicht – er entlastet ihn. Die verbleibenden Fälle sind genau die, bei denen Erfahrung und Rückfragen nötig sind. Diese Arbeitsteilung ist realistischer als der Anspruch, einen Prozess vollständig abzugeben.

Die Fachabteilung als Autorin des Prozesses

Der bemerkenswerte Teil des Beispiels ist nicht die Technik, sondern die Rollenverteilung. Gebaut hat den Agenten ein Team, das den Prozess täglich ausführt – nicht eine externe Entwicklungsabteilung.

Das löst ein klassisches Problem: Bei der Automatisierung geht üblicherweise viel Zeit dafür drauf, implizites Fachwissen in eine Spezifikation zu übersetzen. Wer den Prozess selbst beschreibt, überspringt diesen Übersetzungsschritt. Sonderfälle, Ausnahmen und ungeschriebene Regeln landen direkt in der Beschreibung, weil die Person sie kennt.

Gleichzeitig entsteht ein neuer Anspruch an Fachabteilungen. Wer einen Agenten baut, muss den eigenen Prozess sauber denken können: Welche Eingaben gibt es? Welche Entscheidung folgt daraus? Wann ist ein Fall nicht automatisierbar? Diese Klärung ist Prozessarbeit, nicht IT-Arbeit – und sie zahlt sich auch dann aus, wenn am Ende kein Agent entsteht.

Wo die Grenzen verlaufen

Aus einem gelungenen Einzelfall lässt sich keine generelle Entwarnung ableiten. Mehrere Punkte bleiben unabhängig vom Werkzeug zu klären:

  • Datenzugriff: Ein Agent, der Aufträge anlegt, braucht Schreibrechte in einem produktiven System. Berechtigungen, Protokollierung und Rollbacks gehören von Anfang an dazu.
  • Qualitätskontrolle: Eine Quote von über 80 Prozent sagt nichts darüber, wie die übrigen Fälle erkannt werden. Es braucht ein verlässliches Kriterium, wann ein Mensch übernimmt.
  • Betrieb und Wartung: Prozesse ändern sich, Schnittstellen auch. Wer den Agenten gebaut hat, muss ihn auch pflegen können – oder jemand anderes muss ihn übernehmen können.
  • Dokumentation: Natürlichsprachliche Anweisungen sind lesbar, aber nicht automatisch nachvollziehbar. Ohne Versionierung wird aus dem Hilfsmittel schnell eine Blackbox.
  • Datenschutz: Je nach verarbeiteten Inhalten sind personenbezogene Daten im Spiel. Welche Modelle wo laufen, ist eine Governance-Frage.

Vom Einzelfall zum Muster

Wer das Beispiel übertragen will, sucht am besten nicht nach dem größten, sondern nach dem klarsten Prozess. Gut geeignet sind Abläufe, die ein Team ohnehin schon mit einer internen Checkliste bearbeitet – denn diese Checkliste ist bereits die halbe Beschreibung des Agenten.

Sinnvoll ist außerdem, die Erwartung früh zu kalibrieren. Ein Agent, der einen Teil der Fälle zuverlässig erledigt und den Rest sauber übergibt, ist produktiv. Ein Agent, der alle Fälle halbgut erledigt, erzeugt Nacharbeit und verliert schnell das Vertrauen der Nutzerinnen und Nutzer.

Für Web- und Softwareprojekte verschiebt das die Aufgabenteilung: Fachabteilungen können einfache, klar umrissene Abläufe zunehmend selbst automatisieren, während die technische Seite für Schnittstellen, Rechte, Testbarkeit und Betrieb zuständig bleibt. Wer Systeme wie TYPO3 oder angebundene Fachanwendungen betreibt, sollte deshalb prüfen, ob saubere Schnittstellen und nachvollziehbare Berechtigungen vorhanden sind – sie entscheiden darüber, ob solche Agenten überhaupt andocken können. Der größte Gewinn liegt dabei weniger im Werkzeug als in der Disziplin, den eigenen Prozess vorher präzise zu beschreiben.

Quellen