Kiedy bot dostał doktrynę kodowania

Najpierw doktryna, potem kolejny kod

Tuż po północy 16 czerwca projekt poprosił o doktrynę "vibe coding" dla oprogramowania bota. Pytanie nie dotyczyło już tylko tego, jaką strategię dodać. Chodziło o to, jak nie dopuścić, żeby projekt zamienił się w stos kruchego kodu.

Powstała filozofia kodowania dla projektu, a zaraz potem praktyczne wymaganie: zbudować modułowy szkielet w Pythonie z logowaniem, konfiguracją, obsługą błędów oraz wyraźnym rozdzieleniem środowiska testowego od działania na żywo.

Podzielić system na części

Kilka minut później architektura była już opisywana jako osobne moduły. Strategia miała mieć własne miejsce. Backtesting miał być oddzielny. Wykonywanie transakcji również.

W dojrzałym oprogramowaniu brzmi to zwyczajnie. Dla tego projektu była to istotna zmiana. Wcześniej najważniejsze było często uruchomienie kolejnego skryptu. Teraz pojawiło się pytanie, czy cały system da się zrozumieć, testować i naprawiać.

Po co była modułowość

Bot tradingowy wykonuje kilka bardzo różnych zadań. Czyta dane, podejmuje decyzje, testuje pomysły, zapisuje przebieg działania i ostatecznie wykonuje zlecenia. Jeśli wszystko jest wymieszane w jednym skrypcie, każda zmiana może popsuć coś zupełnie innego.

Pomysł z 16 czerwca był prosty: każda odpowiedzialność powinna mieć swoje miejsce. Konfiguracja nie powinna być rozsiana po kodzie. Błędy powinny być widoczne. Logi powinny tłumaczyć, co się wydarzyło. Testów nie wolno mieszać z pracą na żywo.

To nadal była wczesna inżynieria

Nic z tego nie oznaczało, że bot nagle stał się niezawodny. Następny zachowany etap pokazuje coś przeciwnego. Nadal pojawiały się błędy składni, brakujące biblioteki i problemy z konektorami.

Ten dzień jest jednak ważny historycznie, bo projekt zaczął przechodzić od "AI potrafi wygenerować kod" do "potrzebujemy architektury, która przetrwa zmiany". To zupełnie inny problem.