ИИ против Open Source: что реально поменялось и где проходит граница

Последние годы у нас был рефлекс: нужна мелочь – ставим библиотеку; нужен каркас – берём шаблон; надо что-то «на лету» – подключаем генератор кода. С появлением рабочих моделей кода появился более приземлённый путь: сформулировать требование, написать тесты и получить небольшой, понятный модуль без лишних зависимостей. Это не война с OSS, а сдвиг точки равновесия: сложное и критичное остаётся за проверенными библиотеками, а утилитарное всё чаще выгоднее сгенерировать под себя. Дальше – что именно поменялось, где ИИ «откусил» повседневные задачи, где границы и какие практики работают. При этом пишу с позиции алготрейдинга – поэтому примеры и формулировки из этой области; но сам подход уже заметно работает почти во всех направлениях разработки.

1) Что именно поменялось (без лозунгов)

Было: ««сначала библиотека»». Ищем библиотеку, принимаем транзитивные зависимости, читаем документацию, живём с чужими багфиксами и семантическими обновлениями.

Становится: «описание → тесты → реализация».

1. Коротко и по‑русски описываем поведение: что подаём на вход, что ждём на выходе, что считаем ошибкой и какие правила всегда должны выполняться.

2. Пишем тесты (unit + edge, по возможности property/fuzz).

3. Просим ИИ реализовать ровно это.

4. Проверяем и публикуем в том процессе, который у вас принят (CI/CD или вручную).

5. Фиксируем происхождение (модель, 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. Не делайте из этого идеологию: выбирайте инструмент под контекст.