«А нам точно нужен Open Source? Мы же вайбкодим вообще всё!»

«А нам точно нужен Open Source? Мы же вайбкодим вообще всё!» Это спросил друг, который делает небольшие проекты, и такой вопрос я теперь слышу постоянно. Зачем брать чужую библиотеку или сервис, если за вечер можно навайбкодить своё? Ровно под свою задачу, без лишних фич, без чужой документации и чужих багов.

Вопрос честный, и короткого ответа «потому что так правильно» на него нет. Попробую ответить развёрнуто, на своих проектах.

Сначала про то, в чём они правы

В 2004 году Клей Ширки написал эссе Situated Software про программы для конкретной группы людей и конкретного момента: студенческий сервис на тридцать человек, который не масштабируется, не обобщается и не должен. Тогда такой софт был исключением, потому что писать код было дорого.

Сейчас код почти бесплатный. Бот для семейного чата, скрипт, который раскладывает выписки по категориям, внутренняя админка на три таблицы, лендинг под одну акцию: всё это ИИ пишет за час, и это работает. Брать для таких задач фреймворк, SaaS с подпиской или «enterprise-решение» — как ехать за хлебом на фуре.

Ситуативный софт — реальная и хорошая вещь. Я сам пишу его каждую неделю.

Где это перестаёт работать

Возьмём Postgres. Можно ли навайбкодить хранилище данных? Конечно. Попросите модель сделать key-value хранилище в файле с индексом и транзакциями, и через час у вас будет код, который проходит тесты.

Только никто в здравом уме не заменит им Postgres. И дело не в количестве строк. Postgres развивается с 1986 года, и его ценность не в коде, а в том, что в нём уже учтено:

• что будет, если питание пропадёт посреди записи;

• что будет, если диск сказал «записал», а на самом деле нет;

• что будет, когда два запроса меняют одну строку одновременно;

• что будет на десятом миллионе строк, а не на десятой;

• как обновиться на новую версию и не потерять данные.

Каждый из этих пунктов — это чья-то потерянная база, issue в трекере и исправление. Модель пишет код для счастливого пути, потому что счастливый путь видно в задаче. Редкие сбои в задаче не видно, они появляются только со временем и под нагрузкой. Сгенерировать накопленный опыт отказов нельзя.

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

Моя история: как самописное стало сервисом

В одном из моих проектов нужно было ходить в LLM. Сначала это был один вызов OpenAI прямо в коде, и ситуативный подход тут идеален: десять строк, работает.

Потом началось обычное:

• вендор упал — нужен второй вендор и переключение;

• вендор вернул 429 — нужно понять, ждать или идти к другому;

• стоимость выросла — нужно понимать, какая фича сколько тратит, и ограничивать;

• вышла новая модель — нужно поменять её в нескольких местах и не сломать промпты;

• одни задачи простые, другие сложные — нужно отправлять их в разные модели;

• ключи вендоров разошлись по конфигам — нужно хранить их в одном месте.

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

Понял, что пора выносить, по двум признакам. Первый: я писал один и тот же код в каждом сервисе, которому нужна LLM. Выбор модели по уровню усилия, реестр стоимостей, кэширование стали нужны везде, и везде я их копировал. Второй: я перестал понимать, какому из десяти сервисов выдал ключ от Gemini, а какому от OpenAI.

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

Так получился Keystone (KTMS), open-source шлюз для LLM. Но пост не про него, а про момент, когда пора перестать писать самому.

Критерий: когда вайбкодить, а когда брать готовое

Я для себя свёл это к четырём вопросам.

1. Сколько стоит ошибка? Если сломается бот для друзей, вы переживёте. Если потеряются платежи, данные клиентов или ключи — нет.

2. Меняется ли мир вокруг задачи без вашего участия? Скрипт для своих выписок живёт годами. Интеграция с внешними API ломается каждый раз, когда вендор что-то меняет, и кто-то должен это чинить.

3. Будет ли этим пользоваться кто-то кроме вас? Свой софт можно держать в голове. Чужим людям нужны документация, совместимость и предсказуемые ошибки.

4. Задача у вас одна или она повторяется? Если вы второй раз пишете одно и то же в другом проекте, это уже не ситуативный софт, а библиотека или сервис, просто ещё не оформленный.

Если на все четыре ответ «дёшево, нет, нет, одна» — вайбкодьте и не думайте. Если хотя бы на два ответ другой, посмотрите, нет ли готового.

Неожиданный эффект: ИИ повышает ценность хороших компонентов

Мне кажется, вайбкодинг не убивает готовые решения, а наоборот, делает хорошие из них ценнее.

Модели отлично пишут код поверх Postgres, Redis, S3 и стабильных API: они видели миллионы примеров, документация известна, поведение предсказуемо. И плохо пишут сами Postgres, Redis и S3. Чем больше кода генерируется, тем важнее, чтобы под ним был надёжный и скучный фундамент, к которому этот код можно прикрутить.

Ситуативный софт — это клей, а клей не держит без того, что он склеивает.

А как у вас?

Я уверен, что у многих граница проходит в другом месте. Интересно услышать:

• что вы навайбкодили вместо готового решения и прекрасно живёте;

• что навайбкодили и потом пожалели;

• где для вас проходит граница.