Почему корпоративная разработка с ИИ начинается не с покупки ассистента, а с пересборки требований, архитектуры, контроля качества и ответственности
Привет, Хабр! На связи редакция блога ТЕХНОНИКОЛЬ Диджитал. Обычно по статьям для корпоративного блога прокатываются катком пиар-отдела, из-за чего мясные тексты превращаются в стерильные. Сегодня иной случай. Наш генеральный директор Яков Ильиных написал статью о том, почему просто раздать разработчикам лицензии — это отличный способ слить бюджет, превратив ИИ в дорогое автодополнение и фактически замедлив команду. Отбрасываем формальности с официальными приветствиями. Ниже — текст Якова об архитектуре, контроле качества, guardrails и 90-дневном пилоте AI-фабрики в ТЕХНОНИКОЛЬ с учётом российских реалий, 152-ФЗ, ограничений API и безопасности. В общем, всё как вы любите, устраивайтесь поудобнее. К тексту!
Обычная задача: добавить статус заказа, изменить API, обновить форму, миграцию, тесты и документацию. В AI-native процессе агент может пройти почти весь этот маршрут: изучить постановку, найти связанные компоненты, предложить план, изменить код, запустить проверки и подготовить запрос на слияние (merge request, MR). Человек принимает решение и отвечает за результат.
Но это не рассказ об уже доказанном успехе. Это пример реального кейса внедрения пилота AI-native разработки в корпорации: проверяемая гипотеза, инженерный контур и правила измерения. Положительный результат заранее не объявлен.
Сначала данные, потом модели
В 2025 году METR провела рандомизированное исследование: 16 опытных разработчиков выполнили 246 задач в знакомых им open source проектах. С инструментами уровня февраля-июня 2025 года они работали в среднем на 19% медленнее. После эксперимента участники при этом считали, что ИИ ускорил их на 20%.
Данные 2026 года не сняли противоречие. В опросе METR 349 технических специалистов оценили прирост ценности своей работы от ИИ в 1,4-2 раза, но авторы отдельно предупреждают: самооценка не равна измеренной производительности. Продолжение полевого эксперимента с 57 разработчиками и более чем 800 задачами пришлось перепроектировать. Выборка сместилась, участники не хотели отказываться от ИИ, а параллельные агенты затруднили учёт времени.
DORA в отчёте за 2025 год называет ИИ усилителем организационной системы. Он усиливает не только сильные стороны, но и слабые. Поэтому раздача лицензий сама по себе ничего не доказывает.
METR измеряла работу отдельных специалистов, а не корпоративный AI-native контур. Я не могу подтвердить, что такой контур гарантированно превращает замедление в ускорение. Именно поэтому реальный пилот нужен как эксперимент, а не как церемония подтверждения уже принятого решения.
Российский контур нельзя строить как обычный SaaS
Критический процесс нельзя проектировать в расчёте на постоянную доступность зарубежной модели и её API. На 9 сентября 2026 года России нет в официальном списке поддерживаемых стран Anthropic ни для коммерческого API, ни для Claude.ai. Другие зарубежные облачные сервисы также могут быть недоступны или работать с ограничениями. Бизнес-процесс не должен зависеть от Claude, другой отдельной модели или одного поставщика.
В корпоративном контексте встречаются коммерческая тайна, персональные данные, исходный код и сведения об инфраструктуре. Для персональных данных граждан РФ необходимо учитывать 152-ФЗ, включая предусмотренную частью 5 статьи 18 локализацию ряда операций при сборе данных. Конкретный сценарий требует отдельной юридической оценки по официальному тексту закона.
Отсюда появляется отдельный слой данных и guardrails вне модели: классификация, минимизация, маскирование, контроль маршрута и блокировка запрещённой передачи. Это задачи DLP и policy engine. Один системный промпт здесь не поможет.
Есть и ещё одна российская реальность: унаследованные системы, 1С, интеграционные шины, закрытые сегменты и документация в жанре «спросите того, кто это писал». Для агента такой контекст просто не существует, пока компания не сделала его доступным и управляемым.
Исследование ИСИЭЗ НИУ ВШЭ 2025 года охватило свыше 15 тысяч крупных и средних организаций, уже использующих ИИ. Из них 56% привлекали внешние компетенции, 23% разрабатывали ИИ-ПО своими силами, 18% дорабатывали открытые решения. Это указывает не на единственную правильную платформу, а на гибридную модель: собственные компоненты, рыночные продукты и открытый код.
Что здесь называется AI-native
У термина нет общепринятого стандарта. В этой статье AI-assisted разработка означает помощь человеку на отдельных этапах. **AI-native разработка ** означает, что весь процесс спроектирован для совместной работы людей и программных агентов: требования машиночитаемы, правила формализованы, контекст ограничен правами, изменения проверяются автоматически, важные решения подтверждает человек.
AI-assisted | AI-native |
|---|---|
Ассистент помогает в IDE | Агент участвует в цикле задачи |
Практики зависят от команды и инструмента | Контекст и правила принадлежат компании |
Контроль в основном сосредоточен на коде и CI/CD | Проверяются поведение, безопасность и архитектура |
Метрика: сколько кода сгенерировано | Метрика: как изменился путь до надежного релиза |
Инструменты работают разрозненно | Есть единый контур, политики доступа и аудит |
Если ИИ за минуту написал тысячу строк, а команда два дня их переписывала, выигрыш появился только в презентации. Начинать трансформацию с выбора модели столь же странно, как начинать строительство завода с выбора шуруповёрта.
Пять слоев корпоративного контура
1. Шлюз моделей
Инструменты разработки обращаются к моделям через корпоративный шлюз. Он выбирает разрешённого провайдера, применяет лимиты, маскирует чувствительные данные, журналирует запросы и позволяет заменить модель без пересборки процесса.
Простые задачи можно направлять в компактные модели, сложные изменения и архитектурный анализ — в более сильные. Для составной работы возможна схема «оркестратор и исполнители». Anthropic описывает routing, parallelization и orchestrator-workers как разные паттерны. Рой агентов имеет смысл только при измеримом выигрыше в качестве.
2. Контекст для агента
Агенту недостаточно исходного кода и обычной документации. Нужны актуальные требования, схемы API и данных, ADR, граф зависимостей, каталог тестов, архитектурные ограничения и история решений. RAG и эмбеддинги ускоряют поиск, но не заменяют источник истины. Доступ проверяется во время извлечения контекста, до сборки промпта.
Контекст должен быть версионируемым и связанным с кодом. Иначе агент уверенно предложит решение, которое уже отвергли два года назад. Он не упрямый. Ему просто не показали протокол.
3. Изолированная среда исполнения
Агент работает в песочнице, имеет собственную идентичность в журнале, получает краткокоживущие учётные данные и минимальные права. Необратимые действия и повышение привилегий подтверждает человек. OWASP по риску excessive agency также рекомендует ограничивать функции, разрешения и автономность вне языковой модели.
4. Автоматическая доказательная база
Нужны модульные, интеграционные и контрактные тесты, статический анализ, поиск уязвимостей и секретов, контроль лицензий и архитектурных правил. Для критичных сценариев добавляются evals, то есть воспроизводимые задания для оценки модели и агента. Вместе с результатом фиксируются версии модели, промптов, инструментов и правил.
OWASP относит prompt injection к ключевым рискам LLM-приложений. Инструкция может прийти из документа, страницы или файла в репозитории. Поэтому внешний контент считается недоверенным, а действия агента проходят обычную авторизацию. Нужны также откат и процесс управления инцидентами.
5. Наблюдаемость и экономика
Число активных пользователей ничего не говорит о результате. Нужны время от постановки до релиза, длительность ревью, объём переделок, откаты, дефекты, полная стоимость завершённой задачи и проверяемый след действий агента.
В полную стоимость входят вызовы моделей, инфраструктура, ревью, переделки и сопровождение. Сравнивать нужно одну команду и один тип задач с их исходным уровнем, а не количество токенов между отделами.
Что меняется в работе инженера
Инженер меньше времени тратит на производство каждого фрагмента кода и больше на постановку границ, выбор решения и проверку доказательств. Возрастает роль декомпозиции, архитектурного мышления, тестов и анализа рисков.
Особенно внимательно нужно работать с младшими разработчиками. Если человек ещё не отличает хорошее решение от правдоподобного, ИИ может ускорить накопление ошибок. Наставничество не исчезает. Оно смещается от объяснения синтаксиса к проверке предположений и последствий.
Практический старт на 90 дней
Ниже не абстрактная методика, а кейс производственной компании ТЕХНОНИКОЛЬ: рабочая схема пилота на 90 дней.
Пилот проводится на одной экспериментальной команде. Её выбирают по четырем признакам: стабильный высококвалифицированный инженерный состав, сложные регулярные задачи, доступная история метрик и высокий уровень мотивации к изменениям.
На все 90 дней привлекается внешний AI-трекер. Это человек, а не модель и не панель мониторинга. Он работает как независимый ментор: следит за прогрессом изменений, радикально, но конструктивно критикует решения команды и приносит проверенные мировые практики AI-native разработки. Он не должен быть связан с поставщиком оцениваемых инструментов, не выбирает продукт за команду и не переписывает порог успеха по ходу пилота.
Первые 30 дней: измерить и ограничить. Выбрать для экспериментальной команды несколько повторяемых задач. Зафиксировать исходные метрики, классы данных, разрешённые модели, правила маршрутизации, допустимые инструменты и запрещённые действия.
Дни 31-60: собрать корпоративный инженерный harness. Здесь harness означает не локальную обвязку одного решения, а среду работы агентов: скиллы, то есть повторяемые инструкции и процедуры, роли, правила, контекст, маршрутизацию моделей, оркестрацию, инструменты, evals, песочницу, наблюдаемость и точки подтверждения человеком. У контура должны появиться владелец, правила поддержки и измеримый уровень сервиса. Узкий эксперимент Anthropic с долгоживущим агентом иллюстрирует часть этой задачи: даже сильной модели нужна среда, которая хранит состояние, заставляет работать небольшими шагами и проверять результат.
Дни 61-90: проверить агентный цикл. Разрешить агенту готовить ограниченный тип изменений в песочнице, запускать тесты и формировать запрос на слияние. Сравнить время цикла, дефекты и переделки. Зафиксировать удачные и неудачные паттерны и подготовить пакет переноса на другие команды после завершения пилота. Внутри пилота экспериментальная команда остается одна.
Пилот можно считать успешным, если медианное время выполнения выбранного типа задач сократилось, а доля откатов, дефектов после выпуска и повторных ревью не выросла. Единого универсального процента здесь нет. Порог следует зафиксировать до эксперимента, иначе почти любой результат получится объявить победой.
Если скорость написания кода выросла, а время выпуска не изменилось, узкое место находится дальше по потоку. Возможно, в тестировании, согласовании, архитектурном комитете или управлении релизами. Покупка ещё одной модели этот вопрос не решит.
Где AI-native превращается в дорогой эксперимент
Проблемы начинаются, когда компания разрешает любые публичные сервисы, связывает весь процесс с одним поставщиком, измеряет строки кода и дает агенту автономность раньше, чем появляются тесты и ограничения.
Не лучше работает и отдельная «команда ИИ», существующая в стороне от продуктовой разработки. Платформенная экспертиза нужна, но AI-native подход возникает там, где создается и эксплуатируется продукт, а не в лаборатории презентаций.
Вместо вывода
Главное изменение не в том, что ИИ научился писать код. Дефицитны ясные требования, доступный контекст, быстрые проверки, архитектурная дисциплина и способность организации принимать решения без месячного квеста по согласованиям.
AI-native компания делает эти элементы машиночитаемыми, проверяемыми и управляемыми. Поэтому зрелость стоит измерять не долей кода, созданного моделью, а частью пути от бизнес-задачи до надежного промышленного результата, которую система проходит быстрее, не теряя контроль.
Вернёмся к задаче из начала статьи: добавить статус заказа. Если быстрее появился только код, компания купила очень дорогое автодополнение. Если быстрее и без роста дефектов, риска и полной стоимости прошёл весь путь до промышленного релиза, появился новый производственный контур.
Источники:
ИСИЭЗ НИУ ВШЭ. «Применение искусственного интеллекта в российских компаниях», 12 сентября 2025 года.
METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.
METR. We are Changing our Developer Productivity Experiment Design, 24 февраля 2026 года.
Anthropic. Supported countries and regions. Проверено 19 августа 2026 года.
Anthropic. Effective harnesses for long-running agents, 26 ноября 2025 года.
Федеральный закон № 152-ФЗ «О персональных данных». Официальный интернет-портал правовой информации.
