AMA-сессия #2 про AI-Assisted Engineering

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

Мультиагентный режим полезен не сам по себе. Разделение планирования, реализации и проверки снижает склонность одного исполнителя подтверждать собственное решение, а параллельный поиск помогает в исследованиях и независимом аудите. Но каждый дополнительный агент заново загружает контекст, расходует токены и усложняет понимание происходящего. Начинать стоит с одного агента и подключать отдельные роли только после того, как измеримое ограничение скорости или качества стало очевидным.

Для сервиса без документации первый шаг — не массовая генерация описаний, а наблюдаемое поведение и условие завершения конкретного изменения. Команда фиксирует, что система делает сейчас, добавляет characterization tests вокруг затронутой области и строит короткий цикл обратной связи: компиляцию, линтеры, тесты, снимки интерфейса или специализированный проверочный инструмент. Так агент получает не просьбу «разобраться во всём», а границы, сигнал ошибки и доказуемый результат, не ломая уже работавшие сценарии.

Технический контур не исправляет организационную потерю смысла. Если никто не может объяснить назначение продукта и ответственность за домен, автоматически созданные схемы лишь умножат артефакты без владельца. Тот же принцип действует в информационной безопасности: начинать нужно с модели угроз для обвязки, модели, инструментов, репозитория и данных. Полная изоляция возможна, но дорога; корпоративные шлюзы и политики доступа дают промежуточные варианты. Меры должны защищать конкретный риск, сохраняя экономический смысл системы.

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

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