Появилась запись панельной дискуссии, которую я модерировал на AI Dev Conf. Состав участников был представительным: Алексей Тотмаков из VK Tech, Рафаел Тонаканян из Сбера, Андрей Кулешов из Yandex SourceCraft и я в роли модератора. Мне кажется, получился хороший разговор про то, что AI в разработке уже стал базовой гигиеной: модели помогают писать код, тесты, документацию, разбирать legacy, делать review и быстрее двигаться по рутинным задачам. Но главный вопрос теперь в том, а можем ли мы безопасно встроить AI в инженерную систему так, чтобы он давал измеримый production-результат, а не просто увеличивал количество сгенерированного кода. Мы затронули много тем, но основные отмечены ниже.
1️⃣ Первая большая тема - контекст. Модель без контекста похожа на очень уверенного junior-разработчика, который не знает вашу систему. Она может быстро предложить решение, но не понимает, почему здесь странный workaround, какие SLA у сервиса, какие зависимости нельзя трогать, какие данные нельзя отправлять наружу и какие тесты действительно важны. Поэтому “дать модели доступ к коду” - это еще не стратегия. Нужна нормальная инженерная постановка: цель, ограничения, контекст, критерии приемки, границы изменений, тесты и способ проверки результата. То есть примерно та же цепочка, о которой я уже много говорил:
intent -> context -> plan -> tasks -> implementation -> verification.2️⃣ Вторая тема - переход от ассистентов к агентам. Ассистент помогает человеку, но человек держит цель, план и ответственность. Агент уже может сам разложить задачу, вызвать инструменты, поменять код, запустить тесты, прочитать ошибку и попробовать снова. Звучит красиво, но в большой компании это сразу поднимает неудобные вопросы. К каким репозиториям агент имеет доступ? Можно ли ему читать логи? Может ли он менять конфигурацию? Кто отвечает за security regression? Что логируется? Где нужен approval? Как откатиться назад? Поэтому agentic coding - это не просто “модель поумнее”. Это новая архитектура процесса разработки.
3️⃣ Третья тема - метрики. Очень легко считать не то: купленные лицензии, количество запросов к модели, число сгенерированных строк кода. Все это может быть полезным сигналом adoption, но не показывает, стала ли инженерная система лучше. Смотреть нужно на цепочку целиком: cycle time, time-to-PR, time-to-merge, качество review, дефекты, security-риск, нагрузку на senior-инженеров, стоимость токенов и долю результата, которая реально доходит до production.
4️⃣ Четвертая тема - политики. Если AI получает доступ к коду, задачам, логам, документации и внутренним данным, правила больше нельзя держать “в голове у архитектора”. Нужны машинно-проверяемые политики: какие данные можно отдавать модели, какие модели разрешены для каких задач, куда агент имеет доступ, какие изменения требуют ручного подтверждения, что должно логироваться и какие действия запрещены всегда.
5️⃣ И еще один важный момент: стратегию нельзя строить вокруг одной модели. Модели будут меняться быстрее, чем процессы. Поэтому нужны более устойчивые элементы: gateway, routing между моделями, evals, логирование, лимиты стоимости, сравнение качества и возможность заменить провайдера без переписывания всего процесса.
Для разработчиков вывод такой: важно уметь проектировать проверяемую работу для человека и агента: ставить задачу, давать контекст, ограничивать решение, читать diff критически и строить контур проверки.
Для техлидов, EM и CTO вывод жестче: AI adoption - это не закупка лицензий. Это изменение операционной модели разработки. Нужно думать про контекст, политики, инструменты, песочницы, evals, observability, метрики, экономику и ответственность.
В общем, сейчас основной вопрос в том, а может ли ваша организация безопасно, измеримо и регулярно превращать AI-ускорение в production-результат?
#AI #AI4SDLC #Engineering #Management #Architecture #Agents #DevTools