Windows? Bin ich jetzt unter die Windows-Programmierer gegangen? Naja, fast. Also zumindest kurzzeitig. Tatsächlich habe ich mein erstes produktives Windows-Programm geschrieben, und inzwischen auch veröffentlich. Von null auf Release innerhalb von zwei Tagen. Natürlich dank KI, ohne die Unterstützung der bekannten Chatbots wäre es kaum in der Zeit möglich gewesen.
TL;DR: Wer sich mehr für das Programm selbst als für den Weg und die Hintergründe zur Erstellung interessiert, ist übrigens herzlich eingeladen, direkt die GitHub-Seite zu besuchen, dort gibt’s die obligatorische Kurzanleitung und natürlich die aktuelle Version zum Download.
Am Anfang war die KI-Musik
Wie so oft fing es harmlos an. Über Suno und die Generierung von Songs hatte ich ja bereits berichtet, auch einige Monate nach den ersten Klängen bin ich noch immer von den Möglichkeiten fasziniert. Hingegen habe ich für mich selbst festgestellt, dass die Erstellung von Videos zu einem Lied – ich will gar nicht von „Musikvideo“ sprechen – doch eine eher mühsame Angelegenheit ist, vor allem wenn man kein Redaktionsteam eines TV-Senders oder ähnliches hinter sich hat. Nicht, dass es nicht durchaus interessant wäre, eher im Gegenteil, aber gerade als Anfänger verstrickt man sich zu oft in irgend welchen Kleinigkeiten, spielt mit Effekten herum, die hinterher absolut lächerlich aussehen, baut Bilder ein, die zu klein, zu groß, zu dunkel, zu kryptisch usw. sind, und letzten Endes hat man eine Woche damit verbracht, während des Schneidens und Editierens das dazugehörige Lied gefühlt dreitausend Mal gehört, und möchte irgendwann einfach nur noch Ruhe haben, respektive fertig werden.
Ganz anders bei den auf Suno verwendeten Hintergrund-Bildern. Einerseits generiert Suno während der Song-Generierung bereits ein je nach Prompt durchaus passendes Bild. Wenn einem dies nicht gefällt, lassen sich eigene Bilder hochladen. Dafür hatte ich dann entweder die simple Lösung genutzt, d.h. ein Bild von einer anderen KI generieren lassen, oder auf eigene Fotos zurückgegriffen und diese – wiederum von einer KI – verfremden lassen. Die Ergebnisse empfinde ich zumindest als brauchbar, erst recht angesichts des Aufwandes, der dahinter steckt.
KI-Musik und KI-Bild zu Video – oder auch nicht
Insofern dachte ich, dass es für ein minimales Video doch genügen würde, Hintergrund(-bild) und Song zu kombinieren und mit einem Effekt zu bestücken, damit der werte Betrachter nicht drei Minuten auf dasselbe Foto starren muss. Und da ich diese Audio-Spektrum-Anzeigen schon auf LEDs der Equalizer oder Verstärker aus Hifi-Türmen der 80er-Jahre sehr gerne hatte, lautete die logische Konsequenz, eine solche sich bewegende Anzeige irgendwo auf das Bild zu packen und während des Liedes dabei zusehen zu können, wie sich die Balken oder Linien bewegten.
Eingangs nahm ich an, dass diese Aufgabe für das von mir verwendete Videoschnitt-Programm leicht zu bewältigen wäre, doch als ich die Effekte mit wohlklingenden Namen wie Audio Spectrum, Audio Visualizer, Music Visualizer Bars etc. testete, war der anfängliche Enthusiasmus schnell verschwunden. Denn die Balken oder Striche bewegten sich zwar munter auf und ab, aber außer dass dort in irgend einer Form und je nach verwendetem Tool die Lautstärke, der Bass oder die Höhen interpretiert wurden, hüpften die Effekte gefühlt unkontrolliert auf ihrer jeweiligen Achse herum, anstatt sich an der jeweils gespielten Frequenz auszurichten. Dabei sollte es einfach nur logisch aufgebaut sein – horizontal auf der X-Achse befindet sich die Frequenz von tief bis hoch, tiefe Töne sorgen für eine Amplitude auf der linken Seite, die höheren rechts. Fertig. Wie vor 40 Jahren beim Leuchten der roten Equalizer-LEDs.
Rein optisch sah es bei manchen Effekten gar nicht so schlecht aus, aber es blieb eben einfach falsch. Natürlich gab es dafür Lösungen, von Umstieg auf andere, bessere Videoschnitt-Programme bis hin zu spezialisierten Online-Diensten, die genau diese Anforderungen „Bild + Musik + Effekt-Overlay = Video“ erfüllt hätten. Bei der Suche nach „Audio-Visualizer“ bin ich sogar auf einige dieser Dienste gestoßen, beinahe mehr als erwartet, aber allen gemeinsam war, dass es sich um kostenpflichtige Angebote handelte. Völlig legitim, aber ich hätte vielleicht ein, zwei Videos pro Monat erstellt, wenn überhaupt. Und dafür lohnte sich die Nutzung und insbesondere das Abonnieren derartiger Services einfach nicht. Für den professionellen Bedarf – wunderbar. Für ein kleines, zusätzliches Hobby – eher nicht.
Audio-Visualizer mittels FFmpeg – cool, aber…
Insofern habe ich mich auf die Suche im kostenlosen oder vielmehr Open-Source-Bereich begeben. Und tatsächlich konnte die eierlegende Wollmilchsau, respektive das Schweizer Taschenmesser unter den Audio- und Videodatei-Bearbeitungstools, manche nennen es auch FFmpeg, dabei helfen. FFmpeg ist ein Kommandozeilenwerkzeug unter Open-Source-Lizenz und kann Medien konvertieren, schneiden, zusammenfügen, streamen, komprimieren sowie mit Filtern (z.B. Skalierung, Visualisierungen, Overlays) bearbeiten. Intern nutzt es zahlreiche Codecs und Bibliotheken, es gilt als eine der flexibelsten und technisch präzisesten Lösungen im Multimedia-Bereich. FFmpeg schien somit das perfekte Tool für meine Bedürfnisse zu sein, jedoch erforderte es trotz Unterstützung von ChatGPT geschätzt zwei Dutzend Versuche, bis die Ergebnisse einigermaßen meinen Vorstellungen entsprachen.
Das fing bei der Farbauswahl an – Bildbearbeitungsprogramm öffnen, Farb-Picker nutzen, RGB-Code notieren bzw. per Copy&Paste in das FFmpeg-Kommando einfügen, und hörte bei der Vielzahl von Filter-Optionen noch lange nicht auf. Nicht zuletzt war das CLI-Kommando inzwischen gefühlt drei Kilometer lang geworden und hätte trotz Copy&Paste natürlich jedes Mal angepasst werden müssen. Angesichts dieser Umstände probierte ich sogar noch kostenlose Videoschnittprogramme wie Microsoft Clipchamp oder VSDC aus. Clipchamp zeigte mit dem Audio-Visualizer-Overlay sogar korrekt aussehende Kurven an, erwies sich jedoch leider etwas unflexibel in der Gestaltung. Über VSDC will ich an dieser Stelle lieber nichts schreiben, es würde in einen Rant des komplett unterirdischen Bedienkonzepts ausarten.
Wochenende? Eine GUI für FFmpeg!
Und da ich an dieser Stelle schon einige Zeit in einer Schleife aus Kommunikation mit ChatGPT, Suchen, Finden, Testen und nicht zuletzt von manchem Tool auch Genervt-sein verbracht hatte, lag die Idee nahe, eine eigene kleine GUI für FFmpeg zu bauen. Denn die Ergebnisse von FFmpeg entsprachen bereits meinen Anforderungen, nur der Weg bis dorthin war nun einmal etwas mühselig. Es sollte eine kleine Windows-Anwendung werden, keine plattformübergreifende Lösung, sondern rein nativ mit Windows-Bordmitteln geschrieben. Und ich wollte den Einsatz von KI-Coding-Tools einmal an einem neuen Projekt testen, noch dazu in einer mir bislang eher unbekannten Umgebung. Außerdem sollte es ein kleines Wochenend-Projekt werden, also wirklich eine klar umgrenzte Aufgabe in einer kurzen Zeit von null bis hin zu einer nutzbaren Fassung fertiggestellt sein.
Nebeneffekt: KI-Coding-Tools testen
Über das Verhalten OpenAI Codex und Anthropic Claude Code ließen sich weitere Beiträge schreiben, daher erlaube ich mir an dieser Stelle nur ein kurzes Fazit. Codex ist aus meiner Sicht zwar schnarchlangweilig, aber ein Arbeitstier. Claude Code gibt sich unterhaltsamer, nach eigenen Aussage sogar mit einer Art „Persönlichkeit“, scheiterte aber an seinen eigenen Ansprüchen, und insbesondere den Limits der „Pro“-Version. Es war am frühen Samstagvormittag, und nach eineinhalb Stunden, in denen gerade einmal der Rahmen der Anwendung und erste, rudimentäre Funktionen entstanden waren, ging Claude Code in einen temporären Feierabend: Arbeitsverweigerung bis 14:00 Uhr. Bereits zuvor lief er in API-Fehler aufgrund Token-Limits und verirrte sich einmal in einer Endlosschleife. Codex übernahm jedoch problemlos die begonnenen Aufgaben, kam jeweils zu einer Lösung, verlangte jedoch ständig nach Bestätigung, dieses oder jenes Kommando auch wirklich ausführen zu dürfen.
Laut eigener Aussagen besitzt vor allem die Windows-Fassung der Codex-Extension für Visual Studio Code dieses Problem, aber andererseits wollte ich genau diese für die Entwicklung der Windows-Anwendung nutzen. Hier bleibt somit zu hoffen, dass sich spätere Versionen etwas angenehmer verhalten. ChatGPT daraufhin gefragt, empfahl es sogar die Nutzung von WSL (Windows-Subsystem für Linux), so dass der Agent in einer stabileren Umgebung laufen, und VSCode sich per Remote-WSL damit verbinden würde. Irgendwie erschien mir das aber ein wenig „von hinten durch die Brust ins Auge“, so dass ich mich entschied, lieber erstmal brav die Rückfragen abzunicken.
Drauniav, eine Audio-Visualizer-GUI!
Das Ergebnis von zwei Tagen Prompten, Bestätigen, Testen – und wieder von vorn, befindet sich in der Anwendung Drauniav. Die letzten Buchstaben stehen gedanklich für „image audio video“, der Rest… lässt Raum für Interpretationen. Die Nutzung sollte sich aufgrund des Screenshots eigentlich von selbst erklären – man wählt Bild und Audio-Datei, legt den Namen des zu erzeugenden Videos fest, kann die Farbe der Visualizer-Kurve wählen, entweder per direkter Einstellung oder mittels Farb-Picker aus dem Bild, legt die Visualizer-Optionen fest bzw. wählt zwischen Standard-Einstellungen. Ein Klick auf „Generieren“ sorgt schließlich dafür, dass FFmpeg mit den zuvor gewählten Parametern gestartet und das Video generiert wird. Zwecks Nachvollziehbarkeit und Dokumentation ist das vollständige FFmpeg-Kommando im unteren Bereich zu erkennen.
Und anstatt sich mit einer solch langen Kommandozeile zu beschäftigen, können die Audio-Visualizer-Einstellungen einfach in einem Dialogfenster konfiguriert werden:
Der gesamte Quellcode ist im Drauniav GitHub-Repository verfügbar, ebenfalls finden sich dort die jeweiligen Release-Versionen als „Portable“-Variante zum Download.
Dank des Distribution als „Portable“-Fassung ist eine Installation nicht notwendig. Stattdessen wird einfach das ZIP-File entpackt und die darin enthaltene EXE-Datei gestartet. Bei Nichtgefallen einfach das Verzeichnis wieder löschen, es hinterlässt keine Spuren. Möglicherweise warnt Windows noch vor einem unbekannten Herausgeber und nicht vorhandener Signatur – sorry dafür. Bei einem solch kleinen Hobby- bzw. Wochenendprojekt lohnt sich de facto kein aufwändiger und noch dazu nicht ganz kostenloser Windows-Anwendungs-Veröffentlichungsprozess.
Die einzige Voraussetzung ist die Verfügbarkeit von FFmpeg auf dem System, Drauniav überprüft beim Start, ob FFmpeg gefunden werden kann und gibt im Fehlerfall eine Warnung inklusive Installationshinweis aus.
Anspruch und Wirklichkeit
Zum Schluss möchte ich noch auf das Thema Transparenz eingehen, insbesondere im Zusammenhang mit KI-gestützter Entwicklung. Denn im Gegensatz zu meiner üblichen Vorgehensweise, die eine ausführliche Kontrolle des durch KI erzeugten Codes umfasst, habe ich diesmal der KI quasi freien Lauf gelassen. Das heißt, ich habe mich um die Code-Qualität tatsächlich nicht weiter gekümmert. Sind Funktionen vorhanden, die quasi dasselbe machen, aber sich nur in einer Kleinigkeit unterscheiden? Keine Ahnung. Ist überflüssiger Code enthalten? Mag sein. Ließe sich an einigen Stellen noch etwas optimieren? Mit hoher Wahrscheinlichkeit ja. Wurden manche Parameter umständlicher berechnet als nötig? Auch das wäre möglich. Könnte man weitere, sinnvolle Features hinzufügen? Definitiv!
Das soll nicht heißen, dass der resultierende Code jetzt komplett übel oder unsinnig ist, denn das Ergebnis spricht für sich – das Tool funktioniert, es erfüllt genau die Anforderungen, die ich daran gestellt hatte. Und es darf nicht vergessen werde – auch das ist mir wichtig zu erwähnen – es greift nicht ins System ein, es setzt keine Werte in die Registry, es modifiziert keine Systemeinstellungen, es öffnet noch nicht einmal eine Netzwerkverbindung, es ist insgesamt sicherheitstechnisch somit völlig unkritisch. Die einzige „Gefahr“ ist, dass das generierte Video nicht den Wünschen oder Erwartungen entspricht.
Schlussgedanken: KI in der Software-Entwicklung
Dass KI-gestützte Entwicklung die Arbeitswelt nicht nur in der Software-Entwicklung verändert bzw. dies bereits getan hat, versteht sich mittlerweile von selbst. Die Erstellung von Drauniav fühlte sich insofern mehr wie das Führen eines Teams von (Junior-)Developern an, als reine Programmierung im Sinne von Code schreiben. Wobei zu erwähnen wäre, dass es sich aktuell noch um Junior-Developer oder gar Praktikanten mit temporärem Anflug von Alzheimer handelt. Aber ich denke, dass diese Probleme nur eine Frage der Zeit sind, die nächsten Generationen der KI-Coding-Tools bzw. LLMs werden dafür eine Lösung bieten.
Andererseits lese ich immer öfter Meldungen wie „Ich habe keine Ahnung von Software-Development, aber habe mit KI-Tools <superdupertolle Software> innerhalb von zwei Stunden geschrieben!“ Natürlich kann das durchaus funktionieren, auch wenn ich die „zwei Stunden“ momentan noch nicht wirklich glaube – zumindest bei allem, was über „Hello, World!“ hinaus geht. Auch dabei wird es aber sicherlich Fortschritte geben. Jedoch lassen sich angesichts derartiger Meldungen so einige Fragen stellen. Kann dabei eine funktionierende Anwendung entstehen? Sicherlich ja. Wäre eine solche Anwendung für einen selbst nutzbar? Klar, warum auch nicht. Würde ich einer solchen Anwendung meine Bankdaten anvertrauen? Naja…
Wobei das Thema Vertrauen noch einmal ganz andere Fragen aufwirft. Etwa inwiefern man beim Entwickeln auf Tools oder Libraries zurückgreift bzw. darauf aufbaut. Open Source – schön und gut, aber auch damit hat es in der Vergangenheit Probleme gegeben, aus den unterschiedlichsten Gründen. Und das Thema Vertrauen zieht sich letztlich durch den gesamten Software-Bereich. Inwiefern vertraue ich Herstellern? Einzelnen Entwicklern? Entwickler-Teams? Entwicklern von Open-Source-Software? Und nicht zuletzt mir selbst in der Rolle des Software-Entwicklers?
Und was sind überhaupt die Ansprüche an die eigenen oder auch durch KI-Coding-Tools erzeugten Ergebnisse? Diese Frage kann, oder vielmehr muss sich jeder Entwickler letztlich selbst stellen, auch ich habe keine Standard-Antwort dafür parat. Für manche mag ein „passt scho“ gelten – die Anwendung funktioniert, mehr ist nicht nötig, und wie der Code von innen aussieht, ist beinahe irrelevant. Ich wage sogar zu behaupten, dass dieser Aspekt insbesondere bei nicht wenigen, kommerziellen, insofern „Closed-Source“-Programmen zu finden ist, schließlich liegt es in der Natur der Sache, dass der Quellcode nicht frei zugänglich ist. Für andere sind, auch abseits von ISO-Normen der Softwarequalität, neben funktionaler Eignung Aspekte wie Zuverlässigkeit, Sicherheit, Wartbarkeit, Effizienz, Benutzbarkeit usw. entscheidende Merkmale.
Bei Drauniav bin ich tatsächlich nach dem Motto „works for me“ vorgegangen, auch aufgrund der vermutlich eher schmalen Zielgruppe, und weil das Programm an sich, wie bereits erwähnt, völlig unkritisch in seinem Ablauf und seiner Funktion ist. Bei der Entwicklung einer (öffentlichen) Web-Anwendung, evtl. noch mit Benutzer- oder sonstigen schützenswerten Daten, wäre dieses Vorgehen eher keine gute Idee. Wobei sich an dieser Stelle wiederum fragen lässt, ob eine KI vielleicht jetzt oder mindestens in naher Zukunft bessere und sicherere Software schreibt als ein unerfahrener menschlicher Entwickler… womit man wieder am Anfang der Überlegungen wäre.
Spaß mit KI
Doch ganz abseits von derartigen beinahe schon philosophisch anmutenden Gedanken hat mir die Entwicklung mittels KI-Coding-Tools doch letztlich Spaß gemacht. Die Fakten sprechen für sich, denn auch wenn es nur eine kleine Anwendung ist, hätte ich diese innerhalb von zwei Tagen ohne Zuhilfenahme von KI nicht entwickeln können. Dafür entscheidend ist weniger die eingesetzte Sprache C#, als die mit Windows-Entwicklung einher gehende Verwendung von Frameworks, Libraries, Tools & Co.. Insgesamt ist somit das reine „Coden“ weniger geworden, dafür wurde mit geeigneten Anweisungen, insofern Prompts, das Ziel schneller erreicht.
Es bleibt auf jeden Fall spannend, und ich bin durchaus neugierig auf die nächsten Schritte im Bereich Software-Entwicklung im Zusammenhang mit KI. Vermutlich stehen wir auch erst am Anfang von viel umfassenderen Veränderungen. Aber andererseits ist der Aspekt des steten Wandels nicht wirklich unbekannt – schließlich haue ich auch nicht mehr 6502-Assemblercode in einen bräunlichen Heimcomputer.
Ein kleiner Nachtrag: Wenn man denn doch mal einen Blick in den Quellcode wirft, finden sich darin mitunter interessante Konstrukte:
// ── Process helpers ────────────────────────────────────────────────────────
Neben durchaus korrekt geschriebenen Kommentaren sind einige mit genau solchen „Mojibake“-Zeichen versehen. Vermutlich hat die KI mal wieder schlecht von Umlauten, deren Kodierungen und Dateiformaten geträumt. Zwar kurios, aber irgendwie auch wieder typisch – es ist 2026, UTF-8 gibt’s seit über 20 Jahren, KI-Coding-Tools schreiben einem komplette Programme, aber Umlaute sind noch immer kaputt. „Schei� Encoding“!
