*Технический разбор процесса разработки торговой платформы с использованием Gemini, Claude и ChatGPT. С настоящими постановками задач, архитектурными проблемами и выводами.* Всем привет! Меня зовут Артём, и последние 6 месяцев я создавал полноценную веб-платформу для алготрейдинга. Около 95% кода было сгенерировано c использованием современных LLM, большая часть с помощью **Gemini 2.5 Pro**, ручные правки составили менее 5%.

Речь о проекте **Depth Sight**. Это платформа с гибким визуальным конструктором торговых стратегий, бэктестингом, реальной/бумажной торговлей, мобильной pwa версией и нативно встроенным Ai-ассистентом для помощи в создании и объяснении торговых стратегий, а также анализа результатов бэктестов. Эта статья не столько об алготрейдинге, сколько о новом подходе к созданию сложных программных продуктов. Это кейс о том, как человек с видением продукта может в одиночку создать платформу промышленного уровня. Или нет? Предлагаю разобраться вместе. **Важное уточнение:** У меня нет опыта в коммерческой разработке, нет профильного образования, я никогда не работал в IT-команде, не поддерживал production-системы и не сталкивался с enterprise-процессами. Мой предыдущий опыт ограничивался хобби-проектами (давно изучал PHP и Python) и одним небольшим скринером, который стал прототипом для части этого проекта, он тоже был написан с помощью LLM. Именно Большие Языковые Модели позволили мне масштабировать мои базовые знания до создания полноценной платформы, что было бы невозможно в классическом подходе. Весь код сгенерирован в основном **Gemini 2.5 Pro**, немного **Claude Sonnet** и **ChatGPT** на основе моих ТЗ, как развернутых так и не очень. Данная статья и продукт — живой эксперимент и попытка исследовать для себя границы возможного в этой новой реальности, в которой мы все оказались. Отсутствие коммерческого опыта — это и слабость, и сила. Слабость, потому что я, вероятно, много раз наступал на грабли и изобретал велосипеды, а сила, потому что это позволило мне относиться непредвзято и открыто к предложениям ИИ. ## Метрики проекта * **Время разработки:** ~6 месяцев * **Итераций с ИИ:** ~1500+ диалогов * **Строк кода:** ~220,000 (*Сразу оговорюсь: я не считаю LOC метрикой продуктивности. Это скорее показатель масштаба проекта. Эта цифра включает в себя модели данных, API-эндпоинты, компоненты UI, который ИИ генерирует невероятно быстро, тесты. Не включает зависимости.*)  * **Количество файлов:** 540+ * **Тесты:** 400+ * **Стоимость разработки:** 0$ (*В эту цифру не включено полгода моей жизни, 90%+ кода было сгенерировано в **aistudio.google.com***) **О метриках:** *Цифры основаны на анализе кодовой базы и небольшом личном опыте. Это не научное исследование, а субъективная оценка одного «разработчика».* ## Почему начался этот эксперимент? Идея родилась из простого желания создать бота-скальпера который бы использовал скальперскую логику при совершении сделок, то есть принимал торговые решения основываясь на стакане и ленте в первую очередь. Проведя небольшое исследование, я обнаружил: на рынке алготрейдинга есть две крайности * **Простые конструкторы (3Commas, Bitsgap):** Доступно, но абсолютно негибко, простые GRID – боты, возможность торговать по индикаторам с **TradingView** * **Профессиональные фреймворки (QuantConnect, Backtrader):** Невероятно мощно, но требуют серьезных навыков программирования. Ничто из этого мне не подходило. Я искал инструмент с гибкостью фреймворка (**QuantConnect**), но с простотой конструктора (**3Commas**). Не найдя его, я решил создать его сам и когда появились LLM с миллионным контекстным окном (Привет, Gemini), я решил проверить это на практике. Так родился **DepthSight**. ## Феномен "бесконечного потока": интенсивность не равна выгоранию Прежде чем перейти к техническим деталям, хочу поделиться наблюдением, которое может показаться для кого-то контринтуитивным, а для кого-то банальным. Тем не менее без этого факта статья будет неполной. За 6 месяцев разработки я работал в среднем по 10-12 часов в день, иногда больше, чаще всего без выходных. И я не выгорел. Более того, каждое утро я просыпался с желанием продолжать. **В чем отличие от классической разработки?** В классическом подходе большая часть времени уходит на: - Поиск синтаксических ошибок - Изучение документации - Отладку странного поведения С AI основное время тратится на архитектурные решения, а не на борьбу с синтаксисом. Это как пересесть с «механики» на «автомат». **Результат:** Большой проект за 6 месяцев. Я не "вкалывал", я просто вел диалог с машиной и каждые 15 минут видел прогресс — это фундаментально изменило мое представление о разработке. **Важное уточнение:** Этот "поток", разумеется, был возможен, потому что это мой собственный проект. Я не сталкивался с легаси-кодом и не согласовывал каждое решение с командой. ## Стек и архитектура: от «посоветуй стек» до production-ready системы Мой первый запрос к ИИ был довольно наивным: > Тебе знаком скальпинг? Какие правила из скальпинга можно адаптировать под торгового бота? После нескольких часов обсуждения моих идей и наблюдений за рынком, мы с ИИ (в тот момент это был **ChatGPT**) итеративно пришли к следующему плану, который я для себя зафиксировал в таком виде: > **1. Цели и принципы модуля** > * **Стиль:** скальпинг — быстрые сделки с малыми R : R > * **Интеграция:** использует данные (список монет, свечи, объёмы, натр) из основного приложения, не дублируя логику сбора > * **Торговля:** исключительно через Binance (ccxt или ccxt.pro) > * **Включаемый/выключаемый:** плагин можно запускать и останавливать без перекомпиляции или перезапуска всего приложения > * **Самообучение:** лёгкая ежедневная корректировка ключевых параметров на основании истории сделок > > **2. Взаимодействие с основным приложением** > 1. **Источник данных** > * Основное приложение каждую секунду/минуту обновляет JSON-файл или публикует через локальный WebSocket список перспективных монет (filtered_pairs.json), где, например, natr > 2. > 2. **Консумер-бот** > * Модуль-бот подписывается на эти обновления и хранит в памяти актуальный пул пар для торговли. > 3. **Единый конфиг** > * Все ключевые параметры (фильтры, risk-менеджмент, таймауты) хранятся в config/bot_config.py и при старте бота подтягиваются из общего конфига. > > **3. Архитектура модуля-бота** > ``` > /myapp > /bot_module > __init__.py > config.py > data_consumer.py > strategy.py > executor.py > risk_manager.py > trainer.py > controller.py > logger.py > /data> filtered_pairs.json > main.py > ``` > * **3.1. data_consumer.py** > * Читает filtered_pairs.json — текущий пул монет > * Подписка на WebSocket или периодический polling > * Выдаёт актуальный список в controller > * **3.2. strategy.py** > * Содержит все детекторы скальп-сценариев: > * пробой на объёме (>150% среднего) > * отскок/фейковый вынос от плотности в стакане > * spike-and-fade > * первые 1–2 отката в тренде > * Принимает на вход статус рынка (тренд/флет по ATR+SMA) из controller > * На выходе выдаёт сигнал: (pair, direction, entry_price, stop, take, mode) > * **3.3. executor.py** > * Интерфейс к Binance API (REST или WS через ccxt) > * Методы: open_order(), close_order(), get_positions(), cancel_open_orders() > * Оборачивает ошибки, логирует исполнение > * **3.4. risk_manager.py** > * Рассчитывает размер позиции: lot = risk_pct * balance / (stop_pips * pip_value) > * Контролирует max_daily_drawdown и max_consecutive_losses > * Перед каждой сделкой проверяет, что общие риски не превышены > * **3.5. trainer.py** > * Ежедневно (по расписанию) собирает логи сделок и рыночные признаки > * Считает метрики по каждому сценарию: PF, win-rate, avg R:R, drawdown > * Запускает лёгкую оптимизацию (Grid/Bayes) ключевых параметров (ATR множитель, объёмный порог, размеры стоп-лоссов) на последних 30 днях > * Если новая конфигурация «чётко лучше» (PF↑ > threshold), пушит обновление в config.py > * **3.6. controller.py** > * Оркестратор: > 1. Получает пул пар из data_consumer > 2. Для каждой пары запрашивает показы рынка у strategy > 3. Если есть сигнал — передаёт его в risk_manager → executor > 4. Логирует результат в logger > * Содержит основной цикл (asyncio или поток) > * **3.7. logger.py** > * Хранит в БД или CSV подробный журнал всех сделок, сигналов и рыночных условий > * Дает данные в trainer.py для обучения > > **4. Data-flow и последовательность** > 1. Основное приложение → обновляет /data/filtered_pairs.json > 2. data_consumer → сигнал о новых парах (add/remove) > 3. controller → запрашивает у strategy сигналы по каждой паре > 4. strategy → проверяет условия, отдаёт Signal или None > 5. controller → обращается в risk_manager за размером и проверкой рисков > 6. risk_manager → возвращает Approved/Denied > 7. controller → при Approved даёт команду executor на ордер > 8. executor → выставляет ордер, отслеживает исполнение, обновлённый статус возвращается в controller > 9. controller → логгирует сделку через logger > 10. По расписанию trainer → собирает логи, оптимизирует параметры, правит config.py > | Этап | Описание | Срок | | :--- | :--- | :--- | | **MVP** | data_consumer + strategy(probe) + executor(basic) + risk_manager(simple) + logger | 2 недели | | **v1.0** | все скальп-сценарии, on-break/pre-break режимы, фильтр новостей | +3 недели | | **v1.1** | подключение trainer (batch learning), обновление конфига в runtime | +2 недели | | **v2.0** | UI/CLI для старта/стопа/конфига, Telegram-уведомления | +1 месяц | | **v3.0** | мониторинг через дашборд, A/B-тесты разных стратегий, контейнеризация (Docker) | +1 месяц | > > **6. Итог** > * Плагин-модуль легко стартует и останавливается внутри приложения > * Максимум кода переиспользует существующий data-pipeline > * Развитие от MVP (чёткая базовая логика) к продвинутому самообучению и мониторингу > * Гибкость: можно добавить дополнительные стратегии, подключить другие биржи или развернуть отдельный сервис в будущем > > Этот план даёт чёткую дорожную карту: от прототипа до промышленного решения, минимизируя повторную работу и сохраняя единую архитектуру с основным приложением. Удачи в воплощении! Позже эта архитектура и легла в основу платформы. Стоит отметить также, что на тот момент у меня уже была попытка разработать относительно небольшой проект. Это был скальперский скринер который следит за волатильностью и крупными плотностями по всему крипторынку на 7 биржах. По сей день он является частью логики торгового модуля и поставщиком данных. ### Реальный стек «под капотом» Простой веб-стек не справился бы с нагрузкой. По мере разработки, по совету ИИ, система обросла более серьезными инструментами: * **`Numba`:** Для ускорения критически важных расчетов в Python, особенно в ядре контроллера. * **`River`:** Библиотека для онлайн-машинного обучения. * **`LightGBM / XGBoost`:** Применяются для пакетного офлайн-обучения моделей. * **`DEAP`:** Фреймворк для генетических алгоритмов. Лежит в основе будущей фичи по эволюционному поиску прибыльных стратегий. * **`Pandas-ta`:** Рабочая лошадка для расчета десятков технических индикаторов. ## Процесс разработки: реальные проблемы и постановки задач Я выступал в роли менеджера проекта, а ИИ — в роли команды разработки. Иногда я давал ему четкие ТЗ, но часто решения, порой гениальные, рождались в процессе обычного диалога. Я просто спрашивал, какие есть варианты реализации определенной фичи, и ИИ предлагал несколько вариантов, из которых я дальше уже мог выбирать, на мой взгляд, лучшее. ## Глубокое погружение: Создание `Executor`'а — сердца торгового бота Архитектура, предложенная ИИ, была логичной. Но дьявол, как всегда, в деталях. Самым сложным и критически важным компонентом в самом начале разработки стал `executor.py` — модуль, отвечающий за прямое взаимодействие с API биржи. Здесь не было права на ошибку, ведь он управляет реальными ордерами. Я решил отказаться от готовых библиотек типа `ccxt` в пользу прямой реализации на `aiohttp` и `websockets`. Почему? В предыдущем проекте (скринере) я использовал `ccxt` и, несмотря на все удобство, столкнулся с его ограничениями в скорости и надежности для задач, требующих минимальных задержек, как скальпинг, поэтому осознанно было принято решение писать прямую реализацию. Это позволило добиться нужной производительности и отказоустойчивости. Моя первая постановка задачи для ИИ была сфокусирована на создании полностью асинхронного класса `BinanceExecutor`, которому предстояло использовать `aiohttp` для отправки ордеров (POST `/api/v3/order`) и `websockets` для подключения к `User Data Stream`. ### Итерация №1: Наивный клиент Первая версия, сгенерированная ИИ, была простой и функциональной. Она умела подписывать `REST-запросы` и отправлять ордера. ```python # Первая версия: отправка ордера async def place_order(self, symbol: str, side: str, quantity: float): endpoint = "/api/v3/order" params = { 'symbol': symbol, 'side': side.upper(), 'type': 'MARKET', 'quantity': quantity, } # (Логика подписи запроса) async with self.session.post(self.base_url + endpoint, params=params) as response: return await response.json() ``` Проблема стала очевидна сразу: отправив ордер, мы ничего не знаем о его судьбе. Исполнился ли он? По какой цене? Делать REST-запросы каждую секунду для проверки статуса (`GET /api/v3/order`) — это медленно, неэффективно и быстро исчерпывает лимиты API. Для скальпинга такой подход неприемлем. ### Итерация №2: Добавляем WebSocket. Решение — `User Data Stream`. Это персональный WebSocket-канал, куда биржа в реальном времени присылает все, что происходит с вашим аккаунтом: исполнение ордеров, изменение баланса и т.д. Соответственно, я уточнил задачу для ИИ: необходимо было добавить в `BinanceExecutor` метод `start_user_data_stream`. Этот метод должен был получить `listenKey` через REST, подключиться к WebSocket-каналу биржи и в цикле выводить все входящие сообщения. ИИ сгенерировал рабочий код, но после нескольких минут тестов соединение обрывалось. **Проблема №1: Разрыв соединения.** Сеть нестабильна. Без автоматического переподключения система нежизнеспособна. **Проблема №2: Истечение `listenKey`.** Ключ для подключения к `userData` stream живет всего 60 минут и его нужно периодически продлевать. ### Итерация №3: Переподключение и Keep-Alive Пришлось снова обратиться к ИИ, описав проблемы и **сформулировав детальные технические требования к надежности. Ключевые пункты моей новой задачи были следующими:** * **Модифицировать `start_user_data_stream`** так, чтобы основной цикл прослушивания сообщений был обернут в `while True` для автоматического переподключения при любом разрыве. * **Добавить экспоненциальную задержку** между попытками переподключения (5с, 7.5с, 11с...). * **Создать отдельную фоновую задачу** (`asyncio.Task`), которая каждые 30 минут будет отправлять PUT-запрос на `/api/v3/userDataStream` для продления жизни `listenKey`. Это привело к созданию гораздо более сложной, но надежной архитектуры внутри `Executor`. ### Кейс: Специфичная ошибка окружения (битва с `aiodns` в Windows) Когда базовая логика была готова, я столкнулся с ошибкой, которую не мог решить несколько итераций. При запуске бота на Windows он падал с ошибкой: ``` RuntimeError: aiodns needs a SelectorEventLoop on Windows. ``` Я скормил ИИ полный трейсбек и спросил, в чем дело. Первые несколько ответов были общими: «попробуйте обновить библиотеки», «установите другую политику asyncio». Это не помогало. Прорыв случился, когда я сформулировал для ИИ более конкретную роль и задачу. Я попросил его выступить в роли senior Python-разработчика с опытом отладки `asyncio` на Windows и поставил узкоспециализированный вопрос: как заставить `aiohttp` **не использовать `aiodns`**, а переключиться на свой стандартный потоковый DNS-резолвер, не меняя при этом глобальную политику `asyncio` для всего приложения? **Ответ был мгновенным и точным:** > «Проблема в том, что `aiohttp` автоматически использует `aiodns`, если он установлен. Чтобы принудительно использовать другой резолвер, создайте `TCPConnector` с явно указанным `ThreadedResolver` и передайте его в `aiohttp.ClientSession`.» ```python # Решение проблемы с aiodns from aiohttp import ThreadedResolver resolver = ThreadedResolver() connector = aiohttp.TCPConnector(resolver=resolver) session = aiohttp.ClientSession(connector=connector) ``` Это сработало. **Урок:** иногда нужно не просто описывать проблему, а спрашивать у ИИ, как достичь конкретного технического результата, направляя его в нужную сторону. ### Финальный код: Собираем все вместе После всех итераций и исправлений, ключевая часть `Executor`, отвечающая за `userData stream`, стала выглядеть так. Этот код —  результат десятков уточнений и исправлений, предложенных ИИ в ответ на мои запросы. ```python # bot_module/executor.py class BinanceExecutor: # Честно говоря, в первой версии я вообще не понимал, # как управлять lifecycle этих задач. Пришлось гуглить и задавать вопросы про asyncio. async def _user_data_ws_listener_loop(self): """ Основной цикл, который получает listenKey, подключается к WS и обеспечивает автоматическое переподключение. """ reconnect_delay = 5 # Начальная задержка перед реконнектом while self._user_data_running: try: # 1. Получаем ключ для подключения listen_key = await self.get_listen_key() if not listen_key: logger.error(f"Failed to get listenKey, retrying in {reconnect_delay}s...") await asyncio.sleep(reconnect_delay) continue ws_url = f"{self.ws_base_url}/ws/{listen_key}" # 2. Устанавливаем WebSocket-соединение async with websockets.connect(ws_url, ping_interval=20, ping_timeout=10) as ws: self._user_data_ws = ws logger.info("User data WebSocket CONNECTED.") reconnect_delay = 5 # Сбрасываем задержку при успехе # 3. Запускаем фоновую задачу для продления ключа keepalive_task = asyncio.create_task(self._user_data_keepalive_loop(listen_key)) # 4. Слушаем входящие сообщения async for message in ws: if not self._user_data_running: break try: data = json.loads(message) # Вызываем callback, переданный из Controller'а await self._user_data_callback(data) except json.JSONDecodeError: logger.warning(f"Received non-JSON user data: {message[:200]}") # Отменяем задачу keep-alive, если вышли из цикла keepalive_task.cancel() except (ConnectionClosed, asyncio.TimeoutError, WebSocketException) as e: logger.warning(f"User data WS connection error: {e}. Reconnecting in {reconnect_delay}s...") except Exception as e: logger.error(f"Unexpected error in WS listener loop: {e}", exc_info=True) finally: self._user_data_ws = None if self._user_data_running: await asyncio.sleep(reconnect_delay) reconnect_delay = min(reconnect_delay * 1.5, 60) # Экспоненциальная задержка до 1 минуты async def _user_data_keepalive_loop(self, listen_key: str): """В фоне каждые 30-50 минут продлевает жизнь listenKey.""" while self._user_data_running: await asyncio.sleep(config.USER_DATA_PING_INTERVAL) # Ждем 30-50 минут if not self._user_data_running: break logger.info(f"Attempting to keep-alive listenKey...") await self.keep_alive_listen_key(listen_key) ``` ### Выводы по разработке `Executor`'а 1) **Надежность превыше всего:** Для торгового робота недостаточно, чтобы код просто "работал", он должен быть устойчив к сбоям сети, ошибкам API и проблемам окружения. 2) **Асинхронность не магия:** Управление несколькими фоновыми задачами (`слушатель`, `keep-alive`) требует четкого понимания `asyncio.Task` и их жизненного цикла. 3) **ИИ мощный отладчик:** При правильной постановке вопроса ИИ способен находить причину сложных и специфичных для окружения ошибок, экономя дни работы. Разработка этого компонента стала самым сложным, но и самым важным этапом создания торгового модуля в первый день. Именно здесь закладывался фундамент для стабильной и быстрой работы всего бота, позже большая часть кода была не раз переписана. ### Проблема №2: Генерация ядра векторного бэктестера Для реализации генетического алгоритма поиска стратегий нужно было решить проблему производительности, если запускать тысячи полноценных бэктестов, то я даже не представляю сколько времени уйдет на это. Тогда я попросил сделать быстрый бэктестер на Pandas, ИИ выдал не очень эффективный код с циклами `.iterrows()`. Я уточнил задачу, сформулировав более четкие требования к ядру векторного бэктестера, подчеркнув необходимость избегать циклов в пользу векторизованных операций Pandas и NumPy. **Мое техническое задание выглядело так:** 1. Сгенерировать Python-класс, который принимает на вход DataFrame с колонками OHLCV и двумя boolean-колонками: 'enter_long' и 'exit_long'. 2. Реализовать метод `run()` для симуляции сделок. 3. Определять точки входа, когда 'enter_long' становится True, а позиция была закрыта. 4. Для каждой сделки рассчитывать фиксированные SL и TP в % от цены входа. 5. Векторизованно находить, какая из целей (SL или TP) была достигнута первой на последующих свечах. 6. Собирать лог сделок (вход, выход, цена, pnl) и возвращать итоговые KPI. 7. Использовать `np.where`, `.shift()`, `.cumsum()` и другие векторизованные методы. После нескольких итераций я получил рабочее и быстрое ядро для первичной оценки генетических стратегий. Этот модуль еще требует доработки и тестирования, но первые результаты показывают ускорение в ~100 раз по сравнению с обычным бэктестером. Это лишь пара примеров из тысяч диалогов, которые привели к созданию DepthSight, платформы, которой иначе бы не существовало. Возможно AI пишет не идеальный код, но ведь и многие люди тоже. В любом случае будущее уже наступило. То, что вчера было невозможно, — сегодня стало реальностью. ## Итог: Платформа, где ИИ не только инструмент разработки, а главный продукт Этот процесс привел к созданию продукта, где AI непосредственно участвует в создании и тестировании стратегий. ### 1. AI-Ассистент: От трейдерского жаргона до рабочего алгоритма Главная фича — парсинг сложных торговых идей, описанных на естественном языке, прямо в готовые блоки визуального редактора. Трейдер может описать свою систему так, как писал бы в блокноте. Вот реальный пример такого текстового описания, которое AI-ассистент принимает на вход: > ТВХ: > Набором, с добавлениями тремя-пятью частями. > 1) Первые части - вариативно: >а) Первая часть в минутной/пятиминутной проторговке перед часовым или дневным максимумом, в пробой локальной проторговки, если в момент локального пробоя появляется активность в ленте; >б) Первая часть в середине проторговки при наличии плотности/появления плотности на споте и фьючерсе; >в) Первая часть от нижней границы проторговки. При наличии тренда и плотностей/завалов плотностей ниже. >2) Вторая-четвёртая часть в промежуточный каскадный максимум (часовой/дневной) >3) Третья-пятая часть в крайний максимум формации, в момент пробоя. > >ТП: >1) Движение после пробоя (частичная фиксация 3-10 частями). Суть стратегии не локальный пробой, а пробой крайнего максимума. >2) Фиксирую от 3R|5R >3) 1/5|2/10 остаются до БУ или на выход выше первого импульса > >СЛ: >1) На 1/3 за лой локальной проторговки ( до 1% в движении цены), 0.33%-0.5% от общего депозита. Есть вероятность пробоя, нужно пробовать входить. >2) На 2/3 стоп в БУ|-0.5% от депозита. Вероятность пробоя увеличилась >3) На 3/3 стоп в БУ|-0.3/-1% от депозита. Вероятность пробоя Вероятность пробоя увеличилась, но стоп после набора 3/3 зависит от того были ли микро-стопы до набора полной позиции. > >ОСНОВАНИЯ: >1) Имеются часовые и/или дневные максимумы >2) Наличие каскадов с 2% шагом >3) Инструмент ликвидный (160млн+) >4) Увеличиваются объёмы или не падают >5) Наличие круглого, как доп. фактор >6) Комбинированный вход с добавлением в каждый максимум >7) Рост ОИ, как доп. фактор >8) Есть стаканные основания (плотность в поддержку) и уровень защищается (небольшие плотности/завалы в сопротивление) >9) Отсутствие прокидов по ленте, которые могут сильно развернуть цену >10) Возможность выставить короткий стоп и не выбиться по АТР в минус или БУ >11) BTC не растет и инструмент не коррелирует с поводырем. Желательно проторговка BTC в боковике или без сильной активности. >12) BTC не начинает сильно падать и не мешает началу пробоя. >13) На истории инструмент хорошо пробивает похожие максимумы AI-ассистент парсит этот текст и за минуту генерирует готовую структуру в визуальном редакторе, которую можно подправить руками и тут же отправить на бэктест.

### 2. Итеративный AI-анализ: Превращаем убытки в данные После каждого бэктеста есть кнопка **«Проанализировать с AI»**. Ассистент получает доступ ко всем сделкам и контексту, включая причины отклонения сигналов, и что немаловажно, комбинации сработавших или нет оснований, благодаря чему помогает найти неочевидные закономерности и давать рекомендации. > **Пример анализа от AI:** > «Я проанализировал твои 58 сделок. 80% убыточных позиций были открыты, когда индекс волатильности BTC был выше 75-го перцентиля. **Рекомендация:** Добавь фильтр, который блокирует входы, если ATR на 5-минутном графике BTC превышает X. Хочешь, я сгенерирую новую версию стратегии с этим фильтром?» ### 3. Взвешенные основания: Код для «трейдерской чуйки» Это наш ответ на бинарную логику «ДА/НЕТ» всех существующих конструкторов. Каждое условие для входа в сделку имеет не только переключатель, но и «вес». * Плотность в стакане? **Вес 30.** * Пробой уровня? **Вес 50.** * Ускорение ленты? **Вес 20.** Вы устанавливаете «порог срабатывания», например, **70**. Сигнал на вход сработает, только если исполнится комбинация условий с суммарным весом >= 70. В нашем случае это `уровень + лента` (70) или `уровень + плотность` (80). Это позволяет формализовать интуицию, когда решение принимается на основе совокупности факторов, а не одного жесткого триггера. Не уверен, существует ли где-либо нечто подобное, учитывая сложность «промпта» в котором учитывается лента, стакан, открытый интерес, корреляция с поводырем, частичные входы и выходы, а также анализ бектестов с ассистентом и взвешенные основания, напишите, пожалуйста, в комментариях. ### Визуализация сложности проекта На определенном этапе я попросил ИИ проанализировать весь код и сгенерировать `GraphML`-файл для визуализации архитектуры. Вот карта проекта.

## Почему для одних ИИ — гений, а у других — идиот? Перед тем как написать эту статью, я много читал обсуждения разработки с ИИ, в том числе на Хабре и заметил странный парадокс. **Одни люди пишут:** > "LLM — это революция. Он сделал то, до чего я бы не додумался." **Другие (часто более опытные разработчики) пишут:** > "Пробовал. Ерунда. Код нерабочий." Это один и тот же инструмент, но результаты диаметрально противоположные. Почему? ### Моя гипотеза: дело не в ИИ, а в ментальной модели Я пришёл к выводу, что эффективность работы с ИИ зависит от одного критического фактора: готовности принять, что ИИ может знать больше меня, что в свою очередь позволяло мне задавать вопросы и искать истину в диалогах. Звучит абсурдно. "Как машина может знать больше сеньёра с 15-летним опытом?" Но факт в том, что ИИ обучен на миллиардах строк кода. Он видел паттерны на всех возможных языках программирования, которые senior-разработчик никогда не использовал. Он знает решения проблем, с которыми сталкивались тысячи других разработчиков. Объективно, статистическая модель знает больше, чем любой человек. ### Две модели взаимодействия **Подход 1: "Делай как я сказал"** Ты говоришь: "Сделай X вот так." AI делает по-другому. Ты думаешь: "Неправильно. Переделывай." Итог: постоянное разочарование. **Подход 2: "А как ты думаешь?"** Ты спрашиваешь: "Как лучше решить X?" AI предлагает незнакомое решение. Ты: "Интересно. Почему так? Объясни." Итог: новое знание + работающий код. **Угадайте, какая модель даёт "гения", а какая — "идиота"?** ### Почему мой ИИ — "гений"? Потому что я принял простую истину: ИИ видел больше кода, чем я увижу за всю жизнь. Да, он может ошибаться. Да, иногда он галлюцинирует. Но когда он предлагает решение, которое мне незнакомо, я не думаю: "Ерунда какая-то.". Я думаю: "Это интересно. Почему именно так? Чему я могу научиться? Какие еще есть варианты?" Это не значит, что я считаю себя глупее. Это значит, что я объективно признаю: база знаний модели шире, чем моя. ### А минусы есть? Конечно, не все было гладко, бывали моменты стойкого ощущения, что ИИ отупел когда он не мог выполнить простейшие на мой взгляд задачи в сравнении с теми которые решал раньше. 1. **Рефакторинг** - иногда проще переписать, особенно для профессионального разработчика, чем объяснять AI что именно не так. 2. **Специфичные баги** - AI отлично решает типичные задачи, но часто буксует столкнувшись с неизвестными. 3. **Технический долг** - да, он быстро накапливается, но так же быстро и решается. Но ни одна из этих проблем не остановила проект. ### Вопрос к читателям Хабра Многие комментарии под постами об ИИ в разработке полны скепсиса: > "Пробовал, ничего путного не вышло." > "Это для простых задач, а реальные проблемы ИИ не решит." Но что если дело не в возможностях ИИ, а в способе взаимодействия? Что если разница между "ИИ — бесполезная игрушка" и "ИИ — революционный инструмент" лежит не в технологии, а в готовности спросить: **"Как бы ТЫ это сделал?"** вместо **"Сделай так, как я сказал."** Я не утверждаю, что познал истину, я лишь пытаюсь разобраться в этом феномене, но я уверен в одном: с точки зрения трейдинга этот проект имеет огромный потенциал, потому что я нигде еще не видел ничего подобного. И я прошу сообщество помочь мне разобраться имеет ли он такой же потенциал с точки зрения разработки. - У меня нет опыта коммерческой разработки - Я создал платформу в 220,000 строк кода - Она работает, решает реальную задачу, хотя и в бете - И я не выгорел в процессе ## Что дальше? Безопасность как приоритет: принципы открытой беты Платформа работает. Но я прекрасно понимаю, что продукт связанный с финансами, требует максимальной надежности. Моя главная задача на текущем этапе — убедиться в стабильности и корректности работы всей системы, не подвергая пользователей риску. Поэтому в текущей открытой бета-версии Live-торговля отключена. По умолчанию доступны такие функции: - 5 бэктестов в день - 5 запросов к АИ-ассистенту в день - 30 дней истории для бэктестинга - 10 монет Я бы с удовольствием сделал лимиты больше, но пока вряд ли потяну. Это позволяет попробовать платформу в деле и даже собрать и протестировать стратегию на исторических данных. Если вы хотите проверить, насколько надёжен AI-generated код — проект в открытом бета-тесте: [depthsight.pro](https://depthsight.pro/). Буду благодарен за любую обратную связь или сообщения о багах и уязвимостях. В ближайших планах — развитие **генетического модуля**, где пользователи смогут «скрещивать» свои стратегии или отдельные их части (например, взять систему входа от одной стратегии, а риск-менеджмент от другой), чтобы эволюционно находить новые, более эффективные комбинации. Доработка оптимизации стратегий, обучения моделей, интеграция коннекторов других бирж помимо **Binance**. ### Вопросы для сообщества 1. **Для разработчиков:** Как ИИ изменил ваш workflow? Какие самые сложные задачи вы ему доверяете? 2. **Для тимлидов:** Готовы ли вы принимать сгенерированный код в production? 3. **Для всех:** А ваш ИИ гений или идиот? Спасибо, что дочитали. Буду рад ответить на любые вопросы в комментариях. **Evolve. Or don't look up.** **P.S.** Следить за развитием проекта можно в [Telegram-канале](https://t.me/depthsight).