When the Self-Learning Trading Bot Idea Became Concrete

The idea moved from coding to trading

The conversation began by asking what to call someone who specialises in long and short crypto trading. A minute later, an IT and programming specialist was added to the imagined AI team.

That combination is important. The problem was no longer just how to write Python. The project was starting to combine market knowledge with software building and to treat AI as a group of specialised helpers rather than one generic assistant.

The first explicit plan

At 21:41 the core idea became clear. Build a machine or program that watches the cryptocurrency market, analyses what is happening and spends a period learning before it is allowed to trade.

The early plan imagined roughly a month of observation. It also included both long and short positions. The ambition was already larger than a simple buy or sell signal in a spreadsheet. The software was supposed to watch, learn and eventually make decisions.

At this stage, however, the word "learn" was still vague. There was no mature definition of a model, training protocol or evidence standard. It was an aspiration, not a proven learning system.

Do not start with real money

A few minutes later, the plan gained a useful safety layer. First came learning. Then demo or paper trading. Real money was supposed to appear only if the simulated phase looked profitable, and even then the amount would be very small.

That sequence did not solve the scientific problems of trading research. A profitable paper test is not proof that a strategy will survive live markets. But historically it shows that the project was not designed around immediately giving an unfinished bot access to meaningful capital.

The rough pipeline was simple:

Observe first. Test without money. Use only a tiny real amount if the earlier stage looks convincing.

An early sign of another problem: continuity

Later that evening, there was a request for a recovery prompt in case the conversation was lost. It sounds like a small detail, but it became a recurring problem in the project.

If AI is helping to build a large system over many sessions, losing context can be almost as damaging as losing code. Long before AUR had formal state files, handoffs and research locks, there was already a need to preserve enough context to continue the work.

This was still a naive version of the idea

The June 5 plan had a strong assumption hidden inside it: let the bot watch the market for a while and it will learn enough to trade. The following weeks would show how much was missing from that sentence.

Data collection had to work. Backtests had to be trustworthy. Libraries had to install correctly. Exchange APIs had to behave as expected. A system also needed a clear way to distinguish genuine learning from code that merely calculated indicators and produced decisions.

Those problems started almost immediately.

What came next

On June 6, the project moved into implementation. Early Python and exchange code appeared, historical data became part of the plan, questions started about whether the bot was actually learning, and backtesting produced the first painful environment and dependency problems.

The important change on June 5 was simpler: the destination finally existed. Build a crypto trading bot that observes first, tests before risking money and eventually makes long and short decisions. Everything after that would be an attempt to discover whether the idea could survive contact with reality.