Vor ein paar Jahren hätte niemand für dieses Problem Software gebaut.

Letztens erzählte mir ein Freund von seinem «Problem» und wie er es gelöst hatte. Er wohnt bereits seit Längerem mit seiner Partnerin zusammen, und weil sie verschiedene Arbeitszeiten haben, war oft unklar, ob ihre Katze bereits gefüttert wurde. Die Problemstellung? Nichts Grosses. Keine bahnbrechende Idee für das nächste Start-up. Einfach ein kleiner Nervfaktor im Alltag.

Früher wäre es völlig unverhältnismässig gewesen, hierfür eine eigene App zu bauen. Zu viel Aufwand für zu wenig Nutzen. Eine einfache Notiz am Kühlschrank oder eine kurze Nachricht im Chat wäre völlig ausreichend.

Heute ist das anders. Statt sich mit der Standard-Lösung zufriedenzugeben, hat er sich an einem Abend an den Computer gesetzt und einem KI-Agenten geschildert, was er für eine App möchte. Durch einfaches Chatten, also «Prompten», erzielte er innert kürzester Zeit eine funktionierende App, die er mit seiner Partnerin teilen konnte. Das Resultat? Nicht perfekt, aber vollkommen ausreichend.

Zugegebenermassen ist dieser Freund computeraffin und selbst als Entwickler tätig. Die rasante Entwicklung dieser Coding Agents öffnet diese Möglichkeiten aber zunehmend auch für andere. Und genau hier wird es interessant. Denn wenn selbst Entwickler beginnen, Software nicht mehr «richtig» zu bauen, sondern nur noch schnell genug für den konkreten Zweck zu erzeugen, verschiebt sich eine wichtige Grenze: Plötzlich lohnt sich Software auch für Probleme, die früher schlicht zu klein waren.

Was sind eigentlich Coding Agents?

Kurz ein Schritt zurück. Wenn wir von Vibe Coding sprechen, meinen wir nicht das klassische Autocomplete im Editor, das einzelne Zeilen Code ergänzt. Gemeint sind sogenannte Coding Agents: KI-Systeme, die eigenständig Code schreiben, bestehende Projekte analysieren, Dateien verändern, Befehle ausführen und komplette Aufgaben übernehmen können.

Der Unterschied ist entscheidend. Früher war KI im Entwicklungsprozess vor allem ein Assistent. Heute wird sie zunehmend zum ausführenden Akteur. Man beschreibt nicht mehr jede technische Umsetzung im Detail, sondern eher das gewünschte Resultat:

• «Baue mir eine kleine Web-App für X.»
• «Füge einen Login hinzu.»
• «Speichere die Daten lokal.»
• «Mach das Design mobilfreundlich.»

Der Agent setzt diese Anforderungen anschliessend selbstständig um — inklusive Rückfragen, Anpassungen und Fehlersuche.

Die bekanntesten Vertreter heissen heute Claude Code, Codex oder OpenCode. Entscheidend ist aber weniger das konkrete Tool als die Entwicklung dahinter: Die Hürde, funktionierende Software zu erstellen, sinkt massiv.

Und genau das verändert die Art von Software, die überhaupt entsteht. Kleine interne Helfer, persönliche Automationen, Mini-Tools für Nischenprobleme oder schnelle Prototypen waren früher oft schlicht nicht wirtschaftlich. Nicht weil sie nutzlos gewesen wären, sondern weil der Entwicklungsaufwand zu hoch war.

Mit Coding Agents verschiebt sich diese Grenze. Plötzlich können Einzelpersonen Dinge bauen, für die früher ein Team nötig gewesen wäre. Teams testen Ideen innerhalb von Stunden statt Wochen. Und auch Menschen ohne klassischen Entwicklerhintergrund beginnen, eigene Werkzeuge zu erstellen.

Nicht jede dieser Anwendungen wird langlebig sein. Viele davon müssen es auch gar nicht sein. Aber genau darin liegt der Wandel: Software entsteht zunehmend dort, wo vorher einfach mit einem Workaround gelebt wurde.

Wo es kippt

So weit, so verlockend. Die Katzen-App funktioniert hervorragend, solange sie genau das bleibt: eine kleine, persönliche Lösung für ein begrenztes Problem. Die Anforderungen sind überschaubar, Fehler tolerierbar und niemand erwartet langfristige Wartbarkeit.

Umso spannender wird es, wenn aus einem persönlichen Helfer plötzlich echte Software wird. Was passiert, wenn andere Nutzerinnen und Nutzer dazukommen? Wenn Daten dauerhaft gespeichert werden? Wenn Berechtigungen, Sicherheit, Stabilität oder Nachvollziehbarkeit relevant werden? Wenn die Anwendung auch in einem Jahr noch verstanden, erweitert und betrieben werden muss?

Genau hier stösst Vibe Coding an Grenzen. Nicht weil die Tools schlecht wären. Im Gegenteil: Sie liefern oft beeindruckend schnell brauchbare Resultate. Aber sie optimieren primär auf Umsetzungsgeschwindigkeit, nicht automatisch auf Architektur, Wartbarkeit oder langfristige Verantwortung. Das funktioniert gut, solange Software eher Mittel zum Zweck ist. Sobald daraus jedoch ein Produkt, ein interner Kernprozess oder gar eine geschäftskritische Anwendung wird, tauchen die klassischen Fragen der Softwareentwicklung wieder auf — nur eben später.

Und genau darin liegt auch ein Risiko. Denn vieles wirkt am Anfang erstaunlich einfach. Ein Prompt hier, ein zusätzlicher Agent dort, noch eine schnelle Erweiterung. Doch mit wachsender Komplexität steigt auch der Aufwand, den Überblick zu behalten. Irgendwann verbringt man mehr Zeit damit, die KI zu steuern und ihre Resultate zu korrigieren, als das eigentliche Problem zu lösen.

Die Tools nehmen einem viel Arbeit ab. Das Denken allerdings nicht.

Die gesunde Mitte

Trotzdem wäre es falsch, daraus nur eine Warnung abzuleiten.

Richtig eingesetzt, kann Vibe Coding enorm produktiv machen. Vor allem dort, wo es um repetitive Aufgaben, technische Routinearbeit oder schnelle Exploration geht. Ein erster Prototyp, ein internes Tool, ein neues UI-Konzept oder einfach die Frage «Wie würde das eigentlich aussehen?» — all das entsteht heute in einem Bruchteil der Zeit.

Der eigentliche Gewinn liegt dabei nicht nur in der Geschwindigkeit, sondern in der Verschiebung des Fokus. Weniger Zeit fliesst in Boilerplate und Standardimplementierungen. Mehr Zeit bleibt für Architektur, Fachlogik, Nutzerbedürfnisse und die schwierigen Entscheidungen, die eben nicht automatisch aus einem Prompt entstehen.

Vibe Coding ersetzt gute Entwicklerinnen und Entwickler nicht. Es verändert vielmehr, worauf ihre Aufmerksamkeit gerichtet ist.

Die Voraussetzung dafür ist allerdings, dass man die Kontrolle nicht abgibt. Generierter Code muss weiterhin gelesen, verstanden und hinterfragt werden. Entscheidungen müssen nachvollziehbar bleiben. Reviews verlieren nicht an Bedeutung, nur weil der erste Entwurf von einer KI stammt. Im Gegenteil: Je schneller Software entsteht, desto wichtiger wird die Fähigkeit, Qualität einzuordnen.

Denn ohne dieses Mitdenken produziert Vibe Coding vor allem eines: technische Schuld in höherer Geschwindigkeit. Das Tückische daran ist, dass die Probleme oft erst spät sichtbar werden. Nicht beim ersten Demo-Call. Sondern Monate später, wenn Systeme erweitert, migriert oder stabil betrieben werden müssen.

Ersetzen wird es Dich nicht. Verändern schon.

Wird Vibe Coding Entwicklerinnen und Entwickler ersetzen? Auf absehbare Zeit vermutlich nicht. Was sich aber bereits verändert, ist die Art der Arbeit. Wir schreiben weniger Code von Hand und verbringen mehr Zeit damit, Systeme zu steuern, Resultate zu bewerten und technische Entscheidungen einzuordnen.

Das ist kein Bedeutungsverlust des Programmierens — eher das Gegenteil. Denn je einfacher Software erzeugt werden kann, desto wichtiger wird die Fähigkeit, Qualität zu erkennen. Architektur, Sicherheit, Wartbarkeit und fachliches Verständnis verschwinden nicht. Sie rücken stärker in den Mittelpunkt.

Die Rolle verschiebt sich damit vom reinen Umsetzen hin zum bewussten Steuern, Bewerten und Prüfen. Und genau deshalb greift auch die Vorstellung zu kurz, man müsse sich künftig zwischen «klassischer Entwicklung» und «KI-gestützter Entwicklung» entscheiden. Wer langfristig gute Software bauen will, braucht beides: technisches Fundament und den produktiven Umgang mit KI-Werkzeugen.

Vibe Coding ist weder Heilsversprechen noch Untergang der Softwareentwicklung. Es ist vor allem eines: eine neue Abstraktionsschicht.

Wie bei jeder Abstraktion entsteht ihr Wert nicht dadurch, dass man das Fundament ignoriert, sondern dadurch, dass man sich auf die richtigen Probleme konzentrieren kann.

Die entscheidende Frage ist deshalb nicht, ob wir solche Tools einsetzen werden, sondern wie bewusst wir es tun.