KI-Agenten erstellen: No-Code oder Code?

Wer KI-Agenten bauen will, steht früh vor einer Grundsatzfrage: No-Code, also visuell in einem Workflow-Tool wie n8n, oder eigener Code mit einem Entwickler-Framework? Beide Lager haben laute Fürsprecher, und beide haben in ihren besten Momenten recht. Die nützlichere Frage ist nicht, was moderner wirkt, sondern was Ihr Team lesen kann, wie oft sich der Prozess ändert und wer das System in zwei Jahren betreibt.

No-Code ist dabei längst kein Nischentrend mehr. Gartner rechnet damit, dass bis 2026 rund drei Viertel aller neuen Unternehmensanwendungen mit Low-Code-Werkzeugen entstehen. Die kurze Antwort vorweg: Für die meisten internen Unternehmensprozesse ist ein visuelles Rückgrat mit gezielten Code-Bausteinen der robusteste Weg, eigener Code als Gesamtarchitektur lohnt sich dann, wenn der Agent selbst das Produkt ist. Der Rest dieses Artikels begründet diese Zuordnung entlang der Kriterien, die sich in Projekten als tragfähig erwiesen haben. Kann die Fachabteilung mitlesen? Wo liegen die tatsächlichen Anforderungen, und wo nur die gefühlten?

Worum es eigentlich geht: vier Fragen statt zwei Lager

Die Debatte wird oft als Technikfrage geführt, ist aber eine Organisationsfrage. Vier Punkte entscheiden:

1. Lesbarkeit: Muss nur die Entwicklung verstehen, was das System tut, oder auch die Fachabteilung?
2. Wartung: Von wem und wie schnell wird das System angepasst, wenn sich ein Prozess ändert?
3. Anforderungen: Braucht der Agent eine eigene Oberfläche, extreme Last oder exotische Logik? Oder verbindet er im Kern Systeme und trifft Entscheidungen?
4. Risiko: Was passiert, wenn die eine Person geht, die das System versteht?

Sind diese vier Fragen ehrlich beantwortet, ist die Entscheidung meist schon gefallen. Die Technik folgt der Organisation, nicht umgekehrt.

Was für No-Code-Workflows spricht

Ein Werkzeug wie n8n spielt seine Stärken aus, wenn der Agent vor allem Systeme verbindet. Er liest E-Mails, prüft Daten, schreibt ins ERP und holt menschliche Freigaben ein. Die Logik liegt als Diagramm offen, jeder Schritt ein Knoten, jede Verzweigung eine Linie. Änderungen sind schnell gemacht und sofort testbar. Anbindungen an gängige Systeme bringt das Werkzeug mit, samt der unspektakulären, aber entscheidenden Dinge: Wiederholungsversuche bei Fehlern, Zugangsverwaltung, Ausführungsprotokolle.

Für den Betrieb ist die Sichtbarkeit ein unterschätzter Vorteil. Ein Prozess, den mehrere Personen lesen können, hängt nicht an einer einzigen. Wenn die Fachabteilung im Diagramm sehen kann, warum eine Eingangsrechnung in der Prüfschleife gelandet ist, entsteht Vertrauen, und die Diskussion über den Prozess wird konkret statt abstrakt. Hinzu kommt der Selbstbetrieb, denn n8n läuft auf eigener Infrastruktur, die Daten bleiben im Haus. Für viele Mittelständler ist das ein Ausschlusskriterium gegen reine Cloud-Baukasten-Alternativen.

KI-Agenten in Code: wann sich das lohnt

Eigener Code lohnt sich, wenn der Agent selbst das Produkt ist: eigene Oberflächen für Endkunden, sehr spezielle Logik, hohe Lastanforderungen, tiefe Integration in eine bestehende Softwarelandschaft mit eigenem Entwicklungsteam. Wer ohnehin Software entwickelt, mit Tests, Versionierung und Deployment-Pipeline, bekommt mit einem Framework maximale Freiheit bei Modellanbindung, Speicherkonzept und Orchestrierung.

Diese Freiheit hat ihren Preis, und der wird gern unterschätzt. Alles, was ein Workflow-Tool mitbringt, muss selbst gebaut und gepflegt werden. Fehlerbehandlung, Wiederanläufe, Anbindungen an Drittsysteme, Protokollierung, Zugriffskontrolle: Nichts davon ist konzeptionell schwer, aber alles zusammen ist ein stiller, dauerhafter Wartungsposten. Ein Agent, der in drei Tagen als Prototyp lief, ist damit noch lange kein System, das drei Jahre zuverlässig arbeitet. Teams unterschätzen dabei selten die Entwicklung, sondern den Betrieb. Der Prototyp glänzt in der Demo, aber die Demo zeigt nie den Montagmorgen, an dem eine Drittanbieter-Schnittstelle ihr Format geändert hat.

Die Matrix lässt sich auch ohne Bild zusammenfassen:

• No-Code-Workflow: Der Agent verbindet Systeme, die Fachabteilung soll mitlesen, der Prozess ändert sich regelmäßig, und der Betrieb bleibt im eigenen Haus.
• Code-Framework: Der Agent ist das Produkt, braucht eine eigene Oberfläche oder muss extreme Last tragen, und ein Entwicklungsteam steht dauerhaft dahinter.

Die ehrliche Gegenrechnung: Kosten im zweiten Jahr

Die wahren Kosten eines Ansatzes zeigen sich nicht in der ersten Woche, sondern im zweiten Jahr. Das ist keine Bauchgefühl-These. Klassische Untersuchungen beziffern den Anteil der Wartung an den gesamten Lebenszykluskosten von Software auf 40 bis 80 Prozent, im Mittel rund 60 Prozent (Robert L. Glass, IEEE Software, 2001). Der größte Teil dieser Wartung ist dabei keine Fehlerkorrektur, sondern Weiterentwicklung: rund 60 Prozent entfallen auf neue Anforderungen, nur etwa 17 Prozent auf das Beheben von Fehlern. Ein System zu bauen ist der kleinere Teil der Rechnung. Es über Jahre anzupassen ist der größere.

Diese Zahlen stammen aus der klassischen Softwareentwicklung, treffen aber beide Wege. Auch ein visueller Workflow will angepasst werden, wenn das ERP ein Update bekommt oder die Fachabteilung eine neue Regel braucht. Der Unterschied liegt nicht darin, ob Wartung anfällt, sondern darin, wie viele Personen sie leisten können und was die Stunde kostet.

Der visuelle Workflow, der wächst und wächst, kann unübersichtlich werden, hundert Knoten auf einer Fläche, Verzweigungen über Verzweigungen. Die Gegenmittel sind dieselben wie in der Softwareentwicklung: klare Strukturen, Unter-Workflows für wiederkehrende Bausteine, Namenskonventionen, eine kurze Dokumentation je Workflow. Bleibt das von Anfang an diszipliniert, entsteht auch mit fünfzig Workflows kein Chaos.

Die Code-Basis hat das umgekehrte Problem. Sie ist beliebig strukturierbar, aber nur für die lesbar, die die Sprache sprechen. Verlässt der einzige Entwickler das Unternehmen, steht das System still. Nicht sofort, aber bei der ersten nötigen Änderung. Dieses Risiko ist derzeit alles andere als theoretisch: Nach der Bitkom-Erhebung vom August 2025 sind in Deutschland rund 109.000 IT-Stellen unbesetzt, und eine freie IT-Position bleibt im Schnitt 7,7 Monate vakant.

Was das konkret bedeutet, zeigt eine einfache Modellrechnung. Angenommen, die Pflege eines selbst entwickelten Agenten kostet zwei Tage im Monat, also rund 16 Stunden. Muss diese Arbeit während der 7,7 Monate Nachbesetzungszeit extern überbrückt werden, fallen bei einem durchschnittlichen IT-Freelancer-Stundensatz von 105 Euro (Freelancer-Kompass 2025) etwa 13.400 Euro an. Dazu kommt die Einarbeitung in fremden Code, bei gut dokumentierten Systemen vielleicht 40 Stunden, also weitere 4.200 Euro. Zusammen knapp 18.000 Euro, nur um den Status quo zu halten, ohne eine einzige neue Funktion. Die Annahmen dürfen Sie gern durch Ihre eigenen ersetzen, der Mechanismus bleibt derselbe. Je weniger Personen ein System lesen können, desto teurer wird jeder Personalwechsel.

Der Code-Weg braucht deshalb mindestens zwei Personen, die das System tragen können, dazu Tests, Dokumentation und nachvollziehbare Versionsstände. Das ist leistbar, gehört aber von Anfang an in die Kalkulation.

Der Maßstab Zuverlässigkeit gilt für beide

Unabhängig vom Werkzeug braucht ein produktiver Agent definierte Fehlerpfade, Protokolle und Überwachung. Ein visueller Workflow ohne Fehlerbehandlung ist genauso fragil wie ein Skript ohne Fehlerbehandlung. Er sieht nur freundlicher aus. Die Anforderungen, die wir in unserem Beitrag über stille Fehler und Monitoring beschreiben, gelten für beide Welten unverändert. Auch die Kostenfrage stellt sich identisch. Die KI-Aufrufe kosten dasselbe, egal ob sie aus einem n8n-Knoten oder aus einer Codezeile kommen. Die Hebel aus unserem Artikel über API-Kosten in KI-Workflows funktionieren in beiden Umgebungen.

Das relativiert die Debatte. Die Wahl des Werkzeugs entscheidet nicht über die Qualität des Systems. Sie entscheidet darüber, wer daran arbeiten kann und wie teuer Änderungen sind.

Der pragmatische Mittelweg: visuell mit Code-Bausteinen

In der Praxis bewährt sich oft eine Kombination: n8n als Rückgrat für Ablauf, Anbindungen und menschliche Freigaben. Und dort, wo Speziallogik nötig ist, ein gezielter Code-Baustein innerhalb des Workflows. Eine komplexe Berechnung, eine ungewöhnliche Datentransformation, ein Aufruf an ein System ohne fertige Anbindung. Dafür gibt es den Code-Knoten, ohne dass gleich die ganze Architektur in Code wandert.

So bleibt der Prozess sichtbar und für mehrere Personen wartbar, ohne dass man an den Grenzen des Werkzeugs kleben bleibt. Die Entscheidung ist damit keine Glaubensfrage mehr, sondern eine Zuordnung: Standardstrecke visuell, Sonderfall in Code. In den Workflows, die wir bauen, bleibt der Code-Anteil meist auf wenige Knoten begrenzt, und genau das hält ihn wartbar. Klein genug, dass ihn ein neuer Entwickler in Stunden versteht statt in Wochen. Und die Entscheidung ist reversibel. Wächst ein Code-Baustein über die Jahre zu einem eigenen System heran, kann er ausgelagert werden, ohne dass der Workflow drumherum neu gebaut werden muss.

Drei typische Fehlentscheidungen und wie man sie vermeidet

In Projekten sehen wir immer wieder dieselben drei Muster:

• Code, weil das Team Code spannender findet: Verständlich, aber teuer, denn ein Standardprozess in Eigenbau bindet Entwicklerzeit an ein Problem, das bereits gelöst ist. Ein guter Test ist die Frage, ob die Lösung auch dann in Code gebaut würde, wenn sie danach jemand anderes warten müsste.
• No-Code, obwohl der Agent ein Produkt ist: Eine kundenseitige Anwendung mit eigener Oberfläche auf ein Workflow-Tool zu stützen heißt, irgendwann gegen das Werkzeug zu kämpfen. Workflow-Tools orchestrieren Prozesse. Sie sind kein Anwendungs-Baukasten.
• Beides parallel, ohne Grenze: Wenn dieselbe Logik teils im Workflow, teils im Code lebt und niemand weiß, wo was entschieden wird, entsteht das Schlechteste aus beiden Welten. Die Grenze gehört definiert: Der Workflow führt, der Code rechnet.

Häufige Fragen aus der Praxis

Ist n8n nicht nur etwas für kleine Lösungen? Nein. Die Grenze verläuft nicht bei der Größe, sondern bei der Art der Aufgabe. Prozessorchestrierung über viele Systeme mit menschlichen Freigaben ist genau das Einsatzgebiet, auch bei hohem Volumen. n8n skaliert laut offizieller Dokumentation im Queue Mode horizontal über zusätzliche Worker-Instanzen, für den Ausfallschutz gibt es einen Multi-Main-Betrieb. Eng wird es bei Anwendungen mit eigener Endkunden-Oberfläche oder extremen Latenzanforderungen.

Müssen wir uns heute endgültig festlegen? Nein, und das ist das stärkste Argument für den Mittelweg. Ein visueller Start mit gezielt eingesetzten Code-Bausteinen hält beide Richtungen offen, und Sie lernen am realen Prozess, wo die tatsächlichen Anforderungen liegen. Ein überschaubarer Einstieg, etwa bei IT-Routineaufgaben, liefert diese Erfahrung ohne großes Risiko.

Was, wenn wir gar keine IT-Kapazität haben? Dann ist die Werkzeugfrage zweitrangig. Wichtiger ist, wer das System betreibt und pflegt. Das kann ein Dienstleister sein; entscheidend ist, dass Prozesslogik und Protokolle so nachvollziehbar sind, dass Sie nicht in Abhängigkeit geraten. Auch das spricht für sichtbare Workflows.

Was kostet der Wechsel von No-Code zu Code später? Weniger, als viele befürchten, sofern sauber gearbeitet wurde. Die teuerste Arbeit beim Aufbau eines Agenten steckt nicht im Werkzeug, sondern im Verständnis des Prozesses, in den Regeln, Sonderfällen und Schnittstellen. Diese Erkenntnisse sind in einem dokumentierten Workflow festgehalten und lassen sich in jede Codebasis übertragen. Was bleibt, ist der Aufwand der Neuimplementierung, aber kein Verlust des Gelernten. Ein Lock-in der Prozesslogik entsteht bei sichtbaren Workflows gerade nicht.

Fazit: No-Code oder Code ist eine Organisationsfrage

No-Code oder Code ist keine Richtungsfrage, sondern eine Zuordnungsfrage. Visuelle Workflows gewinnen überall dort, wo Prozesse sichtbar, wartbar und von mehreren Personen tragbar sein sollen. Code gewinnt dort, wo der Agent selbst das Produkt ist und ein Entwicklungsteam dahintersteht. Der Mittelweg mit n8n als Rückgrat und Code als gezieltem Baustein verbindet beides und ist für die meisten Unternehmensprozesse die robusteste Antwort. Und die Entscheidung ist keine Einbahnstraße, denn die dokumentierte Prozesslogik lässt sich später in jede Architektur überführen.

Wenn Sie vor genau dieser Entscheidung stehen, schauen wir uns im kostenfreien Prozess-Check Ihren konkreten Fall an und sagen Ihnen, welcher Weg zu Prozess und Team passt. Auch dann, wenn die Antwort lautet, dass es dafür keine KI braucht.