ИИ заменит прогамистов! Программисты больше не нужны! Слышали? Я часто, и мне захотелось разобраться в теме и понять для себя, как разработка будет жить в условиях всеобщего ИИ. Давайте разберемся, кто такой разработчик и чем он отличается от программиста, архитектора, агроинженера.
Сейчас любой встречный-поперечный может с помощью AI сделать генерацию сайта, бота или использовать нейросеть для генерации приложений. И вроде бы, действительно, программист больше не нужен, но ведь мы интуитивно понимаем, что не всё так просто.
Давайте проведем мысленный эксперимент.
Предположим, вам нужно заселиться в один из двух небоскребов на 99 этаж. Оба небоскреба имеют 100 этажей, основание, у них одинаковая площадь квартир и общедомового пространства, у каждого встроена противопожарная безопасность, но в обоих случаях она еще ни разу не запускалась. Но есть и различия: первое здание прошло полную приемку в органах гос-пожар-тех-потреб надзора, его проектировали и строили люди по всем современным нормам. Второе здание было построено ИИ без привлечения специалистов-людей. Для второго здания гос-пожар-тех-потреб надзор НЕ участвовал во вводе строения в эксплуатацию.
Какое здание вы бы предпочли на ближайшие 5–10 лет? Почему-то мне кажется, что первое.
Подобный эксперимент можно привести и с врачами. К кому на лечение пойдете, если съели не тот гриб? К человеку или к ИИ? Почему-то мне кажется, что за финальным лечением все пойдут к врачу-человеку. И это понятно. Мы еще не настолько сильно доверяем ИИ, и уж тем более в таких вопросах, как здоровье.
И причина тут не в том, что ИИ плох. И даже не в том, что слова врача-человека могут успокоить наши душевные травмы. Причина в том же, почему люди выбирают творчество других людей.
AI и музыка. Исследования музыкальной платформы Deezer
Исследование “Human Bias in the Face of AI: Examining Human Judgment Against Text Labeled as AI Generated” и статья “AI music has surpassed 50% of new music uploads for the first time” от Deezer (https://newsroom-deezer.com/2026/07/ai-music-exceeds-50-percent-daily-uploads-deezer/) явно указывают на это. Последняя приводит интересные цифры: более 50% (около 90 000) всех треков, которые ежедневно загружаются на платформу, созданы с помощью AI, а доля прослушиваний таких треков составляет всего 1–3%. Наталкивает на мысли - правда?
Давайте все же разберемся с главным вопросом. Кто такой архитектор, агроинженер и чем он отличается от разработчика? Все эти специализации объединяет наличие специализированных знаний и взятой на себя ответственности.
Роль навыков и специалзированых знаний
Архитектор зданий отвечает за то, чтобы проект соответствовал применимым нормам и требованиям. Архитектор мостов отвечает за то, чтобы в проекте были учтены нагрузки, условия эксплуатации и требования безопасности. Архитектор ПО отвечает за архитектурные решения, которые позволяют системе выдерживать нагрузки, масштабироваться и развиваться. Разработчик отвечает за то, чтобы созданное им ПО можно было сопровождать и использовать по назначению.
А программист пишет код. Он, конечно, может решать алгоритмические задачи, проходить собеседования и выполнять распоряжения… Но почему-то мне кажется, и я в этом практически уверен, что нейросети делают это лучше и быстрее. А значит, задача каждого программиста - стать разработчиком.
Агроинженер
Я не случайно привел эту профессию. Мы можем рассмотреть эволюцию этой сферы на коленке и уже видим новые синергии ИИ и сельского хозяйства.
До 19 века поля обрабатывали плугами с помощью людей и животных. Позже появились паровые двигатели и ДВС, а в начале 20 века - первые мотокультиваторы. К первой половине 20 века начали массово распространяться тракторы, а к концу 20 века тракторы и комбайны стали неотъемлемой частью крупного сельского хозяйства во всем мире.
Затем механизация начала переходить в автоматизацию технологических процессов и производств: появились электронные контроллеры, датчики, автоматическое управление отдельными операциями.
Позже в сельское хозяйство пришли спутниковые данные и дистанционное зондирование. Сейчас уже есть проекты, где компьютерное зрение и ИИ используются для определения и картирования сорняков, оценки их плотности и биомассы, обнаружения заболеваний растений.
И каждый этап сопровождался отказом от большого объема простых работ и ростом значимости более специализированных знаний.
В IT происходит примерно то же самое.
В рамках IT каждый разработчик - это в первую очередь инженер, а уже потом программист. Программирование постоянно избавлялось от низкоуровневой рутины. От машинных инструкций и ассемблера мы перешли к языкам высокого уровня, библиотекам, фреймворкам и IDE. Каждый такой этап убирал часть рутины и позволял разработчику оперировать более высоким уровнем абстракции и разрабатывать более сложные программы.
Генеративный ИИ делает следующий шаг - теперь рутину описания функций можно отдать самой машине, сосредоточившись на архитектуре и дизайне программы.
Именно поэтому внедрение ии в бизнес процессы и внедрение ии в процессы в целом становятся не столько вопросом генерации кода, сколько вопросом правильного проектирования этих процессов.
То же самое касается автоматизации процессов. Если раньше разработчик автоматизировал отдельную операцию с помощью кода, то теперь он может проектировать целую систему, в которой часть операций выполняется ИИ.
Немного слов про вайбкодинг
Большинство людей не станут самостоятельно строить многоэтажный дом без помощи специалистов. Я верю, что 1–2 этажа каждый из нас может построить сам, но строить 3–4 - без знаний уже опасно. Провести провод, чтобы передвинуть розетку, сможет каждый, но организовать всю проводку в доме, которая выдержит нагрузки - нужны знания. И мы с вами это прекрасно понимаем.
Что делать, когда у нас простуда, мы с вами знаем, но случись что посерьезнее - идем к специалисту. Нам хорошо известны подходы джунов и некоторых мидлов. Мы чувствовали на себе всю боль неверно выбранной архитектуры.
Эйфория пройдет, но останутся сотни тысяч убитых вайбкодингом проектов, которые будут требовать специализированных знаний.
Заключение
Именно поэтому внедрение автоматизации процессов с помощью AI не сводится к тому, чтобы просто подключить нейросеть. Нужно понимать, какие процессы стоит автоматизировать, где нужен человек, где достаточно модели, а где необходим полноценный инженерный контроль.
Я не враг вайбкодинга, это прекрасный инструмент, требующий правильного обращения и тех самых специализированных знаний в архитектуре, разработке и даже программировании.
А если речь идет о сложных системах, то внедрение ии агентов в бизнес процессы требует еще более высокого уровня понимания: агент должен не просто генерировать ответ, а работать внутри определённых бизнес-ограничений, использовать инструменты, обращаться к данным и корректно обрабатывать ошибки.
А иначе будет как с музыкой: 97% людей против 3% AI. AI уже способен производить гигантский объем контента. Но история Deezer показывает интересный парадокс: производить стало дешево. Стало дорого другое - сделать то, что действительно кому-то нужно.
Возможно, именно это и происходит сейчас с программированием.
Код становится дешёвым. Инженерия - нет.
Комментарии (29)
Sergey-1986
29.09.2026 11:07Мы уже в будущем
suver Автор
29.09.2026 11:07Мир действительно сильно быстро меняется, что очень сложно за ним успеть. Но это только начало трансформации
TieBeTie
29.09.2026 11:07если метрики у нейросеток выше, то можно заменять, вот и всё
suver Автор
29.09.2026 11:07Тут не все так однозначно. Метрики действительно важны. Только их собирать можно по разному. И собирать можно не те метрики. А от этого зависит и восприятие того на что смотреть.
Я в командах не смотрю на метрики до тех пор, пока все и каждый не начали работать по одним и тем же правилам. Иначе по метрикам всплывают бестолковые суперспециалисты. Которые по метрикам делают быстро, а по факту - плохо
silovka
29.09.2026 11:07Как мне кажется статья очень сильно не объяснила кто для автора является разработчик и чем он отличается от программиста, кодера, IT-шника и всех других и сколько процентов программистов это именно разработчики
suver Автор
29.09.2026 11:07Возможно. Но в статье речь скорее о специализированных знаниях, зоне ответственности и способности создавать и развивать программный продукт целиком.
Я рассматриваю программиста как более широкое понятие: человек, который пишет код. Разработчик - это специалист, который помимо написания кода понимает задачу, архитектуру, ограничения, принимает технические решения и отвечает за результат.
Я встречал часто разработчиков, которым нужны инструкции что и как делать. И это тонкий момент, потому что спрашивать о том как сделать - это хорошо, это процесс обучения. Но ждать указаний - плохо. Есть и другие - которые супер инициативно делают какую-то дичь. Если такого человека поставить руководителем - его будут называть самодуром. Это тоже плохо. Поэтому разработчик/инженер он понимает что делает, делает это хорошо и готов осознано нести ответственность за результат.
Условно: программист относится к разработчику примерно так же, как оператор набора текста - к автору того-же текста. Оба работают с текстом, но уровни работы - разные.
ShIV03
29.09.2026 11:07Вроде, теперь, до меня дошло:
- Кодировщик - это (одна из) функция Программиста;
- Разработчик - это (одна из) специализация профессии (Программиста, Архитектора зданий).
Тогда, идею Автора, можно представить как:
Некоторые специализации - (дольше) будут выполняться/цениться именно людьмиАвтору: Вы напоминаете меня, лет 30 (ладно, 10) назад - тоже считал "Разработчик - это круто. Кодировшик - тьфу, только слова расставить" (правда, до этого в юности - тоже самое про "ученый-инженер"). Но мне удалось встретиться с настоящими мастерами и ситуациями, когда конкретный исполнитель давал Решение, меняющее-выпрямляющее всё остальное (работу остальных).
К чему: в общем (на уровне "температуры по больнице") - может, Вы и правы (функция кодирования - в массе, перейдет к AI), но не в частностях ("Разработчик", но без функции кодирования, зато "в одном флаконе" - с аналитиком, проектировщиком, ведущим (предлагающим/отвечающим за технические решения), и чего Вы еще себе "понавешали (орденов)").-
И может (только теперь), проявилась Ваша истиная мысль:
Не сохранятся (за человеком) узкие специализации, функции
Имеется в виду работа (в конкретных фирмах), на которой требуется выполнение только одной функции (например, кодирования), внутри конкретной специализации (например, там где занимаются Разработкой)
AntonBak
29.09.2026 11:07Согласен с тем, что это очередной этап ускорения выпуска продукта. Вопрос в дальнейшем, не войдет ли в привычку пользоваться этим инструментом у нового поколения и в связи с этим, потерять первоначальные навыки. К хорошему и простому привыкаешь быстрее, а отвыкать гораздо сложнее.
suver Автор
29.09.2026 11:07Это, скорее, вопрос подхода к разработке, чем привычки. У нас уже есть методология TDD, - хорошая, но плохо применимая. Тут что-то очень похожее. TDD плох на практике, - но красив в теории. С ИИ он находит новые смысле. Я в следующей статье хочу написать как раз о подходах в разработке через ai-first и разобрать плюсы и минусы каждого.
Jajaba
29.09.2026 11:07Будущее поколение программистов не факт, что вообще будет, а если и будет, то крайне малочисленным, ибо большая часть работы будет автоматизирована
Art_Line
29.09.2026 11:07Я 20 лет пытался приспособить существующий софт для своих задач. Делал шаблоны, изобретал костыли. Сейчас за несколько вечеров и 20 баксов я навайбкодил себе прекрасный рабочий инструмент, который работает так, как нужно именно мне. При этом я абсолютно ничего не понимаю в коде, но прекрасно разбираюсь в специфике своей работы. В этом и есть беда разработчиков и программистов - они ничего не знают про мою работу, и будут вникать в неё месяцами. В то время как ИИ получил мои файлы, за 15 минут проанализировал их досконально, задал мне вопросы, о которых я даже не догадывался, и сам составил себе ТЗ.
NSK_SC
29.09.2026 11:07Как тот кто активно изучает бизнес и системный анализ, работая с разными моделями, могу точно сказать что все ИИ и платные и бесплатные часто упускают важные детали, которые легко заметны человеку, и додумывают то чего не существует из-за неспособности правильно понять естественный язык, и вариативность в зависимости от контекста.
suver Автор
29.09.2026 11:07Маленькие проекты можно легко генерировать. Но что-то объемное, сложное то что занимает только в генерации несколько месяцев - "по файлом" не сгенерировать. Уже нужны инженерные навыки и понимание области. Иначе получиться либо совсем плохо, либо вообще не получиться.
Sneg47
29.09.2026 11:07Слышал подобные рассуждения, год назад как высмеивали вайбкодеров. Теперь уже никто так не говорит, а писать код ии это стандарт. Более того, ии сейчас научился находить дыры и следить за безопасностью. Дальше больше.
Человекбудет нужно только в сложных и важных проектах, или как руководитель. Что сильно сократит число программистов.
Я лично не программист и создаю код через ии. Один проект уже делаю больше года и работа продолжается каждый день.
suver Автор
29.09.2026 11:07Поделитесь вашим подходом к созданию кода через ИИ.
Sneg47
29.09.2026 11:07Проект начинается с правил и требований и плана. Готовый код переодически проверяется разными моделями, которые находят друг у друга недочëты. А при выходе новых моделей код снова проверяется.
И естественно всë придумывается, постоянные правки и улучшения.
Поверхностно написал, в целом так.
suver Автор
29.09.2026 11:07Что-то похожее на SDD. Часто бывает что одно чиниться - другое ломается? Приходилось генерировать, таким образом, что-то больше чем CRUD, какую-то сложную бизнес логику?
Sneg47
29.09.2026 11:07Программы, приложения и онлайн сервисы. Было весьма сложное, уходило много месяцев.
Такое, чтобы одно ломало другое, редко, так как всë отделено и не затрагивает друг друга. Поломаться может в случае больших переделок. Но оно также же поломалась, если бы это люди делали руками. Так как серьëзнве изменения, а если там много всего, что-то да сломается. Но и исправляется это также быстро.
suver Автор
29.09.2026 11:07Как я понимаю маленькие микросервисы или отдельное и не связанное между собой маленькое ПО. Такое, как правило, дейсвительно хорошо генерируеться
Sneg47
29.09.2026 11:07Не только, есть и кросплатформ, с кучей разных сложных функций. Вот тут ии встали и было сложно. Тем не менее справились. Это было в середине лета. Сейчас модели ии сильно прокачались и такое уже сделают быстрее.
ShIV03
К сожалению, однобоко устаревший подход - взгляд от проектирования, длительного цикла от идеи-разработки-результата. А жизнь (и суть ИИ-революции) в ускорении. В пределе - Получать результаты сразу, как захотелось.
Отсюда, "К какому пойдете врачу?" - ответ из реальности "К никакому (не дождешься, затаскают, будут долго лечить от плоскостопия)".
ИИ - "просто еще один" удобный советчик (наравне с Гуглом и тусовками).
Хотя, так и хочется написать "антисоветчик".
Надеюсь, что хайп - наша временная "Детская болезнь левизны".
Нет (в реесте профстандартов) такой профессии "Разработчик" - это слово прилагается (к "программист", например в "Помощник программиста"). Т.е. это только одна из выполняемых функций. Да, ключевая, в фирмах-разработчиках.
Из моего опыта работы в фирмах-проектировщиках, из перечисленного Автором - мне ближе "Проектировщик" (кодировщик - тоже разрабатывает, но в своей сфере).
Не стал бы ставить "Осталась карта" на "Функция разработки".
Как и пытаться выдавать какую-либо функцию (Разработка, Проектирование), за уникальные особенности своей профессии (где-то, да, но не у всех).
Соглашусь в такой интерпретации, что:
В конкретном деле (например, архитектуре зданий, их строительстве и сдаче под ключ) - всегда останется важна Специфика (риски, в случае зданий).
Рано делать выводы (нам, руководству) "заменит/не заменит", сравнивая с "полуторагодовалым малышом" (может он в конце и обгонит нас в чём-то. Если будем "стоять и ждать (мы в домике)").
suver Автор
Результат в моменте отличается от долгосрочной стратегии.
Опираться стоит на реальность, а не стандарты из реестра. Для меня это как начальник и руководитель. Первый самодур с должностью, второй уважаемый за проф.пригодность.
Хоть в чемто вы согласны
ShIV03
Совет (но не настаивая, подумайте на досуге): воздерживаться от "приклеивания (сходу) ярлыков", с уникально-персональным (вкладываемым смыслом, из личного опыта и пристрастий) обозначением: "Начальник - плохо, руководитель - хорошо". Это разные функции (что следует из их имени - типа: техлид, тимлид), без следствий "начальник - самодур, с должностью".
"Местечковый ярлык" - затрудняет понимание другими вашей логики (например, в сравнении с профстандартом - хоть каким-то единым якорем).
suver Автор
Благодарю за совет