1. Der Code ist nicht mehr das Problem
Es gab eine Zeit, in der die Frage „können wir das selbst bauen?“ an der Fähigkeit hing, Code zu schreiben. Diese Zeit ist vorbei. Eine Coding-KI erzeugt heute in Minuten, wofür früher Tage nötig waren, und sie tut es in einer Qualität, die für viele interne Anwendungen ausreicht.
Was sie nicht tut: entscheiden. Fragen Sie eine Coding-KI, welche Datenbank sie nehmen soll, bekommen Sie eine plausible Antwort. Fragen Sie dieselbe KI in einem neuen Gespräch noch einmal, bekommen Sie möglicherweise eine andere, ebenfalls plausible Antwort. Beide sind für sich genommen vertretbar. Nur eine passt zu Ihrem Betrieb, und die KI weiß nicht, welche, weil sie Ihren Betrieb nicht kennt.
Das ist der Kern der Sache. Wer mit „Bau mir ein CRM“ beginnt, bekommt zügig etwas, das aussieht wie ein CRM. Ob es Daten dort speichert, wo sie liegen dürfen, ob die Benutzerrechte tatsächlich greifen und ob man das Ergebnis in einem Jahr noch erweitern kann, ist damit nicht beantwortet. Es ist nicht einmal gefragt worden. Wie schnell daraus ein Problem wird, ist beim Thema Sicherheitsrisiken beim Vibe Coding ausführlicher beschrieben.
2. Sieben Festlegungen vor der ersten Zeile
Die folgenden sieben Punkte sind die, die sich später am teuersten korrigieren lassen. Alle sieben kann ein Nicht-Entwickler entscheiden, sofern ihm jemand die Folgen erklärt.
| Festlegung | Die eigentliche Frage | Kosten einer späteren Änderung |
|---|---|---|
| Umfang der ersten Version | Was muss die Anwendung können, damit sie am ersten Tag nützlich ist? | gering, wenn früh geklärt |
| Datenmodell | Welche Dinge verwaltet die Software und wie hängen sie zusammen? | hoch, betrifft alles |
| Rollen und Rechte | Wer darf was sehen, ändern und löschen? | sehr hoch, nachträglich kaum sauber |
| Datenstandort | In welchem Land liegen die Daten und bei welchem Anbieter? | hoch, oft ein Umzug |
| Trennung Entwicklung und Produktivbetrieb | Wo wird ausprobiert, wo wird ernsthaft gearbeitet? | mittel, aber schmerzhaft |
| Versionsverwaltung | Wie kommt man zu einem funktionierenden Stand zurück? | gering, wenn von Anfang an da |
| Zugangsdaten und Schlüssel | Wo liegen Passwörter und Schlüssel, und wer kommt daran? | hoch, siehe jeden zweiten Vorfall |
Auffällig an der rechten Spalte: Die beiden Punkte, die sich später am schwersten korrigieren lassen, sind Datenmodell und Rechte. Genau diese beiden werden von einer Coding-KI ohne Vorgabe nebenbei miterfunden, weil sie zum Losbauen nötig sind. Sie werden also entschieden, nur eben nicht von Ihnen.
3. Entwicklung und Produktivbetrieb trennen
Die häufigste Aufstellung bei selbst gebauten Anwendungen ist auch die riskanteste: Es gibt genau ein System, und darauf wird entwickelt und gearbeitet. Das ist bequem, solange niemand Fehler macht, und genau dafür ist es nicht gebaut.
Zwei Umgebungen reichen für den Anfang. Eine, in der Sie ausprobieren, kaputt machen und wiederherstellen. Eine zweite, auf der die echten Daten liegen und auf der nur landet, was vorher funktioniert hat. Der Aufwand dafür ist bei modernen Diensten überschaubar, oft eine Stunde einmalig.
Warum das gerade bei KI-gestützter Entwicklung wichtiger ist als früher: Eine Coding-KI ändert auf Zuruf viel auf einmal. Das ist ihr Vorteil, und es ist der Grund, warum ein einzelner missverstandener Auftrag mehr Schaden anrichten kann als eine unbedachte Zeile von Hand. Ohne getrennte Umgebung und ohne Versionsverwaltung gibt es dann keinen Weg zurück.
Die eine Regel, die den größten Unterschied macht: Bevor Sie die Coding-KI beauftragen, muss der aktuelle Stand in der Versionsverwaltung gesichert sein. Damit ist jede Änderung, egal wie umfangreich, in einem Schritt rückgängig zu machen. Das ist der Unterschied zwischen einem ärgerlichen Nachmittag und einem verlorenen Projekt.
4. Testdaten statt echter Kundendaten
Während der Entwicklung liegt es nahe, mit echten Daten zu arbeiten. Man hat sie ja, und das Ergebnis wirkt realistischer. Es ist trotzdem die falsche Entscheidung, und zwar aus zwei Gründen gleichzeitig.
Der erste ist datenschutzrechtlich. Sobald echte Kundendaten in einem Entwicklungswerkzeug landen, das bei einem Anbieter im Ausland läuft, entsteht eine Verarbeitung, die begründet und vertraglich abgedeckt sein muss. Für ein Projekt, das noch gar nicht produktiv ist, ist das ein vermeidbarer Aufwand.
Der zweite ist praktisch. Echte Daten sind erstaunlich brav. Sie enthalten selten die Fälle, an denen Software scheitert: den Namen mit Apostroph, die Adresse ohne Hausnummer, den Betrag mit fünf Nachkommastellen, den doppelt angelegten Kunden. Wer sich Testdaten selbst ausdenkt oder von der KI erzeugen lässt, kann genau diese Fälle hineinschreiben und findet Fehler, die sonst erst der erste echte Kunde findet.
Der Aufwand ist gering: Eine Coding-KI erzeugt auf Zuruf hundert plausible Datensätze inklusive Sonderfällen. Die Anweisung dafür gehört zu den Dingen, die man einmal formuliert und dann im Projekt liegen lässt.
Damit hängt eine zweite Festlegung zusammen, die oft übersehen wird: Welche Daten dürfen überhaupt in das Entwicklungswerkzeug? Eine Coding-KI liest, was in Ihrem Projektordner liegt. Wenn dort eine Exceltabelle mit echten Kundenadressen zum Ausprobieren abgelegt wurde, ist sie Teil der Verarbeitung, ohne dass jemand das entschieden hätte. Die einfachste wirksame Regel lautet deshalb: Echte Daten liegen nicht im Projektordner, sondern nur auf dem Produktivsystem. Was nicht dort ist, kann auch nicht versehentlich mitgelesen oder mitgeliefert werden.
5. Woran Sie merken, dass aus dem Prototyp ein System wird
Selbst gebaute Anwendungen wachsen leise. Zuerst nutzt sie eine Person, dann die Abteilung, dann hängt ein Kunde daran. Irgendwo auf diesem Weg wird aus einem Werkzeug ein System, dem Menschen ihre Daten anvertrauen, und dieser Übergang wird selten bemerkt, weil es keinen Tag gibt, an dem er stattfindet.
Vier Anzeichen markieren ihn zuverlässig genug, um sie sich zu merken.
Echte Personendaten sind drin
Sobald Namen, Adressen, Verträge oder Gesundheitsdaten von echten Menschen verarbeitet werden, gelten die vollen Anforderungen. Das ist der eindeutigste Punkt, und er kommt meist früher als erwartet.
Jemand anderes arbeitet damit
Solange nur Sie die Anwendung benutzen, ist ein Fehler Ihr Problem. Sobald eine Kollegin damit arbeitet, braucht es Rollen, Rechte und die Frage, was passiert, wenn zwei Leute dasselbe gleichzeitig ändern.
Ein Ausfall würde stören
Der Moment, in dem Sie sich fragen, was passiert, wenn die Anwendung morgen nicht startet, ist der Moment für Sicherungen und einen erprobten Weg zurück. Eine Sicherung, die nie zurückgespielt wurde, ist keine.
Eine KI-Funktion soll hinein
Dass Sie die Software mit einer Coding-KI gebaut haben, macht sie nicht selbst zu einem KI-System. Sobald aber eine KI-Funktion in die Anwendung einzieht, etwa eine automatische Bewertung oder ein Chat, ist das neu zu beurteilen, auch im Hinblick auf den EU AI Act.
Fazit
Die Reihenfolge ist die ganze Botschaft: erst festlegen, dann bauen lassen. Sieben Entscheidungen, ein getrenntes Produktivsystem, Testdaten statt Kundendaten und eine Versionsverwaltung von Anfang an. Das ist überschaubar, und es ist der Unterschied zwischen einer Anwendung, die mitwächst, und einem Prototyp, den irgendwann niemand mehr anfassen will, weil keiner weiß, was er tut. Wer den Fahrplan dafür nicht allein zusammenstellen möchte, findet ihn im KI-Software-Start. Wer die Anwendung lieber bauen lässt, ist bei der Softwareentwicklung richtig, und wer eine KI-Funktion in eine bestehende Anwendung bringen will, bei der KI-Integration.