Die KI-generierte TL;DR Version des Posts:
Drei Wochen und ein erstes größeres Produkt mit KI-Unterstützung sind vergangen – und nun wirkt Eigenentwicklung wieder erstaunlich modern. Aus einem Experiment wurde in wenigen Tagen eine ernstzunehmende Anwendung, nicht zufällig zusammengesetzt, sondern aus vertrauten Bausteinen, neuen Tools und einer Entwicklungsgeschwindigkeit, die vor kurzem noch kaum vorstellbar war.
Doch auf die erste Euphorie folgten die Momente, in denen die Schattenseite sichtbar wurde: schmerzhafte Programmierfehler, halber Datenverlust, kompletter Datenverlust und Sicherheitsrisiken, die nicht von selbst verschwinden, nur weil KI im Spiel ist.
Gerade darin liegt die eigentliche Erkenntnis dieses Projekts: Nicht die KI allein entscheidet darüber, ob mehr Eigenentwicklung möglich wird, sondern das Umfeld, in dem sie eingesetzt wird. Wer mit KI schnell bauen will, braucht starke Leitplanken bei Daten, Code, Deployment und Sicherheit. Genau deshalb ist dieser Text mehr als ein Erfahrungsbericht aus zehn Tagen Antigravity – er ist der Versuch, die Bedingungen für ein neues Zeitalter der Eigenentwicklung zu beschreiben.
Das Fazit vorweg: Ja, KI kann Eigenentwicklung in Organisationen massiv zurückbringen – aber nur dort, wo die technische Infrastruktur robust genug ist, ihre Fehler auszuhalten.
Seit dem vorherigen Blogpost, in dem es um meine ersten Schritte mit KI-unterstützer Softwareentwicklung ging, sind 3 Wochen vergangen. In dieser Zeit habe ich ein erstes größeres Projekt mit Google Antigravity vorangetrieben. Und damit möchte ich die Überlegungen am Ende des letzten Posts – ‚Kommt die Zeit der Eigenentwicklungen zurück?‘ – fortführen:
10 Tage Arbeit in Antigravity
Was für ein Produkt in dieser Zeit entstanden? Dabei muss man berücksichtigen, dass ich bei weitem nicht in Vollzeit an dem gearbeitet habe, was inzwischen vom Stadium eines umfangreicheren Versuchs auf dem Weg zu einem konkreten Produkt ist. Hier ein Teil des Handbuchs zur Software, welches ich ebenfalls mit Antigravity erstellt und aktuell gehalten habe:
X ist eine Anwendung zur systematischen Evaluation und Qualitätssicherung von KI-Prompts. Sie ermöglicht es, Prompts mit verschiedenen Testdaten und Sprachmodellen zu vergleichen, Versionen zu verwalten und Ergebnisse in strukturierten Testläufen zu analysieren.
Die Anwendung ist hierarchisch strukturiert. Ein Projekt bildet die Klammer um alle weiteren Elemente.
Struktur Beschreibung Zusammenhang Projekt Oberster Container für eine spezifische Aufgabe oder ein Thema. Enthält Prompts, Testdaten und Testsets. Prompt Die Anweisung an die KI. Unterstützt Versionierung, Platzhalter und Markdown. Wird in Testsets verwendet; Änderungen am Inhalt erzeugen neue Versionen. Testdaten Variable Eingabewerte, die über {{testdaten}}in Prompts eingefügt werden.Werden in Testsets mit Prompts kombiniert. Testset Eine Konfiguration, die festlegt, welche Prompts mit welchen Testdaten und welchen Modellen getestet werden sollen. Bildet die Vorlage für automatisierte Testläufe. Testlauf Die tatsächliche Ausführung eines Testsets. Speichert Ergebnisse, Token-Verbrauch, Dauer und Antworten dauerhaft.
….und so weiter. Es ist also keine ganz simple Anwendung mehr, wie man auch an den eingesetzen Technologien sieht:
Tech Stack
Bei der Implementierung ist Antigravity – dabei wurden im Wechsel Gemini und Claude Modelle eingesetzt – meinen Vorgaben gefolgt, wobei ich mich an einigen Stellen mit der KI beraten habe, welche Optionen es gibt und dann eine Entscheidung getroffen habe. Es ist dabei ein Mix von Technologien, die ich schon gut bis sehr gut kenne, und einem Teil, der für mich neu war, aber schon länger auf meiner Liste der Dinge stand, die ich ausprobieren will:
- Grundlage: Java Webanwendung, konkret Spring Boot
- Es sollte Java sein, da ich mich damit am besten auskenne. Es ist dann doch nur Java 21 geworden, es gibt immer noch Dinge, die nicht gut mit den neuesten Java Versionen funktionieren
- Spring Boot, da es sich schnell an den Start bringen lässt und ich die Vorstellung habe, dass ich den Code mit vergleichsweise geringem Aufwand später auch als WAR in einem Tomcat Server bringen kann
- Maven als Build System
- Oberflächen mit Thymeleaf und HTMX
- Die Weboberfläche soll ein modernes Feeling haben, also möglichst wenige Pagereloads zeigen
- HTMX stand schon lange auf meiner Liste der interessante Technologien, da es ‚einfach‘ von Server gelieferte HTML-Schnipsel an den gewünschten Stellen einer Webseite aktualisiert. Also keine API auf Serverseite braucht, die JSON oder so liefert, welches dann im Client wieder in HTML umgewandelt wird
- Thymeleaf für das Interface zu verwenden war ein Vorschlag der KI, ich hatte es bisher nur für die Generierung von PDFs per Template verwendet. Thymeleaf hat im Zusammenspiel mit HTMX die interessante Option der Fragmente: Bei der Requestbearbeitung im Spring Controler kann am Ende signalisiert werden, welcher Teil einer Templatedatei ausgeliefert werden soll. Dadurch lassen sich die vielen kleinen HTML Schnipsel, die die Nutzung von HTMX mit sich bringt, trotzdem in einer Datei konzentrieren. So wie es inhaltlich sinnvoll ist
- Daten in einer PostgreSQL Datenbank
- Idee dabei: Ich kann direkt sehen, wie sich die Anwendung auf Datenbankebene verhält und es gibt einen Migrationspfad, falls ein Betrieb mit zentral gemanagter Datenbank folgt
- Schemaerstellung mit Flyway. Das hatte ich vorher noch nicht eingesetzt und es ergänzt die schnelle Entwicklung mit KI gut
- LLM Zugriff mit Langchain4j
- Das setzen wir in BIKI ein und auch in anderen KI Experimenten habe ich damit gearbeitet
- Docling für Dateikonvertierungen in Markdown
- Dieses leistungsfähige Werkzeug setzen wir ebenfalls in BIKI ein, es kann viele Dokumentenformate verarbeiten und wie ich dann gelernt habe Webseiten direkt abrufen und konvertieren (siehe aber den SSRF Punkt unten)
- Betrieb als Gruppe von Containern
- Die Anwendung soll zunächst lokal auf PCs laufen, aber zugleich einer potentiellen Serverinstallation nahe kommen
- Daher ist sie als Gespann von nun 4 Containern (Java Anwendung, PostgreSQL DB, pgAdmin für den Blick in die DB, Docling) implementiert
- In einer produktiven Umgebung würden die Datenbank und Docling als externe Services angesprochen, in der Java Anwendungen müssten dann nur die Adressen der Endpunkte angepasst werden
Erfahrungen
Nach den ersten unglaublich schnellen Fortschritten mit der Entwicklung und der entsprechenden Begeisterung haben sich dann ein paar Lerneffekte eingestellt, darunter auch das persönliche Erleben einiger der oft kursierenden Fails bei agentischer Softwareentwicklung:
Manches geht doch schneller ohne KI
Beim nächsten Projekt mit Spring (Boot) würde ich das Grundprojekt mit Spring Initializr anlegen, und nicht teure Tokens verbrauchen und darauf warten, dass die KI selbst das gleiche tut. Wenn man solche Projekte in Serie angeht und dabei immer ähnliche Technologien verwenden möchte, dann macht es vermutlich Sinn ein Template anzulegen, von dem aus man startet.
Vieles geht mit KI so leicht
Mal eben einen WYSIWYG Markdown Editor in mehreren Webformularen ergänzen und sich vorher verschiedene Alternativen darstellen lassen? Ein Formular ergänzen, über das sich entweder eine URL oder eine Datei direkt an Docling schicken und das Ergebnis in einen neuen Testdatensatz speichern lässt? Kopierfunktionen für komplette Datensätze an allem möglichen Stellen ergänzen? Einen JSON Ex- und Import für den kompletten Datenbankinhalt – oder auch nur Teile – bauen? Eine Fortschrittsanzeige erstellen, die den komplexen Status eines nebenläufigen Threads darstellt? Das geht so leicht, dass ich auch Dinge von der KI habe einbauen lassen, die ich sonst vermutlich unter ‚wenn mal Zeit und Langeweile ist‘ abgelegt hätte.
Das geht natürlich nur, weil es ein riesiges Open Source Ökosystem gibt, auf dem die KIs zum einen trainiert werden können, und aus dem sich zum anderen Bausteine für komplexe Funktionen einfach beziehen lassen.
Halber Datenverlust durch Programmierungsfehler
Ein schwerer Fehler in der Programmierung sorgte dafür, dass bei der Bearbeitung eines Projekttitels fast alle zum Projekt gehörenden Datensätze gelöscht wurden. Mir war der Fehler beim Code Review nicht aufgefallen, vermutlich weil mein Wissen über Spring und JPA nicht gereicht hat. Erst bei späteren Nutzungen der Anwendung fiel das Problem auf.
Auf Rückfrage hat die KI den Fehler direkt erkannt und korrigiert, aber keines der Modelle hat bei der Erweiterung der Anwendung in den zahlreichen Überarbeitungsschritten von selbst darauf hingewiesen.
Tolle Lösung gegen Datenverlust, verbunden mit totalem Datenverlust
Bei dem Versuch sich gegen solche Datenverluste zu schützen schlug die KI eine für meinen Geschmack elegante Lösung vor, bei der über Trigger in der Datenbank jede Datensatzänderung in eine Audit-Tabelle geschrieben wird. Postgres hat hier ein paar sehr hilfreiche JSON-Befehle. Und die KI brachte mich auf die Idee, dass man über zwei unterschiedliche DB Benutzer – einen für die Schemaänderungen durch Flyway und einen anderen für die Java App, der stark eingeschränkte Rechte hat – noch einmal mehr Sicherheit erreichen kann. Aber nachdem das umgesetzt war, waren ALLE Daten in meiner Testdatenbank weg. Was war passiert?
Um die beiden DB Benutzer anzulegen hat die KI also ein Initscript für den PG Container angelegt. Eine gute Lösung, aber da das nur bei einer leeren Datenbank funktioniert hat sie einmal das Docker Volume mit den DB Inhalten entfernt. Da ich schon lange nicht mehr jedes Kommando der KI einzeln genehmige ist das so durchgerutscht. Ob man ‚der KI‘ jetzt glauben kann, dass so etwas in Zukunft nicht mehr passiert, würde ich dabei bezweifeln.
Manchmal ist es Co-Debugging
Der Versuch der Anbindung des Docling Containers scheiterte lange, die KI hatte auf entsprechende Hinweise mehrere Lösungsansätze und war sich dann immer sicher ‚jetzt funktioniert es‘. Am Ende war es eine Art Co-Debugging: Der Hinweis von mir, dass ein Zugriff mit einem bestimmten curl-Aufruf funktioniert, brachte die KI darauf, dass es an der HTTP Version liegt: Der Java Aufruf verwendete HTTP 2.0, aber der Webserver in Docling kann nur HTTP 1.1. Insgesamt hat die ‚einfache‘ Anbindung der Docling API sehr viel Zeit gekostet.
Don’t repeat yourself – außer, wenn es die KI macht
Ich bin eigentlich ein großer Anhänger des DRY-Prinzips, und betreibe in der ‚manuellen‘ Programmierung lieber etwas Aufwand im Refactoring, um mehrfach vorhandenen Code auf eine gemeinsame Basis zu stellen. Bei komplexer Geschäftslogik ist das zur Qualitätssicherung nach meiner Einschätzung weiterhin die einzig sinnvolle und verlässliche Vorgehensweise. Aber an vielen anderen Stellen wackelt da meine Meinung: Wenn die KI für mich 10 Stellen im Code in Sekunden anpassen kann, muss ich dann noch Zeit und ggf. Komplexität investieren in den Versuch, alles auf eine Stelle zu fokussieren? Ich glaube in vielen Fällen wird das nicht mehr sinnvoll bzw. notwendig sein.
KIs haben Charaktere
Ich habe in Antigravity sowohl die Gemini Modelle von Google wie auch die Claude Modelle von Anthropic verwendet. Und vom Gefühl her sind das unterschiedliche ‚Personen‘ mit verschiedenen ‚Charakteren‘. Gemini kommt mir etwas abwägender, oder auch zögerlicher vor, während Claude pushier wirkt und voran ‚will‘. Beispiel: Ich wollte von Claude an einer Stelle eigentlich nur, dass das Datenmodell um eine neue Entität erweitert wird. Aber Claude hat auch gleich das Interface gebaut, was es eigentlich nicht tun sollte.
Doku erstellen und aktualisieren im gleichen Werkzeug
Das oben zitierte Handbuch war eigentlich erst nur eine Fingerübung nach einer Diskussion mit Kollegen. Und es hat nur ein kurzes Prompt erfordert um es in sehr brauchbarer Form zu bekommen. Aber nun lasse ich es die KI aktuell halten und trage selbst kleinere Punkte nach. Es macht einfach so wenig Arbeit.
KI kann Sicherheit – aber erst auf Nachfrage
Ich habe die KI die Sicherheit der Anwendung prüfen lassen und dabei verlangt, dass auf Basis der OWASP Hinweise vorgegangen wird. Abgesehen von dem noch fehlenden Loginschutz ist dann auch etwas wichtiges gefunden worden: Bei der Implementierung der Dokumentenkonvertierung per Docling war ein Code entstanden, den ich erst sehr schick fand: Man kann Docling direkt eine URL geben, die Docling dann selbst abruft. Im Java Code muss dann nur noch der zurückgegebene Markdown Code verarbeitet werden.
Aber leider auch ein Einfallstor für einen SSRF Angriff, wie die KI bei der Sicherheitsprüfung anmerkte. Die Prüfung per KI hat hier also eine echte Lücke gezeigt und war sehr hilfreich. Allerdings war diese Art von Zugriff gar nicht auf meinen expliziten Wunsch hin so programmiert worden, sondern die KI hatte diese Lösung ohne weitere Rückfrage implementiert.
KI kann also helfen KI-generierten Code abzusichern, aber aktuell würde ich nicht davon ausgehen, dass KI von sich aus völlig sicheren Code erzeugt.
Einschätzung zur KI-unterstützten Entwicklung nach diesen Erfahrungen
Insgesamt bin ich etwas vorsichtiger geworden, aber weiterhin davon überzeugt, dass sich die Entwicklungsgeschwindigkeit von IT-Systemen ganz extrem beschleunigen wird. Die KI kann dabei auf einem riesigen Fundus von Open Source Anwendungen aufbauen, und über Containertechnologien können diese auch aus komplett unterschiedlichen Technologiewelten kommen (z. B. ist Docling eine python-Anwendung). So lassen sich in rasanter Geschwindigkeit enorm komplexe Funktionen komponieren.
Diese Erfahrungen haben meine Einschätzung geprägt, was mir aktuell als notwendige Infrastruktur für den erfolgreichen Einsatz von solchen Anwendungen erscheint:
Infrastrukturen, in denen sich solche Anwendungen gut betreiben lassen
Um meine Anwendung in einen produktiven Multiuser Betrieb zu überführen bräuchte es noch ein paar Dinge, und ich glaube, diese lassen sich verallgemeinern. Warum, dazu komme ich noch:
Stabile Datenhaltung mit Brandmauern
Schon immer waren es die Daten, deren Sicherung die oberste Priorität haben muss. Das hat nicht erst die Ransomeware-Epidemie der vergangenen Jahre gezeigt. Mit der KI-getriebenen Entwicklung ist zumindest aktuell das Risiko vermutlich höher als bisher, dass Fehler durchrutschen oder in den schnellen Entwicklungszyklen etwas ausgeführt wird, dass Daten zerstört.
Ein leistungsfähige Datenbankinfrastruktur mit vollständigen Backups und Restoremöglichkeiten möglichst bis auf jede einzelne Datensatzänderung ist damit das Fundament für einen stabilen Betrieb solcher Anwendungen. Sie bildet das Netz, welches vielleicht doch einmal passierte Fehler auffängt, und ermöglicht damit erst die schnelle Weiterentwicklung.
Es ist dabei sinnvoll Anwendungen auf Datenbankebene voneinander zu trennen, damit Fehler nicht überspringen können. Es muss daher leicht sein neue Datenbanken zu gründen und diese auch gleich in die Backupstrategie zu integrieren.
Quellcodeverwaltung
Ich hatte schon in meinem letzten Post beschrieben, wie sinnvoll die Nutzung von git in der agentischen Entwicklung ist. Selbst wenn man allein mit den Agenten vor sich hin entwickelt. Aber hier gibt es immer noch das Risiko des Totalverlusts, wenn ein Agent das komplette Projektverzeichnis löscht.
Es braucht ein zentrales Repository, in das die Quellen gleich eingechecked werden, zum Beispiel eine Gitlab Instanz. Das Repository sollte den Zugriff über ein Rechtemanagement steuern können, welches bei fehlerhaften Zugriffen durch die Agenten keinen Totalverlust verursachen kann. Also zum Beispiel nur lesende und schreibende / versionierende Zugriffe ermöglichen, aber nicht etwa die vollständige Löschung des Repositories.
Auch für weitergedachte Szenarien, in denen ein agentisches Ticketsystem in der Lage sein soll gemeldete Fehler selbst zu beheben bzw. dazu wenigstens einen ersten Bugfixvorschlag zu machen ist so ein System unabdingbar.
CI/CD Pipeline mit Sicherheitsfunktionen
Das Repository ist die Grundlage für weitergehende Funktionen, insbesondere in der automatischen Bereitstellung der Anwendung. Erst wenn man seine sich rasch weiterentwickelnden Anwendungen mit Kolleg*innen, Nutzer*innen und Auftraggeber*innen schnell teilen kann lässt sich das Entwicklungstempo hoch halten.
Ein CI/CD-System ist auch die Stelle, an der sich automatisierte Sicherheitsfunktionen einbauen lassen, wobei man diskutieren kann, ob nicht das Repository schon diese Stelle sein sollte. Aber oft ist das sowieso miteinander verknüpft. Was sind das für Funktionen? Hier eine Auswahl:
- Check auf Geheimnisse wie API Tokens, die nichts im Repository zu suchen haben
- Prüfung der Abhängigkeiten auf bekannte Sicherheitsprobleme. Basis können hier SBOMs sein, die bei Build erzeugt werden
- Automatisierte Test- und Buildscripts, die festgelegte Prüfungen durchführen
- Ggf. auch KI-basierte Tests, wie meine oben beschriebene, allgemeine Fragestellung ‚Sind in der Anwendung die typischen Angriffsszenarien nach OWASP sicher ausgeschlossen?‘
Containerumgebung oder serverless
Für die konkrete Ausführung der Anwendung – insbesondere im Zusammenspiel mit der CI/CD Pipeline – braucht es eine Umgebung, in der sich die neue Version direkt starten lässt. Hier sind in den meisten Fällen Container der Weg. Ob man dann gleich bei Kubernetes landet, oder bei Docker Swarm Mode oder noch etwas anderem: Hauptsache es lässt sich einfach steuern in welcher Anzahl welche Containter laufen sollen und es gibt ein nahtloses Verfahren zum Upgrade der Container.
Ein weitergehenderer Ansatz ist das sogn. Serverless computing, bei dem man sich als Entwickler*in noch weniger mit der Serverumgebung befasst und seine Anwendungen tendenziell in kleinere Services zerlegt, die sich von der zu Grunde liegenden Infrastruktur nach Bedarf starten lassen. Eine headless Architektur – siehe unten – legt so eine Heransgehensweise durchaus nahe.
In solchen Infrastrukturen ist dann natürlich ein Logging / Monitoring noch wichtiger als es das eh schon ist, damit man wichtige Ereignisse in kurzlebigen Serviceinstanzen nicht verpasst. Auch hier liegt eine zentrale Lösung nahe.
Single Sign-on und TLS Offloading
Meine Anwendung hat aktuell noch kein Login und damit auch keine Multiuserfähigkeit. Aber wenn sie mal diesen Schritt machen sollte, dann soll dazu unser vorhandenes Single Sign-on genutzt werden.
Das sehe ich als generelles Prinzip: Anwendungen lassen sich um so effektiver entwickeln – das gilt eigentlich noch stärker ohne KI-Einsatz – wenn sie sich gar nicht mit den Fragestellungen der Verwaltung der Nutzerinnen und Nutzer und dem Loginprozess befassen müssen.
Ein weiterer ’nerviger‘ Teil des produktiven Systembetriebs sind die HTTPS Verbindungen und die in immer kürzeren Intervallen notwendigen Erneuerungen der TLS Zertifikate. Hier sollte es einen Proxy oder Loadbalancer geben, der diese Aufgabe nach außen hinter übernimmt, so dass in der Anwendung selbst höchstens ein sehr langlebiges, selbstsigniertes Zertifikat verwendet werden muss.
In Kubernetes Infrastrukturen kann z. B. Traefik diese Aufgaben übernehmen.
Headless Architekturen / API First Designs
Und schließlich ein letzter Punkt: Wer es bisher noch nicht getan hat sollte sich einen Weg überlegen, wie auf die eigenen Daten und Geschäftslogiken per API zugegriffen werden kann. Das gibt einem viele Freiheiten:
- KI Anwendungen entstehen selten im luftleeren Raum und brauchen Zugriff auf vorhandene Daten und schreiben vielleicht auch Daten in existierende Systeme zurück. Anstatt Stelle von direkten Zugriffen auf Datenbanken sind APIs ein guter Weg die Systeme voneinander abzuschotten und nur auf definierten Wegen miteinander interagieren zu lassen
- Eine API gibt einem die notwendige Freiheit für eine Zukunft, in der das User Interface vielleicht nicht mehr die klassische Webseite ist, in der Nutzer*innen agieren, sondern viele Agenten, die sich dann direkt an der API bedienen können. Und natürlich kann man immer noch ein User Interface für menschliche Nutzer*innen auf die API aufbauen
- Wenn die Performance ein Problem werden sollte, so kann man in solchen Fällen immer noch auf Zugriffe auf die Datenbanken umstellen, dann aber verbunden mit einem entsprechenden Rechtemanagement
Möglicherweise kommen hier dann noch weitere Architekturelemente hinzu, zum Beispiel API Gateways mit Rechtemanagement, Zugriffstokenverwaltung und Monitoring.
Viele Anforderungen für KI Anwendungen – lohnt sich das überhaupt?
Eigentlich sind es zum größten Teil keine komplett neuen Anforderungen:
- Datenbanken & Backup: Dafür sollte es in jeder Organisation einer gewissen Größe eine Lösung geben
- Quellcodeverwaltung: In Organisationen, die bisher keine (professionelle) Eigenentwicklung hatten, vielleicht noch nicht vorhanden. Aber so ein System kann dann auch für andere Zwecke genutzt werden
- CI/CD Pipeline: Gehört heute zu modernen Quellcodeverwaltungen wie Gitlab bereits dazu. Aber der Betrieb – Stichwort DevOps – ist eine eigene Aufgabe und braucht entsprechende Personalkapazitäten
- Container: Das ist sicher ein größerer Brocken, wenn man noch keine entsprechende Infrastruktur hat. Aber der Weg geht so oder so in diese Richtung, und gibt einem viel mehr Freiheit dabei seine Servicelandschaft weiterzuentwickeln
- SSO: Angesichts der Notwendigkeit eine hohe Loginsicherheit mit MFA, Angriffserkennung und weiterem zu erreichen ist ein SSO System letztlich unumgänglich. Wer es noch nicht hat, der wird sowieso über kurz oder lang dort landen, da sich das heute unverzichtbare Sicherheitslevel nicht mehr anders durchhalten lässt
- TLS Offloading: Die Alternative ist es auf allen Systemen z. B. Let’s encrypt zu betreiben, und die dabei erstellten Zertifikate zwischen den Containerinstanzen zu verteilen. Machbar, aber letztlich deutlich mehr Arbeit
- Headless / API First: Bedeutet u. U. ein Umdenken in den bisher entwickelten Anwendungen und Aufwände beim Einstieg. Bei eingekauften Produkten muss man darauf drängen solche Designs zu erhalten, und dies ggf. zur Einkaufsbedingung erheben
Das neue Zeitalter der Eigenentwicklung
Das Update zu der Frage ob das Zeitalter der Eigenentwicklung zurückkommt ist damit für mich weiterhin ein klares Ja. Es braucht aber, um seine maximale Wirkung entfalten und gleichzeitig mit der notwendigen Sicherheit betrieben werden zu können, die oben beschriebenen Fundamente.
Für Organisationen, die bisher noch gar nicht mit selbst entwickelter Software arbeiten, sind das einige Grundinvestitionen und sicher eine Hürde, die nicht ganz einfach zu überwinden ist. Aber man erhält damit wichtige Fähigkeiten:
Alternativen zur SaaS Falle
Viele Software as a Service Anbieter haben in den letzten Jahren damit begonnen regelmäßig und spürbar an der Preisschraube zu drehen, nachdem sie ihre Kunden nach und nach von Kauflösungen mit einmaliger Zahlung hin zu Abomodellen gedrängt hatten. Inhaltlich werden die Preissteigerungen begründet mit neuen Funktionen, auch wenn man selbst diese Funktionen nie nachgefragt hat und auch gar nicht benötigt.
Faktisch wird es aber so sein, dass die Anbieter die Kosten, die ihre Kunden dabei hätten sie zu verlassen, in ihre Kalkulation einbezogen haben. Und nun jedes Jahr so stark an der Preisschraube drehen werden, dass die Kunden es gerade noch als den geringeren Schmerz einstufen, beim Anbieter zu bleiben.
Aus dieser Falle gab es bisher nur für wenige Organisationen einen Ausweg, meist bestand die Alternative höchstens darin zu einem anderen SaaS Anbieter zu wechseln, der im Zweifel das gleiche Verhalten zeigen wird.
Mit der Verfügbarkeit von KI in der Softwareentwicklung ist aber der Weg der Eigenentwicklung plötzlich wieder attraktiv und bezahlbar geworden und diese Einschätzung steckt auch hinter der sogn. SaaSpocalype: Das Wort bezeichnet einen enormen Kursverlust von SaaS Unternehmen im Februar 2026, der nach der Veröffentlichung eines neuen KI Produkts von Anthropic geschah. Hier haben die Anleger schlagartig das Vertrauen in die Wachstumsprognosen der SaaS Unternehmen verloren.
Passgenaue Lösungen
Die Anbieter von Softwarelösungen müssen sich voneinander differenzieren und ein natürliches Mittel dazu ist es immer mehr Funktionen zu ergänzen. Bei Software gilt aber nicht automatisch der Satz ‚Mehr ist immer besser‘, denn mehr Funktionen sind heute auch immer mit einem Ausbau der Benutzeroberfläche verbunden und machen diese damit komplizierter und für die meisten Nutzer*innen schlechter bedienbar.
Auch in Sicherheitshinsicht sind immer mehr Funktionen eher ein Nachteil, da sie zum einen Einfallstore für Fehler sind und zum anderen durch ihre komplexen Konfigurationen den Systemverantwortlichen höhere Bürden bei der sicheren Konfiguration auferlegen.
Mit einer KI-unterstützen Eigenentwicklung sind passgenauere Lösungen möglich, die das mitbringen, was tatsächlich gebraucht wird, aber nicht mehr. Das soll nicht heißen, dass jemand mit einer KI ganz von allein superelegante und nutzungsfreundliche Oberflächen erstellen kann. Aber wenn sich eine Software auf die wirklich notwendigen Funktionen beschränken kann, dann ist diese Aufgabe deutlich einfacher zu meistern.
Digitale Souveränität
Mit jeder SaaS Lösung, die sich durch eine selbst entwickelte und betriebene Lösung ersetzen lässt, ist man auch gleich ein Stückchen weniger abhängig von Unternehmen, die in anderen Ländern beheimatet sind und damit auch deren Rechtssprechungen unterliegen. Oder Unternehmen, die schon viel zu groß geworden sind, als das man noch irgendeinen Einfluss auf sie hätte.
Natürlich lässt sich nicht jedes SaaS Produkt auf diese Weise kurzfristig ersetzen, es gibt weiterhin Grenzen. Diese liegen mindestens an den Stellen, an denen man mit dem SaaS Produkt auch komplexe Geschäftslogiken bzw. Prozesswissen einkauft, welches man so selbst gar nicht (mehr) hat.
Aber auch hier kann man erste Schritte gehen und vielleicht nur noch einen API Zugriff einkaufen, aber nicht mehr ein Gesamtprodukt mit Benutzeroberflächen, die sich nur mühevoll in die eigene Login- und Sicherheitsinfrastruktur integrieren lassen.