Aki's Vibes

[Akira]

Huhu zusammen,

Nein, hier geht es nicht um Musik, da wär ich wohl im falschen Forum ...

tl;dr Hier geht es um eine Beschreibung von Vibe Coding wie ich es sehe und was ich vor kurzem umgestellt habe, um den Region-Server zu optimieren. Observability, OpenTelemetry, Grafana Cloud sind Themen.


Vielleicht zuerst eine kleine Definition:

Vibe Coding ist ein relativ neuer Begriff in der Programmier-Community, der einen Programmierstil beschreibt, bei dem man sich mehr auf das "Gefühl" und den Flow verlässt als auf strenge Planung oder Best Practices.

Die Kernidee hinter Vibe Coding:

• Man schreibt Code intuitiv, ohne grosse Vorplanung oder Architektur-Überlegungen
  
• der Fokus liegt auf schnellem Experimentieren und "einfach mal machen"
  
• weniger Sorgen um perfekte Struktur, Dokumentation oder Tests
  
• Man lässt sich von der Stimmung und Kreativität des Moments leiten
  

Dann gibt es noch den Begriff Agentic Development auch hier:

Die Kernidee hinter Agentic Development:

• Fokus: KI-Agenten übernehmen ganze Entwicklungsaufgaben autonom
  
• Ansatz: "Ich delegiere komplexe Tasks an einen KI-Agenten"
  
• Kontrolle: Der Agent arbeitet selbstständiger - plant, implementiert, testet teilweise eigenständig
  
• Typisch: KI schreibt ganze Features, refactored Code, debuggt, nutzt Tools eigenständig
  
• Werkzeug: Spezialisierte KI-Agenten (wie Claude Code, Devin, Cursor mit Agent Mode)
  

Hauptunterschied:

Vibe Coding ist eine Arbeitsweise - ein lockerer, Flow-orientierter Stil, den man mit oder ohne KI praktizieren kann.

Agentic Development ist ein Delegationsmodell - man übergibt grössere Verantwortung an autonome KI-Systeme, die komplexere Aufgaben eigenständig lösen.

überschneidung

In der Praxis kombinieren viele Entwickler beides: Sie nutzen agentic tools (wie Claude Code), um sich auf den Vibe zu konzentrieren - also schnell Ideen umzusetzen, ohne sich in Details zu verlieren. Die KI übernimmt die "Denkarbeit" für Implementierungsdetails, während der Mensch im kreativen Flow bleibt.

Mein Vibe im OpenSim

Ich kenne die Architektur des Projekts mehr oder weniger. Ich weiss, was ich erzielen will (kleine Schritte). Dazu nutze ich eine Umgebung, welche mir viel Arbeit abnimmt.

Die beste Erfahrung habe ich mit Claude Code gemacht. Er will eine Änderung machen, zeigt mir dies an und ich entscheide, ob er loslegen soll. Nachteil von Claude Code. Kostet Geld. Aber ich kann den Pro-Plan von Claude nutzen. Kostet pro jahr etwa 160 Euro. Natürlich hab ich da nicht Tokens ohne Ende. Es ist mir schon oft passiert, dass ich eine Meldung kriege: Deine Token sind aufgebraucht, der Reset findet um 20:00 Uhr statt. Also Zwangspause bis 20:00 Uhr. Es existieren noch andere Modi die sind jedoch viiiiel teurer. Und Claude Code funktioniert nur mit Claude zusammen.

In letzter Zeit wird gerade OpenCode gehyped. Hat durchaus auch Vorteile. Es ist möglich beliebige Modelle zu nutzen auch kostenlose. OpenCode ist jedoch näher bei Agentic Development und ich werde da nicht warm damit, den Agent grössere Arbeiten machen zu lassen. Und um die Claude Modelle zu nutzen, brauch ich API Token. Mit OpenCode die Claude Pro Schnittstelle zu nutzen lief bis vor Kurzem, aber Anthropic hat dies nun unterbunden. Und API Token sind sehr teuer.

Vibe von Mistral existiert auch noch. Hat ebenfalls die Möglichkeit gratis Modelle zu nutzen. Ist vom Stil her näher an Claude Code. Und Mistral bietet einen gratis Zugang zu den eigenen Modellen. Begeisterung hält sich aber noch in Grenzen.

Let's do something

Eine Frage welche mich interessiert. Wann läuft ein OpenSim Region Server gut. Und wann nicht und wie sehe ich das. Observability ist das Zauberwort. Hier eine kleine Erklärung:

Observability ist die Fähigkeit, den internen Zustand eines Systems anhand seiner externen Ausgaben zu verstehen und zu analysieren. Der Begriff stammt ursprünglich aus der Kontrolltheorie, hat sich aber vor allem in der Software-Entwicklung und IT-Operations etabliert.

Die drei Säulen der Observability:

Logs – Detaillierte Ereignisaufzeichnungen, die beschreiben, was zu einem bestimmten Zeitpunkt passiert ist
Metrics – Numerische Messwerte über Zeit (z.B. CPU-Auslastung, Response Times, Fehlerraten)
Traces – Verfolgung von Requests durch verteilte Systeme hinweg

Logs habe ich. Kein Thema. Metrics fehlen mir. Klar kann ich mit einem Profiler rein, ist aber für den Betrieb zu heftig. Aber auch dazu gibt es eine Lösung:

OpenTelemetry (oft abgekürzt als OTel) ist ein Open-Source-Framework für Observability, das zum Standard für das Sammeln von Telemetriedaten aus Anwendungen geworden ist.

Was macht OpenTelemetry?

Es bietet eine einheitliche, herstellerneutrale Methode zum Instrumentieren, Generieren, Sammeln und Exportieren von Telemetriedaten (Traces, Metrics, Logs). Statt für jedes Observability-Tool eine eigene Integration zu bauen, verwendest du OpenTelemetry einmal und kannst dann flexibel zwischen verschiedenen Backend-Anbietern wechseln.

Backend-Anbieter also Systeme, welche die OpenTelemetry Daten sammeln und grafisch auswerten, gibt es einige. Kann man sich selber installieren. Jaeger und Zipkin kommen mir da in den Sinn. Die beiden sind spezialisiert auf Traces. Will ich aber im Moment noch nicht. Vorerst brauch ich Logs und Metrics.

Grafana resp. Grafana Cloud war dann die Lösung. Bei Grafana Labs kriegt man eine Grafana Cloud Instanz für Lau mit grosszügig bemessenem Storage. Schnell subscribed und nach 10 Minuten war dies eingerichtet.

Ok was brauche ich nun für OpenTelemetry in meinem Region-Server? Hab ich dann Claude Code gesagt, er solle mir doch bitte OpenTelemetry für Logs und Traces einbauen. Unter anderem kamen da diese Libraries neu in den Region-Server mit rein:

Code:

dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol
dotnet add package OpenTelemetry.Instrumentation.Http

Im Monitoring und Logging Teil des Region-Servers mussten noch einige Anpassungen gemacht werden. Das war ein ziemliches Try-and-Error Spiel. Hatte dann zur Folge, dass noch wesentlich mehr Libraries notwendig wurden.

Einen Region-Server zu bauen ist per Standard runprebuild.sh und compile.sh. Die Abhängigkeiten der Packages werden im prebuild.xml beschrieben usw. Leider funktioniert nur OpenSim mit diesem Prebuild Gedöns. Der Rest der Welt nutzt den NuGet Package Manager. Dieser Prebuild Mechanismus war mir schon lange ein Dorn im Auge. Die Wahrheit liegt in den csproj files und nicht in einem Prebuild XML. Entwicklungsumgebungen sind auf NuGet optimiert und dort ist die Wahrheit halt in den *.csproj files ( wie in Java in den *.pom files ).

Zusammen mit Claude Code war der Build Prozess recht rasch umgebaut. Die Schwierigkeit: Die Package-Verwaltung in OpenSim ist gelinde gesagt ein Desaster oder schlichtweg nicht existent. Da liegen *.dll herum in einer Version, welche gefühlt Jahrzehnte alt sind. Zu einigen DLL gibt es kein NuGet Package und woher sie kommen ist auch unklar. Deshalb haben liegen im Git des OpenSim auch noch dll rum, was eigentlich nicht die feine Art ist.

Egal damit lebe ich erst mal und nach einigen Iterationen war auch dieses Problem gelöst. Und dann Tadaaa:



Vielleicht fällt auf: otel_heartbeat_seconds ist bei 56 Jahren und tendenz steigend. Da hat Claude Code noch was falsch gemacht. Er sendet nur die Timestamps ab Epoch (1.1.1970) und nicht die Differenz von zwei Timestamps. Muss ich ihm noch austreiben.



Find ich voll Cool. Logs und Metrics an einem Ort, zentral.

Fazit:

• Build System modernisiert (NuGet)
  
• OpenTelemetry Logs und Metrics eingebaut
  
• Zeilen codiert: 0
  

Nächstes mal mehr zu weiteren Vibes
Liebe Grüsse
Akira

[Dorena Verne]

Spannender Beitrag, danke Akira.

[Dorena Verne]

Ok, kleine Kritik, ein wenig deutsch für Normalsterbliche würde es für die Allgemeinheit noch interessanter machen.^^

[Akira]

Ok, kleine Kritik, ein wenig deutsch für Normalsterbliche würde es für die Allgemeinheit noch interessanter machen.^^

Vielen Dank. War von der Wortanzahl schon grenzwertig ... aber mit der Zeit denke ich, dass ich auf einige Aspekte vertieft eingehen kann.

[Akira]

Huhu zusammen,

tl;dr Beobachtungen bei unserer Party zum 11 Jährigen Bestehen des Grid und Ersatz einer Grafikbibliothek.

Diese Woche, welche in unserer Geburtstagsparty endete, hab ich einiges hingekriegt. Aber lasst mich mit der Geburtstagsparty beginnen. Ich habe ja Ko Suai und Dereos Plaza mit OpenTelemetry ausgerüstet. Ein Event wie eine Party ist spannend zu beobachten und anschliessend zu analysieren. Hier mal ein Screnshot der gesamten Party:



Ich werde jetzt nicht jedes Feld einzeln erklären. Wen's interessiert, darf gerne fragen. Ansonsten die KI eurer Wahl kann dies auch selbst gut erklären. Das Bild sieht etwa so aus wie ich es erwartet habe. Ab 19:30 Uhr, da sind Ly, Samira und ich auf der Sim aufgeknallt. Nun Beginnen die Kurven stark zu oszillieren. Das dauerte an bis etwas nach 22 Uhr als andauernd neue Gäste eintrafen. Danach lief die Party und irgendwann wurde es spät für einige und am Schluss waren wir noch zu fünft auf der Sim und haben dann gegen 01:00 Uhr Schluss gemacht.



Ein paar mal EINE Aufgabe, welche in dem Thread Pool zur Abarbeitung in der "Warteschlange" standen. Schon mal sehr gut! Das heisst, die Aufgaben wurden alle zügig erledigt. Dass einiges zu tun war, zeigt diese Grafik:



Viel zu tun und rasch erledigt. So soll es sein! Natürlich gab es auch viele Warnungen und Fehler:



Aber nichts Aussergewöhnliches. Sieht man auf jeder Party:



Was mir mehr zu denken gibt, sind diese Warnungen:



Diese CSJ2K Library, mit der hab ich viel Zeit verdödelt. Bin ja dabei, alten Ramsch aus dem Sim zu entfernen. Eine der Libraries, die mich stört, ist die System.Drawing.Common Library. Diese wurde für Linux bis zur Version .NET 6 noch unterstützt. Ab Version .Net 7 gab's dann Fehlermeldungen, dass sie nicht mehr unterstützt ist. Natürlich kann ich die noch lange verwenden, auch in .NET 8+ muss einfach sicher sein, dass ich die alte Version immer im Paket behalte und wenn ihr in euer bin-verzeichnis des OpenSims schaut, dann seht ihr, dass es da zwei Dateien gibt. System.Drawing.Common.dll.linux und System.Drawing.Common.dll.win und je nach System muss dann die richtige eingebunden werden. Also ein Abstellgeleise. Will ich nicht.

Microsoft gibt dazu einige Empfehlungen ab. ImageSharp und SkiaSharp Ich habe mich schlussendlich für SkiaSharp entschieden, ist zwar komplexer im Library Handling aber schlussendlich voll offen unter einer MIT-Lizenz, wogegen die ImageSharp Library von SixLabors lizenziert wird. Ich hatte null Probleme eine freie Lizenz von ihnen zu kriegen, weil die kostenpflichtigen Features von mir nicht genutzt werden. Also als Plan B noch offen halten.

Die umstellung verlief dann relativ harzig. Insbesondere beim Generieren der Maptiles haben wir uns einen Wolf ab-debugged. Bis wir dann die CSJ2K als Bösewicht eingekreist haben. Nachdem ich die aus der Konfiguration entfernt hatte wurden auch die Maptiles korrekt generiert. Die Frage ist nun offen. Was mach ich mit der CSJ2K. In einem Repository von OpenSim gibt es Sourcecode dazu. Auf Github gibt es dieses Repo: https://github.com/cureos/csj2k und diese lib findet man auch im NuGet Repository. Ich gehe aber davon aus, dass Ubit etwas selbst gebrautes verwendet, die arbeiten ja nicht mit NuGet. Ist aber auch fraglich ob ich die verwenden soll. Wir haben ja noch die OpenJpeg Library zusätzlich im Repo. Muss mir da noch einen Task machen.

Wenn alles mit der CSJ2K Library funktioniert, warum nicht wechseln ... wenn ich aber schaue der letzte Commit am 26. September 2018 die ist ja fast so alt wie unser Grid, dann ... na ja, weiterforschen. Ziel für letzte Woche ist erreicht, SkiaSharp eingebaut und angetestet. Nein, nein, auf der PartySim ist die noch nicht eingebaut, erst bei mir lokal im Test.

Nächste Woche: Rausschmiss des SmartThreadPool... der ist in der heutigen Zeit völlig überflüssig. DotNet hat eigene Thread Pools und die Leute vom OpenSim-Tranquility Projekt haben den auch schon entfernt.

[Dorena Verne]

Wenn Ubit nur halb so gute Arbeit leisen würde wie du, wäre OpenSim wahrscheinlich schon um einiges weiter...

[Bogus Curry]

Wenn Ubit nur halb so gute Arbeit leisen würde wie du, wäre OpenSim wahrscheinlich schon um einiges weiter...

Ds muss ich Dorena absolut zustimmen, aber ich denke dem Ubit fehlt es an motivation-

Zu Vibe Coding, mit dem kann man auch Geld verdienen. Ein Auftraggeber, Du machst einen Plan für die KI und die legt los, Egal wie der Coding asuch aussieht, der wird dann verkauft.

Dss gsnzr hat ein Progrsmmierer mal erklärt

[Mareta Dagostino]

Du machst einen Plan für die KI und die legt los, Egal wie der Coding asuch aussieht, der wird dann verkauft.

Das genau ist das ideale Konzept, um Software im großen Stil schlechter zu machen. Einfach das Problem einer KI vorwerfen, und das Ergebnis - falls es läuft - unverstanden ins Volk werfen. Es wird in Zukunft sehr darauf ankommen, ob man sich noch Programmierer leisten will, die sich zwar von KI helfen lassen, aber eine gründliche Endkontrolle machen. Oder ob die Gesellschaft damit zufrieden ist, wenn die verschiedenen KIs voneinander abschreiben und Software den gleichen Weg geht, wie momentan das Internet.

EDIT: Ohne Ubit wäre OpenSim schon lange tot. Immerhin ist OpenSim das einzige freie Metaversum, das den pre-pre-Alpha-Stand überwunden hat und von Endbenutzern ganz normal verwendet werden kann. Das schon seit vielen Jahren...

[Dorena Verne]

Klingt ein wenig nach Angst um den eigenen Job, Mareta.

[Mareta Dagostino]

Im von Bogus verlinkten Video wird es doch am Anfang gut erklärt. Wie oft schaut sich der Kommentator im Video den erzeugten Code an und bessert seine Prompts nach, bis er zufrieden ist? Es ist halt eine andere Art zu programmieren, weniger Tipperei und keine Notwendigkeit mehr, Standardprobleme (noch mal) zu lösen.

KI kann nur die Bröckchen anders zusammensetzen, die irgendwer schon mal ins Internet geworfen hat oder irgendwohin, wo die jeweilige KI trainiert wird. Wenn irgendwann alles nur noch KI-Brei ist, wird es nicht mehr besser. KI ist ein Werkzeug, kein Selbstläufer.

(Um meinen Job brauche ich keine Angst haben, noch 18 Monate. )