AI-native разработка по-русски

Почему корпоративная разработка с ИИ начинается не с покупки ассистента, а с пересборки требований, архитектуры, контроля качества и ответственности

_{На связи редакция блога ТЕХНОНИКОЛЬ Диджитал. Обычно по статьям для корпоративного блога прокатываются катком пиар-отдела, из-за чего мясные тексты превращаются в стерильные. Сегодня иной случай. Наш генеральный директор Яков Ильиных написал статью о том, почему просто раздать разработчикам лицензии — это отличный способ слить бюджет, превратив ИИ в дорогое автодополнение и фактически замедлив команду. Отбрасываем формальности с официальными приветствиями. Ниже — текст Якова об архитектуре, контроле качества, guardrails и 90-дневном пилоте AI-фабрики в ТЕХНОНИКОЛЬ с учётом российских реалий, 152-ФЗ, ограничений API и безопасности. В общем, всё как вы любите, устраивайтесь поудобнее. К тексту!}

Обычная задача: добавить статус заказа, изменить API, обновить форму, миграцию, тесты и документацию. В AI-native процессе агент может пройти почти весь этот маршрут: изучить постановку, найти связанные компоненты, предложить план, изменить код, запустить проверки и подготовить запрос на слияние (merge request, MR). Человек принимает решение и отвечает за результат.

Но это не рассказ об уже доказанном успехе. Это пример реального кейса внедрения пилота AI-native разработки в корпорации: проверяемая гипотеза, инженерный контур и правила измерения. Положительный результат заранее не объявлен.

Сначала данные, потом модели

В 2025 году METR провела рандомизированное исследование: ^[1] 16 опытных разработчиков выполнили 246 задач в знакомых им open source проектах. С инструментами уровня февраля-июня 2025 года они работали в среднем на 19% медленнее. После эксперимента участники при этом считали, что ИИ ускорил их на 20%.

Данные 2026 года не сняли противоречие. В опросе METR ^[1] 349 технических специалистов оценили прирост ценности своей работы от ИИ в 1,4-2 раза, но авторы отдельно предупреждают: самооценка не равна измеренной производительности. Продолжение полевого эксперимента с 57 разработчиками и более чем 800 задачами пришлось перепроектировать. ^[2] Выборка сместилась, участники не хотели отказываться от ИИ, а параллельные агенты затруднили учёт времени.

DORA в отчёте за 2025 год ^[3] называет ИИ усилителем организационной системы. Он усиливает не только сильные стороны, но и слабые. Поэтому раздача лицензий сама по себе ничего не доказывает.

METR измеряла работу отдельных специалистов, а не корпоративный AI-native контур. Я не могу подтвердить, что такой контур гарантированно превращает замедление в ускорение. Именно поэтому реальный пилот нужен как эксперимент, а не как церемония подтверждения уже принятого решения.

Российский контур нельзя строить как обычный SaaS

Критический процесс нельзя проектировать в расчёте на постоянную доступность зарубежной модели и её API. На 9 сентября 2026 года России нет в официальном списке поддерживаемых стран Anthropic ^[4] ни для коммерческого API, ни для Claude.ai. Другие зарубежные облачные сервисы также могут быть недоступны или работать с ограничениями. Бизнес-процесс не должен зависеть от Claude, другой отдельной модели или одного поставщика.

В корпоративном контексте встречаются коммерческая тайна, персональные данные, исходный код и сведения об инфраструктуре. Для персональных данных граждан РФ необходимо учитывать 152-ФЗ, включая предусмотренную частью 5 статьи 18 локализацию ряда операций при сборе данных. Конкретный сценарий требует отдельной юридической оценки по официальному тексту закона. ^[5]

Отсюда появляется отдельный слой данных и guardrails вне модели: классификация, минимизация, маскирование, контроль маршрута и блокировка запрещённой передачи. Это задачи DLP и policy engine. Один системный промпт здесь не поможет.

Есть и ещё одна российская реальность: унаследованные системы, 1С, интеграционные шины, закрытые сегменты и документация в жанре «спросите того, кто это писал». Для агента такой контекст просто не существует, пока компания не сделала его доступным и управляемым.

Исследование ИСИЭЗ НИУ ВШЭ 2025 года ^[6] охватило свыше 15 тысяч крупных и средних организаций, уже использующих ИИ. Из них 56% привлекали внешние компетенции, 23% разрабатывали ИИ-ПО своими силами, 18% дорабатывали открытые решения. Это указывает не на единственную правильную платформу, а на гибридную модель: собственные компоненты, рыночные продукты и открытый код.

Что здесь называется AI-native

У термина нет общепринятого стандарта. В этой статье AI-assisted разработка означает помощь человеку на отдельных этапах. **AI-native разработка ** означает, что весь процесс спроектирован для совместной работы людей и программных агентов: требования машиночитаемы, правила формализованы, контекст ограничен правами, изменения проверяются автоматически, важные решения подтверждает человек.

Если ИИ за минуту написал тысячу строк, а команда два дня их переписывала, выигрыш появился только в презентации. Начинать трансформацию с выбора модели столь же странно, как начинать строительство завода с выбора шуруповёрта.

Пять слоев корпоративного контура

1. Шлюз моделей

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

Простые задачи можно направлять в компактные модели, сложные изменения и архитектурный анализ — в более сильные. Для составной работы возможна схема «оркестратор и исполнители». Anthropic описывает ^[8] routing, parallelization и orchestrator-workers как разные паттерны. Рой агентов имеет смысл только при измеримом выигрыше в качестве.

2. Контекст для агента

Агенту недостаточно исходного кода и обычной документации. Нужны актуальные требования, схемы API и данных, ADR, граф зависимостей, каталог тестов, архитектурные ограничения и история решений. RAG и эмбеддинги ускоряют поиск, но не заменяют источник истины. Доступ проверяется во время извлечения контекста, до сборки промпта.

Контекст должен быть версионируемым и связанным с кодом. Иначе агент уверенно предложит решение, которое уже отвергли два года назад. Он не упрямый. Ему просто не показали протокол.

3. Изолированная среда исполнения

Агент работает в песочнице, имеет собственную идентичность в журнале, получает краткокоживущие учётные данные и минимальные права. Необратимые действия и повышение привилегий подтверждает человек. OWASP по риску excessive agency ^[9] также рекомендует ограничивать функции, разрешения и автономность вне языковой модели.

4. Автоматическая доказательная база

Нужны модульные, интеграционные и контрактные тесты, статический анализ, поиск уязвимостей и секретов, контроль лицензий и архитектурных правил. Для критичных сценариев добавляются evals, то есть воспроизводимые задания для оценки модели и агента. Вместе с результатом фиксируются версии модели, промптов, инструментов и правил.

OWASP относит prompt injection ^[10] к ключевым рискам LLM-приложений. Инструкция может прийти из документа, страницы или файла в репозитории. Поэтому внешний контент считается недоверенным, а действия агента проходят обычную авторизацию. Нужны также откат и процесс управления инцидентами.

5. Наблюдаемость и экономика

Число активных пользователей ничего не говорит о результате. Нужны время от постановки до релиза, длительность ревью, объём переделок, откаты, дефекты, полная стоимость завершённой задачи и проверяемый след действий агента.

В полную стоимость входят вызовы моделей, инфраструктура, ревью, переделки и сопровождение. Сравнивать нужно одну команду и один тип задач с их исходным уровнем, а не количество токенов между отделами.

Что меняется в работе инженера

Инженер меньше времени тратит на производство каждого фрагмента кода и больше на постановку границ, выбор решения и проверку доказательств. Возрастает роль декомпозиции, архитектурного мышления ^[11], тестов и анализа рисков.

Особенно внимательно нужно работать с младшими разработчиками. Если человек ещё не отличает хорошее решение от правдоподобного, ИИ может ускорить накопление ошибок. Наставничество не исчезает. Оно смещается от объяснения синтаксиса к проверке предположений и последствий.

Практический старт на 90 дней

Ниже не абстрактная методика, а кейс производственной компании ТЕХНОНИКОЛЬ: рабочая схема пилота на 90 дней.

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

На все 90 дней привлекается внешний AI-трекер. Это человек, а не модель и не панель мониторинга. Он работает как независимый ментор: следит за прогрессом изменений, радикально, но конструктивно критикует решения команды и приносит проверенные мировые практики AI-native разработки. Он не должен быть связан с поставщиком оцениваемых инструментов, не выбирает продукт за команду и не переписывает порог успеха по ходу пилота.

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

Дни 31-60: собрать корпоративный инженерный harness. Здесь harness означает не локальную обвязку одного решения, а среду работы агентов: скиллы, то есть повторяемые инструкции и процедуры, роли, правила, контекст, маршрутизацию моделей, оркестрацию, инструменты, evals, песочницу, наблюдаемость и точки подтверждения человеком. У контура должны появиться владелец, правила поддержки и измеримый уровень сервиса. Узкий эксперимент Anthropic ^[13] с долгоживущим агентом иллюстрирует часть этой задачи: даже сильной модели нужна среда, которая хранит состояние, заставляет работать небольшими шагами и проверять результат.

Дни 61-90: проверить агентный цикл. Разрешить агенту готовить ограниченный тип изменений в песочнице, запускать тесты и формировать запрос на слияние. Сравнить время цикла, дефекты и переделки. Зафиксировать удачные и неудачные паттерны и подготовить пакет переноса на другие команды после завершения пилота. Внутри пилота экспериментальная команда остается одна.

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

Если скорость написания кода выросла, а время выпуска не изменилось, узкое место находится дальше по потоку. Возможно, в тестировании, согласовании, архитектурном комитете или управлении релизами. Покупка ещё одной модели этот вопрос не решит.

Где AI-native превращается в дорогой эксперимент

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

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

Вместо вывода

Главное изменение не в том, что ИИ научился писать код. Дефицитны ясные требования, доступный контекст, быстрые проверки, архитектурная дисциплина и способность организации принимать решения без месячного квеста по согласованиям.

AI-native компания делает эти элементы машиночитаемыми, проверяемыми и управляемыми. Поэтому зрелость стоит измерять не долей кода, созданного моделью, а частью пути от бизнес-задачи до надежного промышленного результата, которую система проходит быстрее, не теряя контроль.

Вернёмся к задаче из начала статьи: добавить статус заказа. Если быстрее появился только код, компания купила очень дорогое автодополнение. Если быстрее и без роста дефектов, риска и полной стоимости прошёл весь путь до промышленного релиза, появился новый производственный контур.

Источники:

1. ИСИЭЗ НИУ ВШЭ. «Применение искусственного интеллекта в российских компаниях», 12 сентября 2025 года. ^[6]

2. DORA. State of AI-assisted Software Development 2025. ^[3]

3. METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. ^[14]

4. METR. We are Changing our Developer Productivity Experiment Design, 24 февраля 2026 года. ^[2]

5. METR. Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity, 11 мая 2026 года. ^[1]

6. OWASP. LLM01:2025 Prompt Injection. ^[10]

7. OWASP. LLM06:2025 Excessive Agency. ^[9]

8. Anthropic. Supported countries and regions. Проверено 19 августа 2026 года. ^[4]

9. Anthropic. Building effective agents, 19 декабря 2024 года. ^[8]

10. Anthropic. Effective harnesses for long-running agents, 26 ноября 2025 года. ^[13]

11. Федеральный закон № 152-ФЗ «О персональных данных». Официальный интернет-портал правовой информации. ^[5]