Эволюция программирования: почему ИИ смещает акцент с написания кода на управление продуктом

Компания Anthropic недавно поручила отделу по развитию увеличить штат менеджеров по продукту. Согласно отраслевым отчетам, причиной стало внедрение инструмента Claude Code, который позволил инженерному подразделению работать с эффективностью, в три раза превышающей реальное количество сотрудников. В результате основным препятствием для развития стала не скорость написания кода в интегрированной среде разработки (IDE), а процесс принятия решений о том, что именно стоит создавать.

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

Пять этапов трансформации работы инженера

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

• Эпоха Stack Overflow (2014 – конец 2022 года): Программисты искали ответы на специализированных сервисах. С момента запуска ChatGPT количество новых вопросов на Stack Overflow упало примерно на 77%, что ознаменовало конец привычного рабочего процесса.
• Эпоха браузерных вкладок (конец 2022 – 2024 год): Инженеры начали использовать чат-боты в браузере, копируя ответы и вставляя их в редактор кода. Это ускорило работу, но процесс оставался линейным и полностью управляемым человеком.
• Эпоха нативных IDE (2024 – 2025 год): ИИ-модели были интегрированы непосредственно в редакторы (например, Cursor и Claude Code), получив доступ ко всему репозиторию. Путь эскалации проблем к старшему инженеру практически исчез. По прогнозам, к 2026 году первой командой, которую разработчик введет в терминале, станет запуск ИИ-помощника.
• Эпоха работы на основе спецификаций (2025 – 2026 год): Увеличение окна контекста (объема данных, которые ИИ может обработать за раз) позволило превратить короткие сессии в полноценные циклы разработки. В команде Amazon Kiro создание новых функций сократилось с двух недель до двух дней. Другой пример — проект по изменению архитектуры, рассчитанный на 30 инженеров и 1,5 года работы, был выполнен 6 специалистами за 76 дней.
• Эпоха автономных сценариев (с 2026 года): Появление агентов, работающих по расписанию или через вебхуки (механизмы уведомления системы о событиях), позволяет инженеру ставить задачи на ночь и утром проверять готовые запросы на слияние кода. Работа превращается в оркестровку целого «роя» ИИ-агентов.

Фундаментальные знания становятся инструментом контроля

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

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

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

Проверка кода как основная компетенция

К 2026 году объемы генерируемого кода превысят возможности человека по его внимательному прочтению. Согласно опросам, 84% разработчиков используют ИИ, но 46% из них не доверяют результату. Этот разрыв делает навык тщательного рецензирования (ревью) критически важным. Программисты, которые просто копируют код без глубокой проверки, накапливают технический долг, который проявится при первом же серьезном инциденте.

Инженер как проектировщик продукта

По мнению экспертов, инженер будущего не должен ждать готовых задач в Jira (системе управления проектами). Чтобы оставаться востребованным, специалисту необходимо:

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

Следующее десятилетие станет временем тех, кто умеет выбирать правильные проблемы для решения. Роль инженера смещается от набора текста к принятию решений и управлению флотом ИИ-агентов. Те, кто продолжит просто ждать «тикет» с заданием, рискуют обнаружить, что это задание за них уже выполнил искусственный интеллект.

Твитнуть