Как ИИ будет вытеснять программистов

Как искусственный интеллект будет вытеснять программистов: сценарий автоматизации разработки после 2030 года

Программирование — лишь небольшая часть производства программного обеспечения. Разработчик получает задачу, пытается понять требования, изучает существующий проект, проектирует изменение, пишет код, запускает тесты, исправляет ошибки, проводит рефакторинг, создаёт миграции базы данных, проходит code review, собирает приложение, выкладывает его на сервер, наблюдает за работой системы и однажды ночью пытается понять, почему после очередного релиза выросло количество HTTP 500.

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

И этот процесс уже начинается.

По данным DORA, опубликованным Google, к 2025 году ИИ использовали около 90% опрошенных технологических специалистов, а более 80% считали, что он повысил их производительность. При этом исследование обнаружило принципиально важный эффект: более активное использование ИИ связано одновременно с увеличением скорости поставки программного обеспечения и с ростом нестабильности поставки. Иными словами, машина уже помогает производить больше изменений, но увеличение количества изменений само по себе не делает систему надёжнее.

Отсюда и будет разворачиваться автоматизация.

Первая стадия: исчезает ручное написание кода

1️⃣ Период: примерно 2026–2030 годы.

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

CRUD-контроллер, DTO, SQL-запрос, конфигурация Docker, тест, миграция базы данных, сериализатор или REST endpoint достаточно хорошо формализуются. Для них существуют исходные данные, контекст проекта и понятный критерий результата.

ИИ получает задачу:

Добавь в Symfony сущность WebhookSubscription, миграцию PostgreSQL, CRUD для EasyAdmin, сервис отправки webhook и функциональные тесты.

Он изучает repository, создаёт файлы, запускает тесты, видит ошибку, исправляет её и предоставляет готовый diff.

Человеку всё меньше потребуется писать:

public function getTitle(): string { return $this->title; }

С экономической точки зрения именно здесь автоматизация наиболее очевидна.

Уже исследования Anthropic показывали высокий уровень автоматизации при работе с coding-агентами: в анализе Claude Code 2025 года около 79% изученных взаимодействий относились скорее к автоматизации, чем к простому усилению человека. В исследовании 2026 года на примерно 400 тысячах сессий обнаружилась ещё более интересная закономерность: человек чаще принимает решения о том, что необходимо сделать, тогда как агент принимает значительную часть решений о том, как это сделать.

Это, вероятно, и есть первая устойчивая модель будущего.

Разработчик превращается из автора кода в человека, формулирующего намерение. Вместо: написать класс; появляется: изменить поведение системы вот таким образом.

В результате между 2027 и 2030 годами сильнее всего может сократиться потребность в junior-разработчиках, верстальщиках, специалистах по типовым интеграциям, manual QA и программистах, занятых преимущественно стандартными бизнес-приложениями. Но программисты ещё не исчезнут.

Более того, Всемирный экономический форум относит Software and Applications Developers к профессиям, которые должны оставаться среди наиболее быстрорастущих до 2030 года. Это хорошо показывает разницу между автоматизацией отдельных операций и исчезновением самой профессии.

Вторая стадия: исчезает отдельное тестирование

2️⃣ Период: 2028–2032 годы.

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

Агент получает техническое задание, пишет реализацию и одновременно создаёт unit-, integration- и functional-тесты. Второй независимый агент получает только требования и пытается разрушить результат первого. Третий ищет Security-проблемы. Четвёртый генерирует неожиданные сценарии использования. Пятый анализирует изменение производительности.

Возникает своеобразная машинная система сдержек и противовесов.

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

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

Третья стадия: ИИ получает право создавать pull request самостоятельно

3️⃣ Период: 2029–2033 годы.

До этого момента ИИ фактически остаётся очень быстрым подрядчиков. Он предлагает изменение, но человек принимает его. Следующий перелом происходит тогда, когда агенту предоставляют постоянный доступ к репозиторию, issue tracker, документации и CI.

Например, мониторинг обнаруживает ошибку: Undefined array key owner. Агент самостоятельно связывает exception с последним изменением, открывает соответствующий код, воспроизводит ошибку, пишет regression test, исправляет программу, запускает весь pipeline и создаёт merge request.

Разработчик утром уже не получает сообщение: Production error. Он получает: Production error обнаружен в 03:14. Причина найдена. Исправление прошло 1842 теста. Создан MR !391. Вероятность регрессии оценивается как низкая.

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

Четвёртая стадия: исчезает человеческий code review

4️⃣ Период: 2030–2034 годы.

Сегодня code review выполняет сразу несколько функций: поиск ошибок, контроль архитектуры, обеспечение единого стиля, распространение знаний и управление риском. Все функции, кроме последней, чрезвычайно хорошо автоматизируются.

Агент способен сравнить изменение не только с несколькими файлами, которые успел посмотреть коллега, а со всей историей проекта.

Он может проверить: архитектурные зависимости, security-рекомендации, производительность, backward compatibility, database migrations, coding style, тестовое покрытие, API contracts и исторические причины предыдущих изменений.

Постепенно человек перестанет проверять каждую строку. Граница человеческого контроля переместится вверх. Сначала человек утверждает каждую строку. Потом — pull request. Потом — feature. Потом — release. А затем человек будет утверждать только политику, в рамках которой ИИ имеет право менять продукт самостоятельно. Это один из самых важных переходов.

Пятая стадия: ИИ получает доступ к CI/CD

5️⃣ Период: 2030–2035 годы.

Написать код недостаточно. Его необходимо доставить пользователю. Но современный CI/CD уже почти полностью является машинным конвейером. После commit выполняются tests, static analysis, build, создание контейнера, deployment в staging, smoke tests и production deployment.

Человек часто нужен только для команды: Deploy. Следовательно, устранить его технически относительно просто. ИИ получает ограниченное право запуска deployment при выполнении установленных условий.

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

Сначала это будут небольшие изменения. Потом обычные feature. В итоге стандартное обновление продукта может пройти путь от issue до production вообще без человека.

Шестая стадия: автономный rollback

6️⃣ Период: 2031–2035 годы.

Для бизнеса даже важнее умения выполнить deployment будет способность понять, когда deployment оказался плохим. И здесь автоматизация потенциально очень сильна. До релиза: error rate = 0,07 % После: error rate = 1,4 %

Одновременно растёт latency определённого endpoint. Агент сопоставляет изменение с новым релизом и автоматически выполняет rollback. После этого исследует причину, создаёт исправление, повторно тестирует и пробует rollout снова. Когда такой цикл станет достаточно надёжным, исчезнет значительная часть сегодняшней DevOps-рутины.

Седьмая стадия: ИИ начинает обслуживать production

7️⃣ Период: 2032–2037 годы.

Здесь происходит уже более глубокое изменение профессии. ИИ постоянно наблюдает за logs, traces, metrics, queues, database locks, CPU, RAM, network traffic, slow queries и поведением пользователей.

Появляется агентный SRE.

Допустим PostgreSQL начинает периодически упираться в тяжёлый запрос. Агент находит query, выполняет EXPLAIN ANALYZE, обнаруживает последовательное сканирование большой таблицы, проверяет реальные паттерны использования, предлагает индекс, разворачивает его сначала на replica или staging, оценивает изменение нагрузки и затем применяет в production.

Значительная часть задач, которыми сегодня занимаются разработчик, DBA и DevOps, превращается в единую машинную функцию. Человек получает только отчёт.

Восьмая стадия: исчезает само понятие bug backlog

8️⃣ Период: 2033–2038 годы.

Сегодня существует естественная задержка: пользователь обнаружил ошибку → сообщил → support зарегистрировал → product manager приоритизировал → разработчик получил задачу → исправил → QA проверил → DevOps выложил.

Между ошибкой и исправлением могут пройти дни или месяцы. В полностью агентной системе этот цикл может занимать минуты. Ошибка появляется в production. Telemetry замечает аномалий. Агент воспроизводит проблему. Другой агент определяет причину. Третий создаёт исправление. Четвёртый проверяет его.

CI/CD разворачивает исправление на небольшую долю пользователей. Monitoring подтверждает результат. Rollout продолжается.

Человек вообще не участвует. Здесь программное обеспечение начинает напоминать самовосстанавливающуюся систему.

Девятая стадия: ИИ получает архитектурные задачи

9️⃣ Период: ориентировочно 2034–2039 годы.

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

Пользователей стало 15 миллионов. PostgreSQL начинает создавать проблемы. Найди архитектурное решение, которое позволит увеличить нагрузку втрое при росте инфраструктурных расходов не более чем на 40%.

ИИ может проанализировать telemetry, repository, структуру БД, распределение запросов и стоимость инфраструктуры. После этого он способен предложить partitioning, caching, asynchronous processing, read replicas или изменение архитектуры отдельных компонентов. А затем провести миграцию поэтапно. Именно на этой стадии положение senior-разработчика начинает принципиально меняться.

Десятая стадия: один специалист управляет цифровой командой

🔟 Наиболее вероятное устройство IT-компаний середины 2030-х — не компания вообще без программистов.

Гораздо вероятнее схема: один сильный технический специалист + множество специализированных агентов. Такой специалист уже мало пишет код. Он определяет ограничения.

Он говорит: Этот сервис должен обрабатывать миллион запросов в час. Потеря данных недопустима. Бюджет инфраструктуры — столько-то. PostgreSQL сохраняем. Переход должен происходить без downtime. Дальше работу выполняет машинная команда.

Фактически senior-разработчик превращается в технического управляющего автономными системами.

Исследования 2026 года пока скорее подтверждают именно такой промежуточный вариант. Anthropic обнаружила, что более высокая предметная экспертиза пользователя всё ещё повышает успешность агентной разработки и позволяет агенту выполнять больше работы на одну инструкцию человека. То есть сегодня хороший специалист не становится менее полезным из-за ИИ — наоборот, он способен сильнее использовать его возможности.

Что произойдёт со штатом

Рассмотрим условную SaaS-компанию, где сегодня над продуктом работают двенадцать технических специалистов: восемь разработчиков, два QA, DevOps и технический лидер.

К 2030 году аналогичный объём продукта потенциально смогут обслуживать шесть-восемь специалистов. К 2033 году — три-пять. К 2036 году стандартный SaaS-продукт теоретически сможет обслуживать один-два технических специалиста, управляющих агента ми. А где-то ближе к концу 2030-х для достаточно простых продуктов становится технически возможной модель, в которой штатных программистов нет вообще.

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

Это принципиальная разница.

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

Именно поэтому одновременно могут происходить два на первый взгляд противоположных процесса: спрос на software developers остаётся высоким, а количество разработчиков, необходимое для создания одного конкретного продукта, стремительно падает.

Главной жертвой может стать junior-разработчик

Пожалуй, наиболее сложная проблема переходного периода связана именно с начинающими специалистами. Работа junior-программиста во многом состоит из задач, которые проще всего делегировать ИИ: небольших исправлений, стандартных компонентов, тестов, простых API, документации, небольших SQL-запросов.

Первые статистические признаки такого давления уже появляются. Исследование Stanford Digital Economy Lab, обновлённое в августе 2026 года на основе данных ADP, не обнаружило массового вытеснения работников ИИ в экономике США. Но среди работников 22–25 лет в профессиях, наиболее подверженных воздействию ИИ, занятость оказалась примерно на 19% ниже уровня, который наблюдался бы при сохранении динамики менее затронутых профессий. Авторы подчёркивают, что это ещё не свидетельство всеобщей автоматизации, но возрастной разрыв уже заметен.

Для IT возникает неприятный парадокс. Чтобы получить senior-разработчика, отрасли нужны Junior. Но если junior-задачи выполняет ИИ, исчезает традиционная лестница подготовки senior-разработчиков. Поэтому компаниям придётся либо сознательно выращивать специалистов, либо создавать совершенно новую модель технического образования.

Почему движение может происходить быстрее, чем кажется

Исследовательская организация METR пытается измерять так называемый task-completion time horizon — продолжительность задачи для человека-эксперта, при которой агент способен выполнить её с заданной вероятностью.

Это пока далеко не измерение «способности заменить программиста». Сами исследователи специально предупреждают, что их задания лучше формализованы, чем настоящая работа, а реальная работа требует контекста, общения и неоднозначных решений. Тем не менее исторические измерения METR показывают быстрый рост продолжительности программных задач, с которыми способны самостоятельно справляться frontier-модели. При этом METR уже предупреждает, что значения выше 16 часов плохо измеряются существующим набором тестов.

Ключевой момент здесь не конкретное число часов. Важно направление. ИИ постепенно переходит от задачи уровня: исправь эту функцию к задаче: разберись, почему сервис работает неправильно.

Следующий переход: поддерживай этот сервис в рабочем состоянии. А затем: обеспечивай выполнение бизнес-требований этой системы. Именно *последняя формулировка₽ способна уничтожить привычное понятие программиста.

Когда появится настоящий «нулевой штат разработчиков»

Для этого недостаточно создать очень умную модель.

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

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

Первые продукты без постоянной команды разработчиков наиболее вероятны в областях с низкой ценой ошибки. Это корпоративные внутренние сервисы, небольшие сайты, каталоги, контентные проекты, стандартный e-commerce, аналитические панели, CRM для небольшого бизнеса, интеграционные сервисы, ETL, простые мобильные приложения, информационные системы и множество типовых CRUD-приложений.

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

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

Где программисты останутся значительно дольше

Совершенно другая ситуация возникает там, где ошибка стоит дорого.

• Банковские core-системы.
• Управление электростанциями.
• Авиация.
• Медицинские системы.
• Военная инфраструктура.
• Критические государственные информационные системы.
• Промышленная автоматизация.
• Системы управления транспортом.

Здесь проблема будет уже не столько в способности ИИ написать программу. Главным вопросом станет: кто отвечает, если решение оказалось неправильным? Технически ИИ может оказаться способен выполнить 99,99% работы. Но организация всё равно может сохранять людей, которые утверждают архитектуру, security policy и критические Releases. Поэтому последний процент человеческого труда способен оказаться намного устойчивее первых девяноста девяти.

Особенно долго сохранится cybersecurity

Security имеет дополнительную особенность. Большинство программных задач происходит в относительно стабильной среде. Кибербезопасность — игра против разумного противника. Как только защитный ИИ становится сильнее, атакующий ИИ тоже становится сильнее. Следовательно, security превращается в непрерывную гонку автономных систем.

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

Изменится само определение разработчика

Вероятно, главный эффект ИИ заключается не в исчезновении программиста как человека, связанного с технологиями. Исчезнет программист как оператор языков программирования. Сегодня программист разговаривает с компьютером на PHP, Java, Kotlin, Python или C++.

В будущем языком программирования становится описание желаемого состояния системы. Не:

CREATE INDEX...

а:

Снизь p95 времени ответа поиска до 150 миллисекунд, не увеличив инфраструктурные расходы более чем на 10% и не ухудшив скорость записи.

ИИ сам решает, надо ли изменить SQL, добавить индекс, переписать cache layer, изменить алгоритм или перераспределить нагрузку. Программирование поднимается ещё на один уровень абстракции.

Когда-то программисты вручную управляли регистрами процессора. Потом появились assembler и языки высокого уровня. Затем framework. Затем cloud. Следующей абстракцией становится намерение.

Самый вероятный сценарий 2030-х

Поэтому сценарий развития выглядит примерно следующим образом.

Сначала ИИ забирает написание типового кода. Затем тестирование. Потом исправление типовых ошибок. После этого самостоятельное создание pull request. Затем review. Потом deployment. Далее monitoring, rollback и обслуживание production. После этого — рефакторинг, migrations и значительная часть архитектурных решений.

На каждом этапе граница человеческого контроля отступает всё дальше. Сначала человек контролирует строку. Потом commit. Потом pull request. Потом release. Потом архитектурное решение. А в конечной точке он контролирует только цель и допустимый уровень риска.

Парадокс полного замещения

И здесь возникает неожиданный вывод.

Последним человеком в IT-команде может оказаться вовсе не программист. Последним останется человек, который способен ответить на вопрос: что вообще должна делать система?

ИИ может прекрасно реализовать неправильное требование.

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

Именно поэтому роли product owner, системного архитектора, domain expert и технического руководителя могут частично слиться.

Итог

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

К началу 2030-х ИИ способен существенно сократить потребность в ручном кодировании и тестировании. К середине 2030-х автономные агенты могут взять на себя значительную часть полного software development lifecycle — от issue до deployment и monitoring. Во второй половине 2030-х небольшие и средние некритичные продукты теоретически смогут существовать вообще без постоянного штата разработчиков.

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

Таким образом, полное исчезновение разработчика и радикальное сокращение разработчиков — две совершенно разные гипотезы.

Первая пока остаётся крайне НЕ ОПРЕДЕЛЁННОЙ. Вторая выглядит значительно более вероятной.

Самый реалистичный сценарий заключается не в том, что компания из десяти программистов заменит каждого из них отдельным искусственным ИНТЕЛЛЕКТОМ. Она сначала оставит семь ЧЕЛОВЕК. Потом ЧЕТЫРЕ. Потом ДВУХ. После этого один сильный специалист будет руководить десятками программных агентов.

И лишь на последнем этапе некоторые компании зададутся вопросом:

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

Именно этот момент, а не способность ИИ написать очередной класс или SQL-запрос, станет настоящей границей между эпохой программирования человеком и эпохой автономного производства программного обеспечения.