Gestern habe ich das neue Projekt ‚FiLaMr‘ in meinem Github Account veröffentlicht. Die Besonderheit daran: Ich habe keine einzige Zeile des Codes selbst geschrieben. Alles wurde nach meinen Vorgaben von KI erstellt, selbst die Dokumentation. Aber das ist nur eines von mehreren Projekten und Tools, die ich in dieser Woche im Stil des Vibe Codings erstellt oder weiterentwickelt habe. Man kann sagen, dass für mich, nach ersten Gehversuchen vor ein paar Monaten, die Zeit des Vibe Codings wirklich begonnen hat. Hier möchte ich mein erstes Fazit zu dieser neuen Vorgehensweise aktualisieren, aber zuerst ein paar Beispiele zeigen:

Der Pergola Planer

Vermutlich bin ich Kolleginnen und Kollegen damit sehr auf die Nerven gegangen, aber der Pergola Planer ist ein schönes Beispiel für eine Software, vor deren Komplexität ich sonst wohl zurückgeschreckt wäre. 3D Renderings im Webbrowser zu erzeugen ist nichts, was ich irgendwann schon einmal gemacht hätte, auch wenn ich einiges über die Theorie weis und die Optionen von three.js schon lange bewundert habe.

Und es wäre für den Anlass – meine Skizzen per Hand waren so schlecht, dass auf dieser Basis eine Verständigung über die Bauweise der Pergola nicht erfolgreich war – auch vom zeitlichen Aufwand her auch nicht vertretbar gewesen, dafür eine Software in klassischer Weise zu entwickeln. Und die Motivation hier zum Vibe Coding zu greifen war ähnlich wie beim FiLaMr Markdown Editor:

• Es soll ein spezialisiertes Tool entstehen, welches auf den ganz konkreten Aufstellort der Pergola zugeschnitten ist (Platzgröße, Strukturen am Rand, …)
• Es war auch ein Spaßprojekt um zu testen, wie gut ein inhaltlich komplexeres Vorhaben (Wie beschreibe ich einer KI die Bauweise einer Pergola?) sich mit Antigravity umsetzen lässt

Für mich hat sich das Projekt voll gelohnt, es ließen sich unterschiedliche Konstruktionen durchspielen und die Größen der dabei verwendeten Balken und Bretter konfigurieren, auch beim Besuch bei einem Holzhandel war der Laptop mit dem Tool dabei um zu verdeutlichen, was gebraucht wird.

Wettkampforganisation für ein Laufteam

Beim Sommerfest der Uni haben wir wieder eine Gruppe für den Laufwettbewerb gestellt. Ein Teil der Gruppe war zum ersten Mal dabei und durch das nicht ganz simple Regelment ist es eine Strategiefrage, wie man sich einteilt. Also wer an welcher Position läuft und wie viele Runden. Das hat in früheren Jahren auch mit Excel auf einem Laptop, oder ganz ad hoc geklappt, aber am Abend vor dem Event wollte ich ausprobieren, ob sich per Vibe Coding etwas spannendes bauen lässt. Ich bin hier in zwei Schritten vorgegangen, was sich aktuell zu einer Standardvorgehensweise für mich entwickelt hat:

Schritt 1: Mit einer KI das Prompt für die Programmierungs-KI entwickeln

Ich habe mit Mistral Vibe zuerst iterativ ein Prompt entwickelt, welches die Grundlage für die spätere Softwareentwicklung sein sollte. Das Ausgangsprompt sah dabei so aus (die Namen der Kolleg*innen habe ich ausgetauscht):

Ich möchte eine HTML Single Page Applikation entwickeln, die mir bei der Organisation meines Laufteams bei einem speziellen Wettbewerb hilft. Ich möchte deine Hilfe bei der Formulierung des Prompts, mit dem ich dann eine KI zur eigentlichen Entwicklung prompten kann 

Hier sind die ersten Eckpunkte:

- das Laufteam heißt 'Schneller als sie denken' und hat diese 10 Mitglieder: Lukas, Felix, Chen, Hildegard, Gisela, Lena, Sophie, Mia, Maximilian, Jürgen 
- Der Wettbewerb heißt 'Lauf zum Sommerfest 2026'
- Beim Wettbewerb müssen alle Läuferinnen und Läufer nacheinander Runden laufen, jede läuft genau einmal, kann aber eine oder mehrere Runden laufen 
- Der Wettbewerb dauert genau 45 Minuten und ich möchte planen, wie viele Runden die einzelnen Läuferinnen machen sollten, damit alle dran kommen, aber wir auch die maximale Gesamtrundenanzahl erreichen 
- ich möchte in der Webanwendung die Liste der Läuferinnen per drag and drop einstellen können, per Default sollen sie alphabetisch sein
- bei jeder Läuferin muss zum einen die Anzahl der Runden eingestellt werden können. Der kleinste erlaubte Wert ist 1, der maximale 5. Es soll mit Plus / Minus  Schaltern größer und kleiner geschaltet werden können
- zusätzlich muss die Zeit eingetragen werden können, die eine bestimmte Läuferin pro Runde braucht. Der Defaultwert ist 3 Minuten. Hier muss ein Sekunden-genauer Wert gesetzt werden können. Nur Werte zwischen 2 und 5 Minuten sind erlaubt. Bei den Läuferinnen soll das Produkt aus Rundenanzahl und Rundenzeit gezeigt werden, also die Zeit, die die jeweilige Läuferin auf der Strecke verbringen wird 
- ich möchte eine gesamtauswertung in der Seite haben, die die Anzahl der Runden aller Läuferinnen aufsummiert und die Summe der einzelnen Gesamtlaufzeiten. 
- Das Design soll etwas verspielt sein. Zum Beispiel mit einem geschwungenen Font für die Titel. Die Akzentfarbe soll ein tiefes Rot sein, sonst weiß und leichte Grautöne 

Hast Du Fragen an mich dazu?

Vibe hatte tatsächlich noch einige Fragen und insgesamt hat es mit dem Schreiben des Grundprompts und ein paar Fragerunden wohl so eine halbe Stunde gebraucht, bis dann dieses finale Prompt erstellt war:

Erstelle eine **Single-Page-Web-App** in **Vanilla HTML/JS** für die Planung von Laufrunden des Teams *"Schneller als sie denken"* beim Wettbewerb *"Lauf zum Sommerfest 2026"*.
Die App muss folgende Anforderungen erfüllen:

---

### **Funktionen**
1. **Läufer:innen-Liste**:
   - **Feste Daten im Code** (einfach anpassbar):
     ```javascript
     const laeuferinnen = [
        { name: "Lukas", runden: 1, zeit: "3:00" },
        { name: "Felix", runden: 1, zeit: "3:00" },
        { name: "Chen", runden: 1, zeit: "3:00" },
        { name: "Hildegard", runden: 1, zeit: "3:00" },
        { name: "Gisela", runden: 1, zeit: "3:00" },
        { name: "Lena", runden: 1, zeit: "3:00" },
        { name: "Sophie", runden: 1, zeit: "3:00" },
        { name: "Mia", runden: 1, zeit: "3:00" },
        { name: "Maximilian", runden: 1, zeit: "3:00" },
        { name: "Jürgen", runden: 1, zeit: "3:00" }
     ];
     ```
   - **Default-Sortierung**: Alphabetisch.
   - **Drag & Drop**: Reihenfolge per Drag & Drop anpassbar (nur für Startreihenfolge).
   - **Rundenanzahl**: Pro Läufer:in 1–5 Runden (Default: 1), steuerbar mit Plus/Minus-Buttons.
   - **Rundenzeit**: 2–5 Minuten (Default: 3:00), Eingabe in Minuten:Sekunden (z. B. "3:45").
     - **Validierung**: Werte außerhalb von 2:00–5:00 werden sofort blockiert.
   - **Anzeige**: Berechnung und Anzeige der Gesamtzeit pro Läufer:in (Runden × Rundenzeit).

2. **Gesamtauswertung**:
   - Summe aller Runden und aller Gesamtlaufzeiten.
   - **Warnung**:
     - Rot markiert, wenn Gesamtzeit < 45:00 oder > 45:00.
   - **Echtzeit-Updates**: Bei jeder Änderung.

3. **Optimierung**:
   - Button **"Optimieren"**, der eine automatische Rundenverteilung vorschlägt (basierend auf den eingegebenen Zeiten, um die 45 Minuten bestmöglich auszunutzen).

4. **Datenpersistenz**:
   - **Primär**: Speicherung der Konfiguration in der **URL** (komprimiert, z. B. Base64).
   - **Fallback**: `localStorage`.

5. **Export**:
   - Button **"Als CSV exportieren"** für die aktuelle Planung.

---
### **Design**
- **Font**:
  - Titel: Geschwungener Schriftzug (z. B. über Google Fonts oder SVG).
  - Andere Texte: Lesbar (z. B. Arial oder Helvetica).
- **Farben**:
  - Titel: Tiefes Rot (#8B0000) als Hintergrund, weißer Text.
  - Buttons/Akzente: Tiefes Rot.
  - Hintergrund: Weiß (#FFFFFF) mit leichten Grautönen (#F5F5F5).
- **Interaktion**:
  - Visuelles Feedback bei Drag & Drop (z. B. Läufer:in leuchtet kurz auf).
  - Sanfte Animationen bei Änderungen (z. B. Einblenden von Warnungen).

---
### **Technische Details**
- **Technologie**: Vanilla HTML/JS (keine Frameworks).
- **Zielplattform**: Nur Desktop.
- **Code-Stil**: ES6+ Features erlaubt, **kommentiert und strukturiert**, damit die Läufer:innen-Daten leicht auffindbar und anpassbar sind.

---
### **Lieferumfang**
- **Einzelne HTML-Datei** mit eingebettetem CSS/JS.
- **Funktionsfähig ohne Server** (lokal ausführbar).
- **Kommentierter Code** mit klarer Markierung der Läufer:innen-Daten für einfache Anpassungen.

Damit bin ich dann zu Antigravity gegangen:

Schritt 2: Entwicklung der eigentlichen Anwendung

In Antigravity habe ich nicht viel mehr gemacht, als einen Ordner anzulegen und das zuvor erstellte Prompt einzugeben. Eines der Claude Modelle ist dann losgelaufen und hat nach ca. 8 Minuten die tatsächlich nahezu perfekte App erzeugt, die so aussieht:

Dieser Screenshot zeigt dabei eine etwas spätere Version, die noch einen ‚Optimieren‘ und ‚Sortieren‘-Button bekommen hat. Aber grundsätzlich war es eine Entwicklung in einem einzigen Schritt, nachdem die inhaltliche Arbeit zuvor geleistet wurde.

Die KI fragen lassen, was noch nicht verstanden ist, oder wo Lösungsräume nicht stark genug eingeengt worden sind durch die Beschreibung, hat sich für mich schon in verschiedenen Projekten bewährt. Solche Schritte vor dem Start der Codegenerierung zu machen hat diese Vorteile:

• Die Konzeptentwicklung kann schneller iteriert werden, als wenn die KI schon mal Code generiert, den man dann wieder korrigieren lassen muss (Codegenerierung dauert und ist ggf. teuer)
• Lücken in der eigenen Idee werden einem direkt klar und können gefüllt werden. Um das zu forcieren kann man die KI auffordern besonders kritisch zu sein (aber Achtung: Je nachdem, wie scharf man sich die Kritik wünscht, kann das eine Herausforderung an die eigene Kritikfähigkeit sein 😏)

Es braucht allerdings eine schon etwas ausgereiftere Vorstellung davon, was man eigentlich haben möchte. Und manchmal übertreiben es die KIs auch mit den Nachfragen, und man muss selbst entscheiden, wann man einen Schlusstrich zieht und das Resultat haben will.

CSV zu Wiki und Markdown

Bei meiner Arbeit habe ich zur Zeit oft Fälle, in denen ich ein Ergebnis einer SQL Abfrage, welches in einem SQL Tool wie pgAdmin ausgeben wird, direkt in ein MediaWiki oder eine Markdown Datei bringen möchte. Nicht immer klappt das problemlos per Copy-and-Paste und früher habe ich mir oft mit der Macrofunktion von Emacs geholfen. Das geht mir halbwegs schnell von der Hand, aber wenn man es das zweite Mal machen muss, weil man an der SQL Abfrage noch etwas zu verbessern hatte, und ein drittes und ein viertes Mal wird es nervig.

Hier habe ich mir dann mit BIKI eine HTML Anwendung bauen lassen, die die lästige Konvertiererei blitzschnell erledigt. Dieses Tool verwende ich heute nahezu täglich und es spart mir wahnsinnig viel Zeit bzw. ich dokumentiere nun auch Daten in einem Umfang, den ich früher vermieden hätte.

Und weitere Tools….

Es gibt noch eine Reihe weiterer, kleiner Hilfsmittel, darunter:

• Ein Konverter von MediaWiki zu Markdown
• Ein Tool um die Ergebnisse einer bestimmten Datenbankabfrage der Studiengangsmodellierung zu gruppieren und zu filtern (ja, kann man auch mit Excel tun, aber so habe ich ein spezialisiertes, auf den Anwendungsfall fokussiertes Tool)
• Eine Testseite, um Zugriffe per Javascript auf bestimmte Server aus bestimmten Netzwerkumgebungen testen zu können
• Ein Browser für eine komplexe API, der im Vergleich zur Swagger UI insbesondere einen Verlauf hat, mit dem sich schnell zwischen verschiedenen Abfragen samt Parametern hin- und herspringen lässt

Für diese Entwicklungen sind die Funktionen von BIKI meist völlig ausreichend und es braucht oft keine teures OpenAI Modell dafür, offene Modelle wie Qwen 3.6 sind leistungsfähig genug. Die Entwicklung mit BIKI hat auch den Vorteil, dass sich der erreichte Stand einfach teilen lässt. So kann man eine Anwendung bis zu einem gewissen Stand entwickeln, und danach an Kolleg*innen übergeben, die sie nicht nur nutzen, sondern auch selbstständig anpassen können.

Diese Tools haben dabei nur den Anspruch für mich selbst praktisch zu sein. Sie sollen nicht die weltbeste Lösung für irgendeine Herausforderung sein, sie sollen zunächst nur mir das Leben einfacher machen. Und meist bereiten sie mir auch Spaß, da ich sie selbst geschaffen habe.

Meine Arbeitsweise hat sich verändert

Über den rasanten Entwicklungen der KI-generierten Anwendungen schwebt für Informatiker*innen bzw. allen, die Software erstellen, die bedrohliche Frage, ob sie in Zukunft eigentlich noch gebraucht werden? Diejenigen, die hier beschwichtigen wollen, bringen oft das Argument es werde in Zukunft dann einfach mehr Software entwickelt, und damit bleibe genug Arbeit übrig.

Was ich aus der Veränderung meiner persönlichen Arbeitsweise der letzten Monate auf jeden Fall sagen kann: Ich habe mehr Software entwickelt, also ich es in den letzten Jahrzehnten getan habe. Wobei ich das etwas relativieren muss: Da die reine Softwareentwicklung im BIS nicht mehr den Schwerpunkt meiner Tätigkeit ausmacht gab es in der Vergangenheit natürlich Zeiten, in denen ich viel mehr am BIS entwickelt habe, als ich es heute tue.

Aber es gab nie eine Zeit, in der ich so viele unterschiedliche Projekte begonnen und abgeschlossen habe, wie jetzt gerade. Und ich merke dabei, dass bestimmte, tief eingeprägte Hemmungen geringer werden: Es hat sich über die Jahre ein Gefühl entwickelt, welche Dinge an einer Anwendungsidee zumindest für mich schwierig sein würden in der Umsetzung. Und damit verbunden eine Abneigung, ein Thema anzugehen. Da man mit der KI nun jemand hat, der*die*das eigene Vorschläge macht und auch umsetzt verschwindet dieser Gedanke allmählich und die zu lösende Aufgabe bleibt im Fokus.

Für mich gilt also die Aussage ‚KI führt dazu, dass viel mehr Software entwickelt wird‘. Vor allem Software, die ohne KI so nie entstanden wäre. In gewisser Weise ist diese Art Software zu entwickeln für mich auch gewohnt, da ich im BIS schon lange eher die Aufgabe habe eine geplante Software oder Funktion zu beschreiben, und die Kolleg*innen im Team machen die konkrete Umsetzung. In der Hinsicht verlangt die Arbeit mit einer KI ähnliche Herangehensweisen und die Kompetenz zu beschreiben, was man haben möchte. Wenn man dies kombiniert mit einer grundlegenden Erfahrung in der Softwareentwicklung, dann kann man sehr schnell etwas erschaffen, was wirklich nützlich ist.

Der Grundaufwand für eine Software reduziert sich drastisch

Auch im BIS werden wir bald ein erstes, kleines Produkt in Betrieb nehmen, welches nach dem oben beschriebenen Vorgehen entstanden ist:

1. Ausgangspunkt war eine Anfrage einer Fachabteilung, die einen nicht ganz in unseren üblichen Themenfeldern liegenden Wunsch nach IT-Unterstützung hatte. Im ersten Gespräch entstand die Idee hier auf eine HTML-Anwendung zu setzen und diese mit starker KI-Unterstützung zu entwickeln
2. Aus den nun bekannten Anforderungen wurde mit BIKI die technische Lösungsidee verprobt und präzisiert und daraus eine kompakte Beschreibung für die weitere Implementierung erstellt
3. Aus diesem Implementierungsplan ist dann in unserer üblichen Entwicklungsumgebung mit KI-Hilfe ein sehr weit fortgeschrittener Prototyp entstanden, der nun schon in die Tests gehen kann

Wenn dieses Konzept funktioniert, dann ist es ein Beispiel für eine Anwendung, für die wir ohne die Verfügbarkeit von KI vermutlich aus Ressourcenmangel kein Angebot hätten machen können. Ich nehme das als einen ersten, kleinen Beweis dafür, dass die These von der Rückkehr der Eigenentwicklung nicht ganz falsch ist.

Gerade habe ich auf Github ein neues Projekt veröffentlicht: FiLaMr /fi-la-mar/. Es enthält einen rein HTML/JS-basierten Markdown Editor, der komplett in Form einer KI-unterstützen Anwendungsentwicklung entstanden ist, und der ursprünglich den folgenden Bedürfnissen entsprang:

Warum ein Markdown Editor

Markdown (MD) gewinnt für mich immer mehr an Bedeutung, da es zum einen im Umgang mit KI-Systemen sehr wichtig geworden ist. So haben wir kürzlich einen eKVV Datenexport in diesem Format entwickelt mit dem Ziel diese Daten direkt an Sprachmodelle übergeben zu können. Auch die Antworten der Sprachmodelle sind heute in MD und wenn man sie weiterverwenden will, dann hat man dieses Format als Ausgangspunkt.

Zugleich hat der an der Uni genutzte Sync-and-Share-Dienst Sciebo im Zuge der Umstellung auf Nextcloud die Option bekommen, direkt in der Weboberfläche Markdown Dateien erstellen und bearbeiten zu können. Für mich, der ich gewohnt bin Google Drive Dokumente mehrmals am Tag auf mehreren Rechnern blitzschnell zu öffnen und zu bearbeiten, ein echtes Geschenk, denn die Bearbeitung von Word oder Open Office Dokumenten im Webbrowser geht zwar, ist aber quälend langsam und für meine regulären Bedürfnisse an Inhaltsstruktur völlig überfrachtet. So geht es mir auch mit Word und dem Open Office Pendant auf dem Desktop.

Markdown hat noch den großen Vorteil keinerlei proprietäre Software zu brauchen um es zu betrachten. Eigentlich braucht es überhaupt keine Software, zur Not kann ich mir den Inhalt mit cat auf der Kommandozeile ausgeben lassen. Und selbst Microsoft hat seinem ollen Notepad Editor unter Windows 11 offenbar einen Markdown Betrachter spendiert.

Endlich Markdown, aber man ist ja nicht allein auf der Welt

So weit, so gut also? Leider nein, denn Markdown ist weit davon entfernt das Standard Dateiformat zu sein, mit dem man sich unter Kolleg*innen austauscht. Hier dominiert weiterhin die Office Welt und manche Dinge sind mit Markdown auch schlicht nicht schön zu lösen, wie zum Beispiel Anmerkungen und Kommentare, wenn man in einer Gruppe an einem Text arbeitet.

Und manchmal braucht man die Dokumente einfach im Word- oder PDF-Format für weitere Prozesse ‚weil es einfach so ist‘. Hier hatte das schöne MD-Tool in Sciebo für mich eine Schwäche: Ich habe keinen für mich regelmäßig mit vernünftigem Aufwand gangbaren Weg gefunden, wie ich aus dem Sciebo Tool diese Formate erzeugen konnte. Und es fehlte mir auch noch ein MD Betrachter oder Editor für den eigenen Rechner.

Warum noch ein Markdown Editor

Da Markdown ein so einfaches und offenes Format ist gibt es Betrachter und Editoren wie Sand am Meer. Warum also selbst etwas bauen? Da kann ich im wesentlichen diese Gründe anführen:

• Sicherheitsfragen: Wenn ich mir auf meinen Rechner eine Software lade, selbst wenn sie auf Github viele Sterne hat, gibt es immer das Risiko sich hier etwas ins Haus zu holen, dass unerwünschte Dinge tut. Das Risiko mag klein sein, aber es sorgt für ein gewisses Unwohlsein bei mir
• Der Webbrowser sollte die Laufzeitumgebung sein: Er läuft sowieso die ganze Zeit, bringt Sicherheitsfunktionen mit, als Webentwickler liegt mir diese Plattform und in einem anderen Projekt hatte ich bereits EasyMDE als webbasierten MD Editor eingebunden
• Exportmöglichkeiten: Das Tool soll es mir einfach machen die Vorarbeiten im Markdown Format dann in Word fortzusetzen oder den aktuellen Stand als PDF zu verschicken
• Lust am Vibe Coding: Seit den ersten Gehversuchen hat sich das sogn. Vibe Coding für mich zu einer Standardvorgehensweise entwickelt, über die ich nochmal separat schreiben werde. Und so habe ich zunächst in BIKI mit diesem Prompt angefangen:

Ich brauche eine HTML Anwendung, die ich lokal auf meinem Rechner ausführen kann, und die mir bei der Anzeige und bei der Bearbeitung von Markdown Inhalten hilft. Sie soll mir diese Funktionen bieten:

* Ich möchte ein Bearbeitungsfeld für den Markdown Inhalt haben, welches im Webbrowser auf Basis des Pakets EasyMDE arbeitet
* Die Anwendung soll schlank sein und jenseits des Eingabefelds nicht viele UI Elemente haben. Aber das Design soll etwas technisch wirken, so wie ich als Informatiker es mag
* Ich möchte in der Lage sein eine Markdown Datei (Endung .md) in den Editor zu laden
* Ich möchte in der Lage sein den aktuellen Inhalt in einer Datei zu speichern, und dabei Speicherort und Dateiname festlegen können

Hast Du dazu Fragen?

Eine Schwäche von BIKI ist es aber heute, dass es nicht auf das Internet zugreifen kann, was für die Einbindung aktueller Pakete wichtig war. So bin ich dann zu Antigravity gewechselt und habe das Projekt dort finalisiert:

Das war schon vor einigen Wochen und für mich ist das Tool inzwischen das Mittel der Wahl, wenn ich Markdown betrachten oder bearbeiten will:

• Es ist schnell, da es nur aus einer überschaubaren HTML Datei besteht
• Es löst meine Probleme mit den Exports in andere Formate und kann in der letzten Version umgekehrt auch aus Webseiten oder Word übernommene Inhalte meist mit der kompletten Struktur und Formatierung übernehmen
• Es ist offline-fähig, da die externen Abhängigkeiten im Cache bleiben
• Es hat nur die Features, die mir wichtig sind, und ist damit nicht überladen
• Ich weiß, was es genau tut und das keine Daten meinen Rechner verlassen

Da es Interesse von Kolleginnen und Kollegen daran gab habe ich es nun auf Github veröffentlicht, damit lässt sich die Anwendung auch ohne Download aufrufen und bleibt automatisch aktuell:

https://ihbrune.github.io/FiLaMr

Alles Vibe Coding

Ich habe bei dieser Anwendung nach meiner Erinnerung wirklich keine einzige Zeile Code angefasst. Selbst die im Repository enthaltenen Dokumente (README, INFO) sind von den in Antigravity verfügbaren Modellen nach meinen Vorgaben erstellt worden.

Der Prozess war nicht fehlerfrei, neben der Aufgabe der KI möglichst gut zu beschreiben was ich haben will, bestand ein guter Teil meiner Rolle drin zu testen und auf Probleme hinzuweisen. Lehrreich war auch das Ergebnis des Prompts, welches ich in Vorbereitung auf die Veröffentlichung gestellt habe:

Ich möchte dieses Projekt als Open Source Projekt auf Github veröffentlichen. Bitte mache eine kritische Betrachtung der Codebasis: Ist sie reif für eine Veröffentlichung? Sind die Abhängigkeiten auf dem aktuellsten Stand? Sind noch Sicherheitsprobleme vorhanden, die wir vorher beheben sollten? Ist der Code sauber strukturiert und in ausreichendem Umfang kommentiert?

Hier habe ich auch einen Wechsel von den sonst von mir meist bevorzugten Anthropic Modellen auf Gemini Flash 3.7 im High Thinking Modus gemacht und da kam wirklich nochmal eine ganze Menge an Punkten heraus, die entweder inkonsistent, halbgar oder in Sicherheitshinsicht noch nicht zu Ende gedacht waren. Für den Einsatz nur durch mich auf meinen eigenen Rechnern hätte es wohl auch so gereicht, aber nun hat der Code eine deutlich bessere Qualität.

PS

Wofür FiLaMr steht wird in der Github Seite erläutert. Es ist heute nicht so einfach ein Kurzwort zu finden, welches nicht schon dutzendfach verwendet wird 😏

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.