Код Клода превратил каждого инженера в трёх. Теперь компаниям нужно больше специалистов по продуктовому мышлению.
Ишан Гупта
Компания Anthropic недавно поручила своей команде по развитию нанять больше менеджеров по продуктам, а не меньше. Причина, как сообщалось в отраслевых источниках, заключалась в том, что Клод Код незаметно превратил свою инженерную команду в подразделение, выпускающее продукты примерно в три раза чаще, чем его фактическая численность персонала, и узкое место переместилось из интегрированной среды разработки (IDE) к людям, принимающим решения о том, что разрабатывать.
В шумихе вокруг заявлений об эффективности ИИ легко упустить эту деталь. Это также структурный сдвиг, который сейчас переживает вся отрасль. Узким местом в разработке программного обеспечения является уже не набор текста, а решение о том, что именно набирать. И инженеры, которые относятся к этому как к чужой проблеме, скоро достигнут своего предела.
На протяжении большей части последнего десятилетия это решение принимал кто-то другой. Разработка программного обеспечения была ремеслом, которое осваивалось постепенно, а затем практиковалось в длинной, предсказуемой последовательности: глубокое погружение в технологию, написание кода, обращение за помощью на Stack Overflow, если возникали трудности, передача вопроса старшему инженеру, если Stack Overflow не помогал, выпуск продукта. Менеджер по продукту отвечал за весь процесс. Инженер отвечал за сборку. Обе стороны относились к этому разделению как к закону физики.
Затем воронка рухнула в пять этапов.
Краткая история того, как сжался рабочий день инженера.
Эпоха Stack Overflow (с 2014 по конец 2022 года): образ мышления инженеров был сосредоточен в одном месте. Но количество новых вопросов в месяц на Stack Overflow сократилось примерно на 77% с ноября 2022 года, что не случайно совпало с запуском ChatGPT. Это падение — не референдум по поводу самого сайта. Это референдум по поводу рабочего процесса, который он представлял.
Эпоха вкладок браузера (конец 2022 — 2024 гг.): первое поколение ChatGPT работало вне IDE. Инженеры использовали тот же цикл, что и всегда, только с более быстрым оракулом: ввод запроса в браузере, вставка ответа обратно в VS Code, повторение. Работа по-прежнему была однопоточной и управлялась инженером. Влияние было реальным, но локальным.
Эпоха IDE-нативных решений (2024–2025): Cursor и Claude Code переместили модель разработки внутрь редактора и предоставили ему доступ ко всему репозиторию. Путь эскалации от опытного инженера к старшему специалисту в значительной степени исчез. В течение многих лет среди опытных инженеров преобладало мнение, что Bash обладает самым долгим сроком службы среди всех инструментов в стеке. К 2026 году для значительной части работающих разработчиков первой командой, введенной в новом терминале, будет claude.
Эпоха разработки, основанной на спецификациях (2025–2026): Увеличение временных окон контекста превратило работу над проектом за один сеанс в то, что раньше требовало создания тикетов, проектной документации и спринтов. Сообщается, что команда разработчиков IDE Kiro в Amazon сократила время сборки новых функций с двух недель до двух дней, используя тот же рабочий процесс, основанный на спецификациях, который они внедряли. Команда инженеров AWS описала 18-месячную перестройку архитектуры, первоначально рассчитанную на 30 инженеров, которая была завершена 6 людьми за 76 дней. Узким местом перестало быть время, необходимое для написания кода. Теперь им стало то, насколько четко команда может описать, что именно выглядит правильным.
Эра рутинных процессов (2026): В апреле Anthropic выпустила Claude Code Routines: запланированные, постоянно работающие агенты, которые запускаются с заданным ритмом, по веб-хуку или ночью, пока ноутбук закрыт. Cron вернулся. Хуки вернулись. Работа инженера теперь частично сводится к оркестровке: запустить рой перед сном, просмотреть стопку запросов на слияние утром. Сторонние обертки, такие как OpenClaw, которая была ненадолго приостановлена Anthropic в апреле, а затем частично восстановлена, продемонстрировали ту же идею с точки зрения открытого исходного кода.
Проблема сместилась; большинство команд этого не сделали.
Количество инженеров увеличилось примерно втрое. В сфере управления продуктами ситуация не изменилась. Традиционное соотношение 1:8 между менеджерами по продуктам и инженерами, и без того напряженное, теперь фактически приближается к 1:20, поскольку каждый инженер выпускает больше продуктов в день. Например, LinkedIn заменила программу подготовки младших менеджеров по продуктам программой «Создатель продуктов», которая обучает специалистов широкого профиля в области продукта, дизайна и разработки. Anthropic нанимает больше менеджеров по продуктам, а не меньше. Эта тенденция наблюдается во всех компаниях, которые фактически внедрили агентные рабочие процессы в производство: система создает готовые функции быстрее, чем принимает решения о том, что следует создавать.
Для инженеров это самый важный карьерный сигнал десятилетия, и его легче всего упустить из виду, пока в новостной ленте доминируют истории о повышении производительности.
Первостепенные принципы имеют большее значение, а не меньшее.
Стремление объявить фундаментальные принципы устаревшими в эпоху агентских сделок совершенно неверно отражает реальную тенденцию.
Когда утечка памяти парализует работу системы в 3 часа ночи, и причиной оказывается скрытая ошибка управления памятью, обнаруженная 4 года назад, ни один из действующих агентов не может замкнуть этот цикл от начала до конца. Операционные системы, сети, параллелизм и планы запросов по-прежнему определяют, кто может устранить реальный инцидент. Они также определяют, кто может заметить моменты, когда вывод агента выглядит корректным на первый взгляд, но на самом деле оказывается неверным. Агент, написавший 70% кода в современном репозитории, не может надежно указать, где его предположения о потокобезопасности, владении памятью или изоляции транзакций расходятся с реальностью. Инженер, который может прочитать diff и обнаружить это, — это тот инженер, который нужен остальной команде, и этот инженер строится на фундаментальных знаниях, а не на умении подсказывать.
Из этого следует, что знание основ теперь является навыком, который можно использовать как рычаг, а не как гигиенический навык. В 2014 году знание того, как работает повторная передача TCP, позволяло быстрее закрывать заявки на отладку. В 2026 году те же знания предотвратят выпуск регрессионной ошибки в масштабах всей системы выпуска, управляемой агентами. Радиус поражения инженера, знающего, что происходит на самом деле, увеличился, а не уменьшился.
Рецензирование — это новый вид письма.
В 2026 году инженеры генерируют код со скоростью, превышающей ту, которую любой из них может внимательно прочитать. Команда, которая быстро выпускает продукты и выживает, — это команда, инженеры которой относятся к проверке кода, сгенерированного ИИ, как минимум с той же тщательностью, с которой они когда-то относились к его написанию. Опрос разработчиков Stack Overflow 2025 года показал, что 84% разработчиков используют инструменты ИИ, при этом 46% заявили, что не доверяют их результатам, что значительно больше, чем 31% годом ранее. Именно этот разрыв — интенсивное использование в сочетании с низким уровнем доверия — является тем местом, где навыки проверки кода сейчас имеют наибольшее значение. Программисты, которые много пишут и мало проверяют, накапливают долг, который придется погасить при первом же реальном инциденте, и инженер, который сможет его вернуть, — это тот, кто сочетает большой объем работы с глубокими фундаментальными знаниями задействованных систем.
Новым конкурентным преимуществом является воронка продаж.
Оба варианта необходимы. Ни один из них не является достаточным. Важнейшим инженером в 2026 году станет тот, кто перестал ждать, пока поток информации сам собой появится в виде тикета в Jira.
Это означает выполнение тех задач, которые в рамках данной должности исторически разрешалось пропускать.
Поговорите с клиентами. Посмотрите, как они на самом деле используют продукт. Прочитайте очередь в службу поддержки. Присутствуйте на звонках отдела продаж. Сигнал, который команда разработчиков получает через три уровня сводки, инженер теперь может получить из первых рук за один день.
Генерируйте идеи, а не просто оценки. Менеджер по продукту, который раньше находил идеи для 8 инженеров, теперь не сможет находить идеи для 20 с той же точностью. Инженер, который приходит с подтвержденной, четко определенной задачей, больше не выполняет работу менеджера по продукту. Инженер выполняет работу, которую требует новое соотношение.
Начинайте работу с клиента. Amazon уже два десятилетия пишет пресс-релизы, отталкиваясь от него. Этот подход хорошо подходит как для команд из одного человека, так и для целых групп агентов. И те, и другие создают много работающего программного обеспечения, двигаясь в неправильном направлении, без четкого определения того, что означает «победа клиента», до начала написания кода.
Перестаньте прятаться за пропускной способностью. Раньше честный ответ на вопрос «Есть ли у вас ресурсы для реализации этой идеи?» был «Нет». С помощью рутинных действий, «крючков» и системы взаимодействия агентов честный ответ ближе к вопросу «Сколько стоит эта идея?». Это совсем другой разговор, и его гораздо сложнее вести без реального понимания потребностей клиента.
Какие награды получит следующее десятилетие
Описанная выше пятиэтапная история — это не столько история инструментов, сколько история того, какую часть работы приходилось выполнять человеку. Та часть, которая по-прежнему выполняется человеком и останется таковой в обозримом будущем, продвинулась вверх по воронке: от набора текста, к проверке, к принятию решений, к выбору клиента для обслуживания и проблемы для решения.
Идеальный инженер 2026 года — это не тот, кто пишет больше всего кода. Это тот, кто знает, что нужно построить, может доказать, что это стоит построить, и обладает достаточным количеством агентов, а также дисциплиной в проведении проверок, чтобы выпустить продукт, не допустив краха системы.
Инженеры, которые это поймут, проведут следующее десятилетие, занимаясь самой интересной работой, которую когда-либо создавало программное обеспечение. Инженеры, ожидающие обработки заявки, проведут это время, наблюдая, как сотрудник рядом с ними оформляет заявку.
Ишан Гупта — инженер-программист в компании Amazon.
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевых публикаций — это площадка, где технические эксперты делятся своими знаниями и предоставляют нейтральные, непредвзятые аналитические материалы по искусственному интеллекту, инфраструктуре данных, кибербезопасности и другим передовым технологиям, формирующим будущее предприятий.
Узнайте больше о нашей программе гостевых публикаций — и ознакомьтесь с нашими рекомендациями, если вы заинтересованы в написании собственной статьи!
Подпишитесь, чтобы получать самые свежие новости!
Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.
Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.
Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.
Источник: venturebeat.com
Оцените материал:
