Nota historyczna: wpis odtworzono z zachowanego archiwum Gemini. Zweryfikowana sekwencja z 6 czerwca obejmuje kilka połączonych rozmów i pokazuje przejście od pomysłu do pierwszej implementacji.
Pierwsze pytanie nie dotyczyło zysku
Tuż po 1:00 projekt został odtworzony w nowej rozmowie za pomocą promptu przekazującego kontekst z poprzedniej nocy. Niemal od razu padło praktyczne pytanie: jak sprawdzić, czy bot naprawdę analizuje dane i się uczy?
To ważne, bo słowo „uczenie” było wtedy używane bardzo luźno. Program może pobierać ceny, liczyć wskaźniki i generować sygnały, nie ucząc się w sensie machine learningu. Na tym etapie nie było jeszcze rygorystycznego testu, który rozdzielałby te dwie rzeczy.
Pojawił się prawdziwy kod
Kilka minut później do przeglądu trafił wczesny bot tradingowy napisany w Pythonie. Korzystał z biblioteki ccxt do komunikacji z giełdą kryptowalut. To już nie była rozmowa o tym, co być może da się zrobić. Kod musiał się uruchomić, dane musiały przyjść w oczekiwanym formacie, a biblioteki musiały ze sobą współpracować.
Historycznie najważniejsza jest zmiana rodzaju problemu. Dzień wcześniej pytanie brzmiało, czym bot ma się stać. 6 czerwca zaczęło się pytanie, czy implementacja faktycznie robi to, co wszyscy zakładają.
Więcej historii wydawało się odpowiedzią
Wieczorem uwaga przeniosła się na historyczne dane rynkowe. Początkowy pomysł około roku danych szybko rozszerzył się do kilku lat.
To naturalny odruch. Jeśli bot ma poznawać rynek, więcej danych brzmi jak oczywista korzyść. W praktyce oznacza też więcej pracy: poprawne pobieranie, zgodność czasu, braki w danych i pewność, że backtest nie opiera się na błędnych wejściach.
Paper trading stał się konkretnym etapem
O 21:23 wrócił plan z poprzedniego dnia, ale już w praktycznej formie: kiedy można uruchomić paper trading?
Kierunek pozostawał ten sam. Najpierw test bez prawdziwych pieniędzy, dopiero później ewentualny krok live. Żeby jednak ufać nawet symulacji, najpierw trzeba było doprowadzić do porządku dane i backtesting.
Potem środowisko powiedziało „nie”
Od około 21:38 backtesting zaczął wpadać na problemy środowiska i zależności. To mało efektowna część budowania oprogramowania, ale bardzo prawdziwa.
Pomysł na strategię może wyglądać prosto w rozmowie. Uruchomienie go wymaga działającego Pythona, zgodnych pakietów, właściwych modułów i powtarzalnego dostępu do danych. Gdy jeden element nie pasuje, nawet najlepszy pomysł nie dociera do testu.
Wygenerowanie kodu było szybkie. Sprawienie, żeby cały system działał niezawodnie, już nie.
Pierwsze zderzenie z rzeczywistością
6 czerwca nie udowodnił, że bot potrafi się uczyć ani zarabiać. Pokazał coś bardziej podstawowego: ogromną różnicę między planem wygenerowanym z pomocą AI a działającym systemem tradingowym.
Od tego momentu trzeba było osobno pytać: czy dane są poprawne, czy kod działa, czy backtest jest wiarygodny, czy bot naprawdę się adaptuje i czy cały proces da się powtórzyć następnego dnia bez odbudowy środowiska.
Co było dalej
7 czerwca ambicja rosła szybciej niż dojrzałość techniczna. Pojawił się pomysł zbudowania najlepszego tradera na świecie, pytania o to, kiedy bot stanie się ekspertem oraz czy powinien analizować wydarzenia na świecie, skoro wpływają na kryptowaluty.
Różnica między ambicją a aktualną implementacją miała stać się ważną częścią tej historii.
AUR pozostaje projektem badawczym. Wpisy historyczne dokumentują jego rozwój; nie są poradą inwestycyjną ani obietnicą zysków.