Vor ein paar Jahren war eigene Software für die Personalabteilung ein Projekt. Lastenheft, Angebot, Agentur, Abstimmungsschleifen, irgendwann ein Go-live, danach ein Wartungsvertrag. Heute beschreibt jemand aus HR in drei Sätzen, was gebraucht wird, und eine KI baut daraus eine lauffähige App. Das nennt man Vibe Coding: Software entsteht aus einer Beschreibung in Alltagssprache, den Code schreibt die KI.
Wir halten das für eine der besten Nachrichten für Fachbereiche seit Langem. Und wir glauben, dass die meisten Unternehmen gerade an der falschen Stelle darüber diskutieren.
Wer den Ablauf kennt, sollte die Software bauen
Die Leiterin Lohn weiß, wann ein Vertrag nach der Probezeit endet und wann nicht. Der Leiter Einkauf weiß, ab welchem Betrag eine zweite Freigabe nötig ist. Bisher musste dieses Wissen durch mehrere Übersetzungen: vom Fachbereich ins Ticket, vom Ticket in die Spezifikation, von der Spezifikation in Code. Bei jeder Übersetzung ging etwas verloren.
Vibe Coding kürzt diese Kette. Wer den Ablauf kennt, beschreibt ihn selbst. Das ist kein Angriff auf die IT, sondern eine Entlastung: Sie muss nicht mehr jede Excel-Liste in ein Projekt verwandeln, das am Ende doch niemand so wollte.
Das eigentliche Problem ist nicht das Bauen
Die Diskussion dreht sich oft um die Frage, ob KI-generierter Code gut genug ist. Das ist die kleinere Frage. Die größere lautet: Wo läuft die App am Tag danach?
Eine App, die in einem KI-Tool entstanden ist, landet häufig auf einem privaten Account. Geteilt wird per Link. Wer was sehen darf, regelt niemand ausdrücklich. Tests gibt es nicht, und wenn die nächste Änderung etwas kaputt macht, gibt es keinen Weg zurück. Die IT erfährt davon, wenn überhaupt, zuletzt.
Nichts davon ist böser Wille. Es ist schlicht die Lücke zwischen „läuft auf meinem Bildschirm“ und „läuft im Unternehmen“. Früher war diese Lücke vom langen Entwicklungsweg verdeckt. Jetzt, wo Bauen schnell geht, liegt sie offen.
Was „im Unternehmen“ konkret bedeutet
Eine App, mit der ein Team arbeitet, braucht ein paar Dinge, die mit ihrem eigentlichen Zweck nichts zu tun haben:
- Anmeldung mit den Firmenkonten, damit niemand für jede App eigene Passwörter pflegt und wer geht, auch den Zugang verliert.
- Rechte pro Rolle, die bei jedem Zugriff gelten, nicht nur in der Oberfläche.
- Eine Prüfung vor dem Livegang, damit eine kleine Änderung nicht nebenbei Gehälter sichtbar macht.
- Versionen und einen Weg zurück, wenn sich etwas als falsch herausstellt.
- Klare Eigentumsverhältnisse: Code und Daten gehören dem Unternehmen, nicht einem Account.
Diese Dinge sind keine Kür. Sie sind der Unterschied zwischen einem Prototyp und einem Werkzeug, auf das sich ein Team verlässt. Und sie sind genau das, was eine einzelne Person mit einem KI-Tool nicht nebenbei mitbauen sollte.
Leitplanken statt Verbote
Viele Unternehmen reagieren auf die neuen Möglichkeiten mit Verboten oder mit Freigabeprozessen, die so lange dauern wie früher die Entwicklung. Beides führt zum selben Ergebnis: Die Leute bauen trotzdem, nur woanders.
Wir halten einen anderen Weg für richtig. Die Leitplanken gehören in die Umgebung, nicht in den Kopf jeder einzelnen Person. Wenn jede App automatisch mit Firmenanmeldung läuft, automatisch geprüft und automatisch versioniert wird, muss niemand daran denken. Und niemand kann es vergessen.
So ist Openbase.one gebaut. Ihr beschreibt in euren Worten, was die App können soll und wer was sehen darf. Ein Build-Agent baut sie, Openbase.one stellt euch nur die fachlichen Fragen, etwa: „Endet ein Vertrag automatisch mit der Probezeit?“ Jede Version wird gebaut und im echten Browser als jede Testperson geöffnet: als Führungskraft, die kein Gehalt sieht, als HR, die alle Gehälter sieht. Live geht sie erst, wenn die Prüfung bestanden ist.
Der App-Code läuft isoliert und ohne Netzwerkzugang, jeder Datenzugriff wird gegen Workspace, App und Rechte geprüft. Jede Version bleibt erhalten, die vorherige ist mit einem Klick wieder live. Und der Code jeder eigenen App liegt als Git-Repository in eurem Workspace.
Was Vibe Coding nicht ersetzt
Ehrlich gesagt: Eine Prüfung kann zeigen, dass die Führungskraft keine Gehälter sieht. Sie kann nicht entscheiden, ob eure Urlaubsregel fachlich stimmt. Das bleibt eure Entscheidung, und das ist richtig so. Niemand außer euch weiß, wie euer Betrieb funktioniert.
Was sich ändert, ist die Rolle der Fachbereiche. Sie werden nicht zu Entwicklern. Sie bleiben, was sie sind, nur dass ihr Wissen jetzt direkt zu Software wird. Sie müssen keine Datenbank verstehen, aber sie müssen ihre Regeln klar formulieren können. Wer schon einmal eine gute Prozessbeschreibung geschrieben hat, kann das.
Wer dabei Unterstützung möchte, bleibt nicht allein: Plattform-Support ist in jedem Tarif enthalten. Bei euren eigenen Apps helfen buchbare Support-Verträge, im Premium-Vertrag inklusive einer Prüfung neuer Apps vor dem Livegang.
Bauen dürfen, sicher betreiben
Vibe Coding im Unternehmen ist am Ende kein Technikthema. Es ist eine Frage der Erlaubnis. Dürfen die Menschen, die die Abläufe kennen, die Software dafür bauen? Wir finden: ja. Unter der Bedingung, dass das Ergebnis dort läuft, wo das Unternehmen es sehen, prüfen und zurücknehmen kann.
Nicht alles muss man selbst bauen. Fertige Apps kommen aus einem App Store, der ständig wächst: Ablage, Mail & Telefon, Meet, Bank, Lohn, Website und Wiki laufen heute schon. Installiert läuft die veröffentlichte, geprüfte Version, ohne Build und ohne KI-Kosten. Was fehlt, baut ihr selbst.
Kostenlos ausprobieren
Openbase.one kostet pro Workspace, nicht pro User, und jede App ist inklusive. Ihr startet mit 15 € KI-Guthaben und ohne Kreditkarte. Alle Tarife und Support-Verträge findet ihr auf der Preisseite.
Beschreibt eure erste App und seht, wie sie geprüft live geht.
Kostenlos starten