Als die Idee des selbstlernenden Trading-Bots konkret wurde

Von Coding zu Trading

Das Gespräch begann mit der Frage, wie man einen Spezialisten für LONG- und SHORT-Trading mit Kryptowährungen nennt. Eine Minute später wurde dem gedachten KI-Team ein IT- und Programmierspezialist hinzugefügt.

Dieser Schritt ist wichtig. Es ging nicht mehr nur darum, Python zu schreiben. Das Projekt begann, Marktverständnis und Softwareentwicklung zu verbinden und KI eher als Gruppe spezialisierter Helfer zu betrachten als als einen einzigen allgemeinen Assistenten.

Der erste konkrete Plan

Um 21:41 wurde die Kernidee deutlich. Eine Maschine oder ein Programm bauen, das den Kryptomarkt beobachtet, analysiert, was dort passiert, und erst eine Zeit lang lernt, bevor es handeln darf.

Der frühe Plan sah ungefähr einen Monat Beobachtung vor und umfasste LONG- und SHORT-Positionen. Das Ziel war bereits größer als ein einfaches Kauf- oder Verkaufssignal in einer Tabelle. Die Software sollte beobachten, lernen und später Entscheidungen treffen.

Das Wort "lernen" war damals allerdings noch unscharf. Es gab keine ausgereifte Modelldefinition, kein Trainingsprotokoll und keinen belastbaren Evidenzstandard. Es war ein Ziel, kein nachgewiesenes lernendes System.

Nicht mit echtem Geld anfangen

Wenige Minuten später bekam der Plan eine sinnvolle Sicherheitsschicht. Zuerst Lernen. Danach Demo oder Paper Trading. Echtes Geld sollte erst dann ins Spiel kommen, wenn die simulierte Phase profitabel aussah, und selbst dann nur in sehr kleiner Höhe.

Diese Reihenfolge löste die wissenschaftlichen Probleme der Trading-Forschung nicht. Ein profitabler Paper-Test beweist nicht, dass eine Strategie im Live-Markt bestehen wird. Historisch zeigt sie aber, dass ein unfertiger Bot nicht sofort nennenswertes Kapital erhalten sollte.

Zuerst beobachten. Ohne Geld testen. Einen sehr kleinen Live-Schritt erst erwägen, wenn die vorherige Stufe überzeugend wirkt.

Ein frühes Zeichen für ein weiteres Problem: Kontinuität

Später am selben Abend wurde nach einem Wiederherstellungs-Prompt gefragt, falls das Gespräch verloren gehen sollte. Das klingt nebensächlich, wurde aber zu einem wiederkehrenden Problem des Projekts.

Wenn KI über viele Sitzungen hinweg beim Aufbau eines großen Systems hilft, kann verlorener Kontext fast so schädlich sein wie verlorener Code. Lange bevor AUR formale State-Dateien, Handoffs und Forschungs-Locks hatte, bestand bereits der Bedarf, genug Kontext für die Fortsetzung der Arbeit zu sichern.

Die Idee war noch naiv

Im Plan vom 5. Juni steckte eine starke Annahme: Der Bot beobachtet den Markt eine Weile und lernt dadurch genug, um zu handeln. Die folgenden Wochen zeigten, wie viel in diesem Satz fehlte.

Daten mussten zuverlässig gesammelt werden. Backtests mussten vertrauenswürdig sein. Bibliotheken und Umgebungen mussten funktionieren. Börsen-APIs mussten sich wie erwartet verhalten. Außerdem brauchte das Projekt einen Weg, echtes Lernen von Code zu unterscheiden, der nur Indikatoren berechnet und Entscheidungen ausgibt.

Was danach kam

Am 6. Juni begann die Umsetzung. Früher Python- und Börsen-Code tauchte auf, historische Daten wurden wichtig, es kamen Fragen auf, ob der Bot tatsächlich lernt, und Backtesting brachte die ersten schmerzhaften Probleme mit Umgebung und Abhängigkeiten.

Die Veränderung am 5. Juni war einfacher: Zum ersten Mal gab es ein klares Ziel. Einen Krypto-Trading-Bot bauen, der zuerst beobachtet, ohne echtes Geld testet und später LONG- und SHORT-Entscheidungen trifft. Alles danach war der Versuch herauszufinden, ob diese Idee den Kontakt mit der Realität übersteht.