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

Первый вопрос начинается с жалобы: гайды по работе с AI приходится переписывать почти еженедельно. Литвинов предлагает разделить знания по сроку жизни. Настройки модели, версии, кэширование и особенности конкретной harness образуют волатильный слой. Спецификации, правила репозитория и файлы вроде AGENTS.md меняются вместе с продуктом, но реже. Дольше всего живут намерение, границы задачи, инварианты, критерии приёмки и цикл обратной связи. Если правило переносится между моделями и помогает при обычном делегировании людям, это хороший кандидат в фундамент.

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

Распоряжение «теперь все работаем с AI» не меняет практику само по себе. Ранние последователи подхватят его, остальные увидят очередную кампанию сверху, а часть людей начнёт сопротивляться из страха за работу. Убедительнее соседняя команда, которая решает знакомую задачу быстрее и показывает работающий контур, а не демонстрационный прототип. Поэтому внедрение соединяет направление и платформенные возможности от руководства с локальными AI champions, которые проводят пилоты, делятся практиками и превращают протоптанные ими тропинки в повторяемый путь.

Ключевой связующий слой — middle management. Эти руководители перегружены, не определяют корпоративную стратегию, но должны объяснять её командам и отвечать за предсказуемое качество. Им нужен не новый обязательный ритуал, а инструмент, который сначала уменьшит их собственный шум и нагрузку. Полезный пилот связывают с бизнес-целью и измеряют на всём потоке: ускоренный фронтенд бесполезен, если узкое место находится в требованиях, бэкенде или согласовании. Требование «дать X5 пользы» без анализа системы лишь переносит давление на людей.

Эйфорию от быстрой генерации не нужно гасить; нужно изменить определение результата. Им становится наблюдаемое изменение поведения продукта и доказательство, что оно работает. Литвинов предлагает начинать с базовой линии: времени человека на принятие изменения, доли переделок, DORA-метрик и телеметрии агентного запуска. Затем для каждой задачи фиксируются intent, область изменений, запреты, инварианты и критерии приёмки. Механические условия уходят в хуки и CI, изменения классифицируются по blast radius, а pull request дополняется evidence package: тестами, контрактами, визуальными доказательствами и планом отката.

Генерация масштабируется на десятки агентов, человеческое понимание — нет, поэтому один агент не должен одновременно создавать изменение и подтверждать его корректность. По мере зрелости недетерминированные правила заменяются детерминированными проверками, а дорогие централизованные отчёты превращаются в раннюю обратную связь внутри рабочего цикла. Авторство кода при этом отделяется от ответственности: бизнесу важно, чтобы система работала, но у каждого участка остаётся именованный владелец. Инженер и руководитель отвечают уже не только за отдельный diff, а за устойчивость конвейера, который производит и проверяет изменения.