Nota historyczna: ten wpis odtworzono z zachowanego archiwum Gemini. Kluczowa sekwencja pochodzi z jednej rozmowy z 5 czerwca 2025, między 21:36 a 22:35 CEST.
Od programowania do tradingu
Rozmowa zaczęła się od pytania, jak nazywa się specjalista od grania LONG i SHORT na kryptowalutach. Chwilę później do wyobrażonego zespołu AI został dodany specjalista IT i programowania.
To ważny moment. Problemem nie było już tylko napisanie kodu w Pythonie. Projekt zaczął łączyć wiedzę o rynku z budowaniem oprogramowania i traktować AI jak grupę wyspecjalizowanych pomocników, a nie jednego ogólnego asystenta.
Pierwszy konkretny plan
O 21:41 główna idea stała się jasna. Zbudować maszynę lub program, który obserwuje rynek kryptowalut, analizuje to, co się dzieje, i przez pewien czas się uczy, zanim dostanie możliwość handlu.
Wczesny plan zakładał około miesiąca obserwacji. Obejmował zarówno pozycje LONG, jak i SHORT. Ambicja była już większa niż prosty sygnał kup lub sprzedaj w Excelu. Program miał obserwować, uczyć się i później podejmować decyzje.
Słowo „uczyć się” było jednak wtedy bardzo nieprecyzyjne. Nie istniała dojrzała definicja modelu, protokół treningowy ani standard dowodowy. To była ambicja, nie potwierdzony system uczący się.
Nie zaczynać od prawdziwych pieniędzy
Kilka minut później plan dostał ważną warstwę bezpieczeństwa. Najpierw nauka. Potem konto demo lub paper trading. Prawdziwe pieniądze miały pojawić się dopiero wtedy, gdy etap symulowany wyglądałby zyskownie, i nawet wtedy kwota miała być bardzo mała.
Ten schemat nie rozwiązywał problemów naukowych związanych z badaniem strategii tradingowych. Zyskowny test demo nie jest dowodem, że strategia przetrwa na prawdziwym rynku. Historycznie pokazuje jednak, że niedokończony bot nie miał od razu dostać znaczącego kapitału.
Najpierw obserwuj. Potem testuj bez pieniędzy. Dopiero później rozważ bardzo mały krok na żywo.
Wczesny problem z ciągłością projektu
Później tego samego wieczoru pojawiła się prośba o prompt ratunkowy na wypadek utraty rozmowy. To brzmi jak drobiazg, ale później stało się jednym z powracających problemów projektu.
Jeżeli AI pomaga budować duży system przez wiele sesji, utrata kontekstu może być prawie tak samo szkodliwa jak utrata kodu. Na długo przed formalnymi plikami stanu, handoffami i blokadami badawczymi AUR pojawiła się potrzeba zachowania kontekstu potrzebnego do dalszej pracy.
To nadal była naiwna wersja pomysłu
Plan z 5 czerwca miał w środku mocne założenie: bot poobserwuje rynek przez jakiś czas i nauczy się wystarczająco dużo, żeby handlować. Kolejne tygodnie pokazały, ile brakowało w tym jednym zdaniu.
Trzeba było poprawnie zbierać dane. Backtesty musiały być wiarygodne. Biblioteki musiały działać. API giełd musiały zachowywać się zgodnie z oczekiwaniami. Potrzebny był też sposób na odróżnienie prawdziwego uczenia od kodu, który tylko liczy wskaźniki i generuje decyzje.
Co było dalej
6 czerwca projekt przeszedł do implementacji. Pojawił się pierwszy kod Python i kod związany z giełdą, dane historyczne, pytania o to, czy bot rzeczywiście się uczy, oraz pierwsze bolesne problemy z backtestingiem, środowiskiem i zależnościami.
Zmiana z 5 czerwca była prostsza: po raz pierwszy istniał konkretny cel. Zbudować bota do kryptowalut, który najpierw obserwuje, testuje bez ryzykowania pieniędzy i docelowo podejmuje decyzje LONG i SHORT. Wszystko później było próbą sprawdzenia, czy ten pomysł wytrzyma kontakt z rzeczywistością.
AUR pozostaje projektem badawczym. Wpisy historyczne dokumentują jego rozwój; nie są poradą inwestycyjną ani obietnicą zysku.