Ключевые выводы

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

«Написать код» и «создать работающую систему» — разные работы. Модель генерирует конечную точку API, класс, компонент, SQL-запрос. Инженер решает, зачем это нужно, где решение сломается под нагрузкой, что произойдёт при сбое и как это сопровождать через несколько лет.

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

Инженерия промптов — полезный навык, не профессия. Хороший результат зависит от декомпозиции, предметной области, проверки и тестов. Умение формулировать задание модели без инженерной компетенции даёт красивый черновик, а не устойчивый продукт.

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

Что изменилось в работе программиста в 2023–2026

До массовых ассистентов рабочий день часто выглядел так: открыть задачу, написать функцию, прогнать тесты, поправить крайние случаи, дописать документацию, открыть запрос на слияние. Скорость упиралась в набор, поиск по документации и удержание контекста в голове. «Уметь программировать» почти совпадало с «уметь писать код руками».

Потом за короткое время в повседневность вошли автодополнение уровня GitHub Copilot, чат с ChatGPT и Claude, агентные режимы в Cursor и соседних средах. Модель не только предлагает следующую строку: она правит несколько файлов, поднимает черновик сервиса, пишет тесты по образцу, объясняет чужой модуль. 2023–2026 годы стали переломными не потому что «нейросети появились», а потому что генерация кода вошла в ежедневный конвейер миллионов разработчиков, а не осталась демонстрацией на конференции.

Отсюда и главный вопрос этой статьи. Если ИИ умеет писать код, зачем нужен программист? Короткий ответ: потому что программный продукт — не сумма функций. Длинный ответ — ниже. Смежную рамку «где заканчивается генерация и начинается инженерия» я разбирал отдельно: граница кода и инженерии. Здесь — про профессию: кто останется востребован, как ломается карьерная лестница и чему учиться, если строки больше не дефицит.

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

Какую долю работы уже берёт ИИ

Неверный вопрос — «может ли ИИ написать код?». Может. Рабочий вопрос другой: какую долю работ по созданию программного продукта теперь реально поручить модели, если рядом есть человек, который умеет проверять.

На типовых задачах доля уже высокая. Генерация функций и классов по описанию. Скелет CRUD-сервиса: модели, маршруты, формы, базовые проверки. Клиент к внешнему API по документации. SQL-запросы и черновики миграций. Юнит-тесты по уже написанному коду. Механический рефакторинг имён и вынос повторов. Документация модуля. Поиск очевидных ошибок по трассировке. Черновик интерфейса. Dockerfile, шаблон конвейера CI, объяснение незнакомого фрагмента, подготовка сообщения коммита, прототип целого приложения за вечер.

Это не фантазия «через десять лет». Это то, что в 2026 году регулярно происходит в обычной среде разработки — если задача локальная, шаблон узнаваем, а цена ошибки не равна остановке бизнеса. Как устроен конвейер IDE под капотом — в разборе, как IDE работает с кодом.

Чего в этом списке нет: решения, какой сервис вообще должен существовать; выбор границ модулей на годы вперёд; понимание, почему в легаси «странное» правило нельзя трогать до закрытия месяца; оценка, безопасен ли сгенерированный патч; ответственность, когда оптимизированный SQL формально быстрее, но нарушает бизнес-ограничение.

Четыре коротких сюжета, которые я вижу снова и снова.

Первый: модель за часы собирает CRUD-приложение, которое открывается в браузере. Демо выглядит как продукт. Через месяц выясняется, что нет стратегии миграций, секреты в репозитории, а «временный» флаг уже управляет расчётом.

Второй: агент исправляет ошибку и выбирает неверную архитектуру — дублирует сущность, прячет правило в клиент, обходит ограничение базы «пока работает». Тесты зелёные. Через полгода стоимость правки вырастает на порядок. Именно поэтому ревью после патча агента — не формальность, а новый узкий участок конвейера.

Третий: модель переписывает SQL, снижает время запроса и не знает, что отчёт должен считать «закрытый месяц» иначе, чем оперативный экран. Оптимизация корректна технически и опасна предметно.

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

Когда код становится дешёвым

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

Сейчас первый вариант задачи, которая занимала несколько дней, часто появляется за десятки минут. Человек проверяет, выправляет, встраивает в систему. Цикл «набрал → увидел → поправил» сжимается. Код как сырьё дешевеет примерно так же, как когда-то подешевел набор текста после текстового процессора: писать легче, думать не легче.

Если производство строк дешевеет, сами строки перестают быть главным дефицитом. Дефицитными становятся постановка задачи, архитектура, контекст (зачем система устроена именно так), качество, ответственность, понимание бизнеса и способность принимать решения, когда ни один вариант не идеален.

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

Почему хороший инженер пока незаменим

Разница между «написать код» и «создать работающую систему» не в пафосе слова «инженерия». Она в горизонте последствий.

Модель может сгенерировать конечную точку API, класс, компонент, SQL-запрос. Это исполнение известного шаблона. Система появляется, когда кто-то ответил на другие вопросы. Зачем это нужно в продукте, а не в демо. Насколько решение корректно не в юнит-тесте, а в жизненном цикле документа. Какие у него ограничения: нагрузка, регуляторика, команда из четырёх человек, легаси на пятнадцать лет. Как поведёт себя под пиком. Что произойдёт при сбое соседнего сервиса. Насколько безопасно: секреты, права, инъекции, утечка данных через подсказку модели. Как это поддерживать через три года, когда авторы агентного патча уже не в команде.

ИИ не «глупый» на этих вопросах — он не несёт ответственности и не сидел на совещании, где решили не трогать таблицу до закрытия периода. Даже сильная модель достраивает пробелы из общих шаблонов открытых репозиториев. В корпоративном контуре шаблон часто врёт: «правильное» решение в стиле REST ломает договор с банком или отчёт для регулятора. Разбор унаследованной системы это показывает жёстко: ИИ и проект с 15-летней историей.

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

Новая иерархия: от кодера до инженера продукта

Старые ярлыки junior / middle / senior не исчезают с рынка труда, но хуже описывают, за что платят. Удобнее смотреть на четыре уровня ценности — не как на HR-грейды, а как на то, что остаётся дефицитным, когда код дешевеет.

Кодер. Ценность — набор строк по готовому описанию. Именно этот слой модель закрывает лучше всего: типовой CRUD, вёрстка по макету, очевидные тесты, шаблонный серверный код. Если вся экспертиза — «я быстро пишу на фреймворке X», рынок будет предлагать меньше ролей и ниже ставку.

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

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

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

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

Парадокс ИИ: сильные усиливаются, junior — в зоне риска

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

Отсюда формула, которая важнее любых бенчмарков «+55% к производительности»:

Хороший инженер + ИИ ≫ хороший инженер без ИИ.

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

Самая острая сторона парадокса — junior.

Старая лестница была простой: junior → middle → senior. Новичок получал простые задачи — CRUD, правки по макету, тесты по образцу — и на них учился читать чужой код, ошибаться дёшево, наращивать вкус к качеству. Именно этот слой задач автоматизируется первым.

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

Последствия уже видны, даже если статистика рынка шумная. Войти в профессию сложнее: работодатель меньше готов платить за «человека, который пишет то, что модель пишет быстрее». От новичка требуют больше самостоятельности раньше — понимать систему, а не только синтаксис. Обучение смещается от набора кода к чтению, отладке, ограничениям, предметной области. ИИ оказывается одновременно конкурентом на стартовых вакансиях и лучшим персональным наставником, который когда-либо был у новичка: можно разобрать любой фрагмент, получить упражнение, услышать объяснение. Кто использует его как тренажёр, растёт быстрее. Кто использует как замену мышлению, не растёт вовсе.

Это не повод говорить «junior больше не нужен». Системам по-прежнему нужны люди, которые через пять лет станут инженерами третьего и четвёртого уровня. Но путь к этому уровню больше не выглядит как «два года закрывать простые тикеты». Практический ориентир для самого новичка — путь junior → senior: фундамент и чтение кода важнее гонки за очередным фреймворком.

Чему учиться в 2026 году

Список «React, Python, Java, Go, SQL» не стал бесполезным. Он стал недостаточным. Язык и фреймворк по-прежнему нужны, чтобы читать дифф и понимать среду выполнения. Но конкурентное преимущество уезжает в фундамент: алгоритмы и структуры данных, базы, сети, операционные системы, параллелизм, распределённые системы, архитектура, безопасность, тестирование, отладка, профилирование, Git, поведение программы во время выполнения.

Почему фундамент важнее, чем кажется адепту «главное — промпты»? Потому что модель генерирует правдоподобный код. Чтобы понять, почему он плохой, нужно видеть систему: лишние запросы в цикле, гонку, утечку соединения, неверный уровень изоляции транзакции, дыру в правах, тест, который проверяет реализацию, а не намерение.

Шесть практических правил, которые я считаю рабочими в 2026.

Учить фундамент, а не становиться оператором чата. Без понимания среды выполнения вы не отличите ускорение от тихой порчи архитектуры.

Использовать ИИ с первого дня. Соревноваться с моделью в скорости шаблонного кода — проигрышная стратегия. Соревноваться в постановке и проверке — нет.

Учиться читать код. В ближайшие годы умение оценивать чужой (и сгенерированный) код часто ценнее умения быстро его набирать. Ревью — основной рабочий жест, не факультатив.

Учиться проектировать. Границы сервисов, контракты API, модель данных, отказ соседнего узла, обратимость решения. Спека до кода, а не «сначала сгенерируем, потом посмотрим»: разработка от спецификации.

Развивать предметную область. Финансы, производство, медицина, логистика, встраиваемые системы. Домен — то, чего нет в общем шаблоне модели и что дороже всего в инциденте.

Учиться работать с агентами как с конвейером, а не как с магическим окном чата: цель, ограничения, проверка, откат. Это уже не «навык промпта», а навык процесса.

Промпты — навык, а не профессия

Популярная идея 2023–2024 годов: «теперь главный навык программиста — писать промпты». В ней есть доля правды и опасное преувеличение.

Доля правды: от формулировки задания зависит, получите вы полезный черновик или три страницы уверенной галлюцинации. Умение сузить задачу, дать примеры, указать ограничения, приложить фрагмент кода — это грамотность, как умение писать понятный тикет.

Преувеличение: хороший результат почти никогда не следует из одной удачной инструкции. Он следует из контекста (репозиторий, правила, схема данных), архитектурного мышления (что вообще можно генерировать в этом месте), декомпозиции (агенту нужна граница, а не «сделай как надо»), проверки, тестов и понимания предметной области. Без этого «инженер промптов» производит красивый текст, который не переживает первый инцидент.

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

От написания кода к управлению агентами

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

flowchart LR
  H[Инженер] --> A[Архитектура]
  H --> B[Серверная часть]
  H --> C[Клиентская часть]
  H --> D[Проверка качества]
  H --> E[Инфраструктура]

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

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

Три сценария рынка: кто под риском

Станет ли программистов меньше? Одновременно правдоподобны три процесса.

Оптимистичный. ИИ снижает стоимость разработки → появляется больше программного обеспечения → спрос на инженеров остаётся высоким, хотя характер работы меняется.

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

Новый рынок. Дешёвый софт делает выгодными продукты, которые раньше не окупали команду. Внутренние инструменты, узкие отраслевые системы, персональные агенты под процесс — слой, который не существовал при дорогом коде.

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

Под наибольшим риском специалисты, чья ежедневная ценность состоит из типового CRUD, простых интеграций, вёрстки по готовому макету, шаблонного серверного кода, механического рефакторинга, очевидных тестов и чётко описанных тикетов без неопределённости. Главный критерий риска: насколько работу можно разложить на алгоритм и насколько легко проверить результат автоматически. Чем ближе задача к «есть спецификация и зелёные тесты = готово», тем сильнее давление автоматизации.

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

Исторические аналогии здесь уместны именно как аналогии, не как гарантия. Калькулятор не уничтожил математиков — сдвинул работу с арифметики на постановку. Системы автоматизированного проектирования не уничтожили инженеров-конструкторов. Графические редакторы не уничтожили дизайнеров. Компиляторы не уничтожили программистов, хотя «писать в машинных кодах» перестало быть массовой ценностью. Поиск в интернете не уничтожил исследование — уничтожил ценность «я помню, на какой странице мануала это написано». Автопилот не убрал пилотов из кабины, где цена ошибки максимальна. Автоматизация операций меняет уровень, на котором работает специалист. Она не обязана уничтожать профессию — но уничтожает слой, который состоял только из этих операций.

Прогноз на 5–10 лет

С высокой вероятностью ИИ станет таким же стандартным инструментом разработки, каким когда-то стал Git или непрерывная интеграция. Ручного набора типового кода станет меньше. Небольшие команды будут делать заметно больше. Доля сгенерированного кода в репозиториях вырастет — вместе с требованиями к архитектуре, ревью и наблюдаемости, иначе поток патчей утопит продукт. Вход на начальный уровень усложнится. Инженеры высокого уровня станут продуктивнее. Граница между разработчиком, архитектором и техническим лидером размоется: эти роли и так пересекались, агенты только усиливают пересечение.

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

Главный парадокс будущего формулируется коротко:

Чем лучше ИИ умеет программировать, тем меньше ценность самого умения писать код — и тем больше ценность понимания того, что именно нужно построить и почему.

Как эта лаборатория смотрит на системы — в коротком представлении «Химия кода». Здесь достаточно одной мысли метода: ускоритель (агент) не отменяет стоимость ошибки; он делает дешёвой сборку и дорогой неверный инвариант.

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

Что почитать дальше

• Где заканчивается генерация кода и начинается инженерия — граница продукта и строк
• Насколько далеко продвинулся ИИ — зрелость генерации не равна зрелости профессии
• Ревью кода в эпоху ИИ — что проверить после патча агента
• Как IDE работают с кодом — конвейер ассистента в редакторе
• Агентная инженерия — процесс вокруг агентов, не «вайб»
• ИИ и проект с 15-летней историей — где модель помогает понимать систему
• Разработка от спецификации — намерение до кода

Заключение

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

Будущий сильный разработчик держит понимание — продукта и системы — и только затем запускает агентов на исполнение.

                 ПОНИМАНИЕ
                     │
          ┌──────────┴──────────┐
          │                     │
       ПРОДУКТ              СИСТЕМА
          │                     │
          └──────────┬──────────┘
                     │
                ИНЖЕНЕР
                     │
                  ИИ × ИИ × ИИ

Переход от «писать код» к «строить системы» может оказаться самым большим изменением профессии за всю историю разработки ПО. Код стал дешёвым. Дефицит уехал вверх: что строить, почему, и кто отвечает, когда построенное встретится с реальностью.