Мы перевели разработку в Claude Projects и получили +40% к скорости. А потом потеряли всё на третьей неделе — разбор по дням с метриками
Четыре недели, три разработчика, один AI-инструмент — и падение качества на 33% к середине эксперимента. Вот что мы поняли о реальных границах AI-воркфлоу в продуктовой разработке.
Зачем мы вообще это затеяли
У нас внутренний продукт на стадии активной разработки, команда 2–3 человека. Задачи типичные: брифинг на фичи, документация, код-ревью, генерация тестов. Каждая из этих задач съедает время не столько на исполнение, сколько на передачу контекста — объяснить, что мы уже решили, какие ограничения, какой стиль.
Гипотеза была простой: если загрузить в Claude Projects всю документацию проекта — архитектуру, гайды, глоссарий, историю решений — модель станет «членом команды», который всегда в контексте. Ожидали сокращение времени минимум на 30%.
Важный нюанс: Claude Projects — это веб-интерфейс с персистентной базой знаний и загруженными документами. Не Claude Code (CLI-агент для работы с кодовой базой из терминала). Русскоязычное сообщество постоянно путает эти инструменты, а их ограничения принципиально разные.
Что загрузили в shared context
Мы подготовили модульную базу знаний:
- Архитектурный документ — стек, структура модулей, принципы именования (~3K токенов)
- Гайд по стилю кода — паттерны и антипаттерны (~2K токенов)
- Глоссарий проекта — термины предметной области (~1K токенов)
- Текущие задачи и приоритеты (~2K токенов)
- Changelog решений — «почему выбрали X, а не Y» (~4K токенов)
Итого около 12K токенов из доступных 200K. Казалось, запас колоссальный. На практике рабочих токенов — 160–180K, остальное уходит на системный оверхед. Но даже это выглядело более чем достаточно.
Первые две недели: цифры, от которых кружится голова
Результаты превзошли ожидания. Вот конкретные замеры:
Брифинг разработчика сократился с 40–60 минут до 10–15: вместо созвона загружаешь ТЗ в Project, и модель выдаёт структурированный план. Ревью документации ускорилось втрое — модель находила несоответствия между разделами, которые человек пропускал на третьем прочтении.
Соблюдение наших правил в первых 2–3 сообщениях — выше 95%. Модель точно следовала системному промпту, помнила архитектурные решения, выдерживала стиль.
В пересчёте на деньги: при средней ставке разработчика 3000–4000 руб/час экономия составляла 15–20 часов в неделю на команду. Это ощутимо.
День 8–10: первые тревожные звонки
На исходе второй недели заметили паттерн: в длинных диалогах (6–10 сообщений) модель начала «забывать» наши конвенции. Переменные, которые по гайду должны быть в snake_case, появлялись в camelCase.
Это не случайность. По данным из открытых исследований, соблюдение кастомных правил падает с 95%+ на первых сообщениях до 20–60% к шестому-десятому. Оригинальные инструкции из системного промпта фактически «вымываются» новым контекстом.
Мы списали это на длину диалогов и стали чаще начинать новые сессии. Помогло — но временно.
Неделя 3: каскадный отказ
Здесь начался системный сбой, и он развивался стремительно.
День 15. Claude предложил архитектурное решение, которое мы обсудили и отклонили на первой неделе. В том же Project лежал документ с записью «Вариант Б отклонён, причина: ...». Модель его не проигнорировала намеренно — она просто «не увидела» в контексте длинного диалога.
День 17. Два члена команды работали в одном Project параллельно. Один попросил сгенерировать API-эндпоинт в определённом стиле. Второй — в другом диалоге — получил эндпоинт в совершенно другом стиле. Оказалось, разговоры внутри Project изолированы друг от друга: персистентны только загруженные документы, а не история диалогов. Фундаментальное ограничение, которое мы не учли.
День 19. Модель начала генерировать код с багом, который мы исправили неделей ранее. Классическая регрессия — Claude «откатился» к паттерну из обучающих данных, проигнорировав наш зафиксированный фикс.
День 20. Документация деградировала: модель смешивала терминологию из разных частей проекта, путала названия модулей, выдавала внутренне противоречивые описания.
Метрики третьей недели рисуют однозначную картину:
Выигрыш по скорости полностью съедался временем на проверку и переделку. Чистый эффект — около нуля.
Эффект Даннинга-Крюгера для AI-воркфлоу
Здесь важен контекст шире нашего эксперимента. Исследование METR на 246 GitHub-задачах с 16 опытными разработчиками показало парадокс: AI-ассистенты замедлили работу на 19%, хотя разработчики субъективно оценивали ускорение в 20%. Разрыв восприятия — 39 процентных пунктов.
Мы наблюдали тот же эффект. На третьей неделе казалось, что Claude помогает — ответы приходили быстро, выглядели уверенно. Но фактическое время от задачи до готового результата почти не отличалось от работы без AI. Время просто перераспределилось: меньше на написание, больше на верификацию.
Для CTO и продакт-менеджеров это ключевой вывод: нельзя оценивать эффективность AI-инструмента по ощущениям команды. Нужны объективные замеры end-to-end времени.
Что реально работает, а что нет
После четырёх недель у нас сложилась чёткая карта применимости.
Claude Projects отлично справляется с:
- Генерация вариантов — 5 подходов к решению за 3 минуты вместо 30
- Первичная документация — черновики API-документации, README (при верификации человеком)
- Онбординг — новый участник загружает контекст и задаёт вопросы быстрее, чем через wiki
- Шаблонные задачи — CRUD-эндпоинты, типовые тесты, миграции по образцу
- Код-ревью в рамках одной короткой сессии
Claude Projects не справляется с:
- Поддержание единого стиля в проекте длительностью 2+ недели — контекстный дрейф это убивает
- Многоуровневая бизнес-логика — модель путает граф зависимостей между модулями
- Командная работа 3+ человек — изоляция диалогов делает решения одного разработчика невидимыми для другого
- Задачи, требующие памяти о решениях двухнедельной давности
- Рефакторинг с сохранением обратной совместимости — модель не отслеживает внешние зависимости
Как мы починили воркфлоу: протокол четвёртой недели
Три конкретных изменения, которые вернули продуктивность.
1. Жёсткий лимит сессии — 4–5 сообщений. После этого — новая сессия с summary prompt. Шаблон:
«Контекст проекта — в загруженных документах. Текущая задача: [описание]. Решения, принятые ранее: [список с обоснованиями]. Ограничения: [что НЕ делать и почему].»
Занимает 200–400 токенов, экономит часы на исправление дрейфа.
2. Ротация контекстных документов. Вместо одного большого архитектурного документа — модульная структура. Работаешь с API — загружай гайд по API, а не весь архитектурный документ. Меньше шума — выше точность.
3. Человек в петле на всех критических решениях. Claude генерирует варианты, человек выбирает, выбор фиксируется в changelog. Никаких автономных архитектурных решений.
Результаты после внедрения протокола:
Не вернулись к эйфории первой недели, но вышли на устойчивый, воспроизводимый уровень.
Итоговая картина: четыре недели одним взглядом
Устойчивый выигрыш — около 25% при соблюдении протокола. Не 40%, как в медовый месяц, но стабильно и предсказуемо.
Кому стоит пробовать, а кому — подождать
Пробуйте, если:
- Проект до 2 недель активной фазы — контекст не успевает деградировать
- Команда 1–2 человека — меньше конфликтов в shared context
- Есть задачи с повторяющейся структурой и чёткими шаблонами
- Готовы инвестировать время в протокол управления сессиями
Подождите, если:
- Долгосрочная разработка на месяцы без выстроенной дисциплины контекста
- Команда 4+ человек с параллельной работой
- Сложная бизнес-логика с неочевидными зависимостями между модулями
Claude Projects — мощный инструмент с измеримым потолком. Этот потолок предсказуем и частично обходим. Но только если ты знаешь, где он находится, до того как врежешься.
Три правила, которые мы вынесли:
- Лимит сессии — 4–5 сообщений, затем сброс с summary prompt
- Модульный контекст — загружай только релевантное для текущей задачи
- Человек принимает все архитектурные решения, AI генерирует варианты
Если у вас есть опыт долгосрочной работы с AI-инструментами в разработке (3+ недели с метриками) — делитесь в комментариях. Собираем реальные кейсы для следующего исследования.
Подписывайся на Телеграм Вайблаб, чтобы наблюдать за тем, как мы строим AI-first компанию.
Напишите нам напрямую