Auch wenn aktuell Leute davon schwärmen, mittels „Vibe Coding“ komplette Apps zu erstellen, indem sie sich einfach mit ihrer jeweiligen Lieblings-KI unterhalten, möchte ich auf ein paar Dinge hinweisen, die bei mehr oder weniger Allem, was einfache Code-Erzeugung verspricht zu beachten sind.

Das Thema ist keinesfalls so neu, wie so mancher aufgrund des aktuellen Hypes denken mag. Noch zu Zeiten von Terminals mit schwarzem Hintergrund und grüner Schrift, wurden „4GL“-Lösungen (Fourth Generation Language) angeboten, Oracle Forms, das heute als APEX in der Web-Variante weiterlebt, könnte man als App-Baukasten interpretieren. Dann kamen die Desktop-Varianten, die unter Unix und Windows liefen. dBase war weit verbreitet und Basis vieler kommerzieller Lösungen. MS-Access kam dann wesentlich grafischer und mit Maussteuerung daher. Auch Delphi und Konsorten wurden bekannt und geliebt. Irgendwann immer teurer und genauso irgendwann irrelevant.

Aktuell haben sich webbasierte Plattformen wie Airtable oder gerade Notion zu App-Buildern weiterentwickelt. Mit „drag and drop“ schiebt und klickt man sich eine Oberfläche zusammen. Die besseren Tools bieten auch das Abbilden von Prozessen (natürlich grafisch dargestellt).

Bei der Entwicklung drängt sich Copilot ins git-Repository und die üblichen One Trick Ponys zeigen, wie man sich von einer KI mit einem erstaunlich kurzen Prompt ein Snake-Game im Browser erstellen lässt. Die „Fortgeschrittenen“ zeigen, wie man durch Unterhaltung mit einer KI, (es braucht ja unbedingt ein Buzzword, also nennen wir es mal Vibe Coding) ebenfalls zu einem angeblich fertigen Stück Software gelangt.

Bolt,V0, Lovable versprechen den Entwicklern den Himmel auf Erden. Nie mehr DRY (don’t repeat yourself), langweilige Codestücke generiert irgendeine KI.

Soweit die schöne, alte und neue Marketingwelt der insbesondere amerikanischen Software-„Industrie“.

Auch ich probiere diese Tools immer mal wieder aus. Man darf deren Leistungsfähigkeit weder unter- noch überschätzen.

Ein paar Gefahren, die z.T. auch schon die alten Lösungen betroffen haben, muss man immer im Hinterkopf behalten, bevor man ein entsprechendes Tool einsetzt.

1. #politicaldebt

Der Aktualität geschuldet, dieser Punkt an erster Stelle. Die meisten Tool-Anbieter sind nun mal amerikanische Unternehmen. Und hier kann „Agent Orange“ jederzeit mal seine Tech-Bros anweisen, die Nutzung für europäische Anwender zu erschweren (Zölle, Themensperren, irre Forderungen) oder gar komplett zu verbieten. Zudem hat der Datenschutz Richtung USA erstaunlich wenig Substanz. Lediglich ein Dekret Bidens hat für eine auf wackligen Füßen stehende Einigung mit der EU gesorgt, die sicherstellte, dass europäische Unternehmen rechtssicher die amerikanischen Clouds nutzen konnten und ihre unantastbare, geliebte Microsoft-Monokultur beibehalten konnten. Das Ergebnis des Dekrets ist eine „Behörde“, die Widersprüche gegen den Datenschutz amerikanischer Unternehmen aus Europa bearbeiten sollte. Nicht nur, kann das gesamter Dekret von Trump mit einer Unterschrift annuliert werden. Die „Behörde“ besteht aktuell nur noch aus einer einzigen Person, die von Trump installiert wurde.

Jenseits solchen Geplänkels, untersteht jedes amerikanische Unternehmen und dessen Software und Rechenzentren, egal, wo diese auch immer stehen mögen, der amerikanischen Legislatur. Sprich: Trump hat Durchgriff auf alle Daten von allen Microsoft-, Google-, Amazon-, Meta- und [hier jedes beliebige amerikanische Unternehmen einfügen, das selbstverständlich seine DSGVO-Compliance vermarktet]-Nutzern.

2. KI-Code

Ja, die Tools werden scheinbar immer besser. Ich habe aber bisher noch Keines gesehen, das tiefergehende Zusammenhänge wirklich versteht (erwarte ich aktuell auch nicht). Die Tools können Snake-, Tetris- und Doom-Spiele erzeugen, weil sich daran schon sehr viele Entwickler probiert haben. Spätestens als Microsoft git übernommen hat, hatte OpenAI als Partner und milliardenschweres Invest von Microsoft Zugriff auf eine unendlich große Menge von Sourcecode als Trainingsmaterial. Es gibt auch genügend Webformulare online, um die KI ein „Verständnis“ solcher Formulare lernen zu lassen. Daher kann KI aus Zeichnungen von Formularen den zugehörigen Code erzeugen. Sobald es aber um komplexere Anforderungen geht versagt die KI nicht nur bei der Generierung von Code. Auch das Hinzufügen eines neuen Features, laut Vibe-Codern ja nur einen Prompt, der die Anforderung erklärt weit weg von der Realisierung, führt zum Entfernen anderer Funktionalitäten, Chaos im Code und völliger Missinterpretation des neuen Features. KI versteht einfach nicht, was sie da tut.

Gefährlich wird das, wenn man die „vibe gecodete“ Applikation in die freie Wildbahn lässt. Dann merkt man sehr schnell, wie böse die Welt da draußen ist und verliert im schlimmsten Fall vielleicht den Inhalt seines Bankkontos oder wird Teil eines schlimmeren Verbrechens.

Nebenher gelten hier die im Folgenden beschriebenen Gefahren von No- und Lowcode.

3. NoCode

Das ist die schlimmere Variante von LowCode weil man einfach nicht selbst irgend etwas außergewöhnliches oder benutzerfreundliches hinzuprogrammieren kann.

Man ist vollständig auf das Wohlwollen des Anbieters angewiesen. Man bindet sich an seine Plattform, kann nur die Bedienelemente verwenden, die er im Angebot hat (meine Schnelltests sind immer „eine funktionable Baumkomponente“, „Ein Datumsfeld, das die Datumseinstellung des vorherigen Datumsfeldes berücksichtigen kann“, „untereinander abhängige Selektboxen“ und „mindestens reguläre Ausdrücke für die Überprüfung von Eingaben“). Gibt diesem Anbieter seine Daten und setzt vielleicht sein gesamtes Geschäftsmodell auf diesen Anbieter. Da muss man sehr sorgfältig auswählen.

Auch hier gelten die nachfolgenden Nachteile.

4. LowCode

Ist in einem einzigen Punkt besser als NoCode-Plattformen: Man kann eigenen Code einbringen und somit eventuelle Schwächen des Anbieters ausgleichen.

Auch hier begibt man sich meist in die totale Abhängigkeit. Ich kenne keinen Anbieter, der Code erzeugt, den man dann selbst in Betrieb nehmen kann. Ausnahmen sind hier sogenannte CRUD-Generatoren, die auf Basis von Datenbanktabellen einfache Formulare für „Create“,“READ“,“UPDATE“ und „DELETE“, CRUD eben, erstellen. Die bieten oft eine Administrationsoberfläche für die Datenbankinhalte, sind aber von einer gut gestylten Applikation für Normalbenutzer weit entfernt.

5. App-Lawine

Ein großer Nachteil von schneller App-Entwicklung ist, dass man sehr schnell Apps entwickeln kann.

Es ist nahezu unausweichlich, dass jeder, der den Zugang zum Tool erhält, sobald er sich ein wenig eingearbeitet hat, genauso schnell eine App entwickelt, wie seine Kollegen mal eben ein neues Excel Sheet ins Leben rufen. Es entsteht ein unkontrollierter Wildwuchs von Apps mit überlappenden Funktionalitäten, Doppelentwicklungen, Suche nach der richtigen App für die konkrete Aufgabe. Der Vorteil der schnellen Entwicklung wird durch diese Probleme stark reduziert. Verursacht jede einzelne App Kosten, inklusive IT-Ressourcen und Helpdesk, steigen diese mit der Anzahl der Apps kontinuierlich an.

Die IT-Abteilung, die ein solches Tool anschafft, muss sehr genau einschätzen, wieviel Arbeit mit der selbstgeschaffenen „Shadow IT“ auf sie zukommen wird.

6. Citizen Developer

Die Anbieter preisen den sogenannten Citizen Developer. Also den Menschen aus der Fachabteilung, der nun in die Lage versetzt wird, seine eigenen IT-Anforderungen zu befriedigen.

Ich denke, dass es tatsächlich Millionen von z.B. Lotus Notes Anwendern gibt, die durch von solchen Citizen Developern entwickelten Lösungen teils jahrzehntelang gequält wurden. Es gehören eben nicht nur zufällig auf dem Bildschirm platzierte Formularfelder zu einer Applikation. Man muss den Benutzer zum gewünschten Ergebnis führen und ihm dabei die notwendigen Freiheiten lassen. Das hat dann weniger mit „coden“ zu tun, als mit Prozessverständnis und Erfahrung. Da war und ist so mansche Citizen Developer sehr schnell überfordert. Das die Plattform technische Details so kapselt, dass ihm selbst bei genügend Fachwissen unmöglich ist, z.B. eine übermäßige Belastung der Datenbank zu umgehen, macht die Sache nicht besser.

7. Security

Da man selbst nicht der Betreiber der Apps ist, die man da zusammengebaut hat, ist es sehr schwer, die Sicherheit der Apps einzuschätzen. Würde ich sensible Daten in diesen Apps speichern wollen, wäre sogar ein Penetration Test einer Test-App sinnvoll, bevor man sich auf den Anbieter verlässt. Da dieser aber (hoffentlich) seine Plattform immer weiter entwickelt, kann ein solcher Test natürlich nur ein Snapshot-Ergebnis liefern, das schon morgen seine Gültigkeit verloren hat.

Fazit

Beim Einsatz von KI/NoCode/LoCode Programmen ist äußerste Vorsicht geboten. Ein durchdachter Auswahlprozess und intensive Tests sind Pflicht.

Auswahlprozess, Gefahren, Kosten, Datensicherheit sprechen im Grunde gegen eine solche Lösung.

Vielleicht ist den Anwendern ja auch entgangen, dass es leistungsfähige Frameworks wie Laravel oder Django gibt, die schnell ähnliche Ergebnisse liefern, wie die CRUD Generatoren, aber keinerlei Einschränkungen unterliegen. Die hosted man auf einem eigenen Server oder bei einem günstigen deutschen oder europäischen Hoster (mit dem richtigen Know How und Setup sind Dienstleister, die für das „Deployment“, also die Bereitstellung der Software Lösungen bieten, schnell zu eliminieren). Hält die eigenen Sicherheitsmaßstäbe ein und ist völlig frei in der Entwicklung. Selbst eine vollständig selbstentwickelte Lösung kann sehr schnell brauchbare Ergebnisse liefern (ich habe das schon zwei mal in meinem Berufsleben realisiert).