Деньги защищены до списания
Бесплатный dry-run POST /generate/estimate, strict=true с явным списком rejected, pre-charge валидация всех URL-полей HEAD-запросом до списания, refunded: true при сбое провайдера, атомарный дневной лимит.
Отклик на позицию AI-инженера
Сопроводительное письмо.
Перед откликом я разобрал ваш Agent API и MCP-коннектор по документации, чтобы говорить конкретикой. Ниже — сжатая версия; полный аудит с примерами кода на отдельной странице.
Коротко обо мне
Что я делаю каждый день
Строю production-системы в паре с coding-агентами: Factory Droid, Claude Code, Codex. Не как эксперименты, а с PR-процессом, обязательными quality-гейтами и деплоем на свой сервер. Отвечу прямо на вопрос из вакансии: обычно я веду 5–7 параллельных сессий агентов в рабочий день, на пике до восьми. Держится это на простой механике: одна задача — одна git-ветвь — один PR, приоритет проставлен явно (P0–P3), перед merge обязательны lint, test и build.
Моя роль в этой работе — архитектор. Я задаю структуру системы, контракты между слоями, ограничения и критерии приёмки, а код по постановке пишут агенты. В спорных решениях беру второе мнение у другого агента или модели, иногда прямо сталкиваю их между собой и выбираю сам. Ответственность за архитектуру и за то, что уходит и не уходит в merge, — на мне.
Я сейчас в Санкт-Петербурге, готов к работе в офисе 5/2 и к постоянному переезду. Могу приехать на встречу с ноутбуком и показать рабочий процесс живьём, а не на слайдах.
За последний год 2181 контрибуция на GitHub с учётом приватных репозиториев, 13 активных проектов на TypeScript, Rust и Python. Главный, kognitika.ru, работает в production: 396 коммитов во всех ветвях, 31 параллельная ветвь, 357 проходящих unit-тестов, Playwright e2e, Docker, GitHub Actions, health-check с хешем коммита в ответе.
Про Rust отдельно. Писал на нём утилиты для обработки данных информационных систем РЖД. Сейчас на Rust сделаны движок дискретно-событийного моделирования и инструменты мониторинга агентных сессий. В Kognitika веду миграцию аналитического контура с TypeScript на Rust по схеме shadow → canary → primary с временным fallback, без простоя production.
Про предметную область. 20+ лет в ОАО «РЖД» научили доводить идею до внедрения, а не до демо. Учёт топлива по каждому баку 150 тепловозов вместо единого склада, снижение повторного ввода данных диспетчерской смены на 74%, отчётность, которая ушла в масштаб сети.
Про маркетинг я знаю не по статьям. В 2010–2011 я десять месяцев жил с партнёрских программ Amazon и eBay. Механика была такая: генераторы сайтов, массовая автоматическая сборка тематических страниц под поисковый трафик. Называю прямо — по сегодняшним критериям это поисковый спам, тогда в алгоритмах Google было окно. Доход держался около $6 000 в месяц, я координировал команду контент-менеджеров, админов и программистов и заказывал ПО под автоматизацию всей рутины. Закончилось это фильтрами Google: после Panda трафик обнулился, я выгорел и вернулся в найм.
Привожу этот эпизод не как достижение, а потому что он даёт две вещи, полезные именно вам. Первое: я изнутри знаю петлю, которую сейчас закрывают вайб-маркетологи через ваш API — понять спрос, собрать контент, вывести его в канал, посчитать выручку. Тогда каждый шаг делался руками и наёмными людьми, поэтому я вижу, где у вашего пользователя настоящая экономия, а где косметика. Второе: я знаю, где кончается допустимая автоматизация и начинается то, за что платформу выкидывают из выдачи и из рекламных кабинетов. Массовая генерация контента — ровно тот инструмент, и границу здесь пересматривают каждый год. Я проходил этот сдвиг с той стороны, где считают убытки, и учитываю его в проектировании.
Мнение
Сильно
₽
Сильно
⟳
Сильно
◈
Что я думаю про ваш API
Впечатление хорошее, и особенно ценю то, что у вас закрыт финансовый контур. Это самое частое место, где платные генеративные API текут деньгами.
Идемпотентность сделана правильно
Тот же ключ с тем же телом — replayed: true. Другое тело — 409 idempotency_key_conflict. Параллельный дубль — 409 duplicate_request. Это ровно те три исхода, которые нужны для безопасного retry, и их обычно забывают.
Самоописывающийся каталог
GET /capabilities считаю самым важным эндпоинтом. При темпе примерно одна новая модель в неделю единственный работающий подход — тянуть каталог в рантайме, а не хардкодить. Плюс key_cooling_down как серверный circuit breaker.
Что я бы починил в первую очередь
Четыре пункта по приоритету. По каждому в полном разборе есть пример «как сейчас / как лучше» с кодом.
- Нестрогий режим по умолчанию. Сейчас лишние поля молча отбрасываются, и
image_inputдля видео даёт чистый text-to-video со списанием. Ваша же документация называет это самой частой ошибкой агентов. Один флаг по умолчанию убирает целый класс жалоб «списали за не то». - Полиморфизм медиа-полей. Одна сущность «исходный кадр» приходит как
image_urls,first_frame_url,reference_image_urls,image_url,character_image_url. Я бы нормализовал вход единымinputsс ролями, оставив текущие поля алиасами. - Нет OpenAPI и sandbox. Из
/capabilitiesуже можно собрать JSON Schema и генерировать SDK. Без sandbox интеграционные тесты платные, а значит их не пишут. - Inbox-контур — приоритет для аудита. Недоверенное сообщение из Bitrix24 вместе с вложениями попадает в контекст модели, у которой есть исполняемые
crm.*действия. Платформенный авто-ответчик генерируетactionsсам, если агент не забрал сообщение за ~4 секунды, и отключается только флагомauto_reply: false. Whitelist ограничивает набор методов, но не содержание:crm.deal.updateвнутри разрешённого набора позволяет менять суммы и контакты. Классическая indirect prompt injection с записью в CRM. Я бы сделал дефолт обратным, разделил право «отвечать текстом» и право «выполнять действия», и провёл мутации через подтверждение сотрудника.
Оговорка честности. Всё выше — вывод по публичной документации, без нагрузочного тестирования и без доступа к вашему коду. Часть замечаний может быть уже закрыта в реализации или сознательным продуктовым решением. Готов быстро скорректировать выводы после разговора с командой.
Предложение
Над чем предлагаю поработать в первые недели
Сразу честно о способе работы. Я работаю как архитектор: держу структуру, контракты и критерии приёмки, а код по постановке пишут агенты — Factory Droid, Claude Code, Codex. Спорные решения прогоняю через несколько моделей и выбираю сам. Именно так сделаны все мои проекты, включая production, и эта страница. Поэтому сроки ниже — это план работы с агентами на две-четыре недели, а не обещание «сдам готовое к пятнице». Что гарантирую: понятную постановку, проверяемый результат и то, что мусор не уйдёт в production.
-
Типизированный клиент к вашему API
недели 1–2Обязательный
estimateперед платным вызовом,strictпо умолчанию, идемпотентность на каждый запрос, вебхук плюс страховочный поллер, экспоненциальный backoff с учётомretry_after, единая обработка таксономии ошибок. -
OpenAPI и SDK, сгенерированные из
недели 2–3/capabilitiesКаталог уже машиночитаемый — из него собирается JSON Schema на параметры каждой модели, а из схемы генерируются типы для TS и Python. Новая модель в каталоге — обновлённый SDK без правки руками.
-
Eval-стенд для русского языка
недели 2–4По образцу вашего же замера F0 по голосам. Считаю это вашим сильнейшим неочевидным активом: вы уже измеряете то, что конкуренты берут из чужих маркетинговых страниц. Хочу масштабировать подход на остальные модальности — тогда выбор модели под задачу становится измеримым, а не вкусовым.
-
Аудит Inbox-контура и границ доверия
параллельноРазделение прав «текст» и «действие», инверсия дефолта авто-ответчика, подтверждение мутаций, изоляция недоверенного контента от исполняемых инструментов. Это то, что дешевле починить до инцидента.
Готов к тестовому заданию и к техническому разговору. Код открыт: github.com/xodapi. Инфраструктура, на которой лежит эта страница, тоже моя: syntog.ru, nginx, TLS, деплой через SSH-сессию агента.