Anthropic переносит инженерное «узкое место»
Недавно компания Anthropic поручила своей команде роста нанять больше продакт-менеджеров, а не сокращать их штат. Причина, как сообщалось в отраслевых обзорах, заключалась в том, что Claude Code незаметно превратил их инженерный отдел в команду, которая выпускает продукты примерно втрое быстрее относительно своего реального штата, а узкое место переместилось из интегрированной среды разработки (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 в апреле перед частичным восстановлением доступа, подчеркнули ту же тенденцию со стороны открытого исходного кода.
Узкое место сместилось; большинство команд — нет
Инженерный потенциал вырос примерно втрое. Управление продуктом осталось на прежнем уровне. Традиционное соотношение PM-ов и инженеров 1:8, и без того испытывавшее нагрузку, теперь фактически приблизилось к 1:20, поскольку каждый инженер выпускает больше результатов в день. Например, LinkedIn заменила свою программу для ассоциированных продакт-менеджеров программой Product Builder, которая обучает универсалов на стыке продукта, дизайна и инженерии. Anthropic нанимает больше продакт-менеджеров, а не сокращает их. Эта тенденция наблюдается во всех компаниях, которые реально внедрили агентские рабочие процессы в производство: система создает готовые функции быстрее, чем принимает решения о том, что именно должно быть создано.
Для инженеров это важнейший карьерный сигнал десятилетия — и в то же время самый простой для упущения на фоне новостей о росте производительности.
Фундаментальные основы важны как никогда
Стремление объявить фундаментальные знания устаревшими в эпоху агентов полностью искажает реальное положение дел.
Когда утечка памяти «роняет» продакшн в 3 часа ночи, а причиной оказывается завуалированная ошибка владения данными, добавленная 4 года назад, ни один из существующих на сегодня агентов не способен замкнуть этот цикл самостоятельно от начала до конца. Операционные системы, сети, параллелизм и планы выполнения запросов по-прежнему определяют, кто может устранить реальный инцидент. Они также определяют, кто способен заметить моменты, когда результат работы агента выглядит правильным на поверхности, но скрывает в себе серьезные и дорогостоящие ошибки в глубине. Агент, написавший 70% кода в современном репозитории, не может надежно объяснить никому, в какой именно момент его предположения о потокобезопасности, владении памятью или изоляции транзакций разошлись с поведением среды выполнения. Инженер, который способен прочитать дифф и поймать эту ошибку, — это именно тот специалист, который нужен команде в этот момент, и такой специалист опирается на фундаментальные знания, а не на навыки составления промптов.
Отсюда следует, что фундамент теперь — это навык повышения эффективности, а не просто базовая гигиена. В 2014 году знание того, как работает ретрансляция TCP, помогало быстрее закрыть тикет с багом. В 2026 году те же знания спасают весь релизный пайплайн на базе агентов от масштабного появления регрессий. Масштаб возможных последствий ошибок инженера, понимающего внутреннее устройство процессов, вырос, а не уменьшился.
Ревью кода — это новое написание кода
Инженеры в 2026 году генерируют код со скоростью, превышающей возможности любого человека по его внимательному чтению. Команда, которая быстро выпускает продукт и выживает на рынке, — это та команда, чьи инженеры подходят к проверке сгенерированного ИИ кода как минимум с такой же тщательностью, какую они раньше резервировали для его написания. Согласно опросу разработчиков Stack Overflow за 2025 год, 84% девелоперов используют инструменты на базе ИИ, при этом 46% заявляют, что не доверяют результатам (резкий рост по сравнению с 31% годом ранее). Этот разрыв — активное использование в сочетании с низким доверием — как раз и есть та область, где навыки ревью имеют первостепенное значение. Кодеры, которые много пишут и мало проверяют код, накапливают технический долг, который придется выплачивать во время первого же серьезного инцидента, и инженер, способный закрыть этот долг, — это тот, кто подкрепил объемы работы глубокими фундаментальными знаниями задействованных систем.
Новым фактором дифференциации становится продуктовая воронка
Оба этих условия необходимы. Ни одно из них по отдельности недостаточно. Инженер, который имеет реальное значение в 2026 году, — это тот, кто перестал ждать, пока воронка придет к нему в виде тикета в Jira.
Это означает необходимость делать то, что разработчикам исторически позволялось не делать.
Общайтесь с клиентами. Наблюдайте за тем, как они реально используют продукт. Читайте очередь службы поддержки. Присутствуйте на звонках с отделами продаж. Информацию, которую продуктовая команда получает через три слоя кратких пересказов, инженер теперь может получить из первых рук за один подиумный день.
Генерируйте идеи, а не просто оценки. Продакт-менеджер, который раньше генерировал идеи для 8 инженеров, не может выдавать идеи для 20 человек с тем же уровнем проработки. Инженер, который приходит с проверенной и проработанной возможностью, больше не выполняет чужую работу. Он делает именно то, чего требует новое соотношение сил.
Идите от клиента в обратном направлении. Amazon уже два десятилетия сначала пишет пресс-релиз. Этот подход отлично применим как к командам из одного человека, так и к роям агентов. Без четкого определения того, что именно означает «победа клиента» до того, как написана хоть одна строка кода, и те, и другие будут производить огромное количество работающего ПО не в том направлении.
Перестаньте прятаться за нехваткой пропускной способности. Честным ответом на вопрос «Есть ли у вас ресурс на эту идею?» раньше было «Нет». С использованием рутинных процедур, хуков и стека совместных агентов честный ответ ближе к формулировке «Чего стоит эта идея?». Это совершенно другой разговор, и вести его гораздо сложнее, если у вас нет четкой позиции в отношении клиента.
Что будет вознаграждено в следующее десятилетие
Описанная выше пятиэтапная история на самом деле не столько история инструментов, сколько история о том, какую часть работы должен выполнять человек. Та часть, которая по-прежнему остается человеческой и останется таковой в обозримом будущем, сместилась вверх по воронке: от набора текста к ревью, от ревью к принятию решений, от решений — к выбору клиента, которому нужно помочь, и проблемы, которую следует решить.
Версия 2026 года для великого инженера — это не тот, кто пишет больше всего кода. Это тот, кто знает, что именно нужно построить, может доказать ценность этого шага и обладает парком агентов в сочетании с дисциплиной код-ревью, позволяющей выпустить продукт без риска того, что система рухнет под собственной скоростью.
Инженеры, которые осознают это, проведут следующее десятилетие за самой интересной работой, которую когда-либо производило программное обеспечение. Инженеры, ожидающие тикетов, проведут это время, наблюдая за тем, как тикеты за них пишет соседний агент.
Ишан Гупта (Ishan Gupta) — инженер-программист в Amazon.
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевых публикаций — это площадка, где технические эксперты делятся инсайтами и представляют независимый, непредвзятый детальный анализ в сфере ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее бизнеса.
Читайте далее в рамках нашей программы гостевых постов — и ознакомьтесь с нашими рекомендациями, если вы хотите сами подготовить статью для публикации!
