Замечание справедливое! В примере мы намеренно изолировали проверку бизнес-правила, чтобы показать, что ИИ может пропустить ошибку на пограничном значении. Для продовой очереди этого, конечно, недостаточно.
При конкурирующем enqueue, впрочем, возникает race condition: оба воркера могут получить корректный результат проверки на устаревшем состоянии. Поэтому проверка лимита и резервирование слотов, как вы и предположили, должны быть атомарными — например, через транзакцию с блокировкой или атомарную операцию в хранилище.
Это уже несколько другой сценарий для конкурентного тестирования: запустить несколько enqueue параллельно и убедиться, что суммарное число зарезервированных слотов не превышает лимит.
И вместе с тем это хороший пример того, почему корректные unit-тесты ещё не гарантируют корректность системы в целом.
Хардкод, конечно, временный костыль, но случается, что затраты времени и ресурсов неразумны для его починки. В целом, в тестировании доминирует эмпирический подход, по нашему опыту.
Прикладываем смешную картинку для иллюстрации) Для контекста: у кого-то годами тянулся вот такой костыль в легаси.
Пока не предусмотрено такой возможности, но мы рассмотрим.
Доброе утро! Можете еще раз попробовать, сервис был временно недоступен этим утром;
Да, смотрим и в эту сторону тоже, теперь еще более активно)
У децентрализованных inference-сетей сейчас действительно интересная экономика, особенно на open-source моделях вроде Qwen. Но пока там хватает проблем со стабильностью, latency и предсказуемостью качества, особенно если говорить не про инди проекты, а про корпоративные сценарии.
Так что для нас это скорее не "или-или", а ещё один слой инфраструктуры, который со временем может стать частью общей маршрутизации.
Ну и да, Qwen сейчас выглядит слишком сильным, чтобы это игнорировать 🙂
Николай, и вам добрый пятничный вечер! Ждали такой комментарий. :D
Давайте разберёмся по пунктам.
По поводу “инновации”: мы не называем инновацией факт пересылки HTTP-запроса от одного API к другому. "то было бы как минимум нечестно — выставлять изобретение велосипеда за своё.
Ключевая часть нашего продукта — это KodikShield, встроенный слой шифрования данных, который позволяет компаниям безопаснее работать с нейросетями и соответствовать регуляторным требованиям. Для корпоративных клиентов это важнее, чем просто доступы ко всем известным моделям.
Если для ваших задач личный VPS достаточен, то это в самом деле можно сделать быстро. В таком сценарии KodikRouter вам, скорее всего, и не нужен.
По поводу блокировок российских IP и платежей: это одна из задач, которую мы берем на себя как сервис. Если провайдер режет российские платежи, IP, аккаунты или отдельные модели, это не должно становиться проблемой клиента. Наша зона ответственности — искать рабочие маршруты, подключать альтернативных провайдеров и сохранять для клиента единый интерфейс доступа.
По комиссии. OpenRouter берет около 5%, при этом работает в другой платежной и юридической среде. У нас 10%, но на нашей стороне комиссии, платежная инфраструктура, риски, поддержка, обслуживание доступа в РФ, интеграции и операционная часть.
В любом случае, рынок растёт, и со временем рассудит тех, кому нужен самостоятельный VPS, и тех, кому нужен готовый управляемый сервис.
Справедливое замечание. Мы тоже видим это на практике.
Проблема тут скорее не в самом ИИ, а в том, как с ним работают. Если просто генерировать код без фиксации контекста, архитектуры и решений — через несколько месяцев это действительно превращается в легаси быстрее обычного.
Поэтому сейчас постепенно вырисовывается другой подход: ИИ хорошо ускоряет создание, но поддержку нужно сразу закладывать — через контекст, правила и процессы. Без этого масштабирование действительно ломается.
Мы пока в переходной фазе: инструменты уже умеют писать код, а вот культура работы с ним только формируется.
Полностью солидарны с вашим наблюдением!
Единственное что отметим: если берёте на себя продолжение чужого проекта, то лучше по первой отслеживать действия агента в ручном режиме. Особенно в масштабных проектах, где контекст 1M+ токенов.) В ином случае агент может заплутать даже в стандартной миграции БД.
Требования к функции заданы перед примером в статье. Заключаются в следующем:
- равенство допустимо;
- общее число задач не должно превышать лимит;
- некорректные входные значения вызывают исключение.
Именно на этом контракте (не на текущей реализации) строятся ожидаемые результаты тестов. В продовом проекте источником таких требований выступает спецификация или согласованная бизнес-логика.