Google hat das sogenannte Vibe Coding für Android vereinfacht. Gemeint ist damit eine Arbeitsweise, bei der eine Anwendung nicht Zeile für Zeile programmiert, sondern in natürlicher Sprache beschrieben wird: Man formuliert einen Prompt, also eine Anweisung an ein KI-Modell, und erhält daraus eine lauffähige App. Neu ist laut der Meldung vor allem, dass dieser Weg kostenlos offensteht und die Apps nicht den Umweg über den Play Store nehmen müssen. Als Zugangsvoraussetzung reicht ein Google-Konto.

Das klingt nach einer kleinen Änderung, verschiebt aber eine Schwelle, die bislang viele interne Ideen ausgebremst hat. Wer bisher eine Android-App ausprobieren wollte, brauchte eine Entwicklungsumgebung, Build-Kenntnisse, Signaturzertifikate und in der Regel einen Veröffentlichungsprozess. Fällt dieser Unterbau für einfache Fälle weg, verkürzt sich der Abstand zwischen einer Idee im Meeting und etwas Ausprobierbarem auf dem Diensttelefon erheblich.

Wo der Nutzen im Mittelstand liegt

Interessant ist das Angebot weniger für Produkte, die ein Unternehmen verkauft, sondern für die vielen kleinen Anwendungsfälle dazwischen. Typisch sind Situationen, in denen heute eine Excel-Datei, ein Papierformular oder eine improvisierte Lösung im Einsatz ist, weil sich ein eigenes Projekt nicht gerechnet hätte.

  • Prototypen: Eine Bedienidee wird greifbar, bevor Budget für Design und Entwicklung freigegeben wird. Diskussionen über Abläufe werden konkreter, wenn alle auf denselben Bildschirm schauen.
  • Interne Werkzeuge: Kleine Helfer für Lager, Außendienst oder Serviceteams, die nur im Unternehmen laufen und keine öffentliche Zielgruppe haben.
  • Anforderungsklärung: Ein grob funktionierender Entwurf deckt Lücken in den Anforderungen schneller auf als ein Lastenheft.

Der wirtschaftliche Hebel liegt dabei nicht primär bei den gesparten Entwicklungsstunden. Er liegt darin, dass schlechte Ideen früher auffallen und gute Ideen schneller Unterstützung finden.

Was ein Prototyp nicht ist

Gleichzeitig lohnt ein nüchterner Blick auf die Grenzen. Eine per Prompt erzeugte App ist zunächst ein Entwurf. Sie beantwortet die Frage, ob eine Idee trägt, nicht die Frage, ob sie jahrelang betrieben werden kann.

Erfahrungsgemäß entscheiden bei internen Anwendungen nicht die Oberflächen über den Aufwand, sondern die Anbindung an bestehende Systeme: Stammdaten, Berechtigungen, Schnittstellen zu ERP oder CRM, Protokollierung. Genau diese Themen sind in einem schnellen Entwurf meist noch nicht gelöst. Wer das im Hinterkopf behält, nutzt Vibe Coding als Klärungswerkzeug und nicht als Abkürzung um die eigentliche Projektarbeit herum.

Hinzu kommt die Wartung. Code, der in wenigen Minuten entsteht, muss trotzdem von Menschen verstanden werden, wenn er sich ändern soll. Ohne Review bleibt offen, welche Bibliotheken enthalten sind, wie Fehler behandelt werden und ob Randfälle überhaupt abgedeckt sind.

Governance: Die Fragen stellen sich jetzt früher

Dass Apps den Play Store nicht mehr zwingend durchlaufen, ist für interne Zwecke praktisch, verschiebt aber eine Kontrollinstanz. Prüfungen, die bisher zumindest teilweise durch den Veröffentlichungsprozess abgedeckt waren, muss das Unternehmen selbst organisieren. Für IT-Verantwortliche ergeben sich daraus einige Punkte, die man besser vorab klärt als nach dem ersten Zwischenfall:

  1. Datenflüsse: Welche Daten gibt ein Mitarbeitender in den Prompt ein, welche Daten verarbeitet die fertige App? Personenbezogene oder vertrauliche Inhalte gehören nicht ungeprüft in ein Experiment.
  2. Verteilung: Wie gelangt eine App auf Dienstgeräte, wer darf sie installieren, und wie wird sie wieder entfernt? Mobile-Device-Management-Lösungen, also die zentrale Verwaltung von Firmengeräten, sollten eingebunden bleiben.
  3. Verantwortlichkeit: Wer betreut eine Anwendung, nachdem die Person, die sie erzeugt hat, die Abteilung wechselt?
  4. Übergang in den Regelbetrieb: Ab welchem Punkt wird aus dem Experiment ein Projekt mit Architektur, Tests und Dokumentation?

Sinnvoll ist eine ausdrückliche Erlaubnis mit klarem Rahmen: Experimentieren ist gewünscht, aber in definierten Grenzen. Ein pauschales Verbot führt in der Praxis meist nur dazu, dass die Versuche unsichtbar werden.

Ein pragmatisches Vorgehen

Für Unternehmen, die das Thema strukturiert angehen wollen, hat sich ein einfacher Dreischritt bewährt. Erstens: ein überschaubarer Anwendungsfall ohne sensible Daten, idealerweise aus einem Team, das den Schmerz täglich spürt. Zweitens: eine kurze Testphase mit wenigen Nutzerinnen und Nutzern und einer ehrlichen Auswertung, ob der Entwurf tatsächlich Zeit spart. Drittens: eine bewusste Entscheidung, ob die Lösung weggeworfen, so belassen oder sauber nachgebaut wird.

Der dritte Punkt wird häufig übersprungen. Dabei ist er der wichtigste, denn ungeplant verfestigte Provisorien verursachen später mehr Aufwand als ein von Beginn an geordnetes Projekt. Ein Prototyp darf explizit als Wegwerfprodukt geplant werden – das macht ihn wertvoll, nicht wertlos.

Einordnung

Für Web- und Softwareprojekte verschiebt sich damit vor allem der Startpunkt: Die ersten Gehversuche finden künftig öfter in den Fachabteilungen statt, nicht in der Entwicklung. Agenturen und interne IT werden stärker dort gebraucht, wo es um Integration, Datenschutz, Betrieb und langfristige Wartbarkeit geht – also genau in den Bereichen, die ein Prompt nicht mitliefert. Wer diese Arbeitsteilung bewusst gestaltet, gewinnt Tempo in der Ideenphase, ohne sich technische Altlasten einzuhandeln.

Quellen