Последние годы у нас был рефлекс: нужна мелочь - ставим библиотеку; нужен каркас - берём шаблон; надо что-то «на лету» - подключаем генератор кода. С появлением рабочих моделей кода появился более приземлённый путь: сформулировать требование, написать тесты и получить небольшой, понятный модуль без лишних зависимостей. Это не война с OSS, а сдвиг точки равновесия: сложное и критичное остаётся за проверенными библиотеками, а утилитарное всё чаще выгоднее сгенерировать под себя. Дальше - что именно поменялось, где ИИ «откусил» повседневные задачи, где границы и какие практики работают. При этом пишу с позиции алготрейдинга - поэтому примеры и формулировки из этой области; но сам подход уже заметно работает почти во всех направлениях разработки.
1) Что именно поменялось (без лозунгов)
Было: ««сначала библиотека»». Ищем библиотеку, принимаем транзитивные зависимости, читаем документацию, живём с чужими багфиксами и семантическими обновлениями.
Становится: «описание → тесты → реализация».
Коротко и по‑русски описываем поведение: что подаём на вход, что ждём на выходе, что считаем ошибкой и какие правила всегда должны выполняться.
Пишем тесты (unit + edge, по возможности property/fuzz).
Просим ИИ реализовать ровно это.
Проверяем и публикуем в том процессе, который у вас принят (CI/CD или вручную).
Фиксируем происхождение (модель, prompt, дата) для воспроизводимости.
Итог - маленькие, проверяемые кирпичики вместо «комбайнов». Но границы важны: криптография, протоколы, кодеки, движки БД, компиляторы, сложные численные солверы - всё это остаётся за зрелыми OSS‑решениями.
2) Где ИИ уже «откусил» у OSS (4 направления)
A. Мини‑реализации вместо утилитарных пакетов
Когда нужна небольшая логика - формула, валидатор, мини‑парсер, простая статистика - ИИ пишет 20–80 строк кода под ваш формат данных и тесты.
Алготрейдинг‑примеры:
Индикаторы: EMA/SMA/WMA, VWAP/TWAP, ATR, RSI, Z‑score.
Потоковая статистика: дисперсия по Вэлфорду, корреляции окон, простые фильтры шума.
Риск‑правила: лимиты по просадке/плечу, аварийная остановка.
Нормализация истории: календарь/таймзона/границы сессий.
Как понять, что это «наш случай»: задача описывается одним абзацем, крайние случаи перечислимы, а готовый пакет ради неё потянет за собой кучу зависимостей.
Что получается на выходе: маленький модуль в пару десятков строк, который вы читаете целиком и легко меняете под себя.
Типичная ошибка: попытка «сгенерировать всё сразу». Лучше брать кусочками: одна формула, один парсер, одно правило - и тут же тесты.
B. Узкие интеграции вместо больших клиентских библиотек
Чаще всего нужны 2-3 операции: «взять стакан», «поставить ордер», «получить сделки». Зачем тащить всю клиентскую библиотеку, типа Lean или StockSharp?
Алго‑примеры:
Небольшой клиент для REST/веб‑сокетов с ровно теми методами, что вы используете.
Парсер «подмножества» форматов поставщиков (строго под ваши поля и правила валидации).
Лёгкие агрегаторы: тики → бары (1 секунда/1 минута), ресемплинг, дедупликация.
Как понять, что это «наш случай»: у вас есть точный список операций и требования к ошибкам/тайм‑аутам; остальной огромный API не нужен.
Что получается на выходе: читаемый класс‑клиент с понятными именами, без лишних переключателей и «магии».
Где не стоит экономить: бинарные протоколы и ультра‑низкая задержка - это зона проверенных реализаций.
C. Генерация скелета и артефактов вместо «кухон»
Каркас модуля, описания данных и простые утилиты проще попросить у модели и закрепить тестами, чем ставить набор генераторов и шаблонов.
Алго‑примеры:
Скелет бэктеста: бары → признаки → сигналы → заявки → доходность.
Схемы данных: Parquet/строки SQL для историй и календарей.
Развёртывание: файл сборки и проверка перед выпуском, описания развертывания для вашего контура.
Секрет успеха: просить не «универсальный фреймворк», а скромный скелет под ваши названия сущностей и формат данных.
D. Адаптеры и миграции вместо «слоёв совместимости»
Вместо толстых прослоек - узкий адаптер или аккуратная миграция кода: маппинг типов ордеров, округления, переход на другой сетевой клиент или журналирование, конвертер форматов истории.
Алго‑примеры:
Адаптер под биржу: время жизни ордера, шаг цены/количества, контроль точности.
Массовая замена вызовов (код‑мод): перенос мини‑стратегии между языками, унификация логирования.
Конверторы истории CSV ↔ Parquet с явной схемой и проверками.
Почему это удобно: адаптер дёшев в поддержке, а границы ответственности ясны.
3) Где ИИ не должен заменять OSS (границы)
Криптография и защищённые протоколы. Тут важны стандарты, аудит и годы эксплуатации.
Бинарные и высокоскоростные протоколы. FIX/ITCH/OUCH/FAST и подобные - это про детерминизм и задержки, а не про «сгенерим на коленке».
Движки баз данных, кодеки, компиляторы, рантаймы. Сложные подсистемы с массой инвариантов, где экономия на качестве бьёт больнее всего.
Численные солверы и оптимизаторы. Нужна устойчивость и предсказуемость на краях.
Смысл границы простой: там, где критично коллективное знание и долгий бой в проде, оставляем зрелые библиотеки.
4) Вопросы по подходу (коротко)
Это не изобретение велосипеда?
Иногда - да. Если готовая библиотека решает задачу полностью и без лишнего - используйте её. Подход не про «всё своё», а про «не тянуть лишнее».
Как не превратиться в «самопис»?
Держите модули маленькими, интерфейсы ясными, поведение - в тестах. Всё остальное вторично.
Сколько проверок достаточно?
Столько, чтобы спокойно принимать изменения. Лучше несколько понятных проверок сегодня, чем «идеальная методология» завтра.
Что с безопасностью и числами?
Проверяйте границы, необычные входы и сериализацию. Не храните секреты в логах. Для чисел - задавайте допустимые погрешности и сравнивайте с эталонными расчётами.
5) Как применять подход на практике
Опишите поведение простыми словами. Что подаём на вход, что хотим получить на выходе, какие правила неизменны.
Сделайте минимум проверок. Ровно настолько, чтобы вы уверенно мерджили правки.
Сгенерируйте небольшой модуль и подключите его. Лучше без внешних зависимостей.
Проверьте ощущение пользы. Стало проще поддерживать? Если нет - вернитесь к библиотеке.
6) Живые примеры (по одному абзацу)
EMA за 10 минут. Нужно добавить EMA(20) и EMA(50) в поток баров. Пишем короткое описание поведения и пару проверок (на ступеньку и постоянный ряд), просим модель - получаем крошечный класс. Он читается целиком, легко меняется и не тянет «зоопарк» зависимостей.
Клиент «три метода». Требуется только стакан, выставление заявки и проверка статуса. Вместо огромной клиентской библиотеки - маленький класс с понятными методами и обработкой ошибок. Его проще тестировать и поддерживать, а обновления документации биржи не ломают пол‑проекта.
Скелет бэктеста. Из истории делаем бары, считаем признаки, формируем сигналы и заявки, считаем доходность. Не просим «идеальный фреймворк», а генерируем скелет под свои имена сущностей. Через день такой каркас уже приносит пользу, а не лежит грузом.
Адаптер под биржу. Разные биржи - разная точность и время жизни ордера. Узкий адаптер прячет эту «кухню», а остальной код остаётся чистым. Меняется специфика - правим один файл, а не весь проект.
7) Антипаттерны (чего избегать)
«Сгенерируй мне всё». Просить универсальный фреймворк - почти всегда мимо. Берите маленькие куски.
Скрытая зависимость. Подтянуть огромную библиотеку ради одной функции - и забыть. Потом это аукнется.
Бесконечная полировка. Лёгкие проверки сегодня лучше, чем идеальная система завтра.
Неоправданный геройство. Там, где важны стандарты и аудит, берите зрелую библиотеку и не спорьте.
Заключение
Если убрать лозунги, ИИ просто сдвинул привычную границу. Там, где раньше мы тянули «на всякий случай» библиотеку, теперь быстрее и безопаснее родить маленький, понятный модуль под свою задачу и свои тесты. Open Source остаётся опорой для всего сложного и критичного — протоколов, криптографии, движков, кодеков, компиляторов. Но пласт утилитарной рутины — формулы, тонкие клиенты, скелеты, адаптеры — уже логичнее закрывать генерацией.
В алготрейдинге это особенно заметно: меньше зависимостей — ниже риски, артефакты компактнее, аудит проще, итерации быстрее. При этом здравый смысл никуда не делся: как только речь заходит о FIX/ITCH/OUCH, о безопасности, о численной устойчивости или «железных» SLA по задержке — возвращаемся к зрелым библиотекам и их экосистеме, или пишем сами без 5-ти минутного ИИ кода.
Практически это сводится к простому правилу: узкая задача, которую легко описать и проверить, — кандидат на генерацию. Всё остальное — в пользу проверенного OSS. Не делайте из этого идеологию: выбирайте инструмент под контекст.
