To Code or No Code? Selbst programmieren, No-Code oder KI-Agent im Vergleich

Selbst programmieren, eine No-Code-Plattform nutzen oder einen KI-Agenten bauen lassen? Seit Coding-Agenten auf Zuruf ganze Anwendungen schreiben, verschwimmen die Grenzen – und die Entscheidung wird wichtiger, nicht unwichtiger

Angenommen, die Vertriebsleitung eines mittelständischen Maschinenbauers möchte Besuchsberichte nicht mehr in Word-Dokumenten sammeln, sondern in einer kleinen App: Kunde auswählen, Gesprächsnotiz eintippen, Fotos anhängen, Folgetermin festlegen. Vor wenigen Jahren hätte es dafür zwei Wege gegeben. Entweder ein Ticket bei der IT, die das Vorhaben irgendwo zwischen ERP-Update und Firewall-Erneuerung einplant. Oder ein Baukasten wie Microsoft Power Apps, mit dem ein technisch interessierter Kollege die App selbst zusammenklickt.

Heute gibt es einen dritten Weg, und er ist verführerisch. Der Kollege beschreibt einem KI-Werkzeug in ganzen Sätzen, was die App können soll. Nach einer Stunde läuft eine Web-Anwendung mit Datenbank, Anmeldung und Fotoupload. Niemand im Haus hat eine Zeile davon geschrieben – und niemand im Haus versteht sie wirklich.

Damit ist die alte Frage „To Code or No Code?“ nicht beantwortet, sondern neu gestellt. Es geht nicht mehr nur darum, ob jemand programmieren kann. Es geht darum, wer die entstandene Software verantwortet, wenn sie in zwei Jahren noch laufen soll, wenn ein Sicherheitsupdate fällig ist oder wenn der Kollege das Unternehmen verlässt. Wer diese Frage vor dem ersten Klick oder dem ersten Prompt beantwortet, spart sich später viel Ärger.

Drei Wege zur eigenen Software – und warum sie sich heute überschneiden

Bevor es um die Entscheidung geht, lohnt ein kurzer Blick auf die drei Wege. Sie sind weniger scharf getrennt, als es die Begriffe nahelegen.

Selbst programmieren

Klassische Softwareentwicklung heißt: Ein Team schreibt Quellcode in einer Programmiersprache wie Java, C#, Python oder TypeScript, verwaltet ihn in einer Versionsverwaltung wie Git, testet ihn automatisch und betreibt ihn auf eigenen Servern oder in der Cloud. Das ist der aufwendigste Weg, aber der einzige, bei dem das Unternehmen jede Entscheidung selbst in der Hand hat – von der Architektur über die Datenhaltung bis zum Hosting. Wichtig für das Verständnis: Auch wer „selbst programmiert“, tut das heute fast immer mit KI-Unterstützung. Die Grenze zwischen „von Hand“ und „mit KI“ ist im Entwickleralltag längst gefallen.

No-Code und Low-Code

No-Code-Plattformen wie Airtable, Ninox oder Webflow lassen Anwendungen, Datenbanken und Websites über eine grafische Oberfläche entstehen, ganz ohne Programmierung. Low-Code-Plattformen wie Microsoft Power Apps, Mendix oder OutSystems arbeiten ebenfalls visuell, erlauben aber an den Stellen eigenen Code, an denen die Bausteine nicht reichen. Der entscheidende Punkt: Die Plattform bringt den Betrieb gleich mit – Anmeldung, Berechtigungen, Hosting, Updates. Was die Begriffe genau meinen und welche Plattformen es gibt, erklärt der Überblick No-Code und Low-Code: Was dahintersteckt; wie aus einer Idee Schritt für Schritt eine Low-Code-App wird, zeigt der Praxisbeitrag Von der Idee zur App mit Low-Code und No-Code.

KI-Assistenten und Coding-Agenten

Der dritte Weg hat sich in kurzer Zeit stark verändert. Die ersten KI-Assistenten ergänzten beim Tippen die nächste Codezeile. Heutige Coding-Agenten – also KI-Programme, die selbstständig mehrere Arbeitsschritte hintereinander ausführen – lesen ein ganzes Projekt, legen Dateien an, führen Tests aus und korrigieren ihre eigenen Fehler. Dazu gehören Werkzeuge wie GitHub Copilot, Cursor, Devin Desktop (bis Juni 2026 Windsurf) und Claude Code, der Coding-Agent von Anthropic, der im Terminal und in Entwicklungsumgebungen arbeitet und seit Mai 2025 allgemein verfügbar ist. Daneben gibt es Dienste wie Lovable oder Replit, die aus einer Beschreibung im Browser eine fertige Web-Anwendung erzeugen und gleich veröffentlichen. Wie solche Werkzeuge im Detail arbeiten, beschreiben die Beiträge Claude Code im Entwickleralltag und die besten KI-Tools für Entwickler; eine Werkzeugliste braucht es an dieser Stelle deshalb nicht.

Warum sich die Wege überschneiden: Die großen Low-Code-Plattformen haben eigene KI-Assistenten eingebaut, die aus einer Beschreibung eine erste App oder einen Workflow vorschlagen. Coding-Agenten wiederum erzeugen Anwendungen in einer Geschwindigkeit, die bisher den Baukästen vorbehalten war. Für den Anwender sieht das Ergebnis manchmal gleich aus. Darunter liegt aber etwas grundlegend anderes.

Vibe Coding: Wenn Programmieren wie ein Gespräch klingt

Anfang 2025 tauchte ein Begriff auf, der die Debatte seither prägt: Vibe Coding. Geprägt hat ihn der KI-Forscher Andrej Karpathy. Gemeint ist eine Arbeitsweise, bei der man der KI in Alltagssprache beschreibt, was entstehen soll, das Ergebnis ausprobiert und bei Fehlern einfach weiter beschreibt – ohne den erzeugten Code selbst zu lesen. Man folgt dem Gefühl, ob es funktioniert, nicht dem Verständnis, warum es funktioniert.

Für bestimmte Zwecke ist das völlig in Ordnung. Wer am Wochenende ein Skript baut, das die eigenen Urlaubsfotos nach Datum sortiert, muss den Code nicht verstehen. Läuft etwas schief, ist der Schaden klein. Ähnlich bei einem Klickprototyp, der nur zeigen soll, wie eine Anwendung später aussehen könnte: Er wird nach der Vorführung weggeworfen.

Heikel wird es, wenn ein Vibe-Coding-Ergebnis unbemerkt vom Wegwerfprototyp zum Arbeitsmittel wird. Genau das passiert in Unternehmen leicht. Die Besuchsbericht-App aus dem Beispiel funktioniert ja. Also wird sie genutzt, mit echten Kundendaten, von zwanzig Außendienstlern. Und plötzlich hängt ein Geschäftsprozess an einem Programm, das niemand geprüft hat und das niemand pflegen kann.

Wichtig ist die Abgrenzung: KI-gestützte Entwicklung und Vibe Coding sind nicht dasselbe. Ein erfahrenes Entwicklerteam, das mit einem Coding-Agenten arbeitet, liest den erzeugten Code, lässt Tests laufen, prüft Änderungen in einem Review und übernimmt Verantwortung für das Ergebnis. Die KI schreibt schneller, der Mensch entscheidet. Beim Vibe Coding fällt genau dieser zweite Teil weg. Der Unterschied liegt also nicht im Werkzeug, sondern im Umgang damit.

Was Sie am Ende in der Hand halten

Um die drei Wege fair zu vergleichen, hilft eine einfache Frage: Was besitzt das Unternehmen, wenn das Projekt fertig ist? Die Antworten unterscheiden sich deutlich.

• Selbst programmiert (mit oder ohne KI): Sie besitzen Quellcode. Er gehört Ihnen, Sie können ihn überall betreiben, verändern und weitergeben. Sie tragen aber auch alle Pflichten: Updates der verwendeten Bibliotheken, Sicherheitslücken, Hosting, Datensicherung, Dokumentation.
• No-Code oder Low-Code: Sie besitzen eine Anwendung auf einer Plattform. Den Betrieb übernimmt der Anbieter, Updates kommen automatisch, Anmeldung und Berechtigungen sind geregelt. Dafür hängen Sie an dieser Plattform – an ihren Preisen, ihren Funktionen, ihrem Fortbestand.
• Per Coding-Agent erzeugt: Sie besitzen ebenfalls Quellcode, mit denselben Pflichten wie beim selbst programmierten Weg. Der Unterschied: Der Code ist sehr schnell entstanden, und womöglich kennt ihn niemand im Haus. Rechtlich und technisch ist er Ihr Code; praktisch ist er eine Black Box, solange niemand ihn gelesen hat.

Diese Gegenüberstellung erklärt, warum ein KI-generiertes Programm für eine Fachabteilung ohne Entwickler oft die riskantere Wahl ist als eine Low-Code-App, obwohl es schneller fertig war. Und sie erklärt, warum ein Entwicklerteam mit Coding-Agenten häufig besser fährt als mit einer Low-Code-Plattform: Es kann den Code lesen, verantworten und frei weiterentwickeln, ohne an einen Anbieter gebunden zu sein.

Entscheidungshilfe: Fünf Fragen, die den Weg bestimmen

Die Wahl des Werkzeugs ist selten eine technische Geschmacksfrage. Sie folgt aus ein paar nüchternen Fragen, die sich jede Projektleitung vor dem Start stellen sollte. Keine davon verlangt Programmierkenntnisse.

1. Wer pflegt die Anwendung in zwei Jahren?

Das ist die wichtigste Frage, und sie wird am häufigsten übersprungen. Gibt es im Haus Entwickler, die Code lesen und warten können, ist KI-gestützte Programmierung ein naheliegender Weg. Gibt es niemanden, spricht vieles für eine Plattform, bei der der Anbieter die Technik übernimmt und die Fachabteilung nur noch die Inhalte pflegt. Ein KI-generiertes Programm ohne Betreuer ist auf Zeit gebaut, auch wenn das niemand so geplant hat.

2. Wie heikel sind die Daten?

Eine Raumbuchung für den Besprechungsraum ist etwas anderes als eine Anwendung mit Gesundheitsdaten von Beschäftigten oder Zahlungsinformationen von Kunden. Je sensibler die Daten, desto wichtiger sind geprüfte Zugriffsrechte, Protokollierung und ein klarer Speicherort. Bei personenbezogenen Daten gilt die DSGVO unabhängig vom Werkzeug: Das Unternehmen muss wissen, wo die Daten liegen und wer darauf zugreift. Bei Plattformen heißt das: Vertrag zur Auftragsverarbeitung und Rechenzentrumsstandort prüfen. Bei selbst gebautem oder KI-erzeugtem Code heißt es: Sicherheitsprüfung, bevor echte Daten hineinfließen.

3. Wie individuell ist die Logik?

Formulare, Freigaben, Listen und Benachrichtigungen bilden No-Code- und Low-Code-Plattformen gut ab. Wird die Logik dagegen speziell – etwa eine Preisberechnung mit vielen Ausnahmen, eine Optimierung von Lieferrouten oder die Anbindung an eine alte Branchensoftware ohne saubere Schnittstelle –, stoßen Baukästen an Grenzen. Hier spielt Code seine Stärke aus, und Coding-Agenten machen ihn deutlich schneller verfügbar als früher.

4. Wie viele Menschen und Systeme hängen daran?

Eine Anwendung für fünf Kolleginnen verzeiht vieles. Eine Anwendung, an der Hunderte Nutzer, ein Onlineshop oder die Buchhaltung hängen, braucht Lasttests, Ausfallsicherheit und eine geordnete Weiterentwicklung. Low-Code-Plattformen für Unternehmen können das leisten, kosten dann aber oft spürbar mehr pro Nutzer. Bei eigenem Code liegt die Verantwortung für Stabilität vollständig beim eigenen Team.

5. Wie schnell muss es gehen, und wie lange soll es leben?

Ein Prototyp für eine Messe in drei Wochen hat andere Anforderungen als ein System, das zehn Jahre laufen soll. Kurzlebiges darf schnell und pragmatisch entstehen, auch per Vibe Coding. Langlebiges verdient eine saubere Grundlage, sonst zahlt man die Abkürzung später mit Zinsen zurück. Ein bewährter Trick: Schon beim Start festlegen und aufschreiben, ob etwas ein Wegwerfprototyp ist. Dann fällt es leichter, ihn später tatsächlich wegzuwerfen.

Welcher Weg für welches Projekt: typische Fälle

Aus den fünf Fragen ergeben sich für viele Vorhaben recht klare Empfehlungen. Die folgenden Fälle sind Beispiele, keine Gesetze; im Einzelfall können Budget, vorhandene Lizenzen oder das Wissen im Team den Ausschlag anders geben.

• Klickprototyp oder Ideentest: KI-Generator oder Vibe Coding, ausdrücklich als Wegwerfversion. Ziel ist Feedback, nicht Betrieb. Echte Kundendaten gehören nicht hinein.
• Abteilungs-App in einem Microsoft-365-Unternehmen: Low-Code, etwa Power Apps mit SharePoint- oder Dataverse-Daten. Anmeldung und Berechtigungen kommen aus der vorhandenen Umgebung, die IT behält den Überblick.
• Abläufe zwischen Anwendungen automatisieren: Automatisierungsplattformen wie Power Automate oder n8n, die vorgefertigte Anbindungen mitbringen. Eigener Code nur dort, wo eine Schnittstelle fehlt.
• Kleine Datenbank für ein Team ohne IT-Abteilung: No-Code-Datenbanken wie Airtable oder Ninox. Vorher klären, wo die Daten liegen und wie man sie wieder herausbekommt.
• Kundenportal oder Webanwendung mit eigener Logik: eigene Entwicklung mit KI-Unterstützung, wenn ein Team sie betreuen kann; sonst eine Low-Code-Plattform für Unternehmen, die ausdrücklich für externe Nutzer lizenziert ist.
• Eigenes Softwareprodukt oder Kernsystem: eigene Entwicklung, mit Coding-Agenten als Werkzeug des Teams. Hier wäre Abhängigkeit von einer Plattform ein strategisches Risiko, und hier lohnt sich die Investition in Architektur, Tests und Reviews am meisten.
• Auswertung oder Datenbereinigung als Einmalaufgabe: ein KI-Assistent, der ein Skript schreibt, das ein Mensch kurz prüft und dann ausführt. Schneller und flexibler als jede Plattform, und nach getaner Arbeit darf das Skript verschwinden.
• Altsystem modernisieren: Coding-Agenten helfen inzwischen erstaunlich gut dabei, alten Code zu lesen, zu erklären und schrittweise umzubauen. Die Verantwortung für fachliche Richtigkeit bleibt aber bei Menschen, die das Altsystem kennen.

Auffällig ist: Vibe Coding im eigentlichen Sinn – Code übernehmen, ohne ihn zu prüfen – taucht in der Liste nur bei Wegwerfprojekten auf. Coding-Agenten selbst dagegen an vielen Stellen, immer dann, wenn jemand da ist, der ihre Arbeit beurteilen kann.

Risiko Wartbarkeit: Schnell gebaut heißt nicht schnell gepflegt

Software ist nie fertig. Betriebssysteme bekommen Updates, Browser ändern ihr Verhalten, verwendete Bibliotheken schließen Sicherheitslücken, und die Fachabteilung möchte nach drei Monaten ein neues Feld und einen zusätzlichen Bericht. Erfahrungsgemäß entfällt der größere Teil der Kosten einer Anwendung nicht auf ihre Entstehung, sondern auf die Jahre danach.

Coding-Agenten verschieben dieses Verhältnis weiter. Der Bau wird billiger, die Pflege nicht im selben Maß. Ein Agent kann zwar auch spätere Änderungen vornehmen, doch jede Änderung an Code, den niemand versteht, ist ein kleines Glücksspiel. Typische Symptome sind doppelt vorhandene Funktionen, uneinheitliche Benennungen, fehlende Tests und eine Struktur, die sich mit jeder Erweiterung weiter verknotet. Entwickler sprechen von technischen Schulden: Abkürzungen von heute, die später mit Aufwand zurückgezahlt werden müssen.

Es gibt einen zweiten, leiseren Effekt. Wer mit KI arbeitet, fühlt sich schneller, ist es aber nicht immer. Eine viel beachtete Studie der Forschungsorganisation METR fand im Juli 2025, dass erfahrene Open-Source-Entwickler mit KI-Werkzeugen bei ihren Aufgaben im Mittel langsamer waren – sich selbst aber für schneller hielten. METR stuft das Ergebnis inzwischen selbst als überholt ein: Neuere Messungen von Anfang 2026 deuten eher auf einen leichten Zeitgewinn hin, sind aber nach Angaben der Forscher unsicher. Die Werkzeuge haben sich seither deutlich verbessert. Die Lehre bleibt trotzdem gültig: Das Gefühl der Geschwindigkeit ersetzt keine Messung, und gesparte Zeit beim Schreiben kann beim Prüfen und Reparieren wieder verloren gehen.

Was hilft? Bei Low-Code-Apps: Namenskonventionen, eine kurze Beschreibung, was die App tut, und eine benannte Person, die zuständig ist. Bei Code: Versionsverwaltung von Anfang an, automatische Tests, Reviews durch einen Menschen und eine Projektdatei, in der Regeln für den Agenten stehen – etwa welche Bibliotheken erlaubt sind und wie Code aufgebaut sein soll. Das klingt nach Bürokratie, ist aber genau der Unterschied zwischen einem Werkzeug, das ein Team beschleunigt, und einem, das es später ausbremst.

Risiko Sicherheit: Was ungeprüfter Code anrichten kann

KI-Modelle haben aus riesigen Mengen öffentlichen Codes gelernt – darunter auch aus schlechtem und unsicherem. Entsprechend erzeugen sie mitunter Code, der funktioniert, aber angreifbar ist. Die häufigsten Schwachstellen sind dieselben, die auch Menschen unterlaufen, nur in höherem Tempo:

• Fehlende Zugriffsprüfung: Die App zeigt jedem angemeldeten Nutzer alle Datensätze, weil die Rechteprüfung nie ausdrücklich verlangt wurde.
• Zugangsdaten im Code: Passwörter oder API-Schlüssel stehen im Klartext in einer Datei, die später in einem öffentlichen Verzeichnis landet.
• Ungeprüfte Eingaben: Formulareingaben werden ungefiltert in Datenbankabfragen übernommen, ein Einfallstor für sogenannte Injection-Angriffe.
• Erfundene oder veraltete Bibliotheken: Modelle schlagen gelegentlich Softwarepakete vor, die es gar nicht gibt. Angreifer haben begonnen, Pakete unter solchen erfundenen Namen zu veröffentlichen, damit sie bei der nächsten Installation mitgeladen werden.

Coding-Agenten bringen ein zusätzliches Risiko mit. Sie lesen nicht nur Code, sondern auch Dokumentation, Webseiten und Tickets – und führen Befehle auf dem Rechner aus. Versteckt jemand in einer dieser Quellen Anweisungen an die KI, kann der Agent sie befolgen. Fachleute nennen das Prompt Injection. Deshalb gehören Agenten in eine abgeschottete Umgebung, mit möglichst wenigen Rechten und ohne Zugriff auf Produktivdaten oder Zugangsdaten, die sie nicht brauchen.

No-Code- und Low-Code-Plattformen sind nicht automatisch sicherer, aber ein Teil der Verantwortung liegt beim Anbieter: Anmeldung, Verschlüsselung und Updates der Plattform übernimmt er. Die typischen Fehler entstehen hier bei falsch gesetzten Freigaben – etwa einer Tabelle, die versehentlich öffentlich zugänglich ist. Gleich welcher Weg: Bevor eine Anwendung mit echten Daten in Betrieb geht, sollte jemand mit Sicherheitsverstand draufschauen.

Risiko Abhängigkeit: Plattform gegen Modell

Bei No-Code und Low-Code ist das Lock-in-Risiko bekannt. Die Anwendung lebt auf der Plattform des Anbieters, und ein Umzug bedeutet in der Regel Neubau. Erhöht der Anbieter die Preise, stellt Funktionen ein oder verschwindet ganz, hat das Unternehmen wenig Verhandlungsspielraum. Ein Lehrstück lieferte Amazon, als der Konzern seinen Baukasten Honeycode einstellte und Nutzer ihre Anwendungen selbst umziehen mussten.

Bei KI-gestützter Entwicklung sieht die Abhängigkeit anders aus. Der erzeugte Code gehört dem Unternehmen und lässt sich mit jedem anderen Werkzeug weiterbearbeiten. Abhängig wird man stattdessen von der Arbeitsweise: von einem bestimmten Modell, an dessen Stärken sich das Team gewöhnt hat, von Preismodellen, die sich mehrmals im Jahr ändern, und davon, dass der Quellcode zur Verarbeitung an einen Cloud-Dienst geht. Wer das nicht möchte, kann Modelle mit offenen Gewichten auch selbst betreiben – mit eigenen Vor- und Nachteilen, die der Beitrag Open-Weight oder proprietäres Modell für Coding Agents durchspielt.

Die beiden Abhängigkeiten sind unterschiedlich schwer. Den Coding-Agenten zu wechseln, kostet Eingewöhnung. Die Low-Code-Plattform zu wechseln, kostet im Zweifel die Anwendung. Für Kernsysteme spricht das klar für eigenen Code. Für viele kleine Fachanwendungen ist die Plattformbindung dagegen ein vertretbarer Preis für einen Betrieb, um den sich niemand im Haus kümmern muss.

Hybride Teams: Wie Fachabteilung, IT und KI zusammenarbeiten

Die interessanteste Entwicklung ist nicht ein einzelnes Werkzeug, sondern die Verschiebung von Rollen. In vielen Unternehmen entstehen gemischte Teams, in denen Fachleute, Entwickler und KI-Werkzeuge gemeinsam Software bauen. Damit das funktioniert, braucht es eine klare Arbeitsteilung.

Wer was macht

• Fachabteilung: kennt den Ablauf und die Ausnahmen. Sie beschreibt, was gebraucht wird, baut einfache Anwendungen auf der freigegebenen Plattform selbst und testet mit echten Fällen.
• Entwickler: kümmern sich um Architektur, Schnittstellen, Sicherheit und alles, was über die Bausteine hinausgeht. Mit Coding-Agenten liefern sie Erweiterungen, Anbindungen und Tests schneller, und sie prüfen, was die KI vorschlägt.
• IT-Betrieb: legt fest, welche Plattformen und KI-Werkzeuge erlaubt sind, mit welchen Daten sie arbeiten dürfen und wie Anwendungen in den Regelbetrieb übergehen.
• KI-Werkzeuge: übernehmen Routine – Code schreiben, Tests ergänzen, Dokumentation entwerfen, Fehler eingrenzen. Sie arbeiten zu, entscheiden aber nicht.

Spielregeln, die sich bewähren

Erstens eine kurze Liste erlaubter Werkzeuge, statt jedes Team selbst entscheiden zu lassen. Zweitens ein Übergabepunkt: Sobald eine selbst gebaute Anwendung mehr als eine Handvoll Nutzer hat oder personenbezogene Daten verarbeitet, schaut die IT darauf und übernimmt bei Bedarf. Drittens die Regel „Kein Code ohne zweites Augenpaar“ – gleich, ob ein Mensch oder eine KI ihn geschrieben hat. Wie Unternehmen die Verantwortung zwischen Fachanwendern und IT bei Low-Code-Projekten konkret verteilen, behandelt der Beitrag Low-Code-Plattformen und die Zukunft der Softwareentwicklung.

Wie sich die Arbeit der Entwickler verändert

Entwickler schreiben weniger Code von Hand und verbringen mehr Zeit damit, Aufgaben präzise zu beschreiben, Ergebnisse zu prüfen und Zusammenhänge im Blick zu behalten. Das klingt nach Herabstufung, ist aber das Gegenteil: Die Fähigkeit, ein System zu verstehen und Fehler in fremdem Code zu erkennen, wird wertvoller, weil plötzlich viel mehr fremder Code entsteht. Wer nie gelernt hat, sauberen Code zu lesen, kann auch einen Coding-Agenten nicht sinnvoll anleiten. Grundlagen wie Softwaredesign, Testen und Sicherheit verlieren deshalb nicht an Bedeutung, sondern gewinnen.

Für Fachanwender gilt Ähnliches auf anderer Ebene. Wer seine Abläufe klar beschreiben kann, mit Bedingungen, Ausnahmen und Beispielen, bekommt von einer Low-Code-Plattform wie von einem Coding-Agenten bessere Ergebnisse. Die eigentliche Kernkompetenz verschiebt sich vom Programmieren zum präzisen Formulieren von Anforderungen.

Ersetzt KI am Ende No-Code und klassische Entwicklung?

Diese Frage wird oft gestellt, und die ehrliche Antwort lautet: nein, aber sie verschiebt die Gewichte. Coding-Agenten nehmen No-Code-Plattformen einen Teil ihres früheren Hauptarguments, dass man ohne Programmierkenntnisse Software bauen kann. Diesen Vorteil haben die Plattformen nicht mehr exklusiv. Ihr bleibender Vorteil ist ein anderer: der geregelte Betrieb, die eingebauten Berechtigungen und die Möglichkeit für Fachabteilungen, ihre Anwendung selbst zu pflegen, ohne Code anzufassen. Dieser Vorteil wird eher wichtiger, je mehr ungeprüfter Code in Umlauf kommt.

Klassische Entwicklung wiederum verschwindet nicht, sie verändert ihr Gesicht. Die Zahl der Zeilen, die Menschen selbst tippen, sinkt. Die Verantwortung dafür, was in Produktion geht, bleibt bei ihnen. Wer behauptet, Entwickler würden bald überflüssig, verwechselt das Schreiben von Code mit dem Bauen von Software.

Überschätzt wird derzeit vor allem die Vorstellung, eine Fachabteilung könne mit einem KI-Generator dauerhaft auf die IT verzichten. Unterschätzt wird, wie stark Coding-Agenten erfahrene Teams entlasten, wenn diese ihre Abläufe darauf einstellen – mit klaren Regeln, Tests und Reviews statt blindem Vertrauen.

Was das für Ihr Unternehmen bedeutet

Meine Empfehlung: Entscheiden Sie nicht nach Werkzeug, sondern nach Verantwortung. Für jede neue Anwendung sollte vor dem Start feststehen, wer sie in zwei Jahren pflegt, welche Daten sie berührt und ob sie ein Wegwerfprototyp oder ein Arbeitsmittel ist. Aus diesen drei Antworten ergibt sich der Weg meist von selbst.

• Für Fachabteilungen ohne Entwickler: No-Code und Low-Code auf einer von der IT freigegebenen Plattform. KI-Generatoren für Ideen und Prototypen, nicht für den Dauerbetrieb.
• Für Entwicklerteams: Coding-Agenten als festes Werkzeug, mit Regeln, Tests und Reviews. Low-Code dort, wo Fachabteilungen selbst weiterarbeiten sollen.
• Für die Unternehmensleitung: eine kurze, verbindliche Richtlinie, welche Werkzeuge mit welchen Daten erlaubt sind, und ein klarer Übergabepunkt von der Fachabteilung an die IT.

Wer diese Grundlagen schafft, kann die neuen Werkzeuge mit gutem Gewissen nutzen. Wer sie überspringt, baut schneller als je zuvor – und sammelt dabei Anwendungen, die irgendwann niemand mehr versteht. Einen Überblick über Plattformen und Schulungen rund um visuelle Entwicklung bietet das Topic No-Code und Low-Code Plattformen.

Häufige Fragen zu Code, No-Code und KI-Agenten

Kann ich mit Vibe Coding eine App bauen, ohne programmieren zu können?

Ja, für einfache Anwendungen und Prototypen funktioniert das erstaunlich gut. Sobald die App echte Daten verarbeitet, mehrere Nutzer hat oder länger laufen soll, brauchen Sie jemanden, der den Code prüfen und pflegen kann. Ohne diese Person ist eine Low-Code-Plattform meist die sicherere Wahl.

Machen Coding-Agenten No-Code-Plattformen überflüssig?

Nein. Sie nehmen den Plattformen einen Teil ihres Alleinstellungsmerkmals, aber nicht den geregelten Betrieb mit Anmeldung, Berechtigungen und Updates. Für Fachanwendungen, die eine Abteilung selbst pflegen soll, bleibt eine Plattform oft die bessere Lösung.

Wem gehört KI-generierter Code, und darf ich ihn im Unternehmen einsetzen?

Die großen Anbieter beanspruchen in ihren Geschäftsbedingungen in der Regel keine Rechte am erzeugten Ergebnis und übertragen etwaige eigene Rechte auf den Kunden. Ob und wie weit KI-generierter Code urheberrechtlich geschützt ist, ist rechtlich noch nicht abschließend geklärt. Prüfen Sie die Bedingungen des eingesetzten Werkzeugs und klären Sie im Zweifel mit der Rechtsabteilung, welche Werkzeuge mit welchem Code arbeiten dürfen; das ist keine Rechtsberatung, sondern ein Hinweis auf die offenen Punkte.

Was sollten Entwickler jetzt lernen?

Den Umgang mit Coding-Agenten – Aufgaben präzise beschreiben, Projektregeln festlegen, Ergebnisse prüfen –, dazu Grundlagen, die durch KI wichtiger werden: Softwaredesign, automatisierte Tests und sichere Programmierung. Wer fremden Code schnell beurteilen kann, profitiert am meisten von den neuen Werkzeugen.

Womit sollte ein Unternehmen anfangen?

Mit einem überschaubaren Pilotprojekt, das nicht geschäftskritisch ist, und einer kurzen Richtlinie für erlaubte Werkzeuge und Daten. Nach einigen Wochen lässt sich ehrlich bewerten, wo Zeit gespart wurde und wo Nacharbeit entstand.

Wie Entwicklerteams und technisch interessierte Fachleute Coding-Agenten kontrolliert einsetzen – vom ersten Prompt über Projektregeln bis zum Review –, behandelt das Seminar Vibe Coding mit KI-Agenten. Es eignet sich auch als gemeinsamer Einstieg für hybride Teams aus Fachabteilung und IT.