=----- https://medium.com/meetcyber/vibe-coding-the-antidote-104530b856a7 Д

Вайб-кодинг: противоядие

LLM показали себя ужасным способом написания программ. Но проблема, которую они пытаются решить, реальна, и мы не решаем ее никаким другим способом. Вот что нам следует делать.

---

Вы уже знаете этот аргумент. С одной стороны, непрограммисты ликуют: «Могу создать то, что хочу, с нуля, за пару часов, и это может быть онлайн и приносить деньги уже сегодня вечером». Между тем, более опытные и (хочется надеяться) мудрые профессионалы в области разработки ПО печально качают головами и говорят: «Вы об этом пожалеете». И они жалеют; они всегда жалеют! На следующий день вайб-кодеры жалуются: «Откуда взялись все эти расходы на облако?» или «Почему оно продает все продукты бесплатно?» или «Кто-то взломал магазин, и теперь продаю наркотики в Колумбии».

Вайб-кодинг создает иллюзию прогресса: LLM могут действительно быстро создавать приложения игрушечного масштаба. Но по мере масштабирования программы становятся труднее в управлении и менее предсказуемыми. Хотя процесс должен быть диалоговым, на самом деле ИИ не понимает, что уже сделано правильно, и поэтому каждая попытка инкрементальной итерации переписывает всю программу заново. Это не похоже на поэтапное построение на основе прошлых успехов. Это больше напоминает стрельбу из лука по мишени: две-три стрелы могут приземлиться достаточно близко к центру, но следующие десять могут полностью промахнуться мимо цели. По мере роста программы опыт становится все более хаотичным, как у Ученика чародея, который потерял контроль над своими инструментами для уборки.

«Но смотрите!» — заявляют вайб-кодеры. — «Сделал все это, и понятия не имею о программировании. Как это круто?» Вместо того чтобы приложить немного усилий для изучения программирования — или хотя бы для изучения того, как говорить с программистом — они празднуют собственную непрофессиональность и рассматривают свой кажущийся прогресс как самостоятельную добродетель, несмотря на очевидные риски.

Хотелось бы задать этим вайб-кодерам вопрос: доверили бы вы свое благосостояние и здоровье стоматологу-любителю? Или юристу-любителю? Или электрику-любителю? На самом деле, да, вероятно, доверили бы — люди постоянно идут на такие глупые риски: социальные сети и страницы некрологов полны ими.

Мы насмехаемся над этим отношением, но на самом деле сочувствуем ему. Живем в 300-летнем доме, который требует постоянного внимания мастеров. И все же часто сталкиваемся с ситуацией, когда, консультируясь с профессионалами, они не понимают нашу задачу. Они усложняют проблему за пределы нашей способности понять их диагностику, добавляют время и расходы, совершенно несоразмерные самой задаче, и размахивают туманными нормативами и лучшими практиками, как будто это дубинка, чтобы бить нас. Они стоят беспощадно перед нашим жалким «Все, что нужно, это...»: они уверены, что нам нужно что-то другое, и не потерпят неуважения.

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

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

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

Мы понимаем разницу между кодированием и программированием, и полностью согласны с мнением коллег-профессионалов. Но нам это не нравится. Это создает аргумент для вайб-кодеров.

В июне 2014 года Эндрю Бинсток, редактор вскоре закрывшегося Dr Dobbs Journal, написал интересную статью под названием «Just let me code» («Просто дайте мне кодить»). Стоит прочитать полностью, но хотелось бы процитировать эти особенно жалобные разделы:

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

Простые программы из нескольких сотен строк на C++ давно исчезли из нашей практики. То, что было процессом езды на велосипеде, стало эквивалентом путешествия на реактивном самолете; изобилующим задержками, проверками, ограничениями личного выбора и внезапными, необъяснимыми отменами — все это при значительно более высокой стоимости...

Фундаментальная проблема здесь не в сложности приложений, а в сложности инструментов. Инструменты несколько сошли с ума за последнее десятилетие, гоняясь за шибболетами масштабируемости, всесторонности, производительности. Всем, кроме простоты.

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

В дни до графических интерфейсов все программирование было консольным (даже если консоли — через такие вещи, как curses — были немного более изощренными, чем сегодняшние). Языки, которые были тогда — C++, Pascal, Java в своих ранних воплощениях — идеально соответствовали этой задаче. Можно было написать что-то полезное — либо для настольного, либо для промышленного использования — в (да, как говорит Эндрю) несколько сотен строк. Модель Unix из pipe-ов и (крошечных) фильтров царствовала безраздельно. Не было реальной необходимости в репозиториях кода, в регрессионном тестировании, даже в peer review, потому что каждая разработка была небольшой, автономной и, прежде всего, изолированной (даже когда она участвовала в более крупной системе). Можно было понять ее с первого взгляда.

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

А затем произошла Windows 3. Все правила изменились. Теперь программа не простаивала в потоке ввода. Теперь она отвечала на события откуда-то? Наши программы все еще были на C++ и Java, но теперь они были вывернуты наизнанку: ядром программы был цикл событий (который, как подтвердит любой, кто их помнит, был раздутым, неподдерживаемым), а фактическое поведение находилось в нескольких процедурах, которые, тем не менее, должны были взаимодействовать друг с другом и с базовой системой. Все это дрожащее сооружение требовало страниц и страниц инициализации для регистрации новых «классов» окон, только для того, чтобы предоставить место, где сказать операционной системе, где находится ваш код. Это был неподдерживаемый, разросшийся, антимодульный беспорядок.

Именно тогда начали появляться первые фреймворки. Microsoft Foundation Classes был первым: он обернул системную инициализацию и цикл сообщений в систему классов C++, а также объектифицировал Windows API (который в своей основе был простым, нетипизированным C). Это было не очень красиво, и это было нелегко, и было много подводных камней, но было намного лучше, чем необернутая версия.

Но Microsoft сделала кое-что еще. Они создали Visual Basic. Это был один из первых подходов, который действительно взял быка Windows за рога. Вы создавали экраны и диалоги с помощью визуального редактора — просто перетаскивая компоненты — а затем связывали их вместе, используя простейший язык: никаких объектов или классов, никакой сложной взаимосвязанности. Простое «Если это, делай то».

Visual Basic был откровением, и к тому времени, когда он созрел до версии 6, это была одна из лучших технологий программирования, которые когда-либо видел мир.

Это было легко — легче даже, чем Pascal. Можно было постепенно писать программу, и сама платформа направляла вас в ее использовании. Было множество программистов-любителей — практиков, которые много знали о своей предметной области, но не очень много о программном обеспечении — которые могли слепить простую программу и затем построить на этом бизнес. Подозреваем, что даже сейчас VB был ответственен за больше успешных программных стартапов, чем все другие технологии вместе взятые.

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

Увы, VB не продержался. Он совершенно не подходил для недавно развивающихся практик промышленной разработки программного обеспечения, таких как Git и командные монокультуры. Не помогло, когда Microsoft переместила базовый язык в новую, шизофреническую, с комплексом Наполеона среду выполнения .Net, что сделало программирование на нем таким же сложным, как программирование на C#, и уничтожило то самое, что сделало его успешным. (Теперь даже визуального редактора нет, и приходится создавать диалоги в xaml! Последние следы того, что делало VB6 хорошим, наконец стерты.)

Много думали об этом, и вывод, к которому пришли, таков: наши самые фундаментальные современные инструменты просто не подходят для своей цели. Языки, которые используем, в значительной степени основаны на парадигмах 1970-х и 1980-х годов: однопоточные, процедурные, детерминированные и использующие очень странный вид модульности, которую притворяемся объектно-ориентированной (но в действительности она таковой не является). Начиная с 1990-х годов и ускоряясь на протяжении лет, задача программирования изменилась, хотя языки не изменились. Теперь эти языки принципиально не подходят для современных потребностей программного обеспечения: реактивного, асинхронного, недетерминированного, построенного на ненадежных экземплярах и подключении. Все эти тяжелые инструменты, все эти зависимости: они существуют для преодоления этого базового несоответствия импеданса и втискивания наших задач программирования XXI века в технологию программирования 1980-х годов.

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

Так что же должен делать специалист предметной области, программист-любитель? Изучить всю эту мертвую культуру, ритуалы и все равно не суметь решить свою проблему? Или последовать обещанию «кодирование стало тривиальным» и запустить ChatGPT?

Ах, но есть проблема. Если языки программирования — не лучший способ говорить о программном обеспечении, почему мы считаем, что английский был бы лучше? Когда программисты собираются вместе, чтобы обсудить, что кодить, они рисуют диаграммы с текстовыми аннотациями (обычно даже не на английском). Можете представить определение электрической схемы только на английском? Или как насчет сборки мебели Ikea, используя только словесное описание? Даже для навигации по дорожному путешествию большинство водителей предпочитают карты с визуальными инструкциями, гораздо больше, чем список инструкций без какой-либо визуальной структуры. Это причина, по которой вайб-кодинг не работает. Помимо фундаментальных ограничений технологии LLM, сама идея обсуждения программы на английском кажется ошибочной.

К сожалению, не можем вернуться в дни Visual Basic. Он был достаточно прост для любителей, но, основываясь на идеях программирования 1990-х годов, он так же анахроничен в сегодняшнем мире, как C++, Java и их потомки, такие как Rust и Go. Но если бы могли возродить дух VB в более современном стиле, несомненно, это дало бы любителям больше возможностей, чем когда-либо мог вайб-кодинг.

Можем увидеть фрагменты такого подхода в сегодняшнем мире. AWS, наряду с другими облачными провайдерами, предлагает serverless-вычисления. Они предоставляют, как VB, палитру готовых сервисов, которые связываете вместе, используя простую связующую логику. Их Cloud Development Kit означает, что можете создавать свои конфигурации офлайн, а затем загружать их для развертывания за один шаг. Обещание: платите только за то, что используете.

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

Хуже того: Serverless заботится только о back-end, облачной резидентной части: все еще нужно создать front-end сайт или мобильные приложения, все еще нужно управлять собственным доменом и сертификатами, есть странные ограничения на то, что можете делать (так что все еще нужно следить одним глазом за базовым механизмом), и AWS, будучи AWS, расходы почти полностью непредсказуемы.

На другом конце спектра находятся предложения Platform as a Service, такие как Render. Их предложение: весь этот сложный механизм (эластичность сети, аутентификация, безопасность, резервные копии): они практически одинаковы в каждом приложении. То, что делает вас уникальным, — это ваше программное обеспечение. Итак, разрабатываете свой код, загружаете его на их сайт, и они делают все необходимое, чтобы заставить его работать безопасно.

Это отличный сервис, но это тоже не полный ответ. Как создать свое программное обеспечение? Как только начинаете разрабатывать его, как разработать его архитектиру? (Все еще необходима некоторая базовая архитектура.) И, опять же, как разработать front-end?

Наконец, существует множество конструкторов сайтов no-code. Wix, Ionos, Zoho, WordPress (и есть много других) позволяют любому создать сайт просто перетаскиванием готовых компонентов. Каждый продукт имеет свои сильные и слабые стороны — некоторые лучше подходят для создания магазинов, а другие лучше для взяимодействеия с клиентами. Некоторые просты, как начальная школа, а некоторые немного сложнее. Но все они тщательно разработаны, чтобы использоваться новыми клиентами после всего лишь минуты изучения.

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

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

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

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

---

SEO-заголовки (около 100 символов)

1. Вайб-кодинг и LLM: почему они не решают проблему создания программ
2. От Visual Basic к LLM: эволюция инструментов для непрограммистов
3. Что не так с вайб-кодингом и какие инструменты нам действительно нужны
4. Сложность современной разработки: почему вайб-кодеры правы в своих жалобах
5. Будущее программирования: почему нужны новые инструменты вместо LLM
6. Проблема вайб-кодинга: английский язык не заменит языки программирования
7. Serverless, no-code и вайб-кодинг: что действительно нужно разработчикам

SEO Description (около 200 символов)

1. Анализ проблем вайб-кодинга с LLM и причин, почему современные инструменты разработки стали слишком сложными. Что нужно изменить для упрощения создания ПО.
2. Почему LLM — плохое решение для программирования, но проблема реальна. Как эволюция от Visual Basic к современным инструментам привела к кризису доступности разработки.
3. Критика вайб-кодинга и анализ того, почему создание ПО стало сложным даже для профессионалов. Какие инструменты нужны для решения этой проблемы.

Анонсы (около 200 символов)

1. LLM обещают упростить программирование для непрофессионалов, но приводят к хаосу. Реальная проблема — в сложности современных инструментов разработки. Разбираем, что пошло не так.
2. От простоты Visual Basic к хаосу современных тулчейнов: как разработка стала непосильной даже для профессионалов. Почему вайб-кодинг — симптом более глубокой проблемы индустрии.
3. Вайб-кодеры правы: создание ПО стало слишком сложным. Но LLM — не решение. Анализируем, какие инструменты действительно нужны для демократизации разработки программного обеспечения.