Mit KI-Tools können heute alle eigene Softwarelösungen bauen. Was wie der Traum einer agilen Innovationskultur klingt, entwickelt sich oft zum unkontrollierten Wildwuchs. Das sogenannte Vibe-Coding verspricht schnelle Problemlösungen, umgeht dabei aber essenzielle Fragen. Warum «Make or Buy» eine Renaissance erlebt und Bauen nicht immer die beste Lösung für Ihr Unternehmen ist.
Symbolbild von Daniil Komov via Pexels
Das Gespräch, das sich plötzlich überall wiederholt
«Ach, das haben wir eigentlich schon selbst gebaut.» Oder: «Dann bauen wir das halt selbst, wenn euer Standardprodukt so teuer ist.» Oder noch häufiger intern: «Ich habe da etwas kreiert, das du dir unbedingt anschauen musst!»
Als Software-Verkäufer und Berater höre ich solche Sätze inzwischen regelmässig. Und ich sage es offen: Mich beschäftigt das. Nicht weil ich Angst vor der Konkurrenz habe, sondern weil ich weiss, was danach kommt – und ich die Möglichkeiten kennen und einschätzen will.
Vibe-Coding ist da. Es wird genutzt – von Entwicklerinnen, aber zunehmend auch von Mitarbeitenden aus nicht-technischen Abteilungen. Mit Hilfe von KI-Tools kann heute nahezu jede Person bauen, was sie für notwendig hält. Ein Problem, ein Bedarf, eine Herausforderung im Alltag – und zack, in wenigen Stunden steht ein Prototyp. Was bis vor Kurzem noch Wochen dauerte, ist heute eine Abendaktion. Das ist beeindruckend, wirklich beeindruckend.
Aber genau hier fängt die Geschichte erst an.
Ein Painkiller mit starken Nebenwirkungen
Das Vorgehen hat sich in Rekordzeit drastisch gewandelt: Hatte ich früher ein Problem im Business-Kontext oder einen spezifischen Bedarf, habe ich Google gefragt, ob es dafür eine passende Software-Lösung gibt. Seit ein, zwei Jahren frage ich in solchen Fällen eine KI. Und seit einigen Monaten hilft mir die KI sogar dabei, die Lösung einfach selbst zu vibe-coden!
Der Einstieg ist bestechend einfach, erste Resultate werden in rasantem Tempo erzeugt. Ein funktionierender Prototyp ist in vielen Fällen innerhalb weniger Stunden kreiert. Für den eigentlichen, ursprünglichen «Pain» (den Schmerzpunkt) ist also extrem schnell ein passender «Painkiller» geschaffen.
Doch dieses Schmerzmittel bringt – wie so oft im echten Leben – neben den positiven auch signifikante negative Nebenwirkungen mit sich. Auf der positiven Seite steht die schiere Begeisterung bei der erstellenden Person. Aber Achtung, hier lauert das sprichwörtliche «Rabbit-Hole»: Man verliert sich schnell im iterativen Prozess des Erschaffens. Auch die Begeisterung und Bewunderung im Team sind meist gross. Man ist tief beeindruckt, wie schnell und scheinbar mühelos etwas gelöst werden konnte.
Dem gegenüber stehen jedoch handfeste Herausforderungen. Im ersten Schritt ist die neu geschaffene Lösung meist nur lokal und isoliert verfügbar. Die IT-Abteilung reagiert auf solche Alleingänge verständlicherweise oft weniger enthusiastisch. Fragen nach Deployment, Stabilität, IT-Sicherheit und Nachvollziehbarkeit bleiben beim Vibe-Coding oftmals auf der Strecke. Zudem entsteht ein massiver Workload für die IT: Wenn plötzlich alle ihre eigenen kleinen Tools bauen, muss jemand diese Schatten-IT managen, warten und Support dafür leisten.
Auch der Fokus leidet. Ist es wirklich die Aufgabe der Mitarbeitenden, sich um die softwaretechnische Problemlösung direkt und eigenständig zu kümmern? Sollten sie sich nicht primär um das eigentliche Kerngeschäft sorgen? Nicht zuletzt droht ein gefährlicher Domino-Effekt: Das Team verfällt potenziell einem Wunschkonzert und will fortan jede kleinste Abweichung vom Standardprozess komplett individuell gelöst haben.
Bauen ist kein Muss
Jeff Chow, CPTO bei Miro, hat es Anfang Juni 2026 treffend auf den Punkt gebracht: «Just because we can build it doesn’t mean we have to.» Dieses Zitat ist in der Software-Branche bekannt – und es gewinnt gerade wieder an Aktualität und Relevanz. Denn plötzlich können eben nicht mehr nur Entwickler Software bauen, sondern alle. Umso wichtiger ist es, genau hinzuschauen, was davon wirklich einen Wert stiftet.
Die in der Branche altbekannte Frage kehrt zurück: Make or Buy? Und sie ist dringlicher denn je.
Mein Eindruck aus der Praxis ist, dass viele Unternehmen – oder genauer gesagt einzelne Mitarbeitende und Teams – heute direkt in den Bauprozess springen, ohne diese Frage auch nur gestellt zu haben. Die Motivation ist verständlich. Der Einstieg ist einfach. Die ersten Resultate sind schnell sichtbar. Aber ob das die richtige Entscheidung ist? Das wurde nicht bewertet.
Aus Sicht der Innovation ist Vibe-Coding ein echter Impulsgeber. Aber strategisch trägt es Risiken, die beim euphorischen Prototypen-Sprint gerne übersehen werden. Da ist zunächst der Fokus: Jede Stunde, die Mitarbeitende damit verbringen, ein eigenes Tool zu bauen und zu pflegen, ist eine Stunde weniger für das Kerngeschäft. Das klingt trivial – summiert sich aber schnell.
Dann ist da der Datenschutz: Welche Daten fliessen in welches KI-Tool? Wo werden die Daten gehostet? Wer hat das geprüft? Und schliesslich Stabilität und Verlässlichkeit: Ein Prototyp, der heute funktioniert, kann morgen stillstehen – und plötzlich hängt ein ganzer Prozess daran. Wer trägt die Verantwortung? Wer behebt das Problem? In den wenigsten Fällen ist das von Anfang an geklärt.
Ein Plädoyer für den bewussten Einsatz
Damit wir uns nicht falsch verstehen: Ich sage definitiv nicht, dass Vibe-Coding nicht genutzt werden soll. Ganz im Gegenteil, ich bin selbst grosser Fan und habe schon das eine oder andere Projekt dadurch schnell und pragmatisch lösen können. Aber ich sage mit Nachdruck: Jedes KMU benötigt dringend eine KI-Strategie – und nein, das muss keine 100-seitige Doktorarbeit sein! Eine pragmatische, klare Richtlinie reicht völlig aus. Und diese Strategie muss zwingend das Thema Vibe-Coding mit einschliessen.
Denn wenn Vibe-Coding in geregelten Bahnen abläuft, entfaltet es ein enormes Potenzial:
- Prozesse hinterfragen: Vibe-Coding ist grossartig, um die eigenen, festgefahrenen Arbeitsabläufe kritisch zu überdenken.
- Requirements Engineering: Es ist ein fantastisches Werkzeug, um Anforderungen greifbar zu machen.
- Visualisierung: Vibe-Coding ist top, um viel schneller und leichter visuelle Ergebnisse für Stakeholder zu kreieren.
- Prototyping: Es erlaubt das super effiziente Bauen von klickbaren Prototypen, um Hypothesen am Markt oder im Team schnell zu validieren.
Und ja, am Ende des Tages kann Vibe-Coding in manchen Fällen durchaus auch die Basis für die richtige Entscheidung sein, um aus einem erfolgreichen Prototypen ein echtes, vollumfängliches Produkt zu machen.
Strategie ist ein Muss
Die klassische Make-or-Buy-Frage muss dringend aufgefrischt und ins KI-Zeitalter übersetzt werden. Ein möglicher und praxistauglicher Weg für KMU kann folgendermassen aussehen:
- Mitarbeitende hören: Alle sollen und dürfen ihre «Pains» im Arbeitsalltag deklarieren und einbringen.
- Zentrale Bewertung: Jeder dieser Pains wird von einem definierten Team bewertet – sei dies eine Task-Force, ein Digitalisierungsgremium oder ein internes Innovation-Lab.
- Strategische Auswertung: Genau hier wird die Make-or-Buy-Frage systematisch gestellt und beantwortet.
- Transparenz: Der Output und der final gefällte Entscheid müssen nachvollziehbar und offen ins Unternehmen kommuniziert werden.
Vibe-Coding gibt uns unglaubliche Werkzeuge in die Hand. Nutzen wir sie nicht blindlings als schnelle Schmerzmittel, sondern als strategische Instrumente, um unser Business nachhaltig weiterzuentwickeln.
Pippi hatte recht – aber sie hatte auch eine Villa Kunterbunt
Pippi Langstrumpf lebte nach ihren eigenen Regeln. Und das war grossartig. Aber sie hatte eine Basis: Die Villa Kunterbunt. Stabil, verlässlich, ihr Zuhause.
Vibe-Coding ohne Strategie ist Pippi auf dem Dach – kreativ, mutig, beeindruckend. Und gefährlich.
Mit einer Basis darunter? Dann kann daraus echte Innovation entstehen.
Der Autor
Martin Winiker ist Mitgründer und Geschäftsführer der Teamhero Schweiz Gmbh
Der Beitrag erschien im topsoft Fachmagazin 26-2
Das Schweizer Fachmagazin für Digitales Business kostenlos abonnieren
Abonnieren Sie das topsoft Fachmagazin kostenlos. Regelmässig in Ihrem Briefkasten.