Что будет после AI: разработка без швов, живой контекст и новая роль человека

Короткий ответ: после AI разработка не просто станет быстрее. Она начнет перестраиваться вокруг контекста, намерений, правил и автоматической проверки результата. Код останется важным, но все чаще будет выглядеть как побочный продукт хорошо собранного контекста. Роль разработчика сместится от ручного склеивания Jira, Slack, логов, базы, Git и IDE к проектированию среды, где эти связи собираются сами.

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

Содержание

• Главные выводы
• AI как трансформационность, а не трансформация
• Что такое швы между системами
• Почему разработчик сегодня часто работает адаптером
• Контекст становится главным активом разработки
• Почему логи, Git history и AI-сессии становятся ценными
• Бэклог как многомерная поверхность
• Что происходит с product management
• Теория ограничений в мире быстрых AI-циклов
• Невидимая цена автоматизации: obligations
• Человек в центре: личная цифровая среда
• Что делать командам уже сейчас
• FAQ

Главные выводы

1. AI не просто ускоряет разработчика. Он растворяет швы между инструментами: таск-трекером, кодом, логами, мониторингом, CRM, документацией и коммуникациями.
2. Код становится сдачей с хорошо понятой задачи. Чем лучше собран контекст и критерии успеха, тем меньше ручного кодинга остается человеку.
3. Главный дефицит смещается в контекст. Нужно не только написать функцию, а понять клиента, фичефлаги, логи, историю изменений, похожие задачи и последствия.
4. AI-сессии надо сохранять. В них зафиксирован не только ответ модели, но и совместный процесс мышления человека и агента.
5. Бэклог перестает быть списком. Он превращается в динамическое поле связей между задачами, клиентами, кодом, метриками, историей и бизнес-намерениями.
6. Приоритизация меняется. Если контекст действительно собран, бизнес может менять верхнеуровневые ползунки, а система перестраивает поле задач.
7. Автоматизация создает новые обязательства. Чем выше уровень сервиса, тем больше скрытых зависимостей: API, условия, тарифы, правила, политики и поддержка интеграций.
8. Практический ответ - владеть своей средой. Сохранять контекст, строить собственную память, индексировать рабочие артефакты и делать AI продолжением воли человека, а не еще одним внешним интерфейсом.

AI как трансформационность, а не трансформация

Обычный взгляд на внедрение AI выглядит так: компания берет существующий процесс, прикручивает к нему чат-бота, интеграцию или ассистента, а потом ждет, что разработчики станут условно "10x". Jira остается Jira, Slack остается Slack, CRM остается CRM, а сверху появляется дашборд, который можно показать руководству.

В транскрипте предложен другой взгляд: происходящее похоже не на разовую трансформацию, а на трансформационность. То есть меняется не только инструмент, а сам способ изменения. Пока команда внедряет один подход, появляются новые модели, новые MCP-интеграции, новые паттерны, новые способы работы с агентами. Процесс не успевает застыть.

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

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

Что такое швы между системами

Швы между системами - это места, где человек вручную переносит смысл из одного инструмента в другой.

Примеры швов:

• прочитать задачу в Jira и вспомнить обсуждение в Slack;
• открыть мониторинг и связать ошибку с жалобой клиента;
• понять, какие фичефлаги включены у конкретного клиента;
• найти похожий баг в Git history;
• вручную собрать контекст из документации, логов и тикетов;
• объяснить модели, где лежит нужный код и какие ограничения важны;
• после генерации проверить, не нарушены ли внутренние правила команды.

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

Ключевой тезис: чем тоньше швы, тем меньше человеку нужно быть оператором интерфейсов.

Почему разработчик сегодня часто работает адаптером

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

Старый слой работы	Что делает человек	Что начинает делать AI
Таск-трекер	Читает задачу и восстанавливает смысл	Резюмирует задачу, ищет недостающие детали
Коммуникации	Вспоминает обсуждения	Подтягивает релевантные сообщения и решения
Мониторинг	Ищет ошибки и паттерны	Связывает инциденты с изменениями и клиентами
Кодовая база	Держит архитектуру в голове	Строит карту модулей, зависимостей и рисков
Git history	Вручную ищет похожие решения	Находит похожие изменения и объясняет контекст
Проверка	Запускает тесты и ревьюит diff	Предлагает тесты, проверяет гипотезы, ищет регрессии

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

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

Контекст становится главным активом разработки

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

Что должен понять AI-агент перед работой:

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

Контекст для ИИ - это не один большой prompt. Это динамическая связанная система, где тикеты, клиенты, логи, фичефлаги, код, Git history, документация и AI-сессии ссылаются друг на друга.

Если такая система собрана, задача перестает быть строкой в бэклоге. Она становится входной точкой в граф реальности компании.

Почему логи, Git history и AI-сессии становятся ценными

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

Логи

Логи - близкий к ground truth источник того, что действительно происходит в системе. Тикет может быть неточным, клиент может описать проблему неполно, разработчик может ошибиться в гипотезе. Логи фиксируют поведение.

AI-агенту важны:

• ошибки и stack trace;
• пользовательские действия;
• частота повторения проблемы;
• временная связь с релизами;
• признаки деградации;
• реальные пути пользователей.

Git history

Git history показывает, как система становилась такой, какая она есть. Для модели это не просто список коммитов, а история решений, компромиссов, откатов и повторяющихся типов задач.

Если индексировать Git history вместе с AST-деревом и документацией, AI может не только написать код, но и понять, как в этой системе обычно решают похожие задачи.

AI-сессии

Самая недооцененная часть - сессии с Claude, ChatGPT, Cursor или другими агентами. В них хранится не только финальный diff. Там виден путь:

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

Если 10 разработчиков решают 50 задач с AI и сохраняют сессии, через некоторое время можно увидеть не 50 уникальных историй, а набор повторяющихся типов задач. Для каждого типа появляется почти готовый маршрут: какие данные собрать, какие инструменты вызвать, какие проверки пройти.

Это меняет смысл ревью. Одного pull request review становится мало. Важным становится review процесса мышления: почему агент пошел этим путем, какие допущения сделал человек, где не хватило контекста.

Бэклог как многомерная поверхность

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

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

В таком представлении задача не лежит отдельно. Она имеет координаты в пространстве:

Измерение	Что дает
Клиент	Важность, сегмент, риск, история обращений
Код	Затронутые модули, зависимости, сложность
Логи	Реальное поведение и частота проблемы
Git history	Похожие решения, прошлые ошибки, авторы
AI-сессии	Повторяемые маршруты решения
Метрики	Что должно измениться после релиза
Политики	Как команда принимает решения и оформляет изменения

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

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

Что происходит с product management

Если бэклог - не список, то product management перестает быть сортировкой карточек. Он становится поиском аттрактора на этой многомерной поверхности: куда система естественно тянется, если учитывать клиентов, код, метрики, риски и стратегию.

Практически это означает:

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

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

Теория ограничений в мире быстрых AI-циклов

В выступлении используется теория ограничений Голдратта: в сложной системе всегда есть bottleneck, и после его устранения ограничение переезжает в другое место. Раньше это было удобно: нашли узкое место, улучшили, потом нашли следующее.

AI ускоряет переезд bottleneck'ов. Если разработка стала в разы быстрее, узкое место может оказаться:

• в постановке задач;
• в доступе к данным;
• в тестировании;
• в безопасности;
• в ревью;
• в релизном процессе;
• в продуктовой аналитике;
• в юридических согласованиях;
• в способности бизнеса принимать решения.

Проблема не в том, что bottleneck появился. Он всегда есть. Проблема в том, что он становится динамическим. Команда может устранить одно ограничение утром и получить другое к вечеру.

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

Невидимая цена автоматизации: obligations

Еще один сильный тезис транскрипта - автоматизация не всегда уменьшает количество обязательств. Она часто меняет их форму.

Пример: предприниматель вручную выставляет инвойсы. Потом подключает сервис, который делает это автоматически. Ручной труд ушел, но появились новые obligations:

• пройти регистрацию;
• доказать соответствие требованиям сервиса;
• интегрироваться;
• следить за API;
• принимать новые terms of conditions;
• реагировать на изменения тарифов;
• читать уведомления;
• поддерживать зависимость.

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

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

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

Это не аргумент против сервисов. Это аргумент за трезвый учет зависимости.

Человек в центре: личная цифровая среда

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

В практическом виде это начинается с простых вещей:

• сохранять свои AI-сессии;
• архивировать важные транскрипты, видео, заметки и документы;
• строить личный слой поиска по собственным материалам;
• делать быстрый capture ссылок, файлов, звонков и обсуждений;
• транскрибировать рабочие записи;
• связывать материалы в коллекции;
• не терять контекст при смене сервиса.

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

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

Что делать командам уже сейчас

Ниже - практический список действий, который следует из транскрипта и не требует ждать AGI.

1. Перестать считать AI только инструментом кодинга

Оценивайте не количество AI-generated pull requests, а уменьшение швов между системами. Полезные вопросы:

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

2. Собрать карту контекста разработки

Минимальный список:

• таск-трекер;
• кодовая база;
• документация;
• Git history;
• логи;
• мониторинг;
• клиенты и тарифы;
• фичефлаги;
• коммуникации;
• AI-сессии.

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

3. Начать сохранять AI-сессии

Если команда активно работает с Claude, ChatGPT, Cursor или аналогами, сессии нельзя воспринимать как временный мусор. В них находится процесс решения задач.

Что сохранять:

• исходное намерение;
• контекст, который дали модели;
• вызванные инструменты;
• промежуточные ошибки;
• финальное решение;
• проверки;
• выводы для похожих задач.

4. Индексировать логи и Git history не только для людей

Логи и история изменений должны быть доступны агенту в понятной форме. Это не обязательно означает немедленный сложный knowledge graph. Можно начать с простого:

• шаблонов поиска по логам;
• связки тикетов с релизами;
• описания модулей;
• регулярных summary по изменениям;
• сохранения причин откатов и hotfix'ов.

5. Перевести правила команды в политики

Если агент должен работать автономнее, ему нужны не устные привычки, а явные политики:

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

6. Измерять поток целиком

Не ограничивайтесь метрикой "сколько кода написал AI". Смотрите:

• время от задачи до релиза;
• долю ручного сбора контекста;
• число возвратов на ревью;
• число регрессий;
• время диагностики инцидента;
• скорость проверки гипотез;
• эффект фичи по бизнес-метрике.

7. Обсуждать ownership контекста

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

FAQ

Что будет после AI в разработке?

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

Заменит ли AI разработчиков?

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

Почему MCP важен для AI-разработки?

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

Что такое живой граф разработки?

Живой граф разработки - это динамическая связка задач, кода, логов, клиентов, фичефлагов, документации, Git history, метрик и AI-сессий. Он нужен, чтобы агент мог собирать релевантный контекст под конкретную задачу, а не работать по изолированному описанию в тикете.

Зачем сохранять AI-сессии?

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

Почему бэклог перестает быть списком?

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

Что делать бизнесу, который только начинает?

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

Как не потерять контроль над AI-средой?

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

Вывод

Главный вопрос не в том, станет ли AI еще умнее. Важнее другое: что произойдет, когда исчезнут швы между инструментами. Тогда разработка перестанет быть цепочкой ручных переходов между Jira, Slack, IDE, логами, документацией и CRM. Она станет динамической средой, где намерение проходит через контекст, политики, инструменты и проверку.

Для команд это вызов. Нельзя просто купить AI-ассистента и оставить процесс прежним. Нужно строить память, сохранять сессии, связывать источники, измерять поток и возвращать человека в центр среды.

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