За последний год я почти перестал писать код руками.

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

Инженерной работы у меня от этого меньше не стало.

Код появляется быстрее. При этом агенты уже помогают не только с реализацией. Они могут исследовать систему, предлагать варианты, искать риски и спорить с моим решением. Но главный вопрос от этого никуда не исчезает.

Каким выводам я готов доверять, что нужно проверить самому и за какое решение в итоге готов отвечать?

Я решил проверить, насколько мой опыт совпадает с тем, что происходит у других. Посмотрел свежие исследования, несколько публичных карьерных лестниц и поговорил с тимлидами и Middle/Senior‑разработчиками.

По дороге пришлось отказаться от нескольких удобных тезисов. Например, от «AI делает разработчиков на 30% быстрее» и от «Senior — это просто человек, которому можно дать плохо описанную задачу».

В итоге одной аккуратной формулы не получилось. Ниже разберу, что удалось выяснить.

AI правда ускоряет разработку. Но не любую

На части задач AI уже даёт заметный выигрыш.

В 2026 году в Management Science вышли результаты трёх полевых экспериментов с 4 867 разработчиками из Microsoft, Accenture и компании из Fortune 100. У разработчиков с AI‑ассистентом количество завершённых задач выросло в объединённых данных примерно на 26%.

В другом исследовании 2026 года участвовал 151 человек, 95% — профессиональные разработчики. На первой Java‑задаче группа с AI закончила работу на 30,7% быстрее по медиане.

Но у METR была важная оговорка к картине ускорения. В их исследовании на данных начала 2025 года 16 опытных open‑source разработчиков решали реальные задачи в знакомых репозиториях и с AI тратили на работу примерно на 19% больше времени.

К началу 2026 года сам METR уже считает эту картину устаревающей. В новом эксперименте разработчики стали чаще отказываться от задач без AI и выбирать для исследования те задачи, где ожидаемый выигрыш от AI ниже. Из‑за этого авторы считают новые task‑level оценки сильно смещёнными и не дают надёжной цифры текущего ускорения.

При этом по интервью и опросам участников METR считает вероятным, что современные AI‑инструменты уже ускоряют разработчиков сильнее, чем в начале 2025 года.

Результаты напрямую не сравниваются. Исследования измеряли разные задачи и показатели, а сам эффект меняется вместе с инструментами и способом их использования.

AI уже умеет сильно ускорять часть работы. Но нет одного коэффициента, который можно умножить на любого инженера. Всё зависит от задачи, кодовой базы, опыта человека, инструмента и того, как устроен процесс работы.

Меня в этих результатах больше заинтересовал другой вопрос. Если реализацию стало проще получить, что происходит с остальной работой?

Быстрее получить код не значит быстрее получить готовое решение

Один из инженеров, с которым я разговаривал, сказал, что код теперь почти не пишет. Его внимание сместилось на систему целиком и на проверку того, что сделал AI.

Другой инженер сформулировал эту мысль точнее.

Важнее стало проверять не сам код, а то, правильно ли вообще решена задача. Хороший код ещё не означает правильное решение

DORA в 2026 году описывал похожий эффект. Часть времени, которую инженеры экономят на генерации кода, потом уходит на аудит и проверку результата.

А у METR есть ещё более наглядный эксперимент. Мейнтейнеры трёх open‑source проектов проверяли 296 pull request'ов, созданных с помощью AI, которые уже проходили тесты SWE‑bench. Примерно половину они всё равно не стали бы вливать в основную ветку.

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

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

В одном из интервью мне привели почти учебный пример. Разработчик сделал технически нормальное решение, но не учёл обратную совместимость и сценарии ошибок. Локально всё выглядело правильно. Проблема появилась только на уровне системы.

Поэтому пока я бы не называл review новым bottleneck. Но когда код генерируется быстрее, постановка задачи, контекст, проверка и интеграция результата начинают занимать больше внимания.

Хороший код может решать не ту задачу

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

Один Team Lead признался, что после правдоподобного ответа AI очень легко дать слабину и запушить результат без нормальной проверки.

Другой считает, что проверять теперь приходится весь процесс, начиная с постановки задачи и заканчивая финальной реализацией.

Мне этот тезис ближе, чем разговоры о том, пишет AI “хороший” код или «плохой». Хороший код сам по себе ещё не означает, что мы решили правильную задачу.

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

Поэтому для меня важнее другой вопрос. Правильно ли мы поняли проблему, выбрали решение и проверили, что оно работает в нужном контексте?

А что тогда с фундаментальными знаниями?

Здесь легко впасть в другую крайность и решить, что раз AI пишет код, фундаментальные знания теперь важнее всего.

Я не нашёл хороших данных, которые позволяли бы так уверенно сравнивать «до AI» и «после AI». При этом даже если агент способен исследовать систему вместе с инженером, понимание этой системы всё равно нужно тому, кто принимает решение и проверяет результат.

В одном из исследований 2026 года уровень разработчика оставался значимым фактором даже при использовании AI. При этом исследователи не нашли систематического ухудшения сопровождаемости кода, написанного с помощью AI, в изученных задачах. Это тоже полезно помнить. Утверждение «AI‑код по определению хуже» слишком грубое.

В интервью один Senior назвал главным для роста «технический кругозор». По его словам, фронтенд‑инженеру не обязательно становиться бэкенд‑разработчиком, но полезно понимать, как устроены бэкенд, сеть, базы данных, архитектура и где возникают компромиссы.

Другой описал ту же проблему с другой стороны. Можно отлично писать код и всё равно не видеть, что твоё решение ломает за пределами собственного компонента.

Для меня фундаментальные знания здесь не сводятся к памяти на синтаксис.

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

Знать термины мало. Нужно понимать, какой компромисс важен именно в этой ситуации.

Я думал, что Senior отличается умением работать с неопределённостью

До интервью у меня была довольно простая модель.

Middle получает более‑менее понятную задачу. Senior получает проблему и сам разбирается, что делать.

Два Team Lead'а действительно описали Senior примерно одинаково. Ему можно дать задачу в общем виде и не стоять рядом с подробной декомпозицией.

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

А потом я посмотрел карьерную лестницу Dropbox.

И там уже от IC3 ожидают самостоятельной работы с открытыми и неоднозначными задачами. На IC4 растёт не просто количество неизвестных. Растут горизонт работы, бизнес‑влияние, количество затронутых команд, сложность технических решений и ответственность за итог.

То есть формула «Senior умеет работать с неопределённостью» слишком короткая.

С ростом уровня инженеру можно доверять решения с более широким контекстом и более серьёзными последствиями.

Дело уже не только в том, можешь ли ты разобраться в плохо описанной задаче. Важно, можешь ли ты сам построить модель проблемы, сравнить варианты, увидеть последствия для соседних систем, довести изменение до прода и потом понять, что произошло.

Один из респондентов описал хороший практический маркер такой зрелости. Вместо вопроса «что мне делать?» человек приходит уже со своим пониманием проблемы и вариантами решения.

Я понял задачу вот так. Вижу два варианта. Вот плюсы и минусы. Я бы выбрал этот. Что думаешь?

После этого разговор уже идёт о самом решении, а не о последовательности действий.

До кода и после merge

Эта мысль повторялась в интервью чаще всего.

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

После merge легко впасть в другую крайность и считать работу законченной.

Но продакшен не знает, что тикет уже перевели в Done.

Изменение может повлиять на задержки, ошибки, нагрузку, стоимость, пользовательский сценарий или соседние сервисы. А может просто не дать того эффекта, ради которого его делали.

У меня здесь есть ещё один личный критерий. Сильный инженер не обязан каждую проблему превращать в расследование на неделю. Иногда достаточно быстрого фикса. Иногда нужно докопаться до root cause. А иногда разумно осознанно вынести системную проблему в техдолг.

Зрелость не в том, чтобы всегда копать глубже.

Она в том, чтобы выбрать нужную глубину решения и понимать последствия этого выбора.

Где здесь бизнес

Эта тема появилась у меня не из исследования, а из комментария под первым LinkedIn‑постом. Человек написал, что следующий шаг для разработчика состоит в том, чтобы перестать воспринимать код как самостоятельную ценность и начать смотреть на бизнес.

Формулировка резкая, но мысль потом повторилась в нескольких интервью.

Один TL сказал, что инженер с агентами должен быть «владельцем продукта на минималках» и понимать не только технику, но и сам процесс, для которого пишется система.

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

Я не делаю из этого вывод, что каждый разработчик должен стать Product Manager. Бизнес‑контекст был частью сильной инженерной работы и до нынешней волны AI.

Если агенту можно делегировать всё больше реализации и анализа, заметнее становится качество контекста, на котором строится решение. Причём этот контекст живёт не только в репозитории. Часть находится у пользователей, в продукте, процессах и целях.

Поэтому граница уже не проходит между «агент делает, инженер думает».

Для меня важнее не то, кто именно предложил решение, а кто отвечает за его качество, решает, какому контексту и выводам доверять, что проверять и какие последствия принять.

Можно ли этому научить вне работы?

Меня давно интересует production‑like практика. Можно ли дать инженеру опыт архитектурных решений, работы с неопределённостью, rollout, observability и incidents, если его текущая работа таких ситуаций почти не создаёт?

Один Senior ответил, что по‑настоящему важный для него опыт появился только на реальных задачах.

Я спросил, что именно делает их незаменимыми.

Ответ был не про размер кодовой базы и не про сложность инфраструктуры.

Реальная задача приводит к реальному положительному или отрицательному результату — либо довольный пользователь, либо недовольный руководитель. Важно ощущение причастности к процессу и результату, а также реальная ответственность

Мне этот ответ интересен именно потому, что он неудобный.

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

При этом есть исследования project‑based learning в software engineering, где студенты работают с real‑life задачами и даже внешними заказчиками. Такие форматы помогают тренировать не только технические навыки, но и работу с изменениями, командой и требованиями заказчика. Значит, по крайней мере часть опыта, похожего на реальную инженерную работу, можно тренировать и вне обычной команды.

Поэтому теперь мне интереснее понять, что именно такая среда способна натренировать, а где начинаются её ограничения.

Что из инженерного опыта можно натренировать, а что появляется только там, где есть настоящая ответственность?

Вместо вывода

Я начинал с идеи, что AI пишет всё больше кода, а значит ценность инженера просто сместится в архитектуру и качество инженерных решений.

Теперь эта формулировка кажется мне слишком аккуратной.

AI не отменяет саму разработку. В одних задачах он сильно ускоряет работу, в других почти не помогает, а иногда опытный разработчик с ним работает даже медленнее.

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

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

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

Я продолжаю собирать такие кейсы. Особенно интересны те, которые этой картине противоречат.

Кто помог с исследованием

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

Спасибо всем, кто участвовал.

Цитаты в статье я оставил анонимными. Для аргумента важнее содержание ответа, чем то, кому принадлежит конкретная формулировка.

Основные источники

• Cui et al. — The Effects of Generative AI on High‑Skilled Work, Management Science, 2026

• METR — Measuring the Impact of Early-2025 AI on Experienced Open‑Source Developer Productivity, 2025

• METR — Many SWE‑bench‑Passing PRs Would Not Be Merged into Main, 2026

• METR — Uplift Update: AI Experience and Developer Productivity, 2026

• DORA — Balancing AI tensions, 2026

• Borg et al. — Echoes of AI: downstream effects on software maintainability, 2026

• Dropbox Engineering Career Framework

• Software engineering team project courses with industrial customers, 2025

• Application of Project‑Based Learning to a Software Engineering course, 2023