AI4SDLC: что покупать, дорабатывать и держать под контролем

Начинать предлагается с трёх решений: что арендовать, что адаптировать и чем владеть. Передовые модели разумно получать у провайдеров, сохраняя возможность пробовать разные варианты под свои задачи. Готовую обвязку агента, которая организует цикл обращений к модели и инструментам, тоже обычно выгоднее взять у существующего продукта или открытого проекта. Собственная реализация такого цикла увлекательна для инженеров, но крупные поставщики совершенствуют её быстрее и получают доступ к будущим моделям раньше заказчика. Стандартные вычислительные мощности относятся к той же категории: обычной компании трудно повторить инфраструктуру большой AI-лаборатории. Так освобождаются силы для работы, которая зависит от конкретной организации. Покупка готовой возможности при этом не отменяет проверки её пригодности: выбор должен учитывать качество решения задач, стоимость и возможность последующей замены.

Дорабатывать приходится маршрутизацию задач, подготовку контекста и адаптеры к внутренним инструментам. Агенту проще работать со знакомыми открытыми технологиями, чем с самодельной платформой предприятия, поэтому внутренние особенности нужно сделать понятными. Просто завернуть старые API в MCP недостаточно: технически доступный интерфейс ещё может оставаться неудобным для модели. Полностью под своим контролем следует держать полномочия, доступы, политики, проверочные наборы и данные о работе агентов. Пример из выступления: даже отличная модель бесполезна, если ей запрещён сетевой доступ или разрешённый список адресов пуст. Обратная крайность — действия разрешены, но каждую версию проверяют вручную без воспроизводимого набора задач. Полезная система возникает из сочетания модели, обвязки, разрешённых действий и проверки. Возможность заменить модель или обвязку тоже требует отдельной работы, иначе зависимость от поставщика закрепляется незаметно.

В докладе разделяются быстрый и медленный контуры улучшений. В быстром компания меняет маршрут запроса, упаковку контекста, интерфейс инструмента, политику доступа или критерии выпуска агента. В медленном крупные игроки согласуют модели с вычислительной инфраструктурой: памятью, точностью вычислений и связью между ускорителями. Когда агент спотыкается о внутренний процесс, полезно сначала искать исправление в доступном контуре, а не ждать следующую модель. Разные компании собирают полный цикл с разных сторон: вертикально интегрированный игрок — от продукта и собственных вычислений, лаборатория — от исследований и модели, продуктовая компания — от пользовательских задач и обратной связи. Открытые веса переносят часть работы к тем, кто разворачивает модель и приспосабливает её к нужному сценарию. Эти примеры показывают разные точки приложения усилий; копировать весь путь такого игрока своей платформенной команде не обязательно.

Даже совместимость моделей по API не означает одинакового поведения: обвязку приходится подстраивать под конкретные возможности и слабости. Поэтому собственный универсальный агентный цикл рискует превратиться в бесконечную погоню за поставщиками. Более устойчивое вложение — понятные контракты инструментов: кто действует, от чьего имени, что может изменить и как проверить успех. Рядом необходимы телеметрия, трассы выполнения и проверочные наборы, но их роли различаются. Трасса объясняет последовательность действий; успешная демонстрация показывает отдельный случай. Ни то ни другое само по себе не доказывает, что конечная задача решена и прежние возможности не ухудшились. Проверочный набор создавать неудобно: он задаёт исходный уровень, который нужно сохранять при каждом изменении. Зато команда перестаёт выбирать для демонстрации только удачные примеры и получает способ сравнивать версии на одинаковых задачах. Улучшение становится проверяемым результатом, а не впечатлением от очередного показа.

Следующий шаг — разложить процесс разработки на ограниченные эпизоды, например исправление ошибки. В каждом нужны понятные входы, границы действий, выходной результат, телеметрия и проверки. В качестве иллюстрации Поломодов упоминает последовательность от продуктового намерения к спецификации, плану, реализации и выпуску. Смысл такого разложения в том, чтобы организовать работу вокруг задачи, которую можно повторить и проверить. Для улучшения сохраняют задачу, ход выполнения и конечное состояние, воспроизводят эпизод в фиксированной среде, меняют один слой и снова запускают независимые проверки. Именно этот материал компания может накапливать независимо от выбранной модели. Каталог эпизодов даёт практическую основу и для развития агента, и для смены поставщика: обе версии можно сравнить на собственной работе. Без такой основы любое переключение опять превращается в набор ручных проб и субъективных оценок.

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