AI пишет код.
Что остаётся инженеру?

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

На слайде автор ссылается на исследование NBER более чем 100 тысяч GitHub-разработчиков: использование агентов связано с ростом объёма кода на 741% и числа релизов на 30%. В речи он округляет первое изменение до восьмикратного роста. Даже большой выигрыш на одном этапе не переносится целиком на поставку.

Человек не может бесконечно ускорять чтение. Voss приводит результат Cisco / SmartBear: после примерно 450 строк в час точность ревью резко падает. Большой diff, который агент выдал за короткое время, всё равно требует длительной проверки.

Передать ревью машинам логично, но Voss не считает нынешние инструменты достаточно надёжными. В приведённом им сравнении четырёх AI-ревьюеров каждый нашёл реальные ошибки, однако наборы находок не совпали. Его вывод: серьёзная проверка не должна зависеть от одного ревьюера.

Он также пересказывает отказ Dexter Horthy от подхода «не читайте код» после переделки целых систем. В качестве других предупреждений приводит инциденты Amazon и ошибки Anthropic, прошедшие и человеческие, и машинные проверки. Эти примеры поддерживают тезис о недостаточности текущего контроля, а не разрешение убрать его уже сегодня.

Cognition, по словам Voss, меняет вопрос бенчмарка: вместо «пройдены ли тесты?» спрашивает «принял бы maintainer этот PR?». На слайде результат снижается с 80% до 54%. Проверяющий учитывает стиль, побочные эффекты, внешние системы и историю решений, которой нет в коде.

Недостающая часть, по Voss, — представление о том, что для конкретного проекта значит «хорошо». Пока оно существует только в голове maintainer, агент не может полноценно использовать его при генерации и проверке.

Voss опирается на теорию ограничений Элияху Голдратта: ускорять нужно этап, ограничивающий всю систему. Когда его пропускная способность растёт, ограничение возникает в другом месте. Так автор переходит от текущей проблемы ревью к будущей роли инженера.

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

Требуется выяснить, как именно работает заказчик, что должно происходить в системе и по каким признакам он поймёт, что проблема решена. Эти сведения находятся у людей, а не обязательно в обучающих данных модели. Получить их можно разговором и наблюдением за работой.

Критерии качества плохо переносятся даже между похожими продуктами. Календарь и сервис планирования встреч решают близкие задачи, но требуют разных решений. Избыток настроек тоже не гарантирует соответствия потребности: здесь Voss шутит про Jira.

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

Формализация меняет и границу автоматизации. Если качество можно дёшево проверить, на такой проверке можно обучать модель. Автор приводит попытку Cognition определить пригодность PR к слиянию и правила Cursor Bugbot, которые возникают из отрицательной обратной связи команды. Как только неявное знание стало проверяемым правилом, агенты получают возможность его использовать.

Вместо простого увеличения числа product manager автор предлагает сближение ролей. Инженер, который понимает пользователя, выбирает, что строить, и сразу реализует решение с агентами, сокращает передачу задачи между людьми. В подтверждение Voss пересказывает позицию Andrew Ng.

Он сравнивает эту роль с системным аналитиком 1960-х, который выяснял задачу бизнеса. Позднее продуктовая и инженерная работа разделились, а теперь, по его мнению, снова сходятся. Речь идёт о разработке любого ПО, не только AI-продуктов.

Близкий пример на рынке — forward deployed engineer, инженер, работающий с внедрением у заказчика. Автор приводит рост числа таких вакансий на 800% за девять месяцев 2025 года и среднюю компенсацию $240 000. Он подчёркивает, что названия ролей пока разнятся, а уровень ответственности соответствует senior-инженеру.

Voss признаёт слабое место собственной позиции: люди склонны считать автоматизируемым всё, кроме любимой части своей работы. Его утверждение, что постановка задачи останется человеческой, следует читать как ставку, которую он сам предлагает оспаривать.

Раньше начинающему давали хорошо описанную задачу, просили написать код и обучали через ревью. Теперь такую задачу получают агенты. Но потребность в людях, способных самостоятельно разобраться в бизнесе и поставить задачу, не исчезает. Если перестать нанимать начинающих, будущим опытным специалистам неоткуда взяться.

На графике в докладе красная линия группы 22–25 лет идёт вниз, а занятость групп 35–40 и 41–49 лет растёт. Voss использует это как аргумент, что проблема найма начинающих уже наступила.

Как читать график: возрастные группы не тождественны уровням опыта. Само расхождение линий не доказывает, что его целиком вызвали AI-агенты; это иллюстрация аргумента автора, а не отдельная проверка причин.

Программы подготовки product manager, по оценкам Voss, выпускают слишком мало людей для предлагаемой новой профессии: около 50 человек в год в Google APM и порядка тысячи в совокупности у похожих программ. Требуемые 10 тысяч в год он называет своей оценкой масштаба потребности.

Главный учебный пробел он формулирует через пекарню: университеты учат структурам данных, курсы — React, но почти никто не учит провести неделю рядом с владельцем бизнеса и вернуться с хорошей спецификацией. Руководителям нужно намеренно выращивать этот навык: включать разговоры с клиентами и работу с требованиями в обучение начинающих. В докладе IBM приведена как пример такой перестройки начальной роли.

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

Он предлагает различать удовольствие от написания кода и момент, когда удалось понять задачу и увидеть повторяемую систему. Второй остаётся частью инженерной работы. Программирование как ремесло тоже сохранится, подобно ручной работе с деревом после появления мебельных фабрик; но его место на рынке труда, по прогнозу Voss, изменится.

Автор ожидает болезненных десяти лет: поток AI-кода растёт раньше, чем готовы проверки, а привычный путь обучения исчезает раньше, чем возникает новый. Его оптимистический прогноз — в итоге более многочисленная профессия с сопоставимой оплатой, преимущественно похожая на product engineering. Это прогноз, а не установленный исход.