Оригинал статьи:The Collapse Of Software Engineering And The Beginning Of Something New.
Автор, специалист из Индии, характеризует свою компетенцию с помощью ключевых слов: Software Engineer @Arcesium | AI Agents & Software Architecture | Technical Writer @gitconnected & @JavaScriptinPlainEnglish.
Фраза «программная инженерия никогда не сводилась к написанию кода» — это всего лишь способ себя успокоить, хотите вы это признавать или нет. Я, если честно, теперь это признал — сам ведь тоже пытался так себя успокаивать:).
«Кодирование никогда не было самой сложной частью» или «дело никогда не было в написании кода» — это защитная реакция, помогающая нам смириться с тем, что огромная часть нашей работы теперь автоматизирована с помощью ИИ. И речь уже не только о написании кода: ИИ становится всё лучше и в принятии серьёзных решений по архитектуре систем — взять хотя бы Opus 5.5 и GPT Astra.
И этот внезапный сдвиг вызывает у нас стресс. Нам страшно — всем нам, даже тем, кто работает в профессии больше десяти лет. И одним из ответов на этот страх как раз и становится упомянутая выше фраза: «Дело никогда не было в написании кода».
В этой статье я хочу поделиться своим взглядом на будущее нашей профессии — взглядом человека, который сам работает программным инженером. И я хочу быть предельно честным. То, о чём я буду говорить, продиктовано не страхом, а исключительно рациональными соображениями. И я не собираюсь заканчивать статью избитой чушью в духе: «Да, ИИ умеет писать код, но он всё ещё не может…»
Pассуждая обо всём этом, я буду исходить из одного важного принципа: сегодняшний ИИ — худший ИИ из всех, которые у нас когда-либо будут.
Начнём с того, что на самом деле изменилось.
Теперь ИИ способен создавать программные продукты быстро. Очень быстро.
Человек, у которого есть идея, но нет никакого инженерного опыта, может с помощью промптов получить работающее приложение за день — ну, может быть, за неделю. И я не могу делать вид, будто это неправда, потому что это правда.
Каждый раз, когда появляется новая модель ИИ, Twitter и LinkedIn заполняются сообщениями вроде: «Смотрите, я только что сделал собственный браузер с помощью Claude» или «Я только что сделал эту 3D-игру за пять минут с помощью Argon».
Можно говорить, что некоторые из этих продуктов сделаны кое-как. Но для вещей, созданных меньше, чем за час, выглядят они чертовски впечатляюще.
Отлично. Но в корпоративном мире, где в конечном счёте всё программное обеспечение связано с выручкой, нет никакой разницы, было приложение сделано за пять минут, пять дней или пять недель, если оно ничего не зарабатывает.
Скорость сама по себе не приносит денег. Как и способность быстро что-то реализовать.
Деньги появляются тогда, когда люди пользуются программой. Работающее приложение, которое никто не открывает, ничего не стоит — независимо от того, насколько быстро и насколько качественно оно было сделано.
ИИ удешевил создание программного обеспечения. Но он не заставил людей хотеть им пользоваться. Люди не начнут волшебным образом пользоваться какой-то программой только потому, что её сделали за один день.
Так за что же на самом деле все эти годы платили инженерам, если само создание продукта никогда не было дефицитным ресурсом? Признать это непросто, особенно если ты потратил десять лет на то, чтобы научиться хорошо писать код.
Я бы не сказал, что ИИ полностью уничтожил ценность инженерной работы — по крайней мере пока. Что будет в будущем, я утверждать не берусь.
Скорее, ИИ обнаружил, что настоящая ценность инженерной работы всё это время находилась совсем в другом месте.
Значительная часть того, что мы называли инженерией, на самом деле была своего рода налогом, который приходилось платить ещё до того, как становилось возможным выяснить, нужен ли вообще кому-нибудь твой продукт.
Кто-то сначала должен был его написать. И только после этого мог начаться настоящий тест. А настоящий тест никогда не был техническим.
Настоящий вопрос заключался в другом: откроет ли незнакомый тебе человек это приложение снова завтра?
Как только само создание продукта перестаёт быть узким местом, остаётся работа, которую раньше никто особенно не выделял в отдельную профессию: наблюдать за тем, что люди на самом деле делают с созданным тобой продуктом — а не за тем, что, согласно спецификации, они должны были с ним делать, — и на основании этого решать, что исправить, что убрать и что создавать дальше.
Эта работа существовала всегда. Просто раньше она незаметно пряталась внутри работы инженера. Теперь же именно она становится главной, когда всё остальное начинает исчезать. Говорить это не слишком приятно, но у этой работы уже есть название.
Это называется продуктовым мышлением / продакт-менеджментом. Единственная причина, по которой «инженер» и «человек, который решает, что создавать дальше» когда-либо были двумя разными должностями, заключается в том, что создание программного обеспечения было достаточно сложным делом, чтобы для него требовался отдельный специалист. Как только это перестаёт быть правдой, стена между двумя профессиями не просто начинает трещать. Она рушится.
Поэтому, когда я говорю «инженер» применительно к тому, что будет через пять лет, я думаю, что речь пойдёт уже совсем о другой профессии. Мне кажется, это будет человек, гораздо больше похожий на того, кого раньше мы называли продуктовым специалистом, — только теперь он сможет самостоятельно воплощать собственные идеи, вместо того чтобы вставать в очередь и ждать, когда до них доберётся инженерная команда.
Название профессии, возможно, сохранится. Но сама профессия под этим названием — нет.
Если бы мне пришлось делать ставку на то, кто в итоге займёт эту объединённую роль — инженер или продуктовый специалист, — я бы поставил на инженера. И не из преданности собственной профессии. Я действительно считаю, что техническое понимание не перестаёт иметь значение только потому, что создавать программные системы стало быстрее.
Человек, который сам находился внутри системы, который знает, что в ней ломается, когда на неё увеличивают нагрузку, и понимает, почему это происходит, обладает опытом, который невозможно сымитировать человеку, всю жизнь лишь описывавшему другим, что именно нужно построить.
Продакт-менеджер, который никогда не был инженером, не может мгновенно приобрести накопленную за годы способность замечать все те места, где что-то может пойти не так.