Das Wichtigste in Kürze
- Das Werkzeug ist selten das Problem: Mit KI lassen sich sehr sichere und sehr unsichere Anwendungen bauen, entscheidend ist, wer das Werkzeug bedient.
- KI macht andere Fehler: Auch menschliche Entwickler machen Fehler, KI ersetzt alte Fehlerquellen und bringt neue mit.
- Eine weitere Abstraktionsstufe: KI ist in der Programmierung der nächste Schritt nach Lochkarte, Assembler und Hochsprache und erhöht die Produktivität.
- Entwickeln ist mehr als Coden: Anforderungen, Architektur, Sicherheit und Dokumentation bleiben Aufgabe des Menschen, nur das Schreiben von Code übernimmt die KI.
- Security by Design von Anfang an: Wer der KI Frameworks wie die OWASP Top 10, DSGVO, NIS 2 oder den Cyber Resilience Act vorgibt, bekommt sichereren Code.
- Ein klarer Prozess schützt: Projekt zuerst in Claude Code aufsetzen, Lovable nur als Baustein nutzen, Code auf GitHub versionieren und auf einem gehärteten deutschen Server betreiben.
Einführung
Diese Woche ging eine Meldung sogar durch die allgemeine Presse: Programme, die mit Lovable gebaut wurden, seien ein Sicherheitsrisiko. Lovable ist ein Werkzeug aus Schweden. Sie schreiben einen Prompt wie „Baue mir ein CRM-System“, und das Werkzeug baut Ihnen eine lauffähige Anwendung. Klingt zu schön, um wahr zu sein? Genau darum geht es in dieser Episode.
Ich baue gerade selbst ein CRM-System für einen Kunden, unter anderem mit Lovable. An diesem Beispiel zeige ich Ihnen, dass KI wie jedes Werkzeug funktioniert: Sie können damit sehr sichere Lösungen bauen oder sehr unsichere. Die Maschine ist dabei selten das eigentliche Problem. Das Problem ist meistens der Mensch, der sie ohne Plan bedient.
Diesmal melde ich mich übrigens aus dem Hotelzimmer, mit meinem mobilen Studio. Das Thema war mir zu wichtig, um eine Woche zu warten.
Die Lovable-Meldung zeigt ein altes Muster
Die Schlagzeile lautet sinngemäß: KI baut unsichere Software. Das erinnert mich an eine alte Diskussion. Jahrelang hieß es, iOS sei immer sicher und Android immer unsicher. Beides stimmt so nicht.
Auch ein iPhone lässt sich kompromittieren. Inzwischen können Sie bei Apple sogar Apps aus fremden App-Stores installieren. Umgekehrt können Sie Android-Geräte mit einem Mobile-Device-Management sauber im Unternehmen absichern.
Genauso ist es mit KI in der Softwareentwicklung. Wenn Sie wissen, was Sie tun, entwickeln Sie mit KI-Unterstützung sichere Software. Wenn nicht, wird es gefährlich, mit oder ohne KI.
Auch Menschen machen Fehler, nur andere
Im Doppelgänger-Podcast kam dazu ein kluger Gedanke: Wenn wir sagen, KI mache bei der Softwareentwicklung Fehler, gerade im Sicherheitsbereich, dann tun wir oft so, als würden menschliche Entwickler keine Fehler machen. Das ist natürlich nicht so.
Der Vergleich mit selbstfahrenden Autos macht das greifbar. Kein Mensch würde gegen einen weißen Lastwagen fahren, wie es ein Tesla getan hat. Ein befreundeter Kollege erlebte im Urlaub, wie ein selbst einparkendes Auto sein Motorrad von hinten anschob, weil die Sensorik es nicht erkannte. Er rettete sich mit einem Sprung zur Seite.
Andererseits schaut ein Mensch kurz aufs Handy und fährt einem Motorradfahrer auf. Das passiert einem selbstfahrenden Auto in der Regel nicht. Die Lehre: Maschinen und Menschen machen unterschiedliche Fehler. Die Frage ist nicht, ob Fehler passieren, sondern wie Sie sie auffangen.
KI ist die nächste Abstraktionsstufe der Programmierung
In der Programmierung ist KI nichts anderes als eine weitere Abstraktionsstufe. Als Kind durfte ich am Samstag mit meinem Vater in die Firma und auf Lochkarten malen. Die waren sehr nah an der Hardware. Als Assembler und später Compiler kamen, sagten viele Programmierer: Ich weiß gar nicht mehr, was die Kiste macht, und in den Compilern stecken Fehler.
Jede neue Stufe brachte neue Fehler mit, aber auch automatische Korrekturen. Eine fehlende Klammer oder einen Syntaxfehler fangen moderne Werkzeuge längst selbst ab. Früher haben Entwickler danach stundenlang gesucht.
Mit KI ist es genauso. Es kommen neue Fehlerquellen hinzu, alte fallen weg. Unterm Strich steigt die Produktivität deutlich.
Software entwickeln ist mehr als Code schreiben
Was ersetzt KI in der Softwareentwicklung eigentlich? Im Kern das Schreiben von Code und ein Stück weit das Überprüfen und Überarbeiten, also das Refactoring. Mehr nicht.
Sind Programmierer damit überflüssig? Nur, wenn sie sich als Menschen verstehen, die Codezeilen schreiben. Wer Software entwickelt, macht sich zuerst Gedanken über die Anforderungen. Für das CRM-Projekt meines Kunden haben wir mehrere Workshops mit dem Vertrieb gemacht, Anforderungen gesammelt und daraus ein Lastenheft und ein Pflichtenheft entwickelt.
Danach gehört alles in ein Architekturdokument: Mit welcher Architektur bauen wir das? Und von Anfang an muss die Sicherheit mitgedacht werden, nicht erst kurz vor dem Start.
Security by Design: Geben Sie der KI die Regeln vor
Das Gute ist: Für Sicherheit gibt es inzwischen bewährte Frameworks, und die können Sie einer KI direkt mitgeben. Ich setze ein Projekt deshalb nie nur in Lovable auf. Bevor ich dort anfange, richte ich das Projekt in Claude Code ein. Dafür habe ich eine Standardroutine.
Der erste Grundsatz heißt Security by Design. Ich gebe zum Beispiel vor: Berücksichtige immer die OWASP Top 10 2025. Die OWASP ist eine gemeinnützige Open-Source-Organisation. Sie analysiert die häufigsten Schwachstellen von Webanwendungen und beschreibt, wie man sie behebt.
Ein konkretes Beispiel: Ein Programm mit Anmeldung braucht eine Sperre nach mehreren Fehlversuchen. Sonst kann ein Angreifer per Brute-Force- oder Wörterbuch-Angriff alle Passwortvarianten durchprobieren, auch die bekannten Kennwörter, die im Darknet gehandelt werden. Wer das weiß, baut die Sperre ein. Genauso lassen sich DSGVO, NIS 2, DORA und der Cyber Resilience Act von vornherein vorgeben.
Der zweite Grundsatz ist eine saubere Dokumentation aller Schritte. Ich kenne wenige Programmierer, die Dokumentation lieben. Dabei ist eine gute Dokumentation wie ein Liebesbrief an den nächsten Entwickler. Und sie hilft, den Code zu prüfen. Unter diesen Voraussetzungen lässt sich mit KI sicherer Code bauen.
Unreflektierte Nutzung erzeugt AI-Slop
Das eigentliche Problem kenne ich aus vielen Gesprächen. Ich frage: Nutzen Sie schon KI? Die Antwort: Ja, ganz viel. Und wofür? Ich google damit. Das ist ungefähr so, als würden Sie mit dem Griff eines Schraubenziehers einen Nagel in die Wand schlagen.
Ein Large Language Model kann große Texte klein machen, kleine Texte groß machen und Texte vergleichen. Dafür ist es gebaut, nicht als Suchmaschine. Wenn schlechte Fragen hineingehen und die Ergebnisse ungeprüft weiterverwendet werden, entsteht der berühmte AI-Slop.
Ein Beispiel aus dem Alltag: Einer schreibt mit KI eine E-Mail über fünf Seiten, der Empfänger lässt sie von der KI wieder zusammenfassen. Intelligent genutzt ist das nicht.
Bewährte Prinzipien der Softwareentwicklung gelten weiter
Wenn ich Unternehmen bei eigenen Lösungen wie einem CRM-System unterstütze, binde ich die IT-Abteilung ein. Wir arbeiten mit klassischen Prinzipien der Softwareentwicklung. Ein Framework, das ich stark nutze, ist die BMAD-Methode. Dort übernehmen KI-Agenten feste Rollen: Anforderungen klären, ein Product Requirements Document schreiben, die Architektur entwerfen, die Benutzeroberfläche gestalten.
Gerade die Gestaltung wird oft unterschätzt. Am Wochenende zeigte mir meine Frau eine App aus dem App Store. Man sah sofort: Das ist das Standarddesign der KI. Nicht schlecht, aber ohne eigenes Gesicht. Nicht umsonst gibt es Grafiker, die ein Auge dafür haben.
Das sehe ich auch bei meinem digitalen Zeitplanbuch für das iPad, das ich gerade neu belebt habe. Die ursprüngliche Version entstand mit einem professionellen Designer. Wenn ein Designer der KI den Input liefert, kommt ein ganz anderes Ergebnis heraus. Fachwissen plus KI, erst dann passt es.
A fool with AI makes the disaster faster
Ein alter Spruch lautet: A fool with a tool is still a fool. In Zeiten von KI sage ich: A fool with AI makes the disaster faster. Wer Lovable jemandem gibt, der nie programmiert und sich nie mit IT-Sicherheit beschäftigt hat, riskiert ernsthafte Schäden. Lovable hat zwar eigene Sicherheitsprüfungen, und die werden besser. Ein Ersatz für einen sauberen Prozess sind sie nicht.
Mein Vorgehen sieht so aus: Ich baue das Framework zuerst in Claude Code auf. Claude erzeugt dann die Prompts für Lovable, und ich prüfe das Ergebnis. Der Code wird auf GitHub versioniert, einer Plattform, die zu Microsoft gehört. Ein Vorteil von Lovable: kein Lock-in, Sie kommen jederzeit an Ihren Code.
Produktiv läuft bei mir nichts auf Lovable selbst. Die Anwendung kommt auf einen gehärteten Linux-Server bei Hetzner in Deutschland. Test- und Produktivumgebung sind sauber getrennt. Und vor jedem neuen Release gibt es eine umfassende Sicherheitsprüfung.
So gemacht, bekommen Sie mit KI heute sogar sicherere Software als von Hand. Ich bin überzeugt: In zwei, drei Jahren schreibt kaum noch jemand eine Zeile Code selbst, so wie heute niemand mehr mit Lochkarten arbeitet. Das heißt aber nicht, dass Sie die Prinzipien guten Sicherheitsdesigns über Bord werfen. Ganz im Gegenteil.
Fazit
Software mit KI ist nicht automatisch unsicher. Unsicher wird sie, wenn niemand Anforderungen, Architektur und Sicherheit durchdenkt. Geben Sie der KI von Anfang an Regeln wie die OWASP Top 10 vor, dokumentieren Sie jeden Schritt, trennen Sie Test und Produktion und prüfen Sie vor jedem Release.
Für mittelständische Unternehmen mit etwa 20 bis 400 Mitarbeitenden halte ich ein eigenes, mit KI gebautes CRM-System für eine sehr gute Option. Seit meinem ersten C64 vor 44 Jahren beschäftige ich mich mit Programmierung und habe in vielen Unternehmen CRM-Systeme eingeführt. Wenn Sie dabei Unterstützung wünschen, sprechen Sie mich gern an, wir arbeiten zu Festpreisen.
Erwähnte Tools & Ressourcen
- Lovable: KI-Werkzeug aus Schweden, das aus Prompts lauffähige Webanwendungen baut, mit Zugriff auf den eigenen Code.
- Claude Code: KI-Entwicklungsumgebung von Anthropic, in der Thorsten Jekel Projekte, Regeln und Prompts für Lovable aufsetzt.
- OWASP Top 10: Liste der häufigsten Sicherheitslücken in Webanwendungen der gemeinnützigen OWASP, als Vorgabe für die KI nutzbar.
- BMAD-Methode: Framework für KI-gestützte Softwareentwicklung mit Agenten für Anforderungen, Produktdokument, Architektur und Benutzeroberfläche.
- GitHub: Plattform von Microsoft zur Versionierung von Code.
- Hetzner: Deutscher Hosting-Anbieter, bei dem die Anwendungen auf gehärteten Linux-Servern betrieben werden.
Häufige Fragen (FAQ)
Ist Software, die mit Lovable gebaut wurde, unsicher?
Nicht grundsätzlich. Lovable kann sichere wie unsichere Anwendungen erzeugen. Entscheidend ist, ob Anforderungen, Architektur und Sicherheitsregeln vorher festgelegt und die Ergebnisse geprüft werden.
Machen KI-Programmierwerkzeuge mehr Fehler als menschliche Entwickler?
Sie machen vor allem andere Fehler. Auch menschliche Entwickler übersehen Sicherheitslücken. KI fängt manche alten Fehler wie Syntaxfehler zuverlässig ab und bringt dafür neue Fehlerquellen mit, die ein guter Prozess auffangen muss.
Wie sorge ich dafür, dass KI sicheren Code schreibt?
Geben Sie der KI von Anfang an Security by Design vor, etwa die OWASP Top 10 2025 sowie DSGVO, NIS 2, DORA oder den Cyber Resilience Act. Lassen Sie jeden Schritt dokumentieren, trennen Sie Test- und Produktivumgebung und führen Sie vor jedem Release eine Sicherheitsprüfung durch.
Was sind die OWASP Top 10?
Die OWASP Top 10 sind eine Liste der häufigsten Sicherheitsrisiken für Webanwendungen. Herausgeber ist die gemeinnützige Open-Source-Organisation OWASP. Die Liste beschreibt auch, wie sich die Schwachstellen vermeiden lassen, etwa durch eine Sperre nach mehreren fehlgeschlagenen Anmeldeversuchen.
Werden Programmierer durch KI überflüssig?
Nur wer sich als reiner Codeschreiber versteht. KI ersetzt vor allem das Schreiben und Überarbeiten von Code. Anforderungen erheben, Architektur entwerfen, Sicherheit planen und Ergebnisse prüfen bleiben Aufgaben von Menschen.
Lohnt sich ein eigenes, mit KI gebautes CRM-System für den Mittelstand?
Für Unternehmen mit etwa 20 bis 400 Mitarbeitenden kann das eine sehr gute Option sein. Voraussetzung ist ein sauberer Prozess mit Workshops zu den Anforderungen, Lasten- und Pflichtenheft, Architekturdokument und Sicherheitsprüfung.
