Сопроводительное письмо

Строю production-системы в паре с coding-агентами: Factory Droid, Claude Code, Codex. Не как эксперименты, а с PR-процессом, обязательными quality-гейтами и деплоем на свой сервер. Отвечу прямо на вопрос из вакансии: обычно я веду 5–7 параллельных сессий агентов в рабочий день. При кратковременном пике число бывает выше, но качество держится не количеством окон, а механикой: одна задача — одна git-ветвь — один PR, приоритет проставлен явно (P0–P3), перед merge обязательны lint, test и build.

Моя роль в этой работе — AI-инженер и технический архитектор. Я задаю структуру системы, контракты между слоями, ограничения и критерии приёмки, а coding-агенты ускоряют реализацию. В спорных решениях беру второе мнение у другого агента или модели, иногда прямо сталкиваю их между собой и выбираю сам. Ответственность за архитектуру, безопасность, тесты и итоговый merge — на мне.

Я сейчас в Санкт-Петербурге, готов к работе в офисе 5/2 и к постоянному переезду. Могу приехать на встречу с ноутбуком и показать рабочий процесс живьём, а не на слайдах.

За последний год более 2 190 контрибуций на GitHub с учётом приватных репозиториев. Точную цифру не привожу текстом намеренно: она растёт каждый день, её видно прямо на github.com/xodapi без авторизации, а на странице резюме счётчик подтягивает её автоматически раз в час. 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 — понять спрос, собрать контент, вывести его в канал, посчитать выручку. Тогда каждый шаг делался руками и наёмными людьми, поэтому я вижу, где у вашего пользователя настоящая экономия, а где косметика. Второе: я знаю, где кончается допустимая автоматизация и начинается то, за что платформу выкидывают из выдачи и из рекламных кабинетов. Массовая генерация контента — ровно тот инструмент, и границу здесь пересматривают каждый год. Я проходил этот сдвиг с той стороны, где считают убытки, и учитываю его в проектировании.

1. Нестрогий режим по умолчанию. Сейчас лишние поля молча отбрасываются, и image_input для видео даёт чистый text-to-video со списанием. Ваша же документация называет это самой частой ошибкой агентов. Один флаг по умолчанию убирает целый класс жалоб «списали за не то».
2. Полиморфизм медиа-полей. Одна сущность «исходный кадр» приходит как image_urls, first_frame_url, reference_image_urls, image_url, character_image_url. Я бы нормализовал вход единым inputs с ролями, оставив текущие поля алиасами.
3. Нет OpenAPI и sandbox. Из /capabilities уже можно собрать JSON Schema и генерировать SDK. Без sandbox интеграционные тесты платные, а значит их не пишут.
4. Inbox-контур — задокументированный класс риска. Недоверенное сообщение из Bitrix24 вместе с вложениями попадает в контекст модели, у которой есть исполняемые crm.* действия. Платформенный авто-ответчик генерирует actions сам, если агент не забрал сообщение за ~4 секунды. Whitelist ограничивает набор методов, но не содержание: crm.deal.update внутри разрешённого набора позволяет менять суммы и контакты. Это indirect prompt injection (Greshake et al., 2023, Black Hat USA) + excessive agency (OWASP LLM01 и LLM06, Top 10 for LLM Applications 2025). Автоматическая эксплуатация продемонстрирована на production Bing GPT-4 Chat и подтверждена эмпирически (Hofer et al., 2026). Здесь важная деталь, которую я нашёл, перечитывая продуктовые страницы: нужный вам механизм уже существует. У ИИ-бухгалтера заявлено «уровень автономии L2 по умолчанию: рутина сама, любая финансовая операция — после подтверждения в Telegram», а в описании ИИ-отдела автономность формализована как шкала L0–L3. То есть гейт «действие ждёт человека» спроектирован, обкатан и продаётся как преимущество. Вопрос сузился до покрытия: распространяется ли он на мутирующие crm.* в Inbox и на ключи сторонних агентов, которые пишут интеграцию сами на Agent API. Моё предложение — вынести уровень автономии в контракт API (поле у ключа, ответ pending_actions вместо немедленного исполнения, эндпоинт с исходом), чтобы у ваших агентов и у чужих на том же API был один уровень безопасности. Полная защита может быть недостижима (Abdelnabi, 2026), но изоляция агентов + human approval для мутирующих CRM операций снижает риск до приемлемого уровня.