Kategorie: Programmierung

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.

Überblick & Strukturen

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, die in den Bereich der Prompt Evaluation und Qualitätssicherung fällt. Zu diesem Thema kann ich dabei die ‚AI Evals‘-Folge des Programmierbar-Podcasts empfehlen.

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. In einem anderen Fall war Claude explizit im Planning-Modus gestartet worden, sollte als Rückfrage halten, setzte sich aber mit einem ‚Ich mache das vollständig ohne Plan, da es ein klar überschaubarer Umfang ist.‘ einfach darüber hinweg.

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:

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. Anstelle 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 Schnittstellen gebraucht werden für viele Agenten, die sich daran direkt 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.

Der vorletzte Post in diesem Blog hat sich mit der Sicherheit von Werkzeugen zur agentischen Softwareentwicklung beschäftigt. In diesem Post geht es hingegen um erste, eigene Erfahrungen mit so einem Tool, ganz konkret Google Antigravity. Ich spreche dabei für mich nicht von Vibe Coding, da mir weiterhin der Blick in den Quellcode wichtig ist und das technische Verständnis des Produkts, welches sich erzeuge.

Warum Antigravity

Die Wahl war zuerst eher zufällig, ein Zusammentreffen von Meldungen zu diesem noch relativ neuen Angebot, Gelegenheit etwas neues auszuprobieren und meiner alten Affinität zu Google Produkten.

Nach meinen ersten Erfahrungen damit würde ich die Entscheidung im Nachhinein so begründen:

• Antigravity setzt auf Visual Studio Code auf, und damit habe ich schon Erfahrungen
• Die duale Sicht auf die Softwareentwicklung gefällt mir: Einmal die klassische VS Code Oberfläche, die mir als Softwareentwickler den gewohnten, direkten Umgang mit dem Code erlaubt. Dazu aber die Parallelwelt der komplett auf den agentischen Ansatz fokussierten ‚Agent Manager‘ Sicht

Nachteilig ist heute, dass es zumindest nach meinem Stand nicht möglich ist selbst gehostete Modelle zu verwenden:

Der Start: Was erlaube ich den Agenten?

Bei den ersten Schritten mit Antigravity war die Erinnerung an die ganzen Sicherheitsaspekte noch sehr frisch, und ich habe jede Interaktion mit dem System, selbst ein einfaches ls -ltr explizit erlaubt. Aber das ermüdet einen schnell und wenn die Agenten richtig nützlich sein sollen, dann müssen sie auch in Teilen eigenständig voranschreiten können.

Hier kann man sich in den zahlreichen Einstellungen von Antigravity und dem VS Code Unterbau etwas verlieren, ich habe es dann meist bei dem Default gelassen.

Das erste Projekt: Generieren einer komplexen Ordnerstruktur

Für eine anstehende Aufgabe brauche ich eine Möglichkeit beliebig große Ordnerstrukturen mit einem spezifischem Inhalt zu generieren. Ein Kommandozeilentool dafür zu basteln ist ein schönes, in sich abgeschlossenes Projekt. Und dabei nicht völlig trivial. Die Ordnerstruktur ist grundsätzlich so:

/Wurzelverzeichnis
    /12345
        /Textdatei.txt
        /PDF-Datei.pdf
    /12346
        /Textdatei.txt
        /PDF-Datei.pdf
    /12347
        /Textdatei.txt
        /PDF-Datei.pdf

Ich möchte bei der Generierung das vorgeben können:

• Wie soll das Wurzelverzeichnis heißen
• Wie viele Unterverzeichnisse sollen erzeugt werden
• Wie groß sollen die PDF Dateien sein

Dabei möchte ich in den Textdateien einen zufälligen Inhalt aus einer vorgegebenen Liste eintragen und die PDF-Dateien sollen etwas in der Größe variieren und den Namen des Verzeichnisses in einer lesbaren Form enthalten, damit später die korrekte Verarbeitung leicht geprüft werden kann.

Es soll Java 25 verwendet werden und Maven für den Build, damit ich das Produkt auch nachvollziehen und ggf. selbst anpassen kann.

Schneller Erfolg nach Startproblemen

Leider habe ich mir das grundsätzliche Prompt nicht gemerkt und es ist mir später verloren gegangen, nachdem ich das Verzeichnis des Projekts verschoben habe. Offenbar merkt sich Antigravity seine Chats mit Bezug zu dem Verzeichnis, denn nach der Änderungen wurden sie nicht mehr angezeigt.

Aber auf Basis des Prompts, welches die Architektur festlegte, erzeugt Antigravity in dem leeren Verzeichnis schnell die grundlegenden Strukturen und den Maven Build. Das Startproblem kam dann vom VS Code Teil: Hier wurden Add-ons installiert, die nicht mit Java 25 umgehen konnten und das herauszufinden hat dann fast mehr Zeit gekostet, als das Projekt abzuschließen.

Im Endeffekt habe ich dann zwei Java Dateien erhalten, die meine Anforderungen perfekt erfüllen. Einmal UcanDummyGenerator.java, welches dann auf der Kommandozeile aufgerufen wird:

package org.unibi.us;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.HashSet;
import java.util.Random;
import java.util.Set;

/**
 * UcanDummyGenerator - A tool for creating complex folder structures for
 * student tests.
 */
public class UcanDummyGenerator {

    private static final String[] GRADES = {"1,0", "1,3", "2,0", "2,3", "3,0", "3,3", "4,0", "5,0"};
    private static final Random RANDOM = new Random();

    public static void main(String[] args) {
        if (args.length != 3) {
            System.err.println("Usage: UcanDummyGenerator <number_of_subfolders> <target_location> <sizeGoalKB>");
            System.exit(1);
        }

        int numSubfolders;
        int sizeGoalKB;
        try {
            numSubfolders = Integer.parseInt(args[0]);
            sizeGoalKB = Integer.parseInt(args[2]);
        } catch (NumberFormatException e) {
            System.err.println("Error: The first and third arguments must be integers (number of subfolders and size in KB).");
            System.exit(1);
            return;
        }

        String targetName = args[1];
        Path targetPath = Paths.get("outputs", targetName);

        if (Files.exists(targetPath)) {
            System.err.println("Error: Target location '" + targetPath + "' already exists. Execution denied.");
            System.exit(1);
        }

        try {
            Files.createDirectories(targetPath);
            System.out.println("Created target directory: " + targetPath.toAbsolutePath());

            Set<Integer> matriculationNumbers = new HashSet<>();
            while (matriculationNumbers.size() < numSubfolders) {
                // Generate a random 7-digit number (1000000 to 9999999)
                matriculationNumbers.add(1000000 + RANDOM.nextInt(9000000));
            }

            for (Integer matriculationNumber : matriculationNumbers) {
                Path subfolderPath = targetPath.resolve(String.valueOf(matriculationNumber));
                Files.createDirectory(subfolderPath);

                // Create note.txt
                Path noteFile = subfolderPath.resolve("note.txt");
                String grade = GRADES[RANDOM.nextInt(GRADES.length)];
                Files.writeString(noteFile, grade);

                // Create klausur.pdf with matriculation number as content
                Path pdfFile = subfolderPath.resolve("klausur.pdf");
                PDFGenerator.generate("Klausur für " + String.valueOf(matriculationNumber), pdfFile.toString(), sizeGoalKB);
            }

            System.out.println("Successfully generated " + numSubfolders + " subfolders in '" + targetPath + "'.");

        } catch (IOException e) {
            System.err.println("An error occurred during directory or file creation: " + e.getMessage());
            e.printStackTrace();
            System.exit(1);
        }
    }
}

Und dann noch PDFGenerator.java für die Erzeugung der PDF Dateien:

package org.unibi.us;

import java.io.IOException;

import org.apache.pdfbox.pdmodel.PDDocument;
import org.apache.pdfbox.pdmodel.PDPage;
import org.apache.pdfbox.pdmodel.PDPageContentStream;
import org.apache.pdfbox.pdmodel.font.PDType1Font;
import org.apache.pdfbox.pdmodel.font.Standard14Fonts;

/**
 * PDFGenerator - A utility class for generating PDF files from plain text.
 */
public class PDFGenerator {

    /**
     * Generates a PDF file with the given content and saves it to the specified
     * path. Optionally pads the file with random bytes to reach a target size.
     *
     * @param content The plain text content to be included in the PDF.
     * @param filePath The path where the PDF will be stored.
     * @param sizeGoalKB The target size in kilobytes. The result will be +/-
     * 10% of this value. Pass 0 or less for no padding.
     * @throws IOException If an I/O error occurs during PDF creation or saving.
     */
    public static void generate(String content, String filePath, int sizeGoalKB) throws IOException {
        java.util.Random random = new java.util.Random();
        try (PDDocument document = new PDDocument()) {
            PDPage page = new PDPage();
            document.addPage(page);

            try (PDPageContentStream contentStream = new PDPageContentStream(document, page)) {
                contentStream.beginText();
                // Using standard Helvetica font for simplicity
                contentStream.setFont(new PDType1Font(Standard14Fonts.FontName.HELVETICA), 12);
                contentStream.newLineAtOffset(50, 750); // Start near the top-left corner

                // PDFBox doesn't automatically handle newlines in showText, 
                // so we split by newline and handle each line.
                String[] lines = content.split("\\r?\\n");
                for (String line : lines) {
                    contentStream.showText(line);
                    contentStream.newLineAtOffset(0, -15); // Move down for the next line
                }

                contentStream.endText();
            }

            if (sizeGoalKB > 0) {
                // Calculate target bytes with +/- 10% random factor
                double factor = 0.9 + (random.nextDouble() * 0.2);
                long targetBytes = (long) (sizeGoalKB * 1024 * factor);

                // Save to a temporary buffer to see current size
                java.io.ByteArrayOutputStream baos = new java.io.ByteArrayOutputStream();
                document.save(baos);
                long currentSize = baos.size();

                if (currentSize < targetBytes) {
                    long paddingNeeded = targetBytes - currentSize;

                    // Add a dummy stream with random bytes to the document
                    byte[] padding = new byte[(int) Math.min(paddingNeeded, Integer.MAX_VALUE)];
                    random.nextBytes(padding);

                    org.apache.pdfbox.cos.COSStream dummyStream = document.getDocument().createCOSStream();
                    try (java.io.OutputStream os = dummyStream.createOutputStream()) {
                        os.write(padding);
                    }

                    // We need to reference this stream somewhere so it's saved.
                    // Adding it to a custom entry in the document catalog works well for "bloating".
                    document.getDocumentCatalog().getCOSObject().setItem(
                            org.apache.pdfbox.cos.COSName.getPDFName("Padding"),
                            dummyStream
                    );
                }
            }

            document.save(filePath);
        }
    }
}

Der Code ist so weit sauber strukturiert, fängt Fehlerfälle ab wie fehlende Parameter und hat zahlreiche Kommentierungen. Bei den Kommentierungen zeigt sich, dass Antigravity auf Englisch ‚denkt‘, selbst wenn man problemlos auf Deutsch mit dem Tool sprechen kann.

Eine Erweiterung der Funktion geht dann einfach per Prompt. Zum Beispiel so:

Bitte ergänze in dem PDF noch die Note, die für die Textdatei gewählt wurde. Die Note soll unterhalb der Überschrift mit der Matrikelnummer in einer separaten Zeile stehen und das Präfix 'Benotung: ' erhalten

Dann legt Antigravity bei einfacheren Aufgaben direkt los:

Man sieht hier, wie der Build ausgeführt wird, um die syntaktische Korrektheit des erzeugen Codes direkt zu validieren. Bei komplexeren Aufgaben erhält man eine Planungsdarstellung, in der Antigravity seine Überlegungen für die Umsetzung präsentiert. Hier kann man dann kommentierend eingreifen und so das Vorgehen beeinflussen. Oder auch komplett ablehnen. Ein Beispiel dafür zeige ich gleich im Kontext des nächsten Projekts, welches ich mit Antigravity angegangen bin:

Baue mir einen Proxy für die OpenAI API

Beim zweiten Projekt habe ich das initiale Prompt nicht verloren, und das war dieses:

Ich möchte meinen Nutzern den Zugriff auf die OpenAI API bzw. kompatible APIs ermöglichen. Aber um Logging und Abrechungen machen zu können sollen die Zugriffe durch einen eigenen Proxy geführt werden. Das sind die Eckpunkte für die technische Umsetzung:

• Die Implementierung soll in Java erfolgen, mindestens Java Version 17
• Für die Erstellung der API Endpunkte soll Jersey verwendet werden
• Lass uns in der Planung festlegen, welche der OpenAI Endpunkte ich durchreichen will, und welche nicht
• Meine Proxy API soll ansonsten komplett kompatibel sein zur OpenAI API
• Ich brauche ein Logging der Zugriffe, bei der die verwendeten Tokens etc. ausgegeben werden
• Ich möchte in der Lage sein nicht nur Richtung OpenAI API Anfragen weiterzuleiten, sondern auch an andere OpenAI-kompatible APIs. Der API Endpunkt und der API Key sollen daher konfigurierbar sein
• Für die Ansprache der OpenaAI API soll das langchain4j Paket verwendet werden
• Ich möchte in späteren Schritten eine Testmöglichkeit aufbauen mit einer einfachen Chatoberfläche

Hier gibt es nun einen detaillierten Vorschlag, wie das Thema angegangen werden soll, und der beginnt so:

Wieder ist schnell eine erste Version lauffähig und Antigravity hat sich auch ein eigenes Testscript erzeugt, um die Funktionsweise seiner Programmierung jederzeit validieren zu können:

#!/bin/bash
java -cp target/openai-proxy-1.0-SNAPSHOT.jar org.unibi.us.proxy.Main &
SERVER_PID=$!
sleep 5
curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "Say hello and good bye!"}]
  }'
kill $SERVER_PID

Man sieht in späteren Schritten oft, dass Antigravity es selbst verwendet. Und für eigene, manuelle Tests ist es auch nützlich. Aber spannender ist dann etwas, was ich sonst auf Grund des Aufwands wohl nicht gemacht hätte: Ich lasse mir von Antigravity ein kleines Chatinterface bauen, welches mir Tests des Proxys im Webbrowser erlaubt. Und das sieht am Ende so aus:

Wer hier ein Déjà-vu hat und sich an den Header des eKVVs erinnert fühlt: Ich habe Antigravity einen Screenshot gegeben und aufgefordert das Design der Seite zu übernehmen. Wie man sieht hat das nur so halb geklappt, aber es zeigt wie verblüffend einfach es sein kann Designs zu übernehmen.

Was man hier auch sieht: Ich habe mir verschiedene Einstellungen in die Oberfläche einbauen lassen, damit ich das Durchschleifen an die API testen kann. Diese Mühe hätte ich mir vermutlich nicht gemacht, wenn ich den Proxy als manuell programmiertes Projekt implementiert hätte.

Mein Fazit aus den ersten beiden Projekten

Nach den ersten beiden kleinen Projekten – und faktisch noch einem dritten, bei dem ich in Antigravity Folien für eine Präsentation mit dem Slidev Framework entwickelt habe – möchte ich meine Erfahrungen so zusammenfassen:

Stand alone Projekte nur noch so

Auch wenn ich schon lange Software entwickle, und mir das Spaß macht: Eigentlich geht es mir meist mehr um die Realisierung von Ideen, als darum dabei neue Techniken zu erlernen, oder um das Coden um des Codens willen.

Mit einem Tool wie Antigravity lassen sich viele Hürden, die man sonst bei neuen Projekten immer wieder überwinden muss, auf die KI abwälzen. Und man kann sich selbst mehr auf das Produkt fokussieren und seine Ideen dazu, wie man es weiterentwickeln kann.

Durch den gleichberechtigten Blick in den erzeugten Code kann ich nachverfolgen, was passiert, und gleichzeitig noch etwas lernen.

Noch nicht so richtig klar ist mir nach diesen begrenzten Einsätzen, wie man mit so einem Tool in umfangreichen Codebasen arbeiten kann, ohne das die Kosten explodieren oder man die Sorge haben muss, dass das notwendige Codeverständnis auf Grund des begrenzten Kontextes nicht mehr ausreicht.

Sofort git einrichten

Ich habe in den Projekten schnell git eingerichtet, auch wenn das inhaltlich vielleicht gar nicht so notwendig erscheint. Aber es macht nochmal schneller sichtbar, was die Agenten im letzten Schritt geändert haben und die Sache so besser kontrollierbar. Und wenn es etwas schief gehen sollte, dann kann man wieder zurück (zumindest so lange nicht das komplette Verzeichnis ausradiert wird).

Management- und Organisationsqualitäten sind plötzlich wichtig

Die agentische Softwareentwicklung fordert etwas andere Fähigkeiten, als das einsame vor sich hin programmieren:

• Die Fähigkeit das angestrebte Ergebnis zu beschreiben ist die Grundvoraussetzung vor eine erfolgreiche Entwicklung
• Die eigene Rolle verschiebt sich hin zu einem Auftraggeber oder ‚Vorgesetzten‘ einer kleiner Heerschar von Agenten
• Diesen muss man die Arbeit in angemessenen Häppchen geben, damit das Ergebnise in die richtige Richtung geht, verständlich und kontrollierbar bleibt
• Man kann mehrere Agenten parallel losschicken bzw. das sollte man, da die Arbeiten nicht instantan erledigt werden. Hier kann man durchaus etwas in Stress geraten, wenn sich alle paar Minuten einer der Agenten meldet und den Abschluss seiner Arbeit meldet

Ich würde trotzdem sagen, dass ein Verständnis der Softwareentwicklung und des generierten Codes weiterhin wichtig ist, zumindest wenn die Qualität des Produkts eine gewisse Relevanz hat und man es vielleicht auch außerhalb von Antigravity weiterentwickeln will. Auch sieht man, dass Antigravity nicht immer von selbst hinter sich aufräumt und manchmal Artefakte von Tests und Irrwegen erhalten bleiben, die es nicht braucht.

Agenten leben in der Vergangenheit

Die Agenten werden von Sprachmodellen betrieben, deren Trainingsdaten nie aktuell sein können. Auch wenn sie Webrecherchen durchführen können, so schützt dies nicht davor bei veralteten Softwareständen zu landen.

Mir ist es im Proxy Projekt zum Beispiel erst spät aufgefallen, dass Langchain4j in einer 0er Version verwendet wurde, während die aktuelle Version bereits 1.12 ist.

Agenten wollen manchmal zu viel

Im Proxy Projekt hat sich Antigravity sehr in dem Versuch verhakt, die statische HTML Datei mit dem Chatinterface über den gleichen Grizzly Server auszuliefern, der auch die API Endpunkte bereitstellte. Das hat lange nicht funktioniert und viele Runden, in denen Antigravity um sich selbst gekreist ist. Und am Ende bei einer nicht wirklich eleganten Lösung ankam, die man nur für einen Testmodus dulden konnte.

Hier hätte ich vielleicht früher eingreifen und vorgeben sollen, dass ein zweiter Server gestartet wird. Oder die HTML Datei gleich direkt aus dem Dateisystem aufrufen sollen.

Kosten laufen schnell aus dem Ruder

Diese zahlreichen Versuche das Problem mit den sich in die Quere kommenden Webrequests zu lösen waren wohl auch ein Grund, warum mein Guthaben an AI Credits dann schnell aufgebraucht war. Da ich das Projekt nicht so lange unterbrechen wollte, bis ich einige Tag später wieder ein paar Credits von Google geschenkt bekomme, habe ich dann kurzfristig ein Abo abgeschlossen.

Die Oberfläche weist einen nicht wirklich offensiv darauf hin, wie schnell man seine Credits verbraucht, oder wie aufwändig einzelne Aufgaben sind.

Autocompletion auf Steroiden

Fazinierend finde ich die Vorschläge für automatische Vervollständigungen. In beiden Projekten habe ich nachträglich eine README.md angelegt und teilweise wird einem ein kompletter Paragraph mit sinnvollem Text zum Projekt vorgeschlagen, den man einfach nur bestätigen muss.

Auch Commit Messages, Inhalte von bekannten Dateiformaten wie .gitignore und selbst Inhalte für meine Slidev-Präsentation zu BIKI und großen Sprachmodellen kommen wie von Geisterhand. Manchmal allerdings auch etwas zu aufdringlich.

Alles in einer Umgebung

Für die Entwicklung muss man eigentlich Antigravity nicht mehr verlassen, so lange die Credits nicht aufgebraucht sind: Ob man nun erst ein Konzept erstellt, sich bei der Frage der richtigen Technologie berät, einen Stacktrace verstehen will, immer kann man mit der KI sprechen und bleibt dabei im gleichen Kontext.

Kommt die Zeit der Eigenentwicklungen zurück?

Ich bin traditionell eher auf der Seite derer, die Eigenentwicklungen in Organisationen beführworten. Wie könnte das auch angesichts des BIS Projekts anders sein. Trotzdem war immer klar, dass sich komplexe Entwicklungen, insbesondere in Bereichen, die starken Regulierungen unterworfen sind, manchmal so nicht in wirtschaftlicher Weise umsetzen lassen. Und es braucht auch immer Leute, mit denen man dies tun kann.

Die agentische Softwareentwicklung verschiebt aber die Grenze sehr, bis zu der eine Eigenentwicklung vernünftig sein kann für eine Organisation, und das aus mehreren Gründen:

• Durch Vibe Coding kann es Fachabteilungen möglich werden sehr realistische Prototypen zu erstellen, die genau ihren Anforderung entsprechen. Sie müssen sich hier nicht mehr unbedingt von Software Anbietern beraten und damit in die Richtung von Standardprodukten drängen lassen.
• Auch für die IT Abteilungen kann sich die Zeit von der Idee zur produktiven Umsetzung drastisch verkürzen, insbesondere wenn agentische Entwicklung mit CI/CD Umgebungen verbunden ist, die eine rasche Auslieferung neuer Stände ermöglichen.
• Eine passgenaue Eigenentwicklung kann damit möglicherweise schneller zur Verfügung stehen, als eine komplexe Standardsoftware, die verstanden, angepasst und eingeführt werden muss.
• Damit kann einer der großen Vorteile einer Eigenentwicklung, nämlich die Möglichkeit sich iterativ einer komplexen Prozesslage zu nähern, wieder genutzt werden.

Hier steht denke ich ein Umdenken an, damit die neuen Chancen durch die KI realisiert werden können. Dazu muss das Denken in den Bahnen der in den letzten Jahrzehnten etablierten ‚Sicherheiten‘ bei der Wahl des richtigen Softwareprodukts aufhören.

Follow-up

In diesem Post habe ich die Erfahrungen mit einem größeren Antigravity-Projekt und die daraus für mich folgenden Punkte für einen produktiven Einsatz von mit KI-Unterstützung entwickelten Anwendungen beschrieben.