In Entwicklerkreisen kursiert derzeit ein Lehrstück über Erwartungsmanagement: Ein Entwickler hat mit KI-Unterstützung eine Nachbildung von Photoshop erstellt und daraus den Schluss gezogen, die klassische Softwareentwicklung sei damit am Ende. Der Entwickler und Kommentator Golo Roden widerspricht dieser Deutung deutlich. Sein Kernargument lässt sich auf eine einfache Formel bringen: Kopieren ist billig geworden, Entscheiden nicht.

Für Unternehmen, die gerade über Webportale, Produktkataloge oder interne Werkzeuge nachdenken, ist das mehr als eine Fachdebatte. Die Frage dahinter lautet: Was lässt sich künftig in Stunden erzeugen – und wofür braucht es weiterhin Planung, Verantwortung und Erfahrung?

Was hinter dem Begriff Vibe Coding steckt

Als Vibe Coding wird eine Arbeitsweise bezeichnet, bei der Software überwiegend durch natürlichsprachliche Anweisungen an ein KI-Modell entsteht. Statt Zeile für Zeile zu programmieren, beschreibt man das gewünschte Verhalten, prüft das Ergebnis und formuliert nach. Für Oberflächen, kleine Werkzeuge und Demonstrationen funktioniert das erstaunlich gut.

Genau darin liegt die Ursache für den aktuellen Hype. Eine Benutzeroberfläche, die wie ein bekanntes Programm aussieht, lässt sich heute vergleichsweise schnell erzeugen. Das wirkt spektakulär, weil das sichtbare Ergebnis nahe an etwas heranreicht, das über Jahrzehnte entstanden ist.

Warum Nachbauen die leichtere Hälfte ist

Ein Nachbau hat einen entscheidenden Vorteil gegenüber einer Neuentwicklung: Das Zielbild existiert bereits. Welche Funktionen es gibt, wie sie angeordnet sind, welche Arbeitsschritte Anwenderinnen und Anwender erwarten – all das ist vorgegeben und muss nicht mehr erarbeitet werden.

Bei echten Projekten fehlt dieses Zielbild. Dort beginnt die Arbeit mit Fragen, die kein Modell aus einem Prompt ableiten kann:

  • Welches Problem soll die Software tatsächlich lösen, und für wen?
  • Welche Fälle sind Standard, welche sind Ausnahme – und welche Ausnahmen darf man bewusst ignorieren?
  • Welche Daten sind führend, wo liegen sie, wer darf sie sehen?
  • Was passiert, wenn ein Teil des Systems ausfällt oder langsam antwortet?
  • Welche Entscheidung hält zehn Jahre, welche ist in sechs Monaten zu revidieren?

Diese Fragen sind keine Programmieraufgaben, sondern Produkt- und Architekturentscheidungen. Sie erfordern Kontext über das Unternehmen, über bestehende Systeme, über rechtliche Rahmenbedingungen und über die Menschen, die später damit arbeiten. Ein Sprachmodell kann dabei unterstützen, Varianten durchspielen und Formulierungen schärfen – die Verantwortung für die Wahl bleibt bei Menschen.

Die Demo und das Produkt sind zwei verschiedene Dinge

Zwischen einem Prototyp, der in einer Vorführung überzeugt, und einer Anwendung, die jahrelang im Betrieb steht, liegt der größere Teil der Arbeit. Ein Prototyp muss einen Weg funktionieren lassen. Ein Produkt muss mit unvollständigen Eingaben, parallelen Nutzern, wachsenden Datenmengen, Berechtigungen, Protokollierung, Sicherheitsanforderungen und späteren Änderungen umgehen.

Hinzu kommt die Wartbarkeit. Code, der schnell generiert wurde, ist nicht automatisch Code, den ein Team in zwei Jahren noch versteht und sicher verändern kann. Wo Struktur fehlt, steigen die Kosten jeder Anpassung – und Anpassungen sind in der Praxis der Normalfall, nicht die Ausnahme.

Wo prompt-getriebenes Arbeiten echten Wert schafft

Die Schlussfolgerung daraus ist ausdrücklich nicht, KI-gestützte Entwicklung zu meiden. Sie verschiebt lediglich, wo der Aufwand anfällt. Besonders tragfähig ist der Einsatz dort, wo schnelle Ergebnisse Unsicherheit reduzieren:

  • Konzeptklärung: Statt über Wireframes zu diskutieren, lässt sich eine klickbare Variante erzeugen und mit echten Nutzerinnen und Nutzern testen. Missverständnisse zeigen sich früh, solange Änderungen noch günstig sind.
  • Varianten vergleichen: Zwei oder drei Bedienkonzepte nebeneinander zu stellen, war früher teuer. Heute ist es eine realistische Option im Vorprojekt.
  • Interne Hilfswerkzeuge: Kleine Auswertungen, Importhilfen oder Checklisten mit überschaubarem Risiko und begrenzter Lebensdauer.
  • Routineanteile in der Umsetzung: Gerüstcode, Testfälle, Dokumentationsentwürfe, Übersetzungen zwischen Formaten – unter fachlicher Durchsicht.

Entscheidend ist die bewusste Einordnung: Ein Prototyp ist ein Erkenntnisinstrument. Wird er ohne Prüfung zum Produktivsystem erklärt, verlagert man Risiko in die Zukunft, statt es zu senken.

Die Fragen, die vor dem ersten Prompt stehen

Wer KI-gestützte Entwicklung in ein Projekt holt, sollte vorab klären, in welcher Rolle das Ergebnis auftritt. Hilfreich sind drei Festlegungen zu Beginn:

  1. Zweck: Dient das Ergebnis dem Lernen oder dem Betrieb? Davon hängen Qualitätsmaßstab und Prüftiefe ab.
  2. Verantwortung: Wer prüft den generierten Code fachlich und sicherheitsseitig, bevor er in ein System gelangt, das Kundendaten berührt?
  3. Weiterleben: Was passiert mit dem Prototyp nach der Entscheidung – wird er verworfen, überarbeitet oder als Spezifikation genutzt?

Diese drei Punkte kosten wenig Zeit und verhindern den häufigsten Fehler: dass aus einer überzeugenden Demo stillschweigend eine Produktzusage wird.

Einordnung für Web- und Softwareprojekte

Für Web- und Softwareprojekte verschiebt sich die Gewichtung, nicht die Grundlogik: Oberflächen und Durchstiche entstehen schneller, während Anforderungsklärung, Datenmodell, Schnittstellen und Betriebskonzept weiterhin den Ausschlag über Erfolg oder Folgekosten geben. Sinnvoll ist deshalb, die gewonnene Geschwindigkeit in die frühe Phase zu investieren – in belastbare Entscheidungen statt in mehr Code. Wer KI als Werkzeug im Entwicklungsprozess führt und die Verantwortung für Architektur und Produkt bei erfahrenen Menschen belässt, gewinnt Tempo, ohne die Wartbarkeit der nächsten Jahre zu verspielen.

Quellen