Die Zeit des Vibe Codings ist gekommen

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.

FiLaMr ✍ Mein erstes veröffentlichtes Vibe Coding Projekt

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.

Screenshot aus dem Markdown Online Editor in Sciebo

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:

Screenshot von FiLaMr mit der README aus dem Github Projekt

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 😏