Как AI меняет программистов, команды и IT-компании

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

Кирилл формулирует целевой образ: продуктовый специалист прорабатывает гипотезу, инженер с агентами доводит её до работающего изменения, а эксплуатация обеспечивает сопровождение. Александр добавляет условие: требования безопасности, надёжности и других общих функций должны быть доступны заранее и проверяться в рабочем процессе. Иначе быстро написанный код снова ждёт ручного согласования. Инструкции для агента необходимо сочетать с детерминированными проверками; обнаруженная ошибка может становиться новым проверяемым правилом. Платформенная команда предоставляет доступ к моделям через Model Gateway, каталог инструментов MCP Hub, проверенные навыки в Skill Hub и изолированные среды выполнения. Руководство продуктового направления отвечает за изменение собственного процесса. Успешный пилот при этом не гарантирует масштабирования: исключения, согласованные для одного подразделения, могут оказаться недоступны остальной компании. Поэтому техническая готовность платформы и способность организации принять новый порядок работы — разные задачи.

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

Однако знания живут не только в репозитории. В большой организации документацией пользуются продуктовые менеджеры, аналитики, дизайнеры и поддержка; общий переезд в Git означает изменение их повседневной работы. Александр приводит пример, когда даже переход от описания экранов мобильного банка к описанию функций занял два года. Возможный промежуточный путь — поиск поверх существующих систем, но и он не гарантирует правильного контекста: часто посещаемая интерпретация стратегии подразделением может оказаться выше исходного документа компании. Похожее ограничение возникает с внутренними платформами. Форк открытого продукта, переработанный под корпоративные требования, может вести себя иначе, чем ожидает модель. То, что раньше давало экономию на масштабе, теперь требует дополнительных объяснений и интеграции. Совместимость с исходными интерфейсами становится полезным свойством. Кирилл описывает практику возврата исправлений в открытые проекты, а Александр оговаривает: для большого корпоративного форка такой путь значительно сложнее.

Обсуждение измерений проходит через три уровня. Первый — используют ли люди инструменты и какие сценарии покрывают агенты. Второй — сколько времени занимает конкретная инженерная работа: поиск информации, создание изменения, проверка кода или устранение инцидента. Третий — во что превратилось высвобождённое время с учётом затрат на модели, платформу и внедрение. Александр вспоминает измерение промежутка от открытия запроса на слияние до его принятия: оно пропускало начальный этап, на котором агент мог дать основное ускорение. Поэтому важно правильно определить границы наблюдения. При этом подробная инструментализация сама стоит денег, и возможность повторить опыт Google в каждой компании не предполагается. Больше закрытых задач также не равняется большей пользе: без расширения поиска продуктовых возможностей команда может просто брать менее ценные пункты очереди. Кирилл приводит другой случай — накопленные полезные идеи начинают поступать быстрее, когда продуктовые коллеги замечают рост пропускной способности разработки.

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