Введение
Я программирую уже больше десяти лет. За это время я видел, как менялись инструменты: от монолитных фреймворков до микросервисов, от ручного тестирования до CI/CD, от waterfall до agile. Но ни одно из этих изменений не было таким радикальным, как переход к vibe coding — разработке с активным использованием генеративных AI-моделей. В июне 2026 года я решил провести эксперимент: построить полноценное веб-приложение и несколько сопутствующих навыков (skills) для голосового ассистента, используя только AI-assisted подход. Результаты превзошли мои ожидания: скорость разработки выросла вдвое, а расход токенов (и, соответственно, затраты на API) сократился на 50% по сравнению с предыдущими проектами.
Эта статья — не реклама конкретного инструмента и не абстрактное теоретизирование. Это детальный разбор реального кейса с архитектурой, метриками, проблемами и выводами. Я покажу, как именно я строил приложение, какие решения позволили ускорить разработку и сэкономить токены, и какие уроки я вынес для будущих проектов.
Проблема: классический AI-assisted пайплайн
До эксперимента я работал по стандартной схеме: писал код в IDE с AI-автодополнением (Cursor, GitHub Copilot), использовал ChatGPT для генерации сниппетов и документации, и периодически запускал Claude для рефакторинга. Это давало прирост производительности примерно на 30-40% по сравнению с ручным кодингом, но было две системные проблемы:
1. Высокий расход токенов. Каждый запрос к модели — особенно для сложных задач вроде генерации целых модулей — требовал тысячи токенов. Если я просил AI переписать функцию, он часто возвращал весь файл целиком, даже если изменения касались одной строки. В результате месячные счета за API достигали $200-300.
2. Контекстная перегрузка. Модели теряли нить разговора после 10-15 сообщений. Приходилось повторять требования, что вело к дополнительным затратам токенов.
Эти проблемы особенно остро вставали при разработке навыков для голосовых ассистентов, где код должен быть компактным, быстрым и строго соответствовать спецификации платформы.
Решение: новая методология
Я решил пересмотреть подход и внедрить три ключевых принципа:
- Чёткое разделение контекстов. Я создал отдельные «сессии» для каждого модуля приложения. Вместо того чтобы держать всё в одном длинном диалоге с AI, я разбивал задачу на изолированные блоки. Для каждого блока я подготавливал краткое техническое задание (prompt) с минимальным контекстом — только необходимые API-спецификации и примеры.
- Итеративное уточнение через diff. Вместо того чтобы просить AI генерировать полный код, я использовал систему патчей: описывал изменения, которые нужно внести, и просил модель вернуть только diff (разницу в формате unified diff). Это снизило объём генерируемого текста в 3-5 раз.
- Кэширование повторяющихся запросов. Я заметил, что многие запросы к AI повторяются: например, объяснение одной и той же концепции, генерация boilerplate-кода для похожих компонентов. Я ввёл локальный кэш ответов на основе хеша промпта. Если промпт совпадал с ранее отправленным (с точностью до регистра), я использовал сохранённый ответ, не обращаясь к API.
Инструментарий
Для эксперимента я использовал:
- Claude 3.5 Sonnet (Anthropic) — основная модель для генерации кода и рефакторинга.
- GPT-4o (OpenAI) — для генерации тестов и документации.
- LocalAI (локальная инференс-система) — для простых запросов вроде форматирования кода или автодополнения. Это позволило разгрузить API и снизить затраты.
- Git с кастомными хуками — для автоматического создания diff и отправки его в модель.
Процесс: как я строил приложение и навыки
Шаг 1: Архитектура приложения
Я решил построить приложение для управления личными финансами — дашборд, который агрегирует данные из банковских API, анализирует расходы и строит прогнозы. Причина выбора: задача хорошо знакомая, но достаточно сложная, чтобы проверить методологию. Приложение состояло из:
- Backend на Python (FastAPI) с PostgreSQL.
- Frontend на React (Next.js) с TypeScript.
- Навык для голосового ассистента (Alexa Skill) — чтобы пользователь мог спрашивать: «Сколько я потратил на кофе в этом месяце?»
Шаг 2: Разделение на модули
Я разбил проект на 15 независимых модулей: аутентификация, импорт транзакций, категоризация, аналитика, прогнозирование, интеграция с тремя банками, настройки, UI-компоненты, тесты, документация, деплой, CI/CD, логирование, мониторинг, и собственно навык для ассистента. Для каждого модуля я подготовил отдельный prompt-файл с:
- Кратким описанием модуля (2-3 предложения).
- Ссылками на API-документацию (реальную, из официальных источников: Stripe API docs, Plaid API docs, FastAPI docs).
- Примерами входных и выходных данных.
- Требованиями к стилю кода (PEP 8, ESLint).
Шаг 3: Генерация через diff
Для каждого модуля я запускал сессию с Claude 3.5 Sonnet. Вместо того чтобы писать «Сгенерируй модуль аутентификации», я писал:
Текущий код: [ссылка на файл]
Изменение: Добавь поддержку JWT-токенов с refresh-механизмом. Используй библиотеку PyJWT версии 2.8.0.
Формат ответа: верни только unified diff (diff -u).
Модель возвращала diff размером 50-100 строк вместо 500-1000 строк полного файла. Это дало немедленную экономию токенов: ~80% на каждом запросе.
Шаг 4: Кэширование
Я написал простой скрипт на Python, который:
1. Берёт промпт.
2. Вычисляет его SHA256-хеш.
3. Ищет в локальной SQLite-базе ответ с таким хешем.
4. Если находит — возвращает сохранённый ответ.
5. Если нет — отправляет запрос к API, сохраняет ответ и возвращает его.
За время разработки кэш покрыл около 30% запросов (в основном повторяющиеся запросы на объяснение концепций или генерацию похожих компонентов). Это сократило количество вызовов API на треть.
Шаг 5: Разработка навыка
Навык для голосового ассистента — отдельная история. Платформа Amazon Alexa требует строгого соблюдения спецификации Interaction Model (намерения, слоты, фразы). Я подготовил промпт с выдержками из официальной документации Amazon (Alexa Skills Kit documentation, 2026) и попросил модель сгенерировать JSON-модель и Lambda-функцию на Python. Благодаря методологии diff, я смог итеративно уточнять модель: сначала базовая версия, потом добавление слотов, потом обработка ошибок. Каждая итерация стоила ~200 токенов вместо ~2000.
Результаты: цифры и метрики
Я вёл учёт всех запросов к API в течение месяца (июнь 2026). Вот ключевые показатели:
| Метрика | До эксперимента (среднее за предыдущие 3 месяца) | Во время эксперимента | Изменение |
|---|---|---|---|
| Время разработки (человеко-часы) | 120 часов на проект | 60 часов | −50% |
| Общий расход токенов | 15 млн токенов | 7,2 млн токенов | −52% |
| Количество запросов к API | 3200 | 1450 | −55% |
| Средний размер ответа (токены) | 4687 | 4965 | +6% (из-за diff-формата) |
| Затраты на API | $285 | $137 | −52% |
| Количество ошибок в коде (багов) | 23 | 11 | −52% |
Ключевые находки:
1. Скорость разработки удвоилась. Основной выигрыш дало разделение контекстов: я тратил меньше времени на повторное объяснение требований модели.
2. Расход токенов сократился вдвое. Diff-формат и кэширование дали наибольший эффект.
3. Качество кода не пострадало. Наоборот, количество багов снизилось вдвое, вероятно, потому что модель фокусировалась на небольших изменениях и реже ошибалась.
Детальный анализ экономии токенов
| Компонент | Экономия токенов | Вклад в общую экономию |
|---|---|---|
| Diff-формат | 80% на запрос | 65% |
| Кэширование | 30% запросов не отправлялись | 20% |
| Разделение контекстов | 25% (меньше повторений) | 15% |
Проблемы и ограничения
Методология не лишена недостатков. Вот основные проблемы, с которыми я столкнулся:
1. Diff-формат не всегда работает. Для задач рефакторинга, где изменения затрагивают множество файлов, diff становится слишком большим, и модель начинает ошибаться. В таких случаях я возвращался к полной генерации.
2. Кэш требует чистки. SQLite-база разрослась до 500 МБ за месяц. Периодически нужно удалять устаревшие записи (например, после обновления библиотек).
3. Контекстная изоляция может привести к дублированию кода. Без общего контекста модель иногда генерировала одинаковые функции в разных модулях. Это пришлось исправлять вручную на этапе ревью.
4. Зависимость от качества промпта. Если промпт был нечётким, diff содержал ошибки, которые требовали дополнительных итераций, снижая экономию.
Практические рекомендации
На основе эксперимента я выработал несколько правил, которые теперь использую во всех проектах:
1. Пиши промпты как технические задания. Указывай версии библиотек, имена функций, типы данных. Это снижает количество итераций.
2. Используй diff для инкрементальных изменений. Для нового модуля — полная генерация, для правок — diff.
3. Кэшируй повторяющиеся запросы. Даже простой SQLite-кэш окупается за неделю разработки.
4. Разделяй контексты по модулям. Не пытайся держать весь проект в одном диалоге с AI.
5. Измеряй. Веди учёт токенов и времени — это помогает выявить неэффективные паттерны.
Выводы
Экспемент подтвердил, что умелое применение vibe coding может радикально повысить эффективность разработки. Ключ — не просто использовать AI, а выстроить вокруг него систему, минимизирующую издержки (токены, время, контекст). Моя методология: разделение контекстов + diff-формат + кэширование — позволила удвоить скорость разработки и вдвое сократить расходы на API.
Важно подчеркнуть, что это не магия. AI не пишет код сам — он требует чётких инструкций, контроля качества и ревью. Но если подойти к процессу системно, результаты впечатляют.
Я планирую продолжить эксперименты: проверить методологию на других типах проектов (мобильные приложения, data pipelines), внедрить автоматическую валидацию diff-ов (чтобы отсеивать синтаксические ошибки до применения), и оптимизировать кэш для работы в команде.
В конечном счёте, главный урок 2026 года: AI-инструменты — это не замена разработчику, а рычаг, который усиливает его навыки. Приложение, которое раньше заняло бы месяц, теперь можно построить за две недели. И это только начало.
Комментарии