Код стал дешёвым: заменит ли AI разработчиков

12 мин чтения

Последние пару лет я всё чаще слышу от разработчиков одну и ту же мысль: «Ну всё. Ещё год-два — и нас заменит AI».

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

Я не думаю, что завтра компании уволят всех разработчиков и вместо backend, frontend и мобильной команды посадят один Claude Code. Мне кажется, произойдёт другое: понятие «разработчик» начнёт исчезать в том виде, в котором мы привыкли его воспринимать. Не потому что код больше не нужен, а потому что код стал дешёвым.

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

Четыре года AI: уровень абстракции всё время растёт

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

Сначала был просто чат: копируешь функцию, вставляешь, пишешь «найди баг». Потом все занялись prompt engineering и огромными промптами в духе «представь, что ты senior software engineer с двадцатилетним опытом». Потом появились Cursor и похожие инструменты — AI получил доступ уже не к одному сообщению, а к кодовой базе. Потом пришли coding agents: Claude Code, Codex и остальные. И мы перестали говорить «напиши мне вот эту функцию». Мы начали говорить: «вот задача, разберись в проекте и реализуй её».

Дальше появился context engineering — быстро выяснилось, что проблема уже не столько в модели, сколько в контексте, который мы ей дали: какие правила проекта она знает, какие документы читает, какие инструменты может вызвать, как проверяет собственную работу. Сейчас всё больше разговоров идёт вокруг agent harness — всей системы вокруг агента.

Направление видно хорошо:

  • Чат — «найди баг в этой функции». Единица работы: строка.
  • Prompt engineering — «представь, что ты senior engineer с двадцатилетним опытом…». Единица работы: функция.
  • IDE-ассистенты — «перепиши этот модуль по правилам проекта». Единица работы: файл.
  • Coding agents — «вот задача, разберись в проекте и реализуй». Единица работы: задача.
  • Context engineering — правила, документы, инструменты, способ самопроверки. Единица работы: задача вместе с контекстом.
  • Agent harness — вся система вокруг агента. Единица работы: эпик.

Уровень абстракции постоянно поднимается. Сначала AI писал строку. Потом функцию. Потом файл. Потом задачу. Сейчас мы приближаемся к тому, чтобы отдавать ему целые куски проекта.

Зачем бизнесу вообще нужны разработчики

Здесь стоит на минуту отойти от AI.

Я работаю руководителем группы разработки, поэтому взаимодействую не только с разработчиками, но и с бизнесом, менеджментом, продуктом. И мне кажется, разработчики иногда забывают простую вещь: мы существуем не для того, чтобы писать код.

Компания не зарабатывает на том, что мы написали красивый микросервис. Ей в большинстве случаев всё равно, использовали мы Factory Method или другой модный подход. Цикл выглядит иначе: есть проблема пользователя, есть гипотеза бизнеса, как её решить, мы реализуем изменение, выкатываем в production, пользователь начинает им пользоваться, бизнес получает данные, гипотеза подтверждается или нет — и запускается следующий круг.

Если сильно упростить, разработка обеспечивает бизнесу две вещи: скорость изменений и надёжность. Доставлять изменения быстро, но так, чтобы система не разваливалась. Это же измеряют метрики DORA — с одной стороны частота релизов и время от коммита до прода, с другой доля неудачных изменений и время восстановления.

И если завтра появится способ доставлять ту же фичу не за месяц, а за три дня, бизнес будет очень заинтересован в этом способе.

Почему разработка сегодня стоит дорого

Посмотрим, как обычно выглядит процесс.

У бизнеса или пользователя появляется проблема. Продукт решает, какую фичу делать. Подключается системный аналитик: разбирает требования, декомпозирует, пишет спецификацию. Задача попадает разработчику — а если фича большая, то сразу нескольким: backend, frontend, мобильная разработка. Потом QA тестирует. Потом выкатываем в production, смотрим мониторинг. Потом всё это уходит в поддержку.

Обратите внимание: одна и та же задача проходит через головы огромного количества людей. Вместе с этим появляется коммуникация — созвоны, уточнения, переписки, комментарии в Jira.

«А здесь поле обязательное?» «А backend думал, что frontend это сам обработает». «А Android использует старую версию API». «А аналитик вообще имел в виду другое».

Получается сломанный телефон. Причём большую часть времени каждый владеет только своим куском контекста: backend знает backend, frontend знает frontend, QA знает тест-кейсы. А целостная картина находится где-то между всеми этими людьми.

Именно здесь AI поменяет разработку сильнее всего.

Новая единица работы — эпик, а не задача

Мы будем постепенно уходить от модели «вот тебе backend-задача, сделай endpoint» к модели «вот проблема пользователя, вот ограничения, вот ожидаемый результат — доставь решение».

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

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

Нужно сделать frontend, а вы не фронтендер? У вас есть агент. Нужно разобраться, как работает Android-клиент? Есть агент. Написать миграцию или тесты? То же самое.

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

Исчезнут ли аналитики, QA и SRE

Нет. Я вообще осторожно отношусь к прогнозам в стиле «через два года профессии X не будет».

Крупные компании всё равно будут держать людей, которые глубоко разбираются в инфраструктуре, безопасности, сложных бизнес-доменах, мобильной разработке, базах данных. Глубина никуда не делась.

Но границы между ролями будут размываться. В простой или средней задаче уже не всегда нужна цепочка аналитик → backend → frontend → QA → DevOps: большую её часть закроет один сильный инженер с агентами. Специалисты подключаются там, где нужна реальная глубина.

AI не уничтожает специализацию. Он делает дешёвым переход между специализациями.

Практики не изменились — изменилась их цена

Забавный парадокс: мы говорим про какую-то новую AI-разработку, но все хорошие инженерные практики существовали десятилетиями.

Перед реализацией нормально описать задачу. Сложное архитектурное решение зафиксировать в ADR. Большое изменение обсудить через RFC. Код покрыть тестами. Контракты зафиксировать. Документацию поддерживать. Production мониторить.

Раньше это воспринималось как дополнительная работа. Ты уже написал код, а тебе говорят: «напиши ещё документацию». Естественная реакция — «да зачем, я и так всё понимаю».

С AI ситуация другая. Спецификация — это больше не документ, который никто не прочитает. Это контекст для агента. ADR объясняет агенту, почему система устроена именно так. Тесты становятся способом автоматически проверить его работу. Документация помогает ему ориентироваться в проекте.

Практики, которые мы всегда считали правильными, неожиданно стали ещё ценнее. Потому что когда написание кода дешевеет, основная ценность — не набор символов в Git, а принятое инженерное решение: почему мы сделали именно так, какие есть ограничения, какие альтернативы рассматривали, какие инварианты нельзя нарушать, как поймём, что решение работает.

Вот это AI из воздуха не достанет.

Что дешевеет, а что дорожает

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

Что дешевеет:

  • написать код по готовой спецификации;
  • зайти в соседний стек;
  • собрать прототип или черновик;
  • помнить синтаксис, API и конфигурацию;
  • повторить известный паттерн.

Что дорожает:

  • сформулировать задачу и ограничения;
  • принять архитектурное решение и увидеть его последствия;
  • проверить результат на проде;
  • понимать систему целиком;
  • отвечать за результат.

Рынок будет меньше платить за способность писать код. Но это не значит, что он перестанет платить за engineering — скорее наоборот. Чем больше кода генерируют машины, тем важнее люди, которые способны ответить: а тот ли код вообще нужно писать? Как решение встроится в существующую систему? Что будет под нагрузкой? Как безопасно выкатить? Что произойдёт со старой версией мобильного приложения? Как мигрировать данные? Что случится при падении зависимости? Как откатиться? Как это мониторить? Какие риски мы создаём через полгода?

Ответственность с инженера AI пока не снимает.

Сдулось ли IT

Здесь есть две крайности.

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

Вторая: «всё, профессия закончилась». Тоже неверно. Потребность бизнеса в софте никуда не исчезла — скорее наоборот. Если раньше автоматизация внутреннего процесса стоила условные десять миллионов и требовала команду из десяти человек, бизнес мог решить: «да ну его, будем делать руками». Если теперь то же самое делают один-два инженера и значительно быстрее, автоматизировать становится выгодно там, где раньше не было смысла.

Сдувается не software engineering. Сдувается премия за умение писать код по хорошо подготовленной задаче.

Кто будет нужен рынку: T-shaped инженер

Всё движется в сторону T-shaped инженеров. Но T-shaped — это не человек, который знает всё по верхам. У него есть область глубокой экспертизы (например, backend) и при этом достаточно широкое понимание соседних областей: frontend, mobile, инфраструктура, базы данных, observability, QA, security, продукт.

Он может не помнить, как сверстать компонент по макету, — это сделает AI. Но должен понимать, что такое force update мобильного приложения и когда он нужен. Может не разбираться в Kubernetes до мельчайших деталей, но должен понимать readiness и liveness probes. Может не быть DBA, но должен понимать индексы, транзакции, репликацию и миграции. Должен знать, зачем нужен graceful shutdown, что такое backward compatibility, как работает feature flag, что такое circuit breaker, какие бывают стратегии выката.

Синтаксис можно посмотреть. Код можно сгенерировать. А увидеть архитектурную проблему можно только тогда, когда вы знаете, что такая проблема вообще существует.

Почему я бы не строил карьеру вокруг фреймворка

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

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

Если вы backend — посмотрите, как живёт frontend. Как работают мобильные приложения. Как происходит deployment. Как QA строит тестирование. Как система ведёт себя в production. Как продукт принимает решения.

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

Главная проблема: откуда возьмутся senior-разработчики

Это единственное в трансформации, что меня действительно беспокоит.

Если AI съедает рутину — как мы будем выращивать senior-разработчиков?

Раньше junior становился senior именно через рутину. Сначала добавил поле. Потом написал CRUD. Потом сделал небольшую фичу. Потом сломал production. Потом починил production. Потом увидел плохую архитектуру. Потом сам её сделал. За несколько лет накопились тысячи маленьких ситуаций.

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

Мне кажется, это станет одной из главных проблем индустрии ближайших лет. И junior-разработчикам придётся значительно раньше учиться не просто писать код, а понимать систему: читать чужой код, проектировать, дебажить, работать с production, принимать решения и объяснять их.

Что делать прямо сейчас

Короткий список, который я бы взял в работу на ближайший квартал:

  1. Возьмите задачу целиком — от формулировки проблемы до метрик после выката, а не только свой кусок.
  2. Пишите спецификацию до кода — она же станет контекстом для агента и заодно поймает половину нестыковок.
  3. Фиксируйте решения в ADR — почему так, какие альтернативы отбросили, какие инварианты нельзя нарушать.
  4. Выйдите за границу своего стека — с агентом это теперь вопрос дней, а не месяцев.
  5. Проверяйте результат, а не процесс — тесты, мониторинг, план отката. Ответственность всё ещё на вас.

Итог

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

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

Я бы не соревновался с AI в том, кто быстрее напишет endpoint — это соревнование мы, скорее всего, проиграем. Я бы двигался в другую сторону: расширял область ответственности, учился понимать систему целиком и постепенно превращался из человека, которому можно сказать «напиши backend для этой задачи», в человека, которому можно сказать: «Вот проблема. Реши её».

Такой инженер будет нужен бизнесу ещё очень долго.

Частые вопросы

Заменит ли AI разработчиков? AI не заменяет разработчиков целиком, но обесценивает один конкретный навык — писать код по хорошо декомпозированной задаче. Ценность смещается на понимание проблемы, архитектурное решение, проверку результата и ответственность за прод. Инженер, который отвечает за эпик от требований до метрик, остаётся нужен бизнесу.

Стоит ли идти в IT в 2026 году? Потребность бизнеса в софте не упала, а выросла: чем дешевле разработка, тем больше процессов выгодно автоматизировать. Но входной порог поднялся — простые задачи закрывает AI, и рынок ждёт от новичка понимания системы, а не умения писать CRUD. Идти стоит, если готовы учиться инженерии, а не одному фреймворку.

Что делать junior-разработчику, если AI забирает простые задачи? Раньше junior становился senior через тысячи мелких рутинных задач — этот путь сокращается. Замена — осознанно набирать опыт, который AI не отдаёт: читать чужой код, проектировать решения, дебажить инциденты, работать с production и объяснять принятые решения. Использовать агента как усилитель, но разбирать каждое его решение, а не принимать вслепую.

Исчезнут ли QA, системные аналитики и DevOps? Нет. Размываются не профессии, а границы между ролями: простую и среднюю задачу закрывает один сильный инженер с агентами, без цепочки аналитик → backend → frontend → QA → DevOps. Глубокая экспертиза в инфраструктуре, безопасности, базах данных и сложных доменах остаётся востребованной там, где нужна настоящая глубина.

Какие навыки будут цениться выше умения писать код? Понимание проблемы пользователя, архитектура и её последствия, backward compatibility, стратегии выката и отката, наблюдаемость, миграции данных, поведение системы под нагрузкой и при отказе зависимостей. Плюс инженерные практики — спецификации, ADR, тесты, документация: с AI они превратились из бюрократии в контекст, которым вы управляете агентом.