AI4SDLC: что бы я делал по-другому

Исходная рамка делит стек на три части. Передовые модели, базовый агентный цикл и стандартную инфраструктуру автор предлагает по возможности арендовать: рынок меняет их быстрее, чем обычная продуктовая команда успевает поддерживать собственные аналоги. Исключения связаны с ограничениями среды и требованиями к размещению. Даже тогда полезно отделять необходимость контролировать исполнение от желания самостоятельно строить всё остальное. Доработки нужны там, где начинается специфика компании: выбор модели под задачу и бюджет, подготовка контекста, адаптеры к внутренним системам. А владеть необходимо правилами доступа, идентичностью агента, наблюдаемостью и доказательствами качества. Такое разделение помогает обсуждать конкретную ответственность вместо общего запроса «дайте нам лучшую модель». Для команды из двадцати–пятидесяти человек большая часть первых двух слоёв может закрываться готовыми решениями. У крупной организации больше ресурсов, но одновременно больше неоднородных систем, согласований и привычек, которые замедляют изменение процесса.

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

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

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

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

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