ИИ пишет код за секунды: за что тогда платят разработчику

Хороший разработчик — это тот, кто хорошо пишет код. Я держался за это определение годами. Сейчас не так уверен.

Функцию ИИ выдаёт за секунды. Компонент собирает. Ошибку объясняет. Кривой код переписывает. Небольшую фичу может сделать целиком, пока вы стоите рядом с кофе. Если печатать код стало дёшево, за что тогда платят?

Неудобный ответ

За набор символов не платят. Платят за решение о том, какой код вообще должен появиться.

Клиент приходит не с фразой «напишите 437 строк на TypeScript». Он говорит: «пользователи бросают корзину на оплате», «команда тратит часы на ручную работу», «трафик есть, а записей нет», «надо, чтобы эта система разговаривала с той».

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

ИИ умеет быстро делать не то

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

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

Что отдавать машине, а что оставлять себе

Навыки, которые дорожают

• Понимать бизнес-задачу, стоящую за тикетом.
• Задавать вопросы получше — до того, как открыт редактор.
• Разбивать сложное на части, каждую из которых можно проверить отдельно.
• Делать архитектурные компромиссы и объяснять их вслух.
• Понимать пользователей, а не только их жалобы в поддержке.
• Отлаживать системы, а не синтаксис.
• Ревьюить сгенерированный код так же придирчиво, как код коллеги.
• Знать, когда что-то строить не надо.

Практика: что делать до промпта

1. Опишите проблему словами бизнеса. Не «нужен эндпоинт», а «оплата отваливается на последнем шаге у части пользователей».
2. Спросите себя, что случится, если этого не делать вовсе. Иногда честный ответ — «ничего», и задача закрывается на этом месте.
3. Зафиксируйте критерий «готово» до первой строчки кода. Иначе критерием станет «компилируется и выглядит прилично».
4. Разделите работу: что ИИ закроет сам, а где вам придётся думать и отвечать за результат.

Где ИИ выручает, а где мешает

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

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

Типичные ошибки

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

Соревноваться с ИИ в скорости печати — плохая игра. Если CRUD-API пишется за 30 секунд, карьера «самого быстрого печатника CRUD» заканчивается, не начавшись.

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