Журналист The Register описал эксперимент: за семь недель и 337 коммитов он собрал коммерческий RSS‑сервис, полагаясь на Claude Code. История показала и сильные стороны ИИ‑помощников, и типичные ловушки — от забытых ограничений до путаницы окружений.
Обозреватель The Register Томас Клабёрн поделился результатами личного эксперимента: за семь недель и 337 коммитов он собрал коммерческий хостируемый RSS‑сервис RSScal, активно используя Claude Code. По его оценке, «билет» в эксперимент оказался на удивление низким: $40 за подписку Claude (либо около $200 при пересчёте в токены) плюс $14 в месяц за небольшой VPS для хостинга.
Почему эта история зацепила разработчиков
В центре внимания — не столько сам RSS‑сервис, сколько вывод: подход, который ещё недавно воспринимали как полушутливый «вайб‑кодинг», стал давать практический результат. Клабёрн формулирует это резко: «вайб‑кодинг работает», хотя ему самому это ощущение не нравится.
Важно уточнение: автор не «вошёл с улицы». Он кодит с начала 1980‑х и раньше уже делал RSS‑читалку вручную — сначала как приложение на Electron (Vulture Feeds), затем переписал проект под названием RSSputin. Этот опыт помог ему точнее формулировать запросы к модели и замечать, где ИИ уверенно «галлюцинирует» архитектурно.
Что именно он собрал и на каком стеке
Клабёрн подчёркивает, что новую версию делал на технологиях, с которыми раньше «не дружил» достаточно плотно. В проекте использовались:
- Docker‑контейнеры для упаковки и запуска сервисов;
- Python + FastAPI на бэкенде;
- Celery для фоновых задач;
- Redis как очередь/кэш в связке с фоновыми задачами;
- PostgreSQL через Supabase;
- SvelteKit и Tailwind CSS на фронтенде.
Смысл набора понятен даже тем, кто не следит за трендами: это типичная «модульная» схема для небольшого SaaS — быстро стартовать, отдельно масштабировать части, а критичные данные держать в привычной базе.
Где ИИ помог, а где подставил
По описанию автора, модель одновременно проявляла себя как «очень компетентная» и «абсолютно беспомощная» — и это не художественный образ, а рабочее ощущение от итераций. Среди конкретных сбоев он упоминает:
- путаницу между production и development сборками;
- пропуски базовых вещей уровня rate limiting (ограничения запросов), без которых публичный сервис быстро становится уязвимым для злоупотреблений;
- при этом — периодические удачные дизайн‑решения, которые ИИ предлагал неожиданно и без прямого запроса.
То есть ИИ‑помощник ускорял движение, но не заменял ответственности: решение «можно ли это выпускать в интернет» всё равно остаётся на человеке, особенно в вопросах безопасности и эксплуатационной надёжности.
Практический вывод: «дёшево собрать» ≠ «дёшево поддерживать»
Один из главных выводов Клабёрна касается рынка: если конкурент простому SaaS‑продукту можно поднять за месяц‑два и цену подписки на ИИ‑инструмент, давление на студии с шаблонными решениями и на мелкие фриланс‑услуги будет расти.
Но вторая часть вывода звучит ещё приземлённее: сделать «каркас» стало проще, а вот довести до ума — тестами, мониторингом, ограничениями, обновлениями и поддержкой пользователей — по‑прежнему сложно. Это та зона, где «сгенерированный код» чаще всего требует дисциплины, а не вдохновения.
Что это значит для обычных команд и одиночных разработчиков
История полезна как ориентир: ИИ‑кодинг действительно может ускорить старт, но лучше всего работает, когда человек держит в голове требования и проверяет результат. На практике это обычно выглядит так:
- сначала фиксируются сценарии («что должен уметь сервис»), а уже потом просится код;
- в каждом релизе отдельно проверяются безопасность и «гигиена» (валидация данных, лимиты, логирование);
- разворачивания в тесте и в проде разделяются максимально жёстко, чтобы случайно не «перепутать кнопку»;
- принцип «доверяй, но проверяй» применяется ко всему, что сгенерировано моделью.
Эксперимент Клабёрна показывает: ИИ‑ассистенты уже не только про прототипы — они могут помогать доводить продукт до рабочей версии. Однако цена успеха по‑прежнему измеряется внимательностью человека, который выпускает код в реальный мир.
