Продолжай быть инженером

Транскрибация тривиальная задача, простое web-приложение можно собрать за пару часов. Стоит ли бояться, если ты учился этому 10 лет, а теперь любой может сделать то же самое за 10 часов? Мысли пугающие. Но если немного отстраниться, становится очевидно: реальность просто стимулирует многих инженеров (включая меня) мимикрировать под окружающую среду — осваивать новые инструменты и вырабатывать новые подходы к созданию программного обеспечения.

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

Со временем у любого инженера развивается насмотренность — профессионализм, подкрепленный практикой и непрерывным обучением. Именно насмотренность и знания являются тем самым стоп-фактором, который не дает заменить инженеров промпт-инжинирингом.

Да, не зная конкретную технологию или даже целую область, сегодня можно создать какое-то приложение. Возможно, оно даже будет решать поставленную задачу. Но почти всегда это будет PoC, а дальше начинается реальность:

• нужно изменить бизнес-поведение
• исправить дефекты
• развернуть приложение в окружении

На каждом из этих этапов возникают проблемы, решить которые без той самой насмотренности и инженерного опыта невозможно (если речь не идет о калькуляторе). Можно конечно продолжать чинить все новыми промптами, но это лишь порождает новые проблемы. Если смотреть прагматично, нейросети в первую очередь значительно ускорили набор текста — и это одна из ключевых возможностей, которую действительно стоит освоить.

Простой пример. Когда-то я рассказывал, что у меня не было инструмента для анализа релизов продукта на работе, и я просто делал записи в блокноте. За один вечер я создал этот проект, самостоятельно написав не больше 100 строк кода: https://release-calendar-demo.vercel.app. Но что на самом деле понадобилось, чтобы это сделать? По сути, я почти не кодировал, зато я:

• Сформулировал функциональные и нефункциональные требования (для этого нужно понимать предметную область и атрибуты качества)
• Заложил архитектуру для будущих изменений и исправлений (для этого нужно понимать, какая архитектура подходит, а какая — нет)
• Подготовил приложение к запуску (а это навыки работы с окружениями и деплоем)
• Много раз задавал уточняющие и корректирующие промпты (и тут важно понимать, почему конкретный результат — хороший или плохой)

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

Инженерное мышление никуда не делось, оно наоборот стало еще важнее.