7.0 KiB
Выводы по видео
Источник: https://www.youtube.com/watch?v=zBcWcignqng Название: А что если наВайб-Кодить? Длительность: 5:31
Главный тезис
Нейросети открыли ящик Пандоры: теперь любой сервис можно быстро переписать «под себя» — и в этом главная ловушка. Проблема современного софта никогда не заключалась в написании кода. Проблема — в его поддержке. Разработчики не писали свои аналоги Jira, Datadog и т.д. не потому что не могли, а потому что не хотели. И зря забывают об этом сейчас, вдохновившись возможностями ИИ.
Иллюстрация: маятник «сделали своё → вернулись к покупному»
Автор приводит два твита с разницей в несколько месяцев:
| Дата | Что произошло |
|---|---|
| Март 2026 | Компания сделала свой аналог Jira со всем нужным функционалом и переехала на него |
| Июль 2026 | Та же (или похожая) компания вернулась к покупке трекера (Linear), потому что не захотели тащить свой продукт |
Это типичный сценарий эпохи вайб-кодинга: собрать за пару недель — легко, тащить дальше — невозможно.
Почему раньше не переписывали всё сами
Общее заблуждение: «раньше не могли, а теперь с ИИ смогли». Это неправда.
- Разработчики всегда могли написать любой сервис — руками, командой, за несколько месяцев.
- Не писали по одной причине: не хотели управлять этим сервисом дальше.
- Сам код — не проблема. Проблема начинается после первого пользователя.
Что ломается, как только у продукта появляются пользователи
Как только сервис живёт и масштабируется, на разработчиков сваливается:
- баги и регрессии;
- запросы на новые фичи;
- «что-то не так работает / не там работает / не сработало»;
- логи, мониторинг, дежурства;
- ответственность за аптайм.
Проект, который делался «чтобы сэкономить на подписке», превращается в отдельную постоянную работу с выделенными людьми и временем — ровно то, что делала компания-вендор, которой вы платили.
Ключевой парадокс: два бизнеса вместо одного
Если основной бизнес компании — например, «условный ChatGPT», а в фоне она тащит свой self-hosted трекер / логгер / что-то ещё, то она:
- либо переходит из одного бизнеса во второй,
- либо совмещает два IT-бизнеса в одном.
Плохо для всех:
| Кому плохо | Почему |
|---|---|
| Компании | Платит за один продукт, а команда пилит второй |
| Разработчику | Есть основная работа (ругают, если не сделал) + второстепенная (ругают, если не сделал) |
Личный кейс автора
- В его компании используют Datadog.
- Платят «буквально миллионы в год» за работу с логами и их хранение.
- Хотят заменить и уже разрабатывают свой аналог + присматриваются к более дешёвым альтернативам.
- Признаёт: в предыдущем ролике сказал, что «многие сервисы умрут из-за ИИ» — и был неправ.
Сквозные принципы
- Написание кода — не бутылочное горлышко. Никогда не было.
- Стоимость софта = стоимость поддержки, а не разработки.
- «Могу написать за неделю» ≠ «стоит писать». Между этими двумя утверждениями — годы саппорта.
- Внутренний сервис — это внутренний бизнес. Со своими SLA, дежурствами, багфиксами, roadmap.
- Вендор берёт деньги не за код, а за то, что снимает с вас операционную нагрузку.
Что делать: практический вывод автора
«Не пытайтесь переписать всё.»
Оценивать замену сторонних решений стоит по чек-листу:
- Размер зависимости. Небольшие библиотеки без развития — можно переписать.
- Требует ли дальнейшей поддержки? Если да — считайте это отдельным проектом.
- Какую операционную нагрузку добавит? Мониторинг, багфикс, дежурства, дев-время.
- Готов ли бизнес открывать второй IT-бизнес внутри себя?
Если ответы «да / много / нет» — оставайтесь на платном сервисе, даже имея под рукой Claude / Antigravity / Codex.
Кому это полезно
- Тимлидам и техлидам, которые под впечатлением от вайб-кодинга собираются «за спринт заменить Jira / Datadog / Sentry».
- Основателям стартапов, решающим build vs buy для инфраструктурных инструментов.
- Fullstack-разработчикам, прикидывающим себестоимость «своего маленького SaaS-клона».
- Инженерам, оценивающим ROI миграции с внешнего сервиса на in-house решение.