На первый взгляд “AI-native” звучит как очередной броский термин для компаний, где всем выдали ChatGPT, Claude Code, Cursor и пару внутренних ботов. Но это впечатление быстро проходит, когда начинаешь смотреть не на инструменты, а на то, как реально работает компания. Разберем на примере.

В обычной ИТ-компании, как правило, есть продуктовые команды: аналитики, разработчики, QA, архитекторы, DevOps, PM, менеджеры продукта и т.п. Есть документация, backlog, Jira, Confluence, Git, pull request, релизы, инциденты, бесконечные созвоны и встречи. То есть всё то, что мы привыкли называть разработкой продукта. Но если присмотреться, то окажется, что суть этой работы — не работа над продуктами и даже не принятие решений. Суть этой деятельности — перенос контекста.

Один человек услышал клиента. Второй оформил требование. Третий понял его по-своему. Четвёртый вспомнил, что похожее уже обсуждали год назад. Пятый нашёл старую задачу. Шестой сказал, что архитектурно так делать нельзя. QA обнаружил неоднозначность. РП пересобрал статус. Разработчик уточнил, что именно имелось в виду. Потом всё это попало в разработку, релиз, поддержку, документацию и снова вернулось в виде кучи новых вопросов.

Снаружи это выглядит как привычная разработка продукта. Но по сути это огромная система преобразования информации. И именно здесь начинается разговор про AI-native.

Давайте представим:

Что произойдет с компанией, производящей интеллектуальные продукты, если значительная часть интеллектуальной работы по чтению, сжатию, поиску, сопоставлению, черновому анализу, генерации вариантов и проверке информации станет дешевле в 10 раз, быстрее в 10 раз и будет полностью выполняться машинами?

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

И главная мысль такая:

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

Компания как информационный конвейер

Если описывать компанию через роли или должности, то, например, для ИТ это будут: аналитики, разработчики, QA, архитекторы и т.д. Если смотреть с точки зрения основного производственного процесса и информации, то компания — это конвейер, в котором один тип информации постоянно превращается в другой:

клиентский сигнал
    → требование
        → анализ
            → дизайн
                → код
                    → тесты
                        → релиз
                            → эксплуатация
                                → обратная связь
                                    → новые требования

К примеру, клиент сказал: “нам неудобно работать с отчётами”. Это ведь ещё не задача для программиста?

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

То есть компания постоянно преобразует смыслы. И у этого потока есть три важные характеристики:

1. Скорость. Как быстро сигнал проходит путь от идеи до результата?

2. Потери. Сколько смысла/контекста теряется/искажается на каждом переходе между людьми, отделами, документами, системами и продуктовыми решениями?

3. Стоимость обработки. Сколько стоит превратить один входной сигнал в качественный результат?

Люди читают с ограниченной скоростью и держат в голове ограниченный контекст. Человек устает. Через год после начала средненького проекта никто в здравом уме уже не будет перечитывать весь бэклог, всю историю переписки, все ADR, все PR, все инциденты и все требования клиента.

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

Где на самом деле теряется время проекта

Мы часто думаем, что проект тормозит из-за нехватки людей. Не успеваем с проектом? Нужен ещё один разработчик! А к нему нужен дизайнер, аналитик и тестировщик. А потом для них всех ещё один РП. Так?

Иногда работы действительного много и нужны еще люди. Иногда и так понятно (хоть и не всем и не всегда), что “9 женщин не родят за месяц”. Но часто реальная причина торможения глубже: контекст проекта стал слишком большой. Люди просто уже не в состоянии его эффективно продавливать сквозь все этапы производства.

“А где это у нас описано, кто-нибудь может сказать?”
“Почему мы полгода назад приняли такое проектное решение?”
“Без Пети никто не понимает этот модуль, давайте его тоже позовем на встречу”
“В Confluence что-то есть, но не факт, что это актуально, лучше смотреть код...”
“Надо обсудить голосом, потому что из описания мне ничего непонятно!”
“Вышел новый разработчик, но ему нужно три месяца, чтобы начать делать реальные задачи.”

Знакомы такие ситуации?

Всё это не просто мелкие “бытовые” проблемы. Это сигналы того, что информация в компании плохо переносятся между людьми, системами и артефактами.

Контекст живёт в головах людей. Решения живут в переписках. Архитектурные ограничения живут в памяти старожилов. Требования живут в задачах, подзадачах, в цепочках и ворохе несвязанных задач и комментариев в Jira. Если хочешь что-то понять, то читай примерно все, а лучше собери всех на совещание часа эдак на 4 и пусть рассказывают. А продукт подождет…

В такой компании человек больше работает не над созданием продукта, а над восстановлением потерянного смысла. Он ищет, почему так было сделано и что будет, если это изменить. Уточняет детали и вводные. Дописывает задачу или пересказывает контекст коллеге. Исследует легаси. Объясняет новичку, как устроен модуль. Собирает руками для себя то, что уже где-то было давно собрано, но никто не помнит, где это или не может дать гарантию актуальности.

И в какой-то момент становится понятно: проблема не в том, как мы умеем писать код, тесты или документацию, как проводить совещания или работать в команде. Как только проект переваливает определенный предел, все наши системы, фреймворки и ритуалы становятся бессильны, чтобы работать с таким большим контекстом.

Что AI меняет на самом деле

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

Например, раньше у нас был документ:

Вот как мы пишем user story:
...

В AI-native компании это skill или workflow, который может за минуты подготовить черновик, проверить структуру, найти похожие задачи, подсветить недостающие критерии сдачи и передать результат на утверждение человеку.

Раньше у нас был чек-лист:

Вот как мы проверяем требование перед разработкой:
...

В AI-native компании это становится eval — проверкой, которая за секунды бесстрастно прогоняется каждый раз весь результат, а не только тогда, когда у QA или аналитика есть на это время и желание.

Раньше у нас был опыт архитектора:

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

В AI-native компании эти знания доступны как контекст: ADR, история решений, ограничения, связи с кодом и инцидентами.

То есть главный переход будет примерно такой:

документы         → контекст
инструкции        → skills
процессы          → workflows
критерии качества → evals
политики          → guardrails
решения           → decision logs
роли              → зоны ответственности

Вот это и есть суть AI-native - “наши знания, процессы и критерии качества становятся исполняемыми и постоянно совершенствуются”.

Что остается человеку

Самый опасный способ говорить про AI-native — это свести всё к вопросу: “кого заменит AI?”. Такой вопрос слишком узкий.

Правильный вопрос звучит гораздо банальнее:

Чем нужно заниматься человеку, когда часть ранее рутинных и долгих задач будет быстро и дешево делать машина?

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

Например:

1. Постановка задачи

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

2. Риск выбора

Когда AI за минуты может сгенерировать десяток вариантов, ценность смещается к способности выбрать лучший, правильный вариант. Что хорошо? Что уместно? Что соответствует продукту? Что не сломает доверие пользователя? Что выглядит технически красиво, но стратегически ошибочно?

3. Проверка

Чем быстрее и больше AI производит, тем важнее становится скорость и качество проверки. Не просто “мне кажется это нормально”. А проверка по критериям. По тестам. По требованиям. По архитектурным ограничениям. По пользовательскому смыслу. По рискам.

4. Ответственность

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

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

Почему это особенно важно для ИТ

ИТ-компании первыми должны почувствовать этот сдвиг. Потому что мы давно живём в мире, где абстракции превращаются в исполняемые системы. Мы знаем, что такое pipeline. Мы знаем, что такое CI и автоматические проверки. Мы знаем, что такое инфраструктура как код или что такое контракт API.

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

Раньше мы спрашивали:

Как нам быстро, дешево и качественно сделать этот продукт?

Теперь важен другой вопрос:

Как нам построить систему, которая будет быстро, надежно и дешево делать подобные продукты снова и снова?

Это и есть переход к AI-native мышлению.

Главный риск — остаться на уровне инструментов

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

Она просто стала компанией со множеством инструментов. Это полезно. Но это не новая операционная модель.

AI-native начинается там, где компания начинает задавать себе такие вопросы как:

Какие знания у нас критичны, но живут только в головах сотрудников (или еще хуже – в головах сторонних консультантов)?
Какие процессы у нас повторяются постоянно, но каждый раз вручную?
Какие критерии качества у нас есть, но они не проверяются автоматически?
Где человек тратит время не на принятие решений, а на восстановление или передачу контекста?
Где AI может убрать ручной перенос информации?
Где и как результат работы AI можно проверить достаточно надежно?
Какая часть нашей документации может стать инструментом для AI?

Не все ответы будут приятными. Но именно из этих вопросов и рождается AI-native компания.

Финальный вывод

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

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

доступным контекстом
исполняемыми skills
управляемыми workflows
проверяемыми evals
прозрачными decision logs
безопасными агентными действиями
зонами ответственности ЛЮДЕЙ

Именно поэтому главный сдвиг звучит так:

Нужно перестать думать только о том, как делать продукты. Нужно начать думать о том, как делать систему, которая делает продукты.

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

И чем дальше развивается AI, тем важнее становится вопрос:

Способна ли ваша компания превратить свои знания и процессы в систему, которая работает быстрее, чем теряется контекст?

Источники (вдохновения):

1. AI-Native Playbook — A practical guide to rebuilding companies, teams, and individual work around AI agents

2. Anthropic — Effective context engineering for AI agents

3. Anthropic — Building effective agents

4. OpenAI Developers — Building an AI-Native Engineering Team

5. Harvard Business School / BCG — Navigating the Jagged Technological Frontier

6. BCG — Are You Generating Value from AI? The Widening Gap