Любая компания — точка в семимерном пространстве.

Эти семь координат меняются не одновременно. Например, у компании уже могут быть ai — агенты и внутренняя платформа, но сотрудники всё ещё работают через чат, проверки запускают вручную, а решения принимают по старой управленческой логике. Поэтому одного ответа «мы на L5» мало: он не объясняет, где в компании создаётся стоимость, что реально выходит наружу и как быстро организация меняется. Одна шкала легко превращается в маркетинг, а профиль по семи осям даёт более проверяемую картину.

Профиль можно записать так: ⟨A, B, C, D, E, F, G⟩.

Оси D / E / F — структурный сдвиг, который не виден на пирамиде агентов. Их трудно сфейкать: они требуют пересборки ответственности, identity, расчётов и формата производства ценности. Именно там появляется настоящий moat AI-native компании, если он вообще появляется.

Что именно стало лучше в инженерной системе после внедрения AI?

Это можно проверить: сократился ли lead time, стало ли ревью быстрее, уменьшился ли риск изменений, начали ли команды чаще доводить AI-предложения до проверенного pull request. Или AI просто добавил ещё один слой активности: больше черновиков, больше подсказок, больше обсуждений, но тот же bottleneck в тестах, ревью и понимании контекста?

В Stack Overflow Developer Survey 2024 76% респондентов уже используют AI-инструменты в разработке или планируют начать, а 62% уже используют их сейчас. Но позитивное отношение снизилось с 77% до 72%, и это важный сигнал: первая волна восторга проходит, руководители и разработчики начинают спрашивать не «есть ли у нас AI», а «что он реально меняет в работе».

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

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

Зачем вообще замерять AI-native зрелость

Пока AI находится на уровне эксперимента, замеры кажутся бюрократией. Разработчики пробуют инструменты, команды ищут сценарии, менеджмент смотрит на первые демо. На этой стадии достаточно здравого смысла.

Эта рамка не нужна маленькой команде, где два разработчика используют AI для личных задач и весь эффект виден глазами. Она становится полезной позже: когда появляются несколько команд, бюджет, требования безопасности, SLA, внутренние правила и вопрос «почему мы платим за это каждый месяц?».

Как только AI выходит за рамки пилота, без диагностики начинаются четыре проблемы.

Первая: бюджет уходит в самые заметные, а не в самые узкие места. Компания покупает более дорогие модели и агентные платформы, хотя реальный bottleneck в другом: AI не видит контекст проекта, тесты запускаются вручную, ревью перегружено, а результат нельзя воспроизвести без конкретного чемпиона.

Вторая: невозможно отделить пользу от активности. Количество запросов к AI растёт, сотрудники довольны, демо выглядят лучше. Но delivery-метрики не меняются. Без измерения зрелости руководитель видит движение, но не понимает, стало ли это движением бизнеса.

Третья: растёт риск. AI может ускорить генерацию кода быстрее, чем компания успеет усилить проверку. Если агент пишет больше, а тестовая база, code review и observability остаются прежними, CTO получает не productivity gain, а новый источник change failure.

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

Хороший замер даёт три управленческих эффекта.

1. Показывает, где именно находится ограничение: в интерфейсе, данных, тестах, ответственности, культуре ревью или ритме принятия решений.

2. Помогает выбрать следующий инвестиционный шаг, а не покупать «ещё AI» поверх старого процесса.

3. Создаёт язык для разговора между CTO, CEO, CDTO и руководителями разработки: обсуждать не ощущения от AI, а конкретные разрывы в операционной системе компании.

Именно поэтому AI-native зрелость лучше смотреть как профиль, а не как один уровень.

Почему «мы на L4» почти ничего не значит

Здесь L4 можно понимать как уровень корпоративной AI-фабрики: у компании уже есть централизованная AI-инфраструктура, общие агенты, права доступа, аудит, наблюдаемость, интеграции и правила использования. Это уже не личные промпты отдельных сотрудников, но ещё не гарантия бизнес-эффекта.

Одна шкала зрелости удобна для совета директоров. Были на L1, стали на L3, идём к L5. Красивая стрелка, понятный прогресс.

Но в AI-трансформации такая простота быстро превращается в самообман.

Если спросить десять компаний, использующих AI, на каком они уровне, почти каждая захочет поставить себя где-то в верхней половине шкалы. У кого-то есть Copilot. У кого-то внутренний чат-бот. У кого-то агент создаёт тикеты. У кого-то команда экспериментирует с MCP и локальными скиллами. Всё это можно назвать «agentic workflow», если очень хочется.

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

• насколько глубоко AI встроен в операции;

• какую задачу компания пытается решать;

• через какой интерфейс человек получает AI-мощность;

• кто владеет результатом;

• что компания производит наружу;

• где принимаются решения;

• как быстро организация замыкает цикл «сигнал → решение → изменение → проверка».

Если всё это сложить в один «уровень», получится удобный, но слабый управленческий показатель.

Последний риск уже виден в исследованиях. В DORA Report 2024 отмечается, что AI повышает индивидуальную продуктивность, flow и удовлетворённость разработчиков, но может иметь неожиданные trade-off'ы для стабильности и throughput поставки. Вывод неприятный, но честный: AI сам по себе не отменяет инженерные основы — small batch size, тестирование, стабильные приоритеты и качество платформы разработки.

Семь осей вместо одной лестницы

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

Для управленческой диагностики я бы формулировала оси так.

Для разработки важнее всего четыре оси: где AI встроен в процесс, через какой интерфейс он работает, на какие факты опирается при инженерном решении и как влияет на цикл изменения. Поэтому дальше я сфокусируюсь на A, C, F и G. Остальные оси важны на уровне корпоративной трансформации, но для engineering-аудита их можно оставить как фон.

Ось A: AI-субстрат, или где AI реально работает

На нижнем уровне AI живёт в презентациях и личных подписках. Сотрудники копируют контекст в чат, хранят промпты в Notion, показывают удачные демо. Компания называет это трансформацией, но процесс от этого не меняется.

Следующий уровень — команды, где появляются общие правила, репозитории промптов, внутренние практики, агенты для типовых задач. Это уже полезно, но часто держится на энтузиастах. Ушёл чемпион — через квартал команда откатилась к личным чатам.

Более зрелый уровень начинается там, где AI становится частью операционного цикла. В разработке это означает, что агент не просто отвечает на вопрос, а участвует в процессе изменения системы: понимает проект, находит связанные места, предлагает правку, запускает проверку, читает ошибку, уточняет решение.

И здесь возникает первый управленческий фильтр: если AI не связан с реальным инженерным циклом, его сложно привязать к P&L и метрикам разработки.

GitHub в исследовании Quantifying GitHub Copilot’s impact on developer productivity and happiness прямо пишет, что продуктивность разработчика нельзя сводить к простому «output/input». Важны фокус, ощущение прогресса, удовлетворённость, качество и контекст задачи. Для CTO это означает: метрика «сколько строк сгенерировал AI» почти бесполезна. Нужны метрики инженерного потока.

Ось C: интерфейс важнее, чем кажется

Самый частый корпоративный антипаттерн — дорогая AI-инфраструктура, к которой люди обращаются через чат.

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

В разработке это особенно заметно. Код нельзя качественно менять только по переписке. Нужно понимать структуру проекта, зависимости, типы, тесты, конфигурации запусков, ошибки компиляции, покрытие и runtime-поведение. Если агент этого не видит, он может звучать уверенно и всё равно ошибаться.

Поэтому следующий этап рынка — не просто «модель умнее», а «AI ближе к рабочей среде». Для разработчиков это IDE, CI, issue tracker, система логов, код-ревью и документация. Чем меньше ручного переноса контекста между этими средами, тем выше шанс, что AI ускоряет процесс, а не создаёт ещё один слой коммуникации.

На этом принципе строится класс IDE-native агентов: агент работает не только с текстом промпта, а с фактами, которые уже есть в среде разработки. Для экосистемы JetBrains это особенно заметно: IDE знает структуру проекта, символы, зависимости, конфигурации запусков, результаты тестов и ошибки. Если AI использует эти данные, он меньше угадывает и чаще работает как часть инженерного процесса.

Ось F: AI как часть мышления команды, а не генератор саммари

Есть разница между «AI помогает подготовить материалы» и «AI участвует в принятии инженерного решения».

В первом случае он делает саммари, пишет черновики, предлагает варианты. Полезно, но когнитивный контур остаётся прежним: решение принимает человек по своему опыту, политическому контексту и уверенности в конкретной презентации.

Во втором случае AI работает с фактами системы. Например:

• показывает, где используется метод перед рефакторингом;

• находит связанные тесты;

• объясняет, почему падает конкретная конфигурация запуска;

• предлагает минимальное изменение и проверяет его;

• помогает оценить риск изменения до ревью.

Это уже другое качество. Агент не просто «пишет». Он помогает команде думать о системе.

Для CTO это важнее, чем звучит. В больших кодовых базах основная стоимость часто не в наборе кода, а в понимании последствий. Если AI ускоряет набор, но не помогает с последствиями, вы получаете локальное ускорение и системный риск.

Ось G: ритм изменения

Руководители часто говорят про скорость. Но скорость ответа модели и скорость изменения организации — разные вещи.

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

Для engineering-организации важен не «AI отвечает за 5 секунд», а плотность цикла:

1. появилась задача;

2. найден релевантный контекст;

3. предложено изменение;

4. изменение проверено;

5. ошибка разобрана;

6. решение доведено до ревью или релиза.

DORA 2024 здесь полезен как отрезвляющий источник: AI может улучшать индивидуальную продуктивность, но без устойчивых инженерных практик и стабильных приоритетов организация не получает автоматического роста delivery performance. CTO нужно смотреть не на «активность AI», а на то, как меняются lead time, stability и throughput.

Где компании чаще всего ломаются

Дорогая фабрика на чат-интерфейсе

Компания строит платформу, реестр агентов, права доступа, аудит, биллинг, observability. А пользователи продолжают работать через чат-окно.

Итог: мощная инфраструктура проходит через узкое горлышко ручного ввода и длинного текстового ответа. Бюджет уже enterprise, пользовательский опыт всё ещё как у личной подписки на чат-бота.

AI пишет код, но не снижает риск изменения

Команда быстрее получает черновики функций, тестов и документации. Но review time, change failure rate и количество возвратов из QA почти не меняются.

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

Практика держится на одном чемпионе

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

Итог: на демо всё выглядит убедительно, но это не организационная зрелость. Это локальная экспертиза одного человека.

Дорогие инструменты, старое мышление

AI собирает данные, пишет саммари, готовит варианты, но решения принимаются так же, как раньше: по презентациям, иерархии и интуиции.

Итог: AI становится генератором обоснований, а не частью системы принятия решений.

• доля сценариев, которые воспроизводятся на уровне команды, а не одного чемпиона;

• число команд, использующих общий AI-workflow, а не личные промпты;

• доля задач, где агент опирался на факты проекта: зависимости, тесты, конфигурации запусков, ошибки;

• время онбординга нового разработчика в AI-assisted workflow;

• число повторяемых сценариев, которые команда может описать как процесс: разбор падения теста, подготовка рефакторинга, сбор контекста для ревью.

Что это даёт руководителю на практике?

Если lead time падает, а change failure rate растёт, AI ускоряет разработку, но ломает контроль качества. Значит, следующий шаг — не новые модели, а тесты, ревью, observability и правила использования агента.

Если AI активно используют, но review cycle time не меняется, bottleneck не в написании кода. Возможно, агент должен помогать с подготовкой контекста для ревью, объяснением изменений и проверкой риска.

Если эффект есть только у одной команды, значит, компания нашла сильный локальный сценарий, но ещё не построила платформенную практику. Следующая инвестиция должна идти в воспроизводимость: шаблоны, shared context, IDE-интеграцию, обучение и метрики.

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

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

Главная боль: AI рядом с разработкой ещё не AI в разработке

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

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

Разрыв 1: агент не видит проект

Обычный чат-ассистент работает с тем контекстом, который человек успел скопировать. В enterprise-разработке этого мало. Ошибка может быть не в одном файле, а в связке зависимостей, конфигураций, тестов и runtime-поведения.

Отсюда понятная боль CTO: команда получает быстрые ответы, но не получает надёжной проверки. Модель может предложить правку, которая выглядит логично в пределах одного файла, но ломает контракт в другом модуле, не учитывает профиль запуска или не проходит интеграционный тест.

Это хорошо ложится на выводы DORA 2024: AI может повышать индивидуальную продуктивность и satisfaction, но без инженерных практик вокруг проверки и стабильности поставки появляется trade-off. Проще говоря, скорость генерации растёт быстрее, чем способность организации контролировать последствия.

Разрыв 2: AI ускоряет набор, но не проверку

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

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

GitHub Research в исследовании Copilot отдельно подчёркивает, что developer productivity нельзя сводить к «output/input». Для сложной разработки важны фокус, прогресс, качество и контекст задачи. Поэтому вопрос для CTO не «насколько быстро AI пишет код», а «насколько быстро команда получает проверенное изменение».

Разрыв 3: успешные сценарии не масштабируются на команду

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

Здесь полезны инструменты, которые живут не отдельно от инженерной среды, а внутри неё. Например, агент в JetBrains IDE может опираться на уже существующие факты проекта, а не просить разработчика каждый раз вручную переносить контекст в чат. Это не снимает ответственность с человека, но убирает часть ручной транспортировки между моделью и реальностью кодовой базы.

Для рынка это важный сдвиг. На фоне массового adoption из Stack Overflow Survey 2024 дифференциация смещается от «у нас тоже есть AI» к вопросу «насколько этот AI встроен в проверяемый рабочий процесс».

Типичный enterprise-сценарий

Представим задачу: нужно изменить поведение сервиса в большой Java/Kotlin-кодовой базе. Например, бизнес просит поменять правило расчёта статуса клиента после платежа. На словах задача выглядит небольшой. В реальности она может затрагивать сервисный слой, mapper, DTO, интеграционный тест, feature flag и пару неочевидных consumers в соседнем модуле.

В чат-модели разработчик вручную копирует фрагменты кода, пересказывает контекст, получает предложенный фикс, переносит его в IDE, запускает тесты, ловит ошибку, снова копирует stack trace в чат и ждёт новый ответ. На каждом шаге теряется контекст. На каждом шаге человек выступает прокладкой между моделью и реальностью проекта.

Более полезный сценарий выглядит иначе. Агент находит usages метода расчёта статуса, видит связанные тесты, предлагает минимальное изменение, запускает релевантную test configuration, получает падение на контракте DTO/mapper, уточняет фикс и собирает короткое объяснение для ревью: что изменилось, какие проверки прошли, где остаётся риск. Разработчик по-прежнему принимает решение, но тратит меньше времени на ручную транспортировку контекста.

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

Почему «AI пишет код» больше не дифференцирует продукт

Фраза «AI пишет код» уже стала рыночным шумом. Код пишут многие инструменты. Иногда хорошо. Иногда уверенно и неправильно.

Stack Overflow Survey 2024 показывает массовое принятие AI-инструментов, но одновременно снижение доли разработчиков с позитивным отношением. Рынок взрослеет: одного вау-эффекта уже мало.

Для CTO вопрос звучит иначе:

• можно ли доверить AI часть инженерного процесса;

• на какие факты он опирается;

• как он проверяет результат;

• как это влияет на delivery metrics;

• масштабируется ли практика на команду;

• не растёт ли риск вместе со скоростью.

Поэтому сильное позиционирование для AI-агента в разработке — не «мы генерируем код», а «мы помогаем безопасно проводить изменения в сложной системе».

Практический чек-лист для управленческой встречи

Если в компании уже есть AI-инициатива в разработке, можно пройтись по короткому чек-листу.

1. AI встроен в IDE и инженерные инструменты или живёт отдельным чатом?

2. Агент видит весь проект или только фрагменты, которые ему скопировал человек?

3. Он умеет использовать результаты статического анализа, тестов и запусков?

4. Есть ли связь между AI-активностью и метриками lead time, review time, change failure rate?

5. Кто предлагает следующую итерацию после ошибки: человек вручную или агент на основе фактов проекта?

6. Можно ли воспроизвести успешный AI-сценарий на уровне команды?

7. Что произойдёт, если чемпион уйдёт: практика останется или откатится к личным промптам?

8. Есть ли контроль качества AI-изменений до попадания в ревью?

9. Смотрит ли команда метрики в динамике по типам задач, а не одним средним числом по всем изменениям?

Если большинство ответов уходит в сторону «чат», «копируем руками», «работает у одного сильного разработчика», компания находится ближе к ранней стадии AI-использования, даже если в презентации написано другое.

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

Вывод:

AI-native — это не уровень в презентации и не наличие агентов в демо. Это профиль компании по нескольким осям: инфраструктура, амбиция, интерфейс, ответственность, ценность, мышление и ритм.

Рынок уже прошёл стадию «давайте попробуем AI». По данным Stack Overflow, большинство разработчиков либо уже используют AI-инструменты, либо планируют это сделать. По DORA, AI даёт индивидуальные выгоды, но не отменяет инженерные основы и может создавать trade-off’ы для поставки. По исследованиям GitHub, продуктивность разработчика нельзя свести к количеству сгенерированных строк.

Для CTO из этого следует простой вывод: AI-трансформацию нужно измерять не активностью инструментов, а изменением инженерного цикла.

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

В этой картине выигрывают не те инструменты, которые громче обещают «AI пишет код», а те, которые сокращают расстояние между моделью и проверяемыми фактами проекта. Для enterprise-разработки это обычно означает движение от внешнего чата к агенту внутри IDE и инженерного workflow: ближе к тестам, ошибкам, зависимостям, запускам и ревью.

Источники

1. Stack Overflow Developer Survey 2024: AI tools in the development process — https://survey.stackoverflow.co/2024/ai

2. GitHub Research: Quantifying GitHub Copilot’s impact on developer productivity and happiness — https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/

3. DORA / Google Cloud: Accelerate State of DevOps Report 2024 — https://dora.dev/research/2024/dora-report/