Индустрия разработки программного обеспечения переживает потрясения. Никто не знает точно, к чему в итоге приведёт AI-революция, но уже ясно: она изменит многие аспекты работы и жизни, включая программирование.

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

Это утверждение — грубое оскорбление для всех программистов.

Если писать код легко...

Если код — это просто, почему программисты годами были в высоком спросе и требовали высокие зарплаты (ещё до эпохи нулевых ставок)? Почему столько стресса, переработок и выгорания было ещё до того, как AI начал штамповать пул-реквесты на 5000 строк? Почему компании искали «10x-ниндзя-рокстаров» и мучили их leetcode-собеседованиями — разве джуниор сразу после колледжа не справился бы, если всё так просто?

Если код — это просто, откуда взялись такие увесистые книги, как Clean Code и The Pragmatic Programmer? Разве The Art of Computer Programming — это лёгкое летнее чтиво? Разве SICP — книга для кофейного столика? Зачем тогда существуют буткемпы и целые университетские программы, посвящённые программированию?

Если код — это просто, был ли Кармак всего лишь в нужном месте в нужное время? Почему Фабриса Беллара считают гением?

Если код — это просто, почему люди злятся, когда AI (или кто-то ещё) копирует их код? Почему они ведут себя так, будто вложили в нечто настолько тривиальное свой пот, душу и уйму времени?

Если код — это просто, почему многие сейчас чувствуют, что у них отбирают их идентичность и профессиональный смысл?

Если код — это просто, почему программное обеспечение настолько багованное?

Если сложная часть — понять, что строить...

Если решить, что строить, — самая сложная часть, почему так много продакт-менеджеров выглядят растерянными? Почему для них не устраивают жёсткие десятиэтапные собеседования? Почему им не платят больше, чем разработчикам?

Если решить, что строить, — самая сложная часть, почему маркетологов-исследователей, специалистов по юзабилити и уж тем более сотрудников customer success не считают звёздами софтверной компании? Если «понять клиента» сложнее, почему бизнес-аналитиков воспринимают как канцелярских работников?

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

Если код — это просто, почему бы всем просто не строить по десять вариаций продукта и не смотреть, какая выстрелит?

Не бывает «среднего» программиста

Ещё одно клише: «большая часть работы в разработке ПО — это общение со стейкхолдерами, понимание потребностей клиента и ясность в приоритетах».

За карьеру довелось встретить немало программистов, и очень немногие из них хотят разговаривать со стейкхолдерами, не говоря уже о клиентах (исключения — фрилансеры и основатели, особенно студий разработки). А «ясность в приоритетах» на практике сводится к «просто скажите, что делать, и не меняйте задачу каждые два дня».

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

Третьи скажут: «Разработка ПО — это построение теорий». Программы на самом деле — это доказательства (в математическом смысле). Каждый коммит должен рассказывать историю. А решить проблему клиента, залив PHP-файл по FTP, — смертный грех.

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

Что действительно важно?

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

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

¿Por qué no los dos? (Почему бы не и то, и другое?)

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

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

Это форма психологической защиты. А нужно не защищаться, а развиваться.

Речь не о том, чтобы «запрыгнуть в поезд LLM» или «стать менеджером флотилий AI-агентов». И не о том, что «код, сгенерированный AI, — это украденный мусор, с которым нужно бороться до последнего, пузырь всё равно скоро лопнет».

Но стоит признать: индустрия переживает тектонический сдвиг. Нужно понять, как к нему адаптироваться, и разобраться, что, вероятно, изменится, а что останется неизменным.

Что не меняется

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

Пользователи всегда будут хотеть большего и готовы платить меньше. Они по-прежнему не будут знать, как сформулировать свои потребности и желания. Хуже того — они по-прежнему не будут точно знать, чего хотят. Разрыв между клиентами (теми, кто реально платит за софт) и пользователями (теми, кто им пользуется) никуда не денется, как и напряжение между потребностями бизнеса и потребностями его клиентов.

А ещё: продавцов змеиного масла меньше не станет. Модные технологии приходят и уходят (до сих пор ждём нового ренессанса VR!).

Что меняется

Программисты с самого начала занимались тем, что разрушали собственную индустрию. Никто больше не использует перфокарты. Очень немногим нужно писать на ассемблере или COBOL. Десятилетия борьбы с багами памяти в C или C++, оставившие немало шрамов, бесполезны в эпоху Rust, Go, Python и JavaScript.

Достаточно почтенный возраст, чтобы ценить valgrind или помнить mysql_real_escape_string() из эпохи PHP4 — вещи, которые больше никогда не понадобятся. И это было не так уж давно! Эпоху dBase, Clipper, HyperCard и Access удалось застать лишь краем глаза — технологии, которые до сих пор можно встретить работающими в магазинах, кафе или в пыльном, некогда бежевом, а теперь золотисто-коричневом системном блоке, всё ещё бодро крутящем какое-нибудь самописное бизнес-решение (бэкапы? какие бэкапы?).

Как адаптироваться

Стоит принять, что перемены происходят. Быть в равной мере любопытным и критичным по отношению к новому.

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

Роль и обязанности будут меняться. Стоит быть готовым вкладывать время и энергию в изучение смежных областей и ролей.

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

Начинающим и junior-специалистам стоит вкладываться в углубление понимания того, как работает софт. Понимание указателей, рекурсии или иерархии памяти пригодится, даже если работаешь на JavaScript. Понимание сетевых протоколов и работы HTTP окажется полезным, даже если задача — писать плагины для WordPress. Стоит решать leetcode-задачи и изучать алгоритмы и структуры данных, даже если это формально не требуется. Не нужно бояться спрашивать почему и как именно.

Для вдохновения — несколько книг и других материалов, которые могут пригодиться:

И ещё одно

Кем бы ты ни был, не стоит передавать AI на аутсорс своё понимание, суждение, эмпатию и вкус. Не стоит отказываться от ответственности. Не стоит становиться мясным прокси.