AI и будущее инженерной профессии
Вопрос не в том, заменит ли AI разработчиков, а в том, какая часть текущей работы дешевеет, а какая нет. Разбираю, что реально меняется в найме, в роли джуна, в экономике соло-разработки и в ответственности за код, который написал не человек.
Неправильный вопрос и правильный
"Заменит ли AI разработчиков" — вопрос, сформулированный неточно, и именно неточность формулировки порождает большую часть паники и большую часть безосновательного спокойствия одновременно. Правильный вопрос звучит иначе: какая часть сегодняшней работы разработчика дешевеет до уровня рядовой, взаимозаменяемой услуги, доступной любому, кто умеет чётко ставить задачи, а какая продолжает требовать редкого, дорогого умения, которое не автоматизируется тем же способом.
Этот вопрос касается не только тех, кто уже работает в индустрии, но и тех, кто только выбирает, стоит ли в неё входить. Абитуриент, выбирающий специальность, и junior, ищущий первую работу, читают заголовки о том, что "AI пишет весь код" и делают из этого вывод, что вход в профессию больше не имеет смысла. Это ровно тот поспешный вывод, который делает неточная формулировка исходного вопроса, и один из мотивов написать этот текст — предложить более точную рамку для тех, кто принимает подобные решения сейчас, а не только для тех, кто уже давно в профессии и переживает изменение правил игры на ходу.
В материале про AI для разработки я уже формулировал этот тезис коротко: написание кода как таковое дешевеет и продолжит дешеветь. Способность понимать, что вообще нужно построить, как это должно работать в контексте реальной системы, и как проверить, что результат действительно корректен, дешеветь не собирается, потому что именно это остаётся узким местом даже при идеально работающих AI-инструментах. Здесь я разворачиваю этот тезис на весь горизонт профессии: найм, роль джуна, экономику соло-разработки, ответственность за код, которого человек не писал сам, и честный прогноз на несколько лет вперёд.
Пишу это не как футуролог с уверенным взглядом в хрустальный шар, а как инженер, который эти изменения проживает каждый день на практике, включая тот факт, что этот самый текст написан в паре с Claude Code. Там, где я не уверен, буду говорить прямо, что не уверен, вместо того чтобы выдавать личное мнение за неопровержимый факт.
В этом тексте не будет ни бодрого "AI никогда не заменит настоящего инженера", ни панического "через три года программистов не останется". Обе крайности одинаково удобны тем, что снимают необходимость думать о деталях: первая успокаивает без разбора, вторая пугает без разбора. Реальная картина сложнее и менее удобна для короткого лозунга, и именно поэтому в неё стоит разбираться подробно, а не довольствоваться одной из двух готовых позиций.
Заменит ли AI разработчиков
Самый честный ответ: смотря что называть "разработчиком". Если это человек, чья единственная ценность в способности перевести уже полностью специфицированную задачу в синтаксически корректный код на конкретном языке, эта роль действительно сжимается стремительно, потому что именно это AI-агенты делают всё лучше и всё дешевле каждый следующий год. Если это человек, чья ценность в способности разобраться в мутной, плохо специфицированной проблеме, спроектировать решение с учётом ограничений, которые никто явно не проговорил, и нести ответственность за то, что это решение действительно работает в проде, эта роль не только не исчезает, но становится более концентрированной и более высокооплачиваемой, потому что предложение таких людей растёт медленнее, чем спрос на их работу.
Полезно разложить работу разработчика на составные части и отдельно оценить траекторию каждой, вместо того чтобы говорить о профессии как о едином неделимом занятии, потому что именно смешение разных по природе задач в одно понятие "работа программиста" и порождает большую часть путаницы в спорах о будущем профессии. Написание синтаксически корректного кода по готовой спецификации. Проектирование архитектуры под ограничения, которые часто не проговорены явно. Отладка системы, где причина сбоя скрыта за несколькими слоями абстракции. Коммуникация с людьми, которые ставят задачу и от которых зависит бюджет и сроки. Ответственность за то, что результат действительно корректен, а не только выглядит корректным. Первая часть автоматизируется быстрее всего. Остальные четыре либо автоматизируются намного медленнее, либо не автоматизируются в обозримом горизонте вообще, потому что упираются в природу самой задачи, понимание неявного контекста, доверие между людьми, ответственность за последствия, а не в техническую сложность.
Полезная историческая параллель, о которой я тоже писал в материале про AI для разработки: профессия уже проходила похожие переходы несколько раз, просто на разных уровнях абстракции. Переход от ассемблера к языкам высокого уровня не убрал профессию программиста, он убрал необходимость держать в голове регистры процессора. Переход от собственноручного написания структур данных к использованию стандартных библиотек не убрал профессию, он сдвинул ценность от умения написать хорошее дерево поиска к умению правильно выбрать готовую структуру под задачу. Каждый такой переход не уменьшал число разработчиков, а менял, что именно считается работой разработчика.
Отличие нынешнего перехода не в направлении, а в скорости. Переход к языкам высокого уровня занял годы адаптации всей индустрии. Переход к agentic-разработке происходит на протяжении одного-двух лет, и именно эта сжатая скорость создаёт ощущение тревоги, которого не было при более медленных переходах прошлого, хотя структурно происходящее похоже на уже пройденные этапы.
Сжатая скорость перехода означает и то, что у индустрии физически меньше времени на выработку новых норм и практик, чем было при предыдущих переходах. Соглашения о том, как правильно ревьюить агентный код, как распределять ответственность внутри команды, как учить junior-специалистов в новых условиях, обычно формируются годами коллективной практики методом проб и ошибок. Когда сам переход занимает год-два, эти нормы вырабатываются на ходу, параллельно с самим внедрением технологии, а не после него, и часть сегодняшней неопределённости в индустрии объясняется именно этим отставанием практик и норм от скорости изменения самого инструмента.
Как изменится найм в ближайшие годы
Найм разработчиков уже меняется, и происходит это не через полное исчезновение позиций, а через смещение критериев отбора. Способность быстро написать рабочий алгоритм на собеседовании, которая десятилетиями была стандартным фильтром при найме, теряет диагностическую ценность, потому что тот же результат сегодня получается за секунды через AI-ассистента, и собеседование, построенное вокруг этого навыка, всё хуже отличает сильного кандидата от того, кто просто умеет пользоваться инструментом.
Собеседования постепенно смещаются в сторону задач, которые труднее делегировать модели целиком: разбор существующей плохо документированной кодовой базы, поиск неочевидной причины бага в системе с множеством взаимодействующих частей, аргументированная защита архитектурного решения перед вопросами с подвохом. Это не значит, что технические собеседования исчезнут, значит, что их содержание продолжит смещаться от "напиши код" к "разберись в системе и объясни решение".
Компании, которые продолжают нанимать по старым критериям просто потому, что эти критерии знакомы и привычны для тех, кто проводит собеседование, рискуют получать кандидатов, отобранных не по той способности, которая реально нужна на рабочем месте. Кандидат, идеально решающий классические алгоритмические задачи на собеседовании, но не умеющий эффективно делегировать рутину AI-агенту и контролировать результат, на практике окажется медленнее коллеги с более скромными алгоритмическими навыками, но отлаженным agentic-процессом. Разрыв между тем, что проверяет собеседование, и тем, что реально нужно на работе, будет только расти, пока процессы найма не догонят изменившуюся структуру самой работы.
Второе заметное изменение: растёт ценность кандидатов, которые уже умеют эффективно работать с AI-агентами как с частью рабочего процесса, а не воспринимают их как факультативную игрушку. Компании, которые перестроили процессы вокруг agentic-разработки, всё чаще ищут людей, способных сразу включиться в такой процесс, а не тратить месяцы на адаптацию к самой идее делегирования кода агенту.
Третье изменение касается портфолио и резюме. Ссылка на личный проект, полностью написанный самим кандидатом от начала до конца без единого AI-инструмента, постепенно теряет ту демонстративную ценность, которую имела раньше, просто потому что становится неясно, показывает ли она реальный навык или просто отсутствие доступа к современным инструментам. Более информативным сигналом становится то, как кандидат объясняет решения внутри проекта, а не сам факт его существования: почему выбрана именно эта архитектура, какие альтернативы рассматривались и отклонены, что пошло не так в процессе и как это было исправлено.
Какие инженерные навыки остаются ценными
Список навыков, которые не дешевеют вместе с написанием кода, довольно устойчив, и его стоит проговорить явно, а не оставлять как абстрактную идею. Первый: способность формулировать требования достаточно точно, чтобы задача была решаема, но достаточно широко, чтобы не упустить реальную проблему за узкой технической спецификацией. Второй: системное мышление, способность держать в голове, как изменение в одном месте системы аукнется в другом, не всегда очевидном месте. Третий: способность оценить, действительно ли предложенное решение, человеком или агентом, корректно работает, а не просто выглядит правдоподобно.
Четвёртый навык, который недооценивают чаще остальных: коммуникация с людьми, а не с моделями. Убедить команду в правильности архитектурного решения, договориться с продактом о реалистичных сроках, объяснить нетехническому руководству, почему технический долг сейчас дороже, чем кажется, ни один из этих навыков не автоматизируется тем же способом, что написание кода, потому что они завязаны на человеческое доверие и человеческие отношения, а не на техническую корректность результата.
Показательно, что этот навык не новый и не специфичный для эпохи AI, он был важен и раньше, просто оставался в тени более заметного, легко измеримого навыка написания кода. Компании годами нанимали и продвигали в первую очередь по видимому техническому результату, а не по качеству коммуникации, именно потому что технический результат проще измерить объективно, а качество коммуникации трудно оценить без длительного наблюдения. Сейчас, когда написание кода как узкое место исчезает, коммуникационная и организационная составляющая работы становится видна отчётливее просто потому, что рядом с ней больше не стоит равновеликая по важности задача набора текста, отвлекающая внимание на себя.
Пятый навык, специфичный именно для эпохи AI-агентов: способность эффективно ставить задачу агенту и оценивать результат. Это не тот же навык, что программирование в привычном смысле, но и не тривиальный навык, который приходит сам собой без практики. Подробно я разбирал его в материале про AI-ассистентов в разработке: настройка, формулировка задачи, ревью агентного кода — всё это отдельная, растущая по важности компетенция.
Шестой навык, менее очевидный, но всё более значимый: умение проектировать структуру проекта и документацию так, чтобы с ней было легко работать не только человеку, но и агенту. Подробно я разбирал эту тему в материале про архитектуру для AI-driven разработки: явные конвенции именования, единая точка входа для инструкций агенту, модульность вместо удобных, но связанных сокращений. Разработчик, который умеет строить такую архитектуру, получает совокупный выигрыш от каждого агента, работающего в его кодовой базе, тогда как разработчик, игнорирующий эту сторону работы, платит за плохую архитектуру растущую цену с каждой новой agentic-сессией.
От разработчика к оркестратору AI-агентов
Роль, которая складывается на глазах, ближе к дирижёру оркестра, чем к музыканту, играющему одну партию. Дирижёр не обязан уметь виртуозно играть на каждом инструменте лучше, чем сами музыканты, но обязан понимать, как звучит партия каждого инструмента, где партии должны сойтись вместе и что делать, если один из музыкантов фальшивит. Разработчик, работающий с несколькими параллельными AI-агентами над разными частями системы, занимается структурно похожей задачей: не пишет каждую строчку сам, но отвечает за то, чтобы результат работы всех агентов сложился в согласованную, корректную систему.
Метафора с дирижёром полезна и в другом смысле: дирижёр, который не умеет играть ни на одном инструменте вообще, физически не способен оценить, фальшивит ли конкретный музыкант, и такая же логика применима к оркестрации AI-агентов. Способность эффективно направлять несколько агентов параллельно требует достаточной глубины собственного технического понимания, чтобы заметить, когда результат агента неверен, даже если сам код для этого результата человек уже давно не пишет руками постоянно. Оркестрация без базового технического понимания превращается в слепое доверие результату, которое рано или поздно приводит к серьёзной ошибке, пропущенной просто потому, что некому было её заметить.
Эта роль требует другого распределения внимания в течение дня, чем классическое программирование. Меньше времени уходит на набор текста кода, больше на постановку задач, ревью результата и разрешение конфликтов между частями системы, сделанными разными агентами или разными людьми. Это не облегчение работы в смысле меньшей нагрузки, а изменение её характера: нагрузка смещается с моторного навыка написания кода на когнитивную нагрузку постоянного контроля качества и согласованности результата.
Многие разработчики, привыкшие к прежнему распределению внимания, первое время воспринимают это смещение как потерю, а не как изменение характера работы. Написание кода даёт немедленное, ощутимое чувство прогресса: строчки появляются на экране, функция начинает работать. Ревью чужого, пусть и агентного, кода такого немедленного чувства не даёт, и первое время новая роль может субъективно ощущаться менее удовлетворяющей, даже если объективно человек за то же время закрывает больший объём реальной работы. Это чисто психологическая адаптация, а не признак того, что что-то идёт не так, и она проходит по мере накопления практики в новой роли.
Экономика соло-разработки в эпоху AI
Один инженер с хорошо выстроенным agentic-процессом сегодня закрывает объём работы, для которого несколько лет назад требовалась небольшая команда. Это не преувеличение ради красивой фразы, а прямое следствие того, что рутинная часть реализации, которая раньше требовала нескольких пар рук просто чтобы физически успеть набрать весь необходимый код, теперь делегируется агентам, а человеку остаётся архитектура, ревью и принятие решений.
Я подробно разбираю, как это работает на практике, включая свои собственные провалы и рабочие решения, в материале про то, как строю AI-продукты соло: там же разбор конкретных компромиссов между скоростью соло-решений и отсутствием второго мнения, которое даёт команда. Здесь важно закрепить общий тезис: экономика разработки продукта меняется не только для крупных компаний, нанимающих меньше junior-инженеров, но и для отдельного человека, у которого появляется реалистичная возможность строить продукт в одиночку там, где раньше это требовало команды или значительного капитала на найм.
Эта экономика меняет и то, какие продукты вообще имеет смысл начинать строить. Идея, которая раньше отсеивалась на старте просто потому, что требовала команды из трёх-четырёх человек на полгода ради проверки гипотезы, а такие ресурсы редко есть у одного человека без внешнего финансирования, теперь может быть проверена одним человеком за заметно меньший срок. Это не значит, что качество или сложность продукта, которую способен построить один человек, сравнялись с тем, что способна построить полноценная команда, но порог входа в саму попытку заметно снизился, и это меняет структуру того, кто вообще решается пробовать.
Побочный эффект этого сдвига: конкуренция в нишах с низким порогом входа тоже растёт, потому что больше людей физически способны попробовать похожую идею одновременно. Это не аргумент против соло-разработки как стратегии, а честное уточнение к оптимистичной картине: снижение порога входа снижает его для всех одновременно, а не только для конкретного человека, читающего этот текст, и конкурентное преимущество теперь чаще определяется не самим фактом использования AI-инструментов, а тем, насколько хорошо конкретный человек умеет их применять и насколько глубоко понимает нишу, в которой строит продукт.
Junior-разработчики в эпоху AI
Из всех разделов этого текста этот, вероятно, самый чувствительный, потому что затрагивает конкретных людей на самом раннем и самом уязвимом этапе карьеры, а не абстрактную индустрию в целом. Здесь честность важнее оптимизма. Классический путь роста junior-разработчика долгое время строился на том, чтобы делать рутинную, хорошо специфицированную работу под присмотром старшего, постепенно набираясь опыта и переходя к более сложным задачам. AI-агенты забирают именно эту рутинную работу, и это реально сужает классический путь входа в профессию через выполнение простых тикетов под наблюдением.
Это создаёт реальную организационную проблему, значимую для всей индустрии на горизонте нескольких лет, а не только индивидуальную проблему конкретного junior-специалиста, который сейчас ищет первую работу. Если рутинные задачи, которые раньше доставались junior-специалистам, теперь делает агент под руководством senior-инженера напрямую, откуда возьмётся следующее поколение senior-специалистов через десять лет, если у них не было того самого этапа накопления опыта через рутину, на котором раньше держалось профессиональное взросление. Это вопрос, на который у индустрии пока нет проверенного практикой ответа, и компаниям, которые всерьёз думают о развитии кадров на горизонте в несколько лет, стоит сознательно проектировать новые пути накопления опыта, а не полагаться на то, что старая модель наставничества продолжит работать без изменений в новых условиях.
Это не значит, что дорога для новых разработчиков закрылась, значит, что она меняет форму. Ценность для junior-специалиста смещается с "умею быстро написать код по готовой спецификации" на "умею быстро разобраться в чужом коде, задать агенту правильный вопрос и заметить, если результат агента неверен". Это более требовательный набор навыков на старте карьеры, чем раньше, и здесь есть реальный риск: без осознанной практики глубокого понимания, а не только использования готовых ответов от модели, junior рискует остаться на уровне человека, который умеет запускать чужие решения, но не понимает, почему они работают.
Практический совет для тех, кто сейчас входит в профессию: сознательно тратить часть времени на то, чтобы понимать код, который написал агент, а не только проверять, что он запускается. Разница между использованием AI как костыля, который позволяет пропустить понимание, и использованием AI как ускорителя, который освобождает время для более глубокого понимания той же задачи, определяет, вырастет ли из junior специалист, который реально разбирается в деле, или человек, зависимый от инструмента без понимания, что происходит внутри.
Конкретная практика, которая помогает удержать этот баланс и которую стоит превратить в привычку с самых первых недель работы: после того как агент решил задачу, потратить несколько минут на то, чтобы объяснить решение самому себе или коллеге своими словами, не подглядывая в код. Если объяснение не получается, это сигнал, что задача решена, но не понята, и стоит вернуться и разобраться, прежде чем переходить к следующей. Это требует дисциплины, потому что скорость, с которой агент выдаёт рабочий результат, создаёт соблазн сразу двигаться дальше, не останавливаясь на то, что кажется уже закрытым вопросом.
Ответственность за эту адаптацию лежит не только на самом junior-специалисте, который часто ещё недостаточно опытен, чтобы самостоятельно заметить разницу между решённой и понятой задачей, но и на компаниях и менторах, которые его нанимают и обучают. Организация, которая продолжает мерить прогресс junior-сотрудника количеством закрытых тикетов, не заботясь о том, понимает ли он реально написанный код, рискует вырастить специалиста, зависимого от инструмента настолько, что без него окажется беспомощным перед задачей, которую годом ранее решил бы самостоятельно.
AI и open source: как меняется экосистема
Open source традиционно держался на добровольном труде людей, которые решали свою собственную проблему и делились решением с остальными. AI-агенты меняют экономику этого труда с обеих сторон: с одной стороны, снижают порог вхождения в контрибьютинг, потому что человеку не нужно держать в голове весь контекст большого проекта, чтобы предложить осмысленный патч, агент может помочь разобраться в незнакомой кодовой базе быстрее. С другой стороны, создают новую нагрузку на мейнтейнеров: рост числа автоматически сгенерированных, не всегда качественных пул-реквестов, которые нужно отфильтровывать, ощутимо увеличивает объём ревью на стороне тех, кто поддерживает проект.
Уже сейчас заметен конкретный симптом этого сдвига: мейнтейнеры крупных проектов регулярно жалуются на пул-реквесты, которые выглядят технически грамотно, проходят автоматические проверки, но на деле не решают заявленную проблему или решают её поверхностно, без понимания более широкого контекста проекта. Такие вклады отнимают время ревьюера примерно так же, как и качественный патч, потому что различить их на глаз, не углубляясь в детали, часто невозможно, и это асимметрия, которая работает не в пользу мейнтейнера: автору патча создать правдоподобно выглядящий, но неглубокий вклад стало заметно дешевле, чем ревьюеру его тщательно проверить.
Долгосрочный эффект пока неясен и, честно говоря, я не готов делать здесь уверенный прогноз. Возможный сценарий: усиление уже существующего разрыва между небольшим числом крупных, хорошо финансируемых open source проектов, которые могут себе позволить строгие процессы модерации вклада, и множеством маленьких проектов, поддерживаемых одним человеком, для которых поток низкокачественных AI-сгенерированных предложений может стать непосильной нагрузкой без дополнительных инструментов фильтрации.
Есть и обратный, более оптимистичный сценарий, который тоже стоит держать в уме: те же AI-инструменты, которые увеличивают поток предложений на входе, способны помогать и на стороне ревью, автоматически отсеивая явно некачественные или неполные патчи до того, как они доходят до внимания живого мейнтейнера. Какой из двух эффектов перевесит, скорость роста нагрузки или скорость роста инструментов фильтрации этой нагрузки, определит, станет ли эта эпоха для open source периодом изобилия вклада или периодом истощения мейнтейнеров, и у меня пока нет уверенного ответа, какой из сценариев реализуется на практике.
Что говорят исследования о влиянии AI на продуктивность
Здесь честность требует признать: однозначной, устоявшейся картины пока нет. Часть исследований показывает существенный прирост скорости выполнения задач при использовании AI-ассистентов, особенно на рутинных, хорошо специфицированных задачах. Другие, более узко сфокусированные работы показывают смешанную или даже отрицательную картину в конкретных условиях: например, там, где опытный разработчик уже прекрасно знает конкретную большую кодовую базу и время на формулировку задачи агенту и проверку его результата перевешивает выигрыш от того, что код написан не руками.
Разница в результатах между исследованиями объясняется в первую очередь разницей в задачах и в опыте участников, а не противоречием как таковым. Прирост продуктивности от AI-ассистентов выше на новых, малознакомых кодовых базах и на рутинных задачах, и ниже или даже отрицателен на задачах в глубоко знакомой системе, где интуиция опытного разработчика уже работает быстрее, чем цикл формулировки запроса и проверки ответа. Разумный вывод из этой неоднородности: не полагаться на общее убеждение "AI однозначно ускоряет работу" как на универсальную истину, а трезво оценивать, для какого конкретно типа задачи в твоей собственной практике это утверждение реально верно.
Практическая оговорка для читателя, который хочет опираться на конкретные цифры прироста продуктивности из подобных исследований: перед тем как доверять любой конкретной цифре, стоит проверить, на какой выборке разработчиков и на каком типе задач она получена, потому что именно эти детали чаще всего определяют, применим ли результат к твоей собственной ситуации, а не общий процент, вынесенный в заголовок исследования или новостной заметки о нём.
Есть и методологическая сложность, которая объясняет часть разброса результатов сама по себе: субъективное ощущение ускорения и объективно измеренное время выполнения задачи не всегда совпадают. Разработчик может чувствовать себя быстрее с AI-ассистентом просто потому, что часть рутинной, утомительной работы теперь делает не он, хотя объективное время до готового результата осталось примерно тем же или даже выросло за счёт времени на формулировку запросов и проверку ответов. Субъективное ощущение легче измерить опросом, объективное время выполнения требует более трудоёмкого наблюдения, и часть шумихи вокруг впечатляющих цифр прироста продуктивности, вероятно, отражает именно эту разницу между ощущением и объективным замером, а не выдумку или ошибку в конкретном исследовании.
Кто отвечает, если AI-агент сломал прод
Вопрос ответственности не абстрактный: он возникает в первый же раз, когда сгенерированный агентом код проходит ревью, мержится и ломает что-то в продакшене. Юридический и организационный ответ здесь простой и, на мой взгляд, единственно разумный: ответственность несёт человек, который одобрил изменение и отправил его в прод, а не инструмент, которым он пользовался. Агент не несёт ответственности в том смысле, в котором её несёт человек, у него нет карьеры, репутации и трудового контракта, которые может задеть ошибка.
Соблазн переложить часть ответственности на инструмент психологически понятен, особенно сразу после инцидента, когда естественно искать объяснение, снимающее часть личной вины. "Агент написал плохой код" звучит как объяснение, но не является оправданием, точно так же как "компилятор скомпилировал ошибку" никогда не считалось приемлемым объяснением для программиста, допустившего логическую ошибку. Инструмент делает ровно то, о чём его попросили, и ответственность за то, была ли просьба сформулирована достаточно точно, а результат достаточно проверен, остаётся на человеке независимо от того, насколько автономным кажется сам инструмент в моменте использования.
Это не абстрактное рассуждение. В процессе работы над этим самым сайтом всплывал реальный баг: CMS падала с ошибкой при повторном сохранении поста из-за несовпадения типа булева поля между бэкендом и фронтендом. Код, где закралась эта нестыковка, был написан в паре с Claude Code, но ответственность за то, что баг дошёл до продакшена, лежит на мне, потому что я его смержил без теста именно на этот сценарий. Инструмент не проверяет себя сам за пределами того, что явно попросили проверить, и делегирование написания кода агенту не означает делегирования ответственности за качество результата.
Похожая история случилась и с багом транслитерации кириллицы в слаге поста, где буквы "ь" и "ъ" не исчезали при генерации URL, как ожидалось. Оба случая объединяет одна и та же структура ошибки: код формально работал в очевидных сценариях и ломался в неочевидном краевом случае, который не пришёл в голову ни мне, ни агенту в момент написания. Ни в одном из этих случаев не имело смысла винить инструмент за то, что он не предугадал сценарий, который я сам не сформулировал явно, точно так же, как не имело бы смысла винить джуна за баг в задаче, которая была поставлена нечётко.
Практическое следствие для команд, внедряющих agentic-разработку: процесс ревью и тестирования должен оставаться настолько же строгим, а иногда и строже, чем при коде, написанном человеком, а не ослабляться из предположения, что раз код написан AI, то он как-то автоматически надёжнее или не требует того же уровня проверки.
Отдельный организационный вопрос, который компаниям только предстоит для себя решить, и я не вижу, чтобы индустрия уже выработала здесь устоявшуюся практику: как распределяется ответственность, если код одобрил один человек, а написал агент, настроенный и запущенный другим. В классической модели код-ревью человек, оставивший одобрение, несёт ответственность за то, что он одобрил, независимо от того, кто именно писал код физически. Agentic-разработка не меняет этот принцип по существу, но усложняет его практическое применение, потому что ревьюеру приходится оценивать не только сам код, но и то, насколько разумно был построен процесс, которым этот код получен, а это требует понимания самого agentic-процесса, а не только чтения диффа.
Как оставаться конкурентоспособным разработчиком
Практические выводы из всего разобранного выше складываются в конкретный набор действий, а не в абстрактную тревогу. Первое: сознательно инвестировать время в навыки, которые не дешевеют, системное мышление, способность оценивать корректность решения, коммуникацию с людьми, а не только в изучение очередного нового AI-инструмента ради самого факта его новизны.
Это не значит игнорировать новые инструменты, скорость их появления слишком высока, чтобы полностью их игнорировать было разумной стратегией. Значит соблюдать пропорцию: время, потраченное на изучение конкретного нового инструмента, стоит сопоставлять со временем, потраченным на развитие навыков, которые остаются полезными независимо от того, какой конкретно инструмент окажется популярным через год. Инструмент, ставший фаворитом сегодня, вполне может устареть через полтора года, а системное мышление и умение работать с людьми остаются полезными десятилетиями.
Второе: активно практиковаться в эффективной работе с AI-агентами как с отдельным навыком, а не ждать, что он придёт сам собой от пассивного использования. Про то, как реально устроена продуктивная система вокруг такой работы, я писал в материале про системы продуктивности и в материале про фокус и глубокую работу: способность удерживать внимание на сложной архитектурной проблеме, не отвлекаясь на каждую мелкую заминку через обращение к ассистенту, остаётся ровно тем навыком, который отличает эффективного оркестратора агентов от человека, зависимого от постоянных подсказок.
Здесь же стоит вспомнить дисциплину ревью, о которой я писал в материале про AI code review: способность быстро и качественно проверять чужой, в том числе агентный, код становится одним из центральных навыков профессии, а не вспомогательным довеском к написанию кода, по мере того как доля самостоятельно написанного кода в рабочем дне сокращается, а доля проверенного и одобренного кода растёт.
Третье, менее очевидное: беречь себя от тревоги, которая сама по себе снижает качество работы. Тревога о замене AI тесно связана с синдромом самозванца, о котором я писал в материале про профилактику выгорания: попытка компенсировать эту тревогу постоянной переработкой и попыткой "успеть везде" обычно ухудшает, а не улучшает результат, потому что истощённый специалист хуже справляется именно с теми задачами системного мышления и проверки качества, которые остаются самой ценной частью работы.
Порочный круг здесь тот же, что и в общей механике выгорания: тревога о собственной заменимости провоцирует переработку, переработка снижает качество системного мышления и внимательность к деталям, снижение качества подтверждает исходный страх "я недостаточно хорош на фоне того, что теперь умеет AI", и цикл повторяется с новой силой. Разорвать его получается через прямо противоположное действие, а не через ещё большее усилие: сознательно защитить время для отдыха и глубокой, немногозадачной работы именно тогда, когда тревога подсказывает делать обратное.
Четвёртое практическое действие, о котором редко говорят прямо: строить репутацию не вокруг конкретного технологического стека, а вокруг способности решать определённый класс проблем. Стек устаревает циклами в несколько лет, иногда быстрее. Репутация человека, который умеет разбираться в сложных, плохо специфицированных системах и доводить решение до продакшена, переживает смену конкретных инструментов и языков, потому что она не привязана к тому, что именно эти инструменты умеют делать сегодня.
Куда движется профессия: личный взгляд
Дальше идёт открыто личное мнение, а не прогноз, выдаваемый за факт.
К 2030 году я ожидаю, что понятие "разработчик" разделится заметнее, чем сейчас, на несколько отдельных, менее похожих друг на друга ролей: архитекторов систем, которые проектируют, но почти не пишут код руками; специалистов по надёжности и проверке, чья основная работа — валидация результата, произведённого агентами; и узких экспертов в конкретных областях, чья ценность в глубоком знании предметной области, а не в универсальном умении программировать.
Я ожидаю, что часть индустрии, которая сегодня существует в состоянии тревоги "AI отберёт работу", через несколько лет либо адаптируется к новой структуре ролей, либо действительно столкнётся с реальным сокращением спроса на свой конкретный, узкий набор навыков. Это не радостный прогноз и не катастрофичный, а просто честный: переходы такого масштаба всегда создают проигравших и выигравших, и то, на какой стороне окажется конкретный человек, будет определяться не тем, использует ли он AI вообще, а тем, вложился ли он в навыки, которые остаются ценными по мере того, как дешевеет написание кода.
Я также ожидаю, что часть сегодняшних инструментов и практик, которые кажутся передовыми прямо сейчас, окажутся к 2030 году такими же устаревшими, какими сегодня выглядят практики программирования десятилетней давности. Конкретные детали настройки конкретного AI-ассистента, которые я разбираю в других материалах этого блога, почти наверняка изменятся до неузнаваемости. Принципы, стоящие за этими деталями, разделение ответственности между человеком и агентом, важность проверки результата, ценность понимания системы поверх умения писать код, вероятно, останутся теми же самыми, просто применёнными к другим, более развитым инструментам.
Отдельно ожидаю, что сама профессия станет менее однородной по требуемому набору навыков, чем сегодня. Разрыв между инженером, работающим архитектором в крупной системе, и инженером, ведущим единственный небольшой проект в одиночку, по набору повседневных задач уже сейчас больше, чем разрыв между двумя условными "программистами" десять лет назад, и я ожидаю, что эта дивергенция продолжит расти, а не выравниваться, по мере того как AI забирает разные доли рутинной работы у этих двух ролей в разной степени.
Если этот прогноз через несколько лет окажется неверным хотя бы частично, я предпочту признать это прямо, а не тихо переписать текст задним числом. Дата в начале этого материала фиксирует момент, когда эти рассуждения были актуальны, и это единственная честная гарантия, которую можно дать любому прогнозу подобного рода.
Что бы ни оказалось верным из перечисленного здесь, одно кажется мне устойчивым сильнее остальных прогнозов: профессия не исчезнет и не останется прежней одновременно. Она продолжит существовать в форме, которую сегодня трудно предсказать в деталях, точно так же как программист девяностых с трудом узнал бы в сегодняшнем agentic-workflow ту же самую профессию, хотя преемственность между ними очевидна задним числом. Единственное, что реально в моих силах сделать сейчас, это не пытаться угадать все детали этой будущей формы, а вкладываться в то, что остаётся ценным при любом разумном сценарии: понимание систем, честная оценка собственной работы и способность договариваться с другими людьми о том, что вообще стоит строить.
Комментарии
Комментариев пока нет. Будь первым.