Код стал дешёвым. Что осталось программисту?

Продолжаю отвечать на ваши вопросы. Сегодня разбираем вопрос Куда идет разработка, ведь стоимость кодогенерации стремиться к нулю, на что ставим, изучаем ? Т.е. что уже понятно, а что еще нет У меня на этот счёт довольно оптимистичный взгляд. Профессии программиста нет ещё и ста лет: одни из первых программистов ENIAC начали работать в 1945 году. Для сравнения, фотография стала коммерческой профессией ещё в 1840-х, а регулярные авиалинии появились в 1914-м. Поэтому, может быть, мы наблюдаем не смерть программирования, а наоборот — его подростковый возраст. Профессия просто впервые настолько сильно меняет форму.

Я работаю разработчиком с 2008 года, и написание кода никогда не было главной частью моей работы. Работающий код — это продукт, который производит разработчик. А его реальная работа происходит раньше.

Когда мне делали оффер в СберТех, я спросил будущих коллег, что для них важно в моей роли. Мне ответили: «90% времени надо работать головой». Так и получилось. В моей нынешней R&D-работе я иногда могу три недели почти не писать код и всё это время вполне успешно продвигаться по задаче. R&D — это, конечно, крайность, но и в любой разработке сначала нужно ответить на вопросы: — Какую задачу мы вообще решаем? — Зачем? Кому от этого станет лучше или перестанет быть плохо? — Какие есть ограничения? Как решение встроится в существующую систему? — Что мы сломаем? Как потом это поддерживать и развивать?

И только после всего этого идёт код. Поэтому мне не кажется, что нейронки обесценивают труд программиста. Скорее они его выкристаллизовывают. Последние два года я много пишу на C и так его и не полюбил: слишком много надо стучать по кнопкам, чтобы сделать простые и понятные вещи. И я счастлив, что теперь значительную часть этого может сделать coding-агент, а я потрачу освободившееся время на YouTube shorts более глубокое исследование задачи.

То же самое относится к Make, CMake, Bash, Git, GDB и куче других инструментов, которые невероятно мощны, но совершенно не приспособлены к тому, чтобы простые смертные могли легко ими пользоваться. Раньше существенная часть времени уходила на то, чтобы вспомнить хитрый флаг, раскопать синтаксис Makefile или найти нужную команду GDB. Если не пользуешься этим каждый день, детали мгновенно вымываются из головы.

Теперь мне всё меньше нужно помнить как именно попросить инструмент сделать нужную вещь. Но мне всё ещё нужно понимать, что он умеет и что именно я хочу от него получить. Можно не помнить команду GDB — но нужно понимать устройство процесса и что именно ты пытаешься проверить.

Есть и ещё одно следствие. Дешевеет не только production-код — дешевеет эксперимент. Раньше мысль «а что если сделать вот так?» могла стоить 3 дня работы, поэтому многие гипотезы я даже не проверял. Теперь можно быстро собрать прототип, попробовать несколько альтернативных решений, написать benchmark — и выкинуть всё, если идея не сработала.

Поэтому я бы сейчас ставил не на способность производить больше кода и не на запоминание ещё большего числа инструментов. Я бы ставил на способность понимать системы, разбираться в незнакомом, видеть ограничения, формулировать гипотезы и быстро их проверять.

Стоимость написания кода стремится к нулю. Стоимость понимания задачи — нет. И всё чаще скорость разработки определяется именно скоростью этого понимания.

А какая часть вашей работы уже сейчас упирается скорее в понимание, чем в написание кода?