Автор честно меняет подход: от идеи «сделать и синхронно, и асинхронно» — к async-only, с поломкой обратной со

Автор честно меняет подход: от идеи «сделать и синхронно, и асинхронно» — к async-only, с поломкой обратной совместимости.

Что произошло:
- первый вариант на гринлетах уже был близок к рабочему;
- но он добавлял лишнюю сложность;
- дублировал тест-матрицу: нужно было поддерживать сразу два мира — sync и async.

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

Новый ход радикальнее:
- переписать часть функций с `def` на `async def`;
- на вызовах добавить `await`;
- сознательно отказаться от старого API.

Это не про «асинхронность ради асинхронности» и не про обещание чудесного прироста скорости. Скорее, про исследовательский эксперимент: взять большой кодовую базу как полигон для агентного программирования и посмотреть, как далеко можно уехать с автоматизацией изменений 🤖

Для product-команд здесь знакомый паттерн: иногда самый дорогой вариант — не сломать старое, а долго тащить два сценария сразу.