AI-native разработка по-русски: почему ИИ начинается не с покупки ассистента
Корпоративная разработка с искусственным интеллектом не сводится к выдаче инженерам лицензий на Copilot, Claude или другой программный инструмент. Если просто добавить ИИ к прежним процессам, компания рискует получить дорогое автодополнение, рост числа ошибок и иллюзию ускорения.
AI-native подход означает более глубокую перестройку: меняются требования, архитектура, правила работы с данными, контроль качества, распределение ответственности и способы измерения результата. Агент становится не отдельной функцией в редакторе, а участником управляемого инженерного контура.
Представим типичную задачу: добавить статус заказа, изменить API, обновить пользовательскую форму, подготовить миграцию, написать тесты и дополнить документацию. В AI-native-процессе агент способен изучить постановку, найти связанные компоненты, сформировать план, внести изменения, запустить проверки и подготовить merge request. Однако финальное решение, проверка рисков и ответственность за результат остаются за человеком.
Важно не выдавать пилот за доказанный успех. Внедрение AI-native-разработки в корпорации следует рассматривать как проверяемую гипотезу с заранее определёнными метриками, ограничениями и критериями остановки.
Почему лицензии не гарантируют ускорения
В 2025 году METR провела рандомизированное исследование с участием 16 опытных разработчиков. Они выполнили 246 задач в хорошо знакомых open source-проектах. При использовании инструментов, доступных в период с февраля по июнь 2025 года, специалисты в среднем работали на 19% медленнее. При этом после эксперимента участники полагали, что ИИ ускорил их примерно на 20%.
Более поздние данные не устранили это противоречие. В опросе METR, охватившем 349 технических специалистов, респонденты оценили прирост ценности собственной работы от ИИ в 1,4-2 раза. Авторы отдельно подчёркивали: субъективная оценка не равна измеренной производительности. Продолжение полевого эксперимента с 57 разработчиками и более чем 800 задачами пришлось пересматривать из-за смещения выборки, нежелания участников отказываться от ИИ и сложностей с учётом времени при параллельной работе нескольких агентов.
Отчёт DORA за 2025 год описывает ИИ как усилитель организационной системы. Он способен масштабировать сильные стороны компании, но точно так же усиливает хаос, плохую документацию, слабое тестирование и неясные зоны ответственности. Поэтому количество купленных лицензий ничего не доказывает.
Исследования отдельных специалистов нельзя автоматически переносить на корпоративный AI-native-контур. Такой контур может устранить часть потерь - например, за счёт единого контекста, автоматических проверок и повторяемых процессов, - но гарантировать ускорение заранее невозможно. Именно поэтому пилот должен быть экспериментом, а не формальным подтверждением уже принятого решения.
Сначала данные, потом модели
Российскую корпоративную систему нельзя проектировать как обычный SaaS, завязанный на постоянную доступность одного зарубежного провайдера. На 9 сентября 2026 года Россия не входила в официальный перечень поддерживаемых Anthropic стран ни для коммерческого API, ни для Claude.ai. Другие иностранные облачные сервисы также могут быть недоступны, ограничены по функциям или изменять условия работы.
Критический бизнес-процесс не должен зависеть от конкретной модели, поставщика или внешнего API. Архитектура должна допускать замену моделей, использование локального контура и временное переключение на резервные решения.
В корпоративных системах обрабатываются коммерческая тайна, персональные данные, исходный код, сведения об инфраструктуре, договорах и внутренних процессах. При работе с данными граждан России необходимо учитывать требования 152-ФЗ, включая положения части 5 статьи 18 о локализации ряда операций при сборе персональных данных. Каждый конкретный сценарий требует отдельной юридической оценки по действующей редакции закона.
Одного системного промпта для защиты таких данных недостаточно. Нужны классификация информации, минимизация, маскирование, контроль маршрута, запрет передачи определённых категорий и журналирование действий. Эти функции относятся к DLP и policy engine и должны находиться рядом с моделью, но не внутри неё.
Пять слоёв корпоративного AI-native-контура
1. Шлюз моделей
Шлюз скрывает от приложений и агентов конкретных поставщиков. Через него задаются маршрутизация запросов, лимиты, политики хранения, журналирование и резервные сценарии.
В зависимости от класса задачи можно использовать разные модели: небольшую локальную - для классификации и извлечения данных, более мощную - для анализа архитектуры, специализированную - для генерации кода. Такой подход снижает расходы и уменьшает зависимость от одного API.
Шлюз также должен учитывать стоимость, задержку, доступность и чувствительность данных. Запрос с фрагментом исходного кода и персональными сведениями не должен автоматически отправляться туда же, куда направляется обезличенная техническая документация.
2. Контекст для агента
Агент не умеет "знать" корпоративную систему сам по себе. Ему необходим управляемый контекст: репозитории, схемы баз данных, API-контракты, правила кодирования, архитектурные решения, история изменений, описание интеграций и ограничения безопасности.
Однако простая загрузка всей документации в векторную базу не решает проблему. Контекст должен быть актуальным, версионируемым и связанным с конкретным проектом. В противном случае агент будет уверенно использовать устаревшие интерфейсы и несуществующие зависимости.
Полезно разделять постоянные знания и временный контекст задачи. К первым относятся архитектурные принципы и стандарты, ко вторым - конкретная ветка, тикет, набор затронутых сервисов и результаты текущих проверок.
3. Изолированная среда исполнения
Генерация кода без безопасного запуска - лишь половина процесса. Агенту требуется изолированная среда, где он может собрать проект, выполнить тесты, проверить миграции и запустить статический анализ без доступа к критическим системам.
Для этого применяются контейнеры, временные окружения, ограниченные учётные записи, сетевые политики и одноразовые рабочие пространства. Агент не должен иметь постоянных привилегий и прямого доступа к производственной базе.
Особенно важен режим "сначала предложение, потом действие". Изменения должны проходить через diff, автоматические проверки и подтверждение ответственного специалиста. Для опасных операций - публикации, удаления данных, изменения схемы или выдачи прав - необходимо отдельное согласование.
4. Автоматическая доказательная база
Результатом работы агента должен быть не только изменённый файл, но и набор подтверждений: какие требования обработаны, какие файлы изменены, какие тесты пройдены, какие проверки завершились ошибкой, какие предположения использовались.
Так появляется трассируемость от требования до результата. Для корпоративной разработки это особенно важно: через несколько месяцев команде нужно понимать, почему было принято решение и на основании каких данных оно прошло проверку.
В доказательную базу могут входить отчёты тестов, результаты линтеров, скриншоты интерфейса, планы миграций, результаты анализа безопасности и перечень отклонённых агентом действий.
5. Наблюдаемость и экономика
Необходимо видеть не только количество сгенерированных строк, но и реальную эффективность процесса. Важны время от постановки до merge request, доля успешно принятых изменений, количество возвратов на доработку, дефекты после релиза, частота откатов, стоимость модельных запросов и нагрузка на ревьюеров.
Отдельно следует измерять эффект на разных классах задач. ИИ может хорошо помогать с тестами, документацией и типовыми интеграциями, но почти не давать выигрыша в старом монолите с неясными зависимостями.
Что меняется в работе инженера
Разработчик постепенно перестаёт быть только автором строк кода. Его роль смещается в сторону постановки задач, проверки архитектурных решений, анализа рисков и контроля качества результата.
Это не означает, что инженер превращается в пассивного проверяющего. Напротив, от него требуется более глубокое понимание системы: плохой специалист может не заметить ошибку агента, даже если код выглядит аккуратно.
Команда должна договориться о правилах использования ИИ. Например, изменения агента обязательно проходят ревью, запрещается вставлять секреты в запросы, нельзя принимать код без тестов, а для критических компонентов требуется ручное подтверждение владельца системы.
Полезно также вести реестр сценариев: где агент разрешён без дополнительного согласования, где нужен обязательный просмотр специалиста, а где применение ИИ полностью запрещено.
Практический план на 90 дней
В первые две недели следует выбрать ограниченный участок разработки и зафиксировать исходные показатели: среднее время выполнения задач, процент возвратов, число дефектов и длительность ревью. Без базовой линии невозможно оценить эффект.
На следующем этапе нужно подготовить минимальный контур данных: перечень доступных репозиториев, правила маскирования, классификацию информации, политики доступа и описание допустимых моделей.
В течение первого месяца стоит запустить один-два сценария с низким риском. Подходящими кандидатами могут стать написание тестов, обновление документации, подготовка типовых миграций или анализ повторяющихся ошибок.
Во второй месяц добавляются изолированное исполнение, автоматические проверки и формирование доказательной базы. Все действия агента должны логироваться, а опасные операции - блокироваться или требовать подтверждения.
На третьем месяце проводится сравнение с контрольной группой или историческими значениями. Если скорость выросла, но одновременно увеличилось число дефектов и ручных возвратов, эксперимент нельзя считать успешным.
Когда AI-native становится дорогой игрушкой
Проблемы начинаются, если компания внедряет агента до наведения порядка в требованиях, документации и тестах. В таком случае ИИ не исправляет процесс, а ускоряет производство противоречивого кода.
Другой риск - ориентация на одну модную модель. При изменении тарифов, ограничениях API или ухудшении доступности весь процесс оказывается под угрозой.
Не стоит также путать активность с результатом. Число запросов, строк кода и автоматически созданных merge request не является бизнес-метрикой. Важны надёжность, скорость поставки, стоимость сопровождения и отсутствие новых рисков.
AI-native-разработка в российских компаниях должна начинаться не с покупки ассистента, а с проектирования устойчивого инженерного контура. В нём есть данные, политики, модели, песочницы, проверки, наблюдаемость и человек, который сохраняет право последнего решения.
Только при таком подходе искусственный интеллект становится частью производства программного обеспечения, а не очередным дорогим дополнением к редактору кода.