Historical note: this chapter is based on verified Gemini archive anchors from June 17, 2025. Credentials, private infrastructure and sensitive implementation details are omitted.
The code kept breaking
On the evening of June 17, the main bot stopped on a Python syntax error. Minutes later another problem appeared: a library module expected by the code could not be found.
A new environment did not magically solve it. The expected futures connector still would not load. The project had entered a phase where fixing one problem often revealed the next one.
Generated code is not a working system
This was an important distinction. AI could produce a plausible script in seconds. But a real trading bot also depended on compatible libraries, correct imports, stable connectors, configuration and an environment where all of those pieces agreed with each other.
The difference only became obvious when the code was actually run. A script that looked reasonable in a chat window could fail immediately on a real machine.
Errors became information
Those failures were frustrating, but they were also useful. Each traceback showed another hidden assumption. Each missing dependency showed that the system was more than the code visible on screen.
The practical loop became simple: run the program, read the error, understand what failed, repair one thing, then test again. Reliability was not something AI could declare. It had to be demonstrated by repeated execution.
A harder project than expected
Only a day earlier the project had tried to impose a modular coding doctrine. June 17 showed why that mattered. Without clear modules, logs and controlled dependencies, debugging a growing trading system quickly became chaotic.
This chapter did not produce a breakthrough strategy. It produced something more basic: the realization that building reliable software is a different job from generating code.
AUR is a research project. Historical posts are not investment advice and do not promise future returns.