Wie ein Discord-Bot mich zurück zur Softwareentwicklung gebracht hat

Warum meine Reise Richtung AI Engineering nicht mit KI begonnen hat

Rückblickend hat meine Reise Richtung Softwareentwicklung und AI Engineering nicht mit einer Weiterbildung begonnen.

Sie hat auch nicht mit einem großen Plan begonnen. Und schon gar nicht mit der Idee, irgendwann über KI-Systeme, Automatisierungen, Docker, Selfhosting oder eigene Dashboards zu schreiben.

Eigentlich begann sie mit einem ziemlich praktischen Problem auf Discord.

Ich war damals Teil des Support- und Admin-Teams von Immortal Roleplay, einem der größten und bekanntesten GTA-RP-Server im deutschsprachigen Raum. Zusätzlich war ich im Event-Team aktiv. Unsere Aufgabe war es, Events für Spieler zu planen, zu organisieren und gemeinsam mit ihnen umzusetzen.

Das klingt erstmal nach Spaß. Und das war es auch.

Aber sobald viele Menschen, Termine, Ideen, Dateien, Absprachen und Zuständigkeiten zusammenkommen, entsteht ziemlich schnell ein Problem, das viele Community-Projekte irgendwann kennen:

Organisation.

Am Anfang funktioniert vieles noch irgendwie. Man nutzt Google Sheets. Man schreibt sich über Discord. Bilder, Dateien und Informationen gehen per DM hin und her. Termine werden manuell eingetragen. Zuständigkeiten werden irgendwo notiert.

Und irgendwann merkt man:

Das funktioniert zwar, aber es fühlt sich nicht mehr gut an.

Nicht, weil die Leute keine Lust hatten. Sondern weil die Struktur irgendwann nicht mehr zu dem passte, was wir eigentlich brauchten.

Das Problem war nicht Discord. Das Problem war der Workflow.

Wir hatten bereits Discord.

Wir hatten Google Sheets.

Wir hatten motivierte Leute.

Wir hatten Ideen für Events.

Was gefehlt hat, war ein System, das besser zu unserem Alltag passte.

Google Sheets war praktisch, um Dinge aufzuschreiben. Aber es war kein Ort, an dem ein kompletter Workflow wirklich natürlich stattfinden konnte. Benachrichtigungen waren schwierig. Externe Dienste wären nötig gewesen. Spieler mussten Dateien, Bilder und Informationen teilweise per DM schicken. Teammitglieder mussten selbst nachschauen, ob etwas Neues passiert ist.

Kurz gesagt:

Die Informationen waren da, aber sie lagen nicht dort, wo die Arbeit eigentlich stattfand.

Und die Arbeit fand auf Discord statt.

Also kam irgendwann der Gedanke:

Wenn wir sowieso Discord nutzen, warum verlagern wir dann nicht mehr von diesem Prozess direkt dorthin?

Natürlich gab es schon fertige Bots. Ticket-Bots, Moderations-Bots, kleine Helfer für Community-Server. Aber je konkreter ich über unsere Anforderungen nachgedacht habe, desto klarer wurde:

Ein fertiger Bot wird wahrscheinlich nicht genau das können, was wir brauchen.

Nicht so, wie wir es brauchen.

Nicht mit unseren Abläufen.

Nicht mit unseren Sonderfällen.

Und genau da begann der eigentliche Einstieg.

Aus einer Idee wurde ein Bot

Ich fing an, nach Tutorials zu suchen.

Discord-Bots mit JavaScript. Node.js. Discord.js. Erste Commands. Erste Events. Erste Verbindungen zur Discord API.

Am Anfang war vieles Copy-Paste.

Ich habe Videos geschaut, Kanäle verglichen, Ansätze ausprobiert und versucht zu verstehen, warum manche Dinge funktionieren und andere nicht. Irgendwann bin ich auf einen englischsprachigen Kanal gestoßen, der viele Grundlagen sehr gut erklärt hat. Das war für mich wichtig, weil ich nicht nur fertigen Code übernehmen wollte, sondern langsam verstehen wollte, wie so ein Bot eigentlich aufgebaut ist.

Neben Job, Supportarbeit, Eventplanung, RP, Familie und allem anderen entstand Stück für Stück der erste eigene Bot.

Der Name war passend unspektakulär:

Anfragebot.

Gebaut für unseren speziellen Discord-Server rund um die Eventverwaltung, später unter dem Namen „Universe Entertainment“.

Am Anfang war der Bot noch ziemlich einfach.

Stumpfe Message-Befehle. Einfache Übersicht für Teammitglieder. Erste kleine Hilfen, damit Informationen nicht komplett verstreut lagen.

Aber genau das war der Anfang.

Nicht perfekt.

Nicht sauber architekturiert.

Nicht so, wie ich es heute bauen würde.

Aber es war etwas Eigenes. Etwas, das ein echtes Problem lösen sollte.

Der Moment, in dem es nicht mehr nur Spielerei war

Viele kleine Projekte fühlen sich am Anfang wie Spielerei an.

Man testet etwas. Man schaut, ob es funktioniert. Man freut sich, wenn der Bot auf einen Befehl reagiert.

Aber irgendwann kam ein anderer Moment.

Der Bot wurde tatsächlich genutzt.

Nicht nur von mir.

Nicht nur zum Testen.

Sondern von Menschen, die damit arbeiten wollten.

Tickets wurden erstellt. Anfragen wurden strukturierter. Teammitglieder wurden benachrichtigt. Spieler konnten Informationen übergeben, ohne dass alles in privaten Nachrichten verloren ging.

Aus „ich probiere mal einen Bot aus“ wurde plötzlich:

Ich habe etwas gebaut, das andere Menschen verwenden.

Das war für mich ein ziemlich wichtiger Punkt.

Denn genau da verändert sich die Perspektive.

Solange man nur für sich selbst programmiert, ist vieles egal. Wenn etwas kaputtgeht, merkt man es selbst. Wenn ein Feature umständlich ist, lebt man damit. Wenn der Code hässlich ist, stört es erstmal niemanden.

Aber sobald andere Menschen ein System nutzen, wird es anders.

Dann geht es nicht mehr nur darum, ob der Code irgendwie läuft.

Dann geht es darum, ob der Ablauf verständlich ist. Ob Fehler abgefangen werden. Ob Daten sauber gespeichert werden. Ob der Bot zuverlässig reagiert. Ob Teammitglieder damit wirklich Zeit sparen.

Und genau dadurch wurde das Projekt für mich viel ernster.

Von einfachen Commands zu echten Workflows

Mit der Zeit wuchs der Anfragebot weiter.

Aus einfachen Message-Befehlen wurden später Slash Commands.

Aus einfachen Antworten wurden strukturiertere Abläufe.

Irgendwann kam MongoDB als Datenbank dazu.

Das war einer der Punkte, an denen ich gemerkt habe, dass Softwareentwicklung sehr schnell über das reine Schreiben von Befehlen hinausgeht.

Ein Bot, der nur auf eine Nachricht reagiert, ist eine Sache.

Ein Bot, der Daten speichern, verändern, wieder abrufen und in einem sinnvollen Ablauf nutzen soll, ist etwas anderes.

Besonders die korrekte Anbindung von MongoDB und das Handling innerhalb einzelner Funktionen waren für mich anfangs eine echte Baustelle. Gerade wenn sich Daten ändern sollten, wurde schnell sichtbar, dass man nicht einfach nur irgendetwas in eine Funktion schreibt und hofft, dass es schon passt.

Man muss verstehen, wann Daten gelesen werden. Wann sie verändert werden. Was passiert, wenn etwas nicht gefunden wird. Was passiert, wenn ein Nutzer eine falsche Eingabe macht. Was passiert, wenn mehrere Dinge gleichzeitig passieren.

Das war einer meiner ersten größeren technischen Fehlerbereiche.

Und gleichzeitig eines meiner wichtigsten Learnings.

Weil ich zum ersten Mal wirklich verstanden habe:

Daten sind nicht einfach nur „irgendwo gespeichert“.

Sie sind Teil des gesamten Workflows.

Wenn man sie falsch behandelt, wird der ganze Ablauf instabil.

Das Ticketsystem wurde immer konkreter

Mit der Zeit wurde aus dem Bot immer mehr ein richtiges System.

Ein Button öffnete ein Modal. Spieler konnten dort Informationen eintragen. Danach wurde automatisch ein Channel in einer vordefinierten Kategorie erstellt. Teammitglieder wurden gepingt.

Der Channel wurde passend benannt, später sogar automatisch anhand von Datum, Uhrzeit und Auftraggeber angepasst.

Das klingt heute für mich relativ normal.

Damals war es ein großer Schritt.

Denn jeder dieser Schritte bedeutete neue Fragen:

Wie erstellt man Channels per Bot?

Wie setzt man Rechte richtig?

Wie liest man Modal-Eingaben aus?

Wie verhindert man falsche oder leere Angaben?

Wie benennt man Channels dynamisch?

Wie hält man den Überblick, wenn mehrere Anfragen gleichzeitig entstehen?

Aus einem kleinen Bot wurde nach und nach ein Werkzeug, das echte Abläufe abbildete.

Und genau das hat mir wahrscheinlich am meisten Spaß gemacht.

Nicht einfach nur ein Feature zu bauen, weil es technisch möglich ist.

Sondern einen Prozess zu verstehen und ihn dann in Code zu übersetzen.

RP, Rechnungen und ein kleines Billing-System

Später kam noch eine Art Billing-System dazu.

Das hatte mit dem GTA-RP-Kontext zu tun.

Viele Dinge sollten nicht nur außerhalb des Spiels organisiert werden, sondern auch irgendwie ins Roleplay eingebunden sein. Werbung konnte gebucht werden. Events wurden geplant. Leistungen sollten im Spiel nachvollziehbar sein. Rechnungen konnten im RP-Kontext bezahlt werden.

Das war technisch vielleicht nicht das komplexeste System der Welt.

Aber es war fachlich interessant.

Weil es nicht nur um Code ging, sondern um eine Art Verbindung zwischen Community, Discord, Organisation und Spielwelt.

Der Bot war dadurch nicht einfach ein externer Helfer.

Er wurde Teil eines größeren Systems.

Und genau solche Verbindungen finde ich bis heute spannend.

Wenn digitale Werkzeuge nicht isoliert stehen, sondern echte Abläufe unterstützen.

Eigentlich war das Interesse schon viel älter

Das Spannende ist:

Der Bot war nicht mein erster Kontakt mit Programmierung.

Eigentlich hatte ich schon als Kind und Jugendlicher Spaß an Technik und Entwicklung.

Anfang der 2000er habe ich bereits mit Webseiten experimentiert. HTML, CSS, erste Ideen für eigene Seiten. Vieles davon war nie richtig online oder professionell, aber das Interesse war da.

Ich habe mich mit Spieleentwicklung beschäftigt, als Unreal Engine für mich noch etwas komplett Neues und Faszinierendes war. Ich hatte mir sogar Bücher ausgeliehen, um Programmiersprachen wie C# oder ähnliche Grundlagen besser zu verstehen.

Später kamen andere Dinge dazu:

Webseitenelemente.

Navigationen.

YouTube.

Videoschnitt.

Streaming.

Discord-Server.

Community-Aufbau.

Design.

Technische Setups.

Wenn ich heute darauf zurückschaue, war Technik eigentlich nie komplett weg.

Sie war nur lange nicht der Mittelpunkt.

Der Anfragebot hat dieses Interesse nicht neu erfunden.

Er hat es wieder aktiviert.

Aus Basteln wurde Lernen

Am Anfang wollte ich einfach ein Problem lösen.

Ich wollte keinen Karriereweg planen. Ich wollte nicht direkt Entwickler werden. Ich wollte auch nicht strategisch Content über meine Reise aufbauen.

Ich wollte, dass unser Event-Team besser arbeiten kann.

Aber genau das ist rückblickend interessant.

Viele Dinge, die heute wichtig für mich sind, kamen nicht aus einem großen Plan.

Sie kamen aus konkreten Problemen.

Ich wollte einen Bot bauen.

Dann musste ich JavaScript besser verstehen.

Ich wollte den Bot online halten.

Dann musste ich mich mit Hosting beschäftigen.

Ich wollte ihn stabiler betreiben.

Dann kam Linux dazu.

Ich wollte Prozesse besser kontrollieren.

Dann kamen PM2, Panels, später Docker und Docker Compose ins Spiel.

Ich wollte Projekte übersichtlicher machen.

Dann wurde Webentwicklung wieder wichtiger.

Ich wollte Inhalte und Systeme selbst verwalten.

Dann entstanden Ideen für Dashboards.

Und irgendwann war die Frage nicht mehr:

Wie baue ich diesen einen Bot?

Sondern:

Wie baue ich Systeme, die wirklich funktionieren?

Das war der Punkt, an dem aus Basteln Lernen wurde.

Warum dieser Bot mehr verändert hat, als ich damals dachte

Der Anfragebot war nicht perfekt.

Wahrscheinlich würde ich heute viele Dinge anders bauen.

Strukturierter. Sauberer. Besser getrennt. Mit klareren Services. Mit besserem Error Handling. Mit saubererem Datenmodell.

Aber genau darum geht es gar nicht.

Der Bot war wichtig, weil er mich gezwungen hat, weiterzugehen.

Ein kleines Problem führte zum nächsten. Ein Feature führte zu einer neuen technischen Frage. Ein Fehler in MongoDB führte zu mehr Verständnis über Daten. Ein Hosting-Problem führte zu Linux. Ein Deployment-Problem führte später zu Docker. Ein Organisationsproblem führte zu Dashboards.

Und genau so entsteht für mich echte Entwicklung.

Nicht durch perfekte Kurse allein.

Sondern durch Projekte, bei denen man irgendwann nicht mehr ausweichen kann.

Wenn etwas nicht funktioniert, muss man verstehen, warum.

Der Weg Richtung Weiterbildung

Während der Arbeit am Bot wurde mir immer klarer, dass mir das nicht nur kurzfristig Spaß macht.

Es war nicht nur:

„Cool, der Bot funktioniert.“

Sondern eher:

„Ich will das wirklich besser können.“

Ich wollte verstehen, wie man Anwendungen sauberer baut. Wie man mit Daten arbeitet. Wie man Systeme hostet. Wie man eigene Tools entwickelt. Wie man aus Ideen nutzbare Software macht.

Und irgendwann war der Gedanke da:

Vielleicht ist das nicht nur ein Hobby.

Vielleicht ist das etwas, womit ich langfristig arbeiten möchte.

Diese Erkenntnis kam nicht auf einmal.

Sie entstand nebenbei.

Zwischen Discord, JavaScript, Fehlermeldungen, Tutorials, Datenbankproblemen und dem Gefühl, dass ich bei jedem gelösten Problem eigentlich nur noch neugieriger wurde.

Heute bin ich in einer Weiterbildung im Bereich Softwareentwicklung und AI Engineering.

Aber wenn ich ehrlich bin, war der entscheidende Impuls schon früher da.

Während ich an einem Discord-Bot für Eventverwaltung gearbeitet habe.

Warum AI Engineering für mich kein kompletter Richtungswechsel ist

Von außen kann es so wirken, als wäre AI Engineering plötzlich ein ganz anderes Thema.

Erst Discord-Bots.

Dann Server.

Dann Webentwicklung.

Dann KI.

Für mich fühlt es sich aber eher wie eine Weiterentwicklung an.

Denn der Grundgedanke ist ähnlich geblieben:

Wie kann ich technische Systeme bauen, die Arbeit erleichtern?

Beim Anfragebot ging es darum, Eventanfragen besser zu organisieren.

Bei Automatisierungen geht es darum, wiederkehrende Prozesse abzubilden.

Bei Agentensystemen geht es darum, Tools, Daten und Entscheidungen miteinander zu verbinden.

Bei KI geht es nicht nur darum, ein Modell irgendwo einzubauen.

Spannend wird es erst, wenn daraus ein System entsteht, das in einen echten Workflow passt.

Genau deshalb interessieren mich heute Themen wie:

• AI Engineering
• Agentensysteme
• Automatisierungen
• Selfhosting
• eigene Dashboards
• Webentwicklung
• Infrastruktur

Nicht als einzelne, voneinander getrennte Themen.

Sondern als Bausteine für Systeme, die man wirklich nutzen kann.

Was ich aus dieser Zeit mitgenommen habe

Wenn ich heute auf den Anfragebot zurückblicke, sehe ich nicht nur ein altes Projekt.

Ich sehe einen Wendepunkt.

Ich habe gelernt, dass ein technisches Projekt nicht groß starten muss.

Es muss nur echt sein.

Ein echtes Problem.

Echte Nutzer.

Echte Fehler.

Echte Anforderungen.

Das reicht oft schon, damit man mehr lernt als durch viele theoretische Beispiele.

Ich habe auch gelernt, dass man nicht alles vorher wissen muss.

Man darf anfangen, bevor man sich bereit fühlt.

Man darf Fehler machen.

Man darf Dinge später umbauen.

Man darf Code schreiben, den man ein Jahr später kritisch sieht.

Das gehört dazu.

Wichtig ist nur, dass man nicht stehen bleibt.

Heute ergibt vieles mehr Sinn

Heute sehe ich meine bisherigen Themen nicht mehr als einzelne lose Phasen.

Frühe Webseiten.

Spieleentwicklung.

YouTube.

Videoschnitt.

Discord-Server.

Community-Aufbau.

Bots.

Linux.

Docker.

Selfhosting.

Webentwicklung.

AI Engineering.

Das wirkt auf den ersten Blick vielleicht durcheinander.

Für mich ergibt es inzwischen aber ziemlich viel Sinn.

Es ging immer darum, Dinge zu bauen, zu gestalten, zu verstehen und nutzbar zu machen.

Mal waren es Videos.

Mal Communities.

Mal Server.

Mal Bots.

Mal Webseiten.

Und heute sind es zunehmend Systeme, die Softwareentwicklung, Infrastruktur und KI miteinander verbinden.

Der eigentliche Anfang

Deshalb würde ich heute sagen:

Meine Reise Richtung AI Engineering begann nicht mit KI.

Sie begann auch nicht mit einem perfekten Plan.

Sie begann mit dem Wunsch, ein konkretes Problem in einer Community zu lösen.

Ein Discord-Bot sollte uns helfen, Eventanfragen besser zu verwalten.

Am Ende hat er viel mehr getan.

Er hat mich zurück zur Softwareentwicklung gebracht.