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

Код больше не главный дефицит

Раньше ценность разработчика измерялась скоростью написания кода Сейчас написать кусок кода стало проще. AI может накидать функцию, тест, SQL-запрос, компонент или регулярку.Но код сам по себе не равен решению! Можно быстро сгенерировать много строк и так же быстро получить проблемы: лишнюю сложность, странную архитектуру и убедительные баги.

AI помогает, где человек понимает, что делает. И опасен там, где человек сам не понимает задачу, но надеется, что модель «как-нибудь разберётся».

Разработчика заменяет не AI, а привычка не включать голову

Если человек просто копирует описание задачи в чат, вставляет ответ в проект и отправляет на ревью — это уже не разработка. Это доставка случайного кода до репозитория.

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

Слабые места становятся заметнее

Сильный специалист использует AI как ускоритель: задаёт контекст, проверяет результат, ищет риски и не отдаёт модели право думать вместо себя. Слабый специалист использует AI как костыль.

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

Иногда в вайбкодинг толкает сам бизнес

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

Когда бизнес требует «быстрее, ещё быстрее, нам главное выкатить», когда нет времени на нормальную декомпозицию, ревью, тесты и обсуждение рисков, AI легко превращается из инструмента в способ выживания.

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

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

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

А где через пару лет брать мидлов?

Мидлы не появляются из воздуха. Они вырастают из джунов на реальных задачах: ошибаются, получают ревью, чинят баги, учатся видеть последствия решений.

Если джуну сразу дать AI и не научить думать, он может быстро выдавать код, но это не значит, что вместе с кодом выросло инженерное мышление.

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

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

Так кто прав?

Одни запрещают AI из-за рисков безопасности, качества и утечек. Другие, наоборот, сокращают людей на фоне «AI-оптимизации» и ждут, что скорость вырастет сама собой.

Кто прав? Зависит от того, понимают ли они последствия.

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

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

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