Может ли работник производственного цеха навайбкодить для себя приложение?

Да, потому что навайбкодить для себя приложение фактически означает напросить его у LLM. В целом любой, кто закончил 3-й класс без троек и научился писать и читать, может написать в чат произвольной LLM своё желание, и модель его исполнит. Если человек ещё может и по инструкции от LLM какие-то пункты по шагам выполнить, это вообще уже почти гений, потому что он даже сможет работающий софт развернуть у себя на ноутбуке. А если он ещё сможет полученные файлы скопировать и вставить на диск какого-нибудь хостинг-провайдера, так и совсем, получается, звезда взошла, потому что в итоге родился настоящий сайт.

Результат зависит в основном от модели и подписки. Если есть около $200 на ChatGPT/Claude, результат получится лучше, если есть только $20 — хуже и дольше, но всё равно что-то получится. А если итог не понравился с первого раза — «довайбкодить» тоже можно.

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

У сотрудника появилась возможность создать для себя собственное приложение, сайт, веб-форму, скрипт, алгоритм и использовать его для рабочих целей. С точки зрения пользователя всё отлично и суперинтересно. Ещё и руководство поощряет, ведь это позволит сэкономить много денег на дорогостоящих программистах (а в будущем даже вообще от них отказаться!!!).С другой стороны, теперь этот сотрудник достаточно большой квант своего времени тратит не на выполнение своих непосредственных задач, а на написание просьб к LLM (вайбкодинг), тестирование и отладку работы полученного софта, доработку, исправление ошибок LLM, выслушивание извинений от LLM за совершённые ошибки и т. д.

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

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

Строго говоря, сотрудник в этом случае в целом переходит в категорию программистов, поскольку начинает создавать ИТ-продукт. Но при этом не обладает должными навыками, знаниями, архитектурным видением, собственным представлением об устройстве будущего софта, а пока может только просить его у LLM.

В конечном счёте вайбкодинг в таком случае заканчивается либо на первых интеграциях продукта с какой-то другой системой, либо на попытках расширить его функциональность, либо заходит в тупик при определённом размере полученного исходного кода, когда LLM перестаёт вести себя адекватно, теряет контекст или исходный план (которого чаще всего и не было).

Компания получает ложные надежды, потерянное (но оплаченное) время сотрудника, сложный актив с непонятными планами на его развитие: выкинуть жалко, а как развивать — непонятно.

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

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

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

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

P. S. Каждый раз чувствую себя очень некомфортно, когда начинаю рассказывать очередному вайбкодеру или руководителю бизнеса, в котором тот работает, про базовое устройство софта: слои данных, звенья архитектуры, модули, консистентность данных, различия между разными СУБД, платформами разработки и многие другие важные (на мой взгляд, разумеется) нюансы, влияющие на качество работы будущего приложения, чистоту данных, масштабируемость, интегрируемость в экосистему продуктов, модифицируемость отдельных компонентов.
Больше контента по этой теме у меня в канале:
Telegram: Афанасьев PRO цифровизацию
MAX: Афанасьев PRO ИТ