C++ разработчик и искусственный интеллект

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

Короткий ответ: инженеры нужны, но планка сместилась. Ниже - почему.

ИИ воспроизводит то, чему его учили

Модель обучена на огромном объёме уже написанного кода и по своей природе выдаёт то, что чаще всего встречалось в этих данных. Она отлично справляется с задачами, которые человечество уже решало тысячи раз: разобрать JSON, поднять HTTP-сервер, написать тесты к понятной функции.

Ровно отсюда растут и её ограничения:

• Нетипичное решается плохо. Ваша предметная область, ваши ограничения по железу, компромисс между памятью и задержкой именно в вашем случае - этого в обучающих данных не было. А инженерная работа во многом состоит из таких вот «а у нас всё не так».
• Перекос в сторону старого кода. Открытого C++ кода накоплено за десятилетия, и написан он преимущественно в старом стиле. Поэтому модели охотно выдают new/delete вместо умных указателей, сырые циклы вместо алгоритмов, C-строки вместо std::string_view. Код будет рабочим, но не тем, который вы бы хотели видеть у себя в проекте.
• Уверенность не равна правоте. Модель может сослаться на несуществующую функцию стандартной библиотеки или перепутать поведение перегрузки - и изложить это ровно тем же тоном, что и правильный ответ.

Почему в C++ цена ошибки выше

В языках с управляемой памятью неверный код обычно падает громко и сразу. В C++ это не так.

• Неопределённое поведение может не проявиться на тестах. Гонка данных, обращение к освобождённой памяти, выход за границу массива - всё это способно годами работать «нормально» на вашей машине и выстрелить у пользователя или после смены версии компилятора. Ни один тест не гарантирует, что сгенерированный код от этого свободен.
• Время жизни объектов - самое тонкое место. Именно здесь модели ошибаются чаще всего: возвращают ссылку на локальный объект, захватывают переменную в лямбду по ссылке, не задумываются, кто владеет объектом.
• Многопоточность. Код, выглядящий корректным, может содержать гонку, которая воспроизводится раз в неделю под нагрузкой.

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

Узкое место разработки - не скорость набора кода

Это самое важное. Работа инженера никогда не сводилась к печатанию символов. Она состоит из:

• выяснения, что на самом деле нужно заказчику (обычно он и сам формулирует это не с первого раза);
• решения, каких ошибок в системе быть не должно, и что делать, когда они всё-таки случатся;
• компромиссов: скорость против читаемости, сроки против технического долга, надёжность против стоимости;
• ответственности за результат.

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

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

Что действительно меняется

Было бы нечестно сказать, что ничего не происходит. Происходит, и вот что видно уже сейчас:

• Рутина обесценивается. Умение быстро написать очередной шаблонный класс само по себе больше не является преимуществом.
• Растёт ценность проверки и системного мышления. Способность заметить, что предложенное решение красивое, но не выдержит нагрузки или не ляжет в существующую архитектуру, становится ключевым навыком.
• Планка входа поднялась. От джуниора и раньше ждали, что он умеет писать код. Теперь всё чаще ждут, что он умеет ещё и оценивать чужой - в том числе машинный.

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

Ловушка для тех, кто только учится

Самый серьёзный риск ИИ для начинающего разработчика - не «отнимет работу», а помешает научиться.

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

Что с этим делать:

• На учебных задачах сначала решайте сами, а к ассистенту идите за разбором готового решения - «что здесь можно было сделать лучше и почему».
• Просите не код, а объяснение: почему именно так, какие есть альтернативы, что сломается при изменении условий.
• Не вставляйте код, который не можете объяснить построчно. Это правило одинаково хорошо работает и для кода со Stack Overflow, и для кода от модели.
• Периодически пишите что-нибудь вообще без ассистента - чтобы честно видеть свой реальный уровень.

Как пользоваться с пользой

• Как ускоритель рутины: шаблонный код, заготовки тестов, разбор незнакомого API, черновики документации.
• Как объясняющий собеседник: «почему компилятор ругается вот так?» - ошибки в шаблонах C++ модели расшифровывают заметно понятнее, чем компилятор.
• Как навигатор по чужой кодовой базе: быстро понять, где что лежит и как связано.
• Как рецензент: попросить найти проблемы в вашем коде. Не как истина в последней инстанции, а как ещё одна пара глаз.

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

Чего никто не знает

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

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

---

На главную страницу