all

raw/sources/А что если наВайб-Кодить.md

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