Школьник может открыть AI-инструмент разработки, описать идею и за несколько часов получить интерфейс, API и базу данных, развёрнутые на сервере. Это наблюдение сформулировал инженер Алексей Стукалин в статье на Хабре о структуре IT-команды будущего, и оно точно описывает то, что сейчас видит любой, кто нанимает разработчиков или сам ведёт проекты: производство кода подешевело в разы, а понимание того, почему система вообще работает, — нет. За внешне убедительным результатом почти всегда скрываются непонятная архитектура, неконтролируемые зависимости, отсутствие тестирования и требования безопасности, добавленные «во второй версии».

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

Аналитик перестаёт писать ТЗ и начинает писать контекст

В модели Стукалина системный и бизнес-анализ объединяются в одном специалисте, чья задача — не составить традиционное техзадание, а собрать структурированный и понятный человеку и машине контекст: предметную область, бизнес-правила, ограничения, модель данных, сценарии и критерии приёмки. Автор называет такой формат «Vibe++» и отмечает: главным артефактом разработки постепенно становится не программный код, а качественно сформированный контекст, из которого этот код может быть создан.

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

Архитектор больше не главный по клавиатуре

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

Тестировщик становится тем, кто ломает систему нестандартно

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

Зачем в команде нужен «фантазёр»

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

Какие роли перестают требовать отдельного человека — но не исчезают как функция

Автор отдельно разбирает три позиции, которые в маленькой AI-native компании перестают быть штатной единицей, хотя сама функция остаётся:

• Технический писатель. Значительная часть документации формируется автоматически из требований, кода и истории изменений — но кто-то должен задать структуру, из которой это можно собрать.
• Дизайнер. Для небольшого продукта дизайн-систему и UX-принципы достаточно определить один раз, дальше их соблюдают и люди, и ИИ; штатный дизайнер на каждую задачу не нужен.
• Проектный менеджер. Декомпозицию, статусы и протоколирование можно в основном автоматизировать, а функцию управления распределить между аналитиком и архитектором — но коммуникация с заказчиком как отдельная задача никуда не девается.

Разница между «роль исчезла» и «роль перестала требовать отдельного человека» здесь принципиальна: если в команде никто не берёт на себя функцию явно, она не автоматизируется сама по себе — она просто перестаёт выполняться, и это вскрывается уже на проде.

Проблема, которую этот сдвиг ролей не решает сама по себе

Автор фиксирует ключевое узкое место AI-разработки — потерю контекста моделью: она может забыть принятое ограничение, заново принять уже отменённое решение или предложить архитектуру, которая противоречит предыдущей. Решение, которое он предлагает, — не процесс ревью как таковой, а единая машиночитаемая база знаний: описание бизнеса, требования, архитектура, правила разработки, требования безопасности, история решений и тестовые сценарии, оформленные как «паспорт проекта» в markdown и обновляемые вместе с кодом. Без такого артефакта каждая новая сессия работы с ИИ начинается заново, и команда компенсирует это временем людей на постоянные повторные объяснения.

Кому и когда стоит применять эту модель ролей

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