Vibe Testing: лови баги в ТЗ до первой строчки кода

Почему ТЗ ломает проекты, а не строит их

Ты знаешь эту историю. Команда потратила три недели на разработку. Фича готова, тесты проходят, код чистый. Показываешь продукт заказчику, а он смотрит как на инопланетянина: "Я не это имел в виду". Ты открываешь ТЗ, перечитываешь третий раз и понимашь: там нет ни слова про этот кейс. Или есть, но формулировка такая, что её можно трактовать четырьмя разными способами.

Проблема не в разработчиках. Не в тестировщиках. Проблема в том, что мы тестируем код, но не тестируем требования. А требования - это самый дорогой баг. Чем позже его найдешь, тем дороже фикс.

Что такое Vibe Testing и почему это не "просто промпт"

Vibe Testing - это методология анализа документов с помощью LLM. Не просто "прочитай и скажи, что думаешь". Это системный подход, где модель играет роль скептического рецензента, который ищет:

• Противоречия между разделами
• Неопределенные формулировки ("быстро", "удобно", "современный")
• Пропущенные edge cases
• Техническую нереализуемость требований
• Конфликты с существующей системой

Название "Vibe" появилось не просто так. Речь идет о проверке "ощущения" документа. Читаешь ТЗ и чувствуешь, что что-то не так, но не можешь сформулировать? LLM помогает это сформулировать.

Реальный кейс: 15 документов, одна платежная система

Недавно я анализировал спецификацию для платежного шлюза. 15 документов: API документация, требования к безопасности, SLA, интеграционные гайды. В теории все идеально. На практике - катастрофа.

Запустил Vibe Testing через Claude 3.7 Sonnet (последняя версия на 01.02.2026, кстати, с улучшенным контекстом в 200K токенов). Через 20 минут получил отчет на 8 страниц. Вот что нашлось:

Это не гипотетические проблемы. Каждая из них стоила бы команде минимум неделю работы и нервов. А нашли их до написания первой строчки кода.

Как настроить Vibe Testing: пошаговый план

1 Выбери правильную модель

Не все LLM одинаково полезны для анализа документов. На 01.02.2026 я рекомендую:

• Claude 3.7 Sonnet - лучший баланс цены и качества для длинных документов (200K контекст)
• GPT-4.5 Turbo - если нужна максимальная точность, несмотря на цену
• DeepSeek Coder V3 - для технических спецификаций с кусками кода (бесплатно, кстати)

2 Подготовь промпт-скелет

Худшее, что можно сделать - скормить документ со словами "проанализируй". Модель начнет пересказывать содержание. Тебе нужна структурированная атака.

# Базовый промпт для Vibe Testing
vibe_prompt_template = """
Ты - senior технический рецензент с 15-летним опытом.
Анализируешь документ: {document_name}

Твои задачи:
1. Найди внутренние противоречия (разные числа, условия, требования в разных разделах)
2. Выяви неопределенные формулировки (слова без количественных метрик)
3. Определи пропущенные edge cases для каждой функциональности
4. Проверь техническую реализуемость каждого требования
5. Оцени согласованность с общим контекстом системы

Формат ответа:
- Категория проблемы
- Цитата из документа
- Почему это проблема
- Предложение по исправлению
- Уровень критичности (блокер/высокий/средний/низкий)

Документ:
{document_content}
"""

3 Настрой цепочку промптов

Один промпт не справится. Нужна цепочка (prompt chaining):

1. Первичный анализ на противоречия
2. Глубокий анализ каждого раздела
3. Проверка cross-reference между документами
4. Генерация тестовых сценариев для найденных дыр

Вот как это выглядит на практике для API спецификации:

# Цепочка промптов для API документации
prompt_chain = [
    {
        "role": "system",
        "content": "Ты анализируешь OpenAPI спецификацию. Найди endpoints без описания error responses."
    },
    {
        "role": "user", 
        "content": openapi_spec
    },
    # Второй промпт в цепочке
    {
        "role": "system",
        "content": "Для каждого найденного endpoint сгенерируй вероятные error cases."
    }
]

4 Автоматизируй процесс

Ручной запуск промптов - путь в никуда. Настрой автоматизацию:

• Git hook на изменение .md файлов в docs/
• Ежедневный анализ новых коммитов в документации
• Интеграция с Confluence/Notion через API
• Автоматические отчеты в Slack/Jira

#!/bin/bash
# Пример git hook для Vibe Testing

# Анализируем измененные .md файлы
CHANGED_DOCS=$(git diff --name-only HEAD HEAD~1 | grep '\.md$')

for doc in $CHANGED_DOCS; do
    echo "Анализирую $doc..."
    
    # Получаем содержимое
    CONTENT=$(cat "$doc")
    
    # Запускаем анализ через LLM API
    RESPONSE=$(curl -X POST https://api.anthropic.com/v1/messages \
        -H "Content-Type: application/json" \
        -H "x-api-key: $ANTHROPIC_API_KEY" \
        -d "{\"model\": \"claude-3-7-sonnet-20250226\", \"messages\": [{\"role\": \"user\", \"content\": \"$vibe_prompt_template\"}]}")
    
    # Парсим и сохраняем результат
    echo "$RESPONSE" > "reports/$(basename "$doc").json"
    
    # Если найдены блокеры - останавливаем коммит
    if echo "$RESPONSE" | grep -q '"уровень": "блокер"'; then
        echo "Найден блокер в $doc! Коммит отменен."
        exit 1
    fi
done

Типичные ошибки и как их избежать

Ошибка 1: Слишком общий промпт

Как делают: "Проанализируй этот документ и найди проблемы"

Что получают: Общие фразы вроде "документ хорошо структурирован, но можно улучшить"

Как делать: Давай конкретные категории для поиска. Модель не умеет читать мысли.

Ошибка 2: Игнорирование контекста

LLM анализирует документ в вакууме. Если в ТЗ написано "интегрироваться с LegacySystem", модель не знает, что LegacySystem - это монолит на COBOL с API 1998 года.

Ошибка 3: Слепая вера в LLM

Модель может галлюцинировать. Найти "противоречие", которого нет. Пропустить реальную проблему.

Проверяй каждую найденную проблему. Особенно "блокеры". LLM - это инструмент, а не истина в последней инстанции.

Интеграция с существующими процессами

Vibe Testing не заменяет людей. Он усиливает их. Вот как встроить его в workflow:

Промпты, которые работают прямо сейчас

Бери и используй. Проверено на реальных проектах.

Для поиска неопределенностей

prompt_find_vague = """
Найди в тексте все формулировки, которые нельзя измерить количественно.
Для каждой:
1. Цитата
2. Почему это проблема (как можно трактовать по-разному)
3. Предложение по замене на измеримый критерий

Примеры плохих формулировок:
- "быстрый отклик" → заменить на "отклик < 200мс в 95% случаев"
- "удобный интерфейс" → заменить на "основные действия выполняются за ≤3 клика"
- "надежная система" → заменить на "uptime ≥99.9%, MTTR ≤1 час"
"""

Для проверки полноты API спецификации

prompt_api_completeness = """
Проверь OpenAPI спецификацию на полноту.
Для каждого endpoint проверь наличие:
1. Всех возможных HTTP статусов (включая 4xx, 5xx)
2. Описания всех query/path/body параметров
3. Примеров запросов и ответов
4. Описания авторизации (если требуется)
5. Ограничений rate limiting

Сгенерируй список отсутствующих элементов с приоритетами.
"""

Для анализа бизнес-логики

prompt_business_logic = """
Проанализируй описание бизнес-процесса.
Найди:
1. Пропущенные альтернативные потоки (что если пользователь отменит? что если система упадет?)
2. Неявные допущения (предположения, которые не задокументированы, но подразумеваются)
3. Конфликты правил (правило A говорит X, правило B говорит Y для одного сценария)

Представь себя злонамеренным тестировщиком. Как можно сломать этот процесс?
"""

Что дальше? Vibe Testing 2.0

Текущий подход уже экономит сотни часов. Но это только начало. Вот что появляется на горизонте:

• Мультимодальный анализ - LLM проверяет не только текст, но и диаграммы, мокапы, архитектурные схемы. Находит несоответствия между визуалом и текстом.
• Семантическое сравнение версий - автоматическое определение, какие изменения в ТЗ ломают backward compatibility.
• Генерация тестов из требований - не просто поиск дыр, а автоматическое создание тест-кейсов для найденных сценариев.
• Интеграция с мониторингом - сравнение реального поведения системы с документацией, автоматические алерты при расхождении.

Самое интересное - это семантическое заземление. Модели учатся понимать не просто слова, а реальные ограничения мира. Когда LLM будет знать, что "обработать платеж за 1мс" физически невозможно из-за скорости света в оптоволокне - вот тогда начнется настоящая магия.

Начни сегодня

Не жди идеального момента. Возьми текущее ТЗ, скорми его Claude или GPT с промптом выше. Первые результаты увидишь через 10 минут.

Самый частый вопрос: "А сколько это стоит?". На 01.02.2026 анализ 100-страничного ТЗ через Claude 3.7 Sonnet стоит около $2-3. Одна найденная на этапе требований ошибка экономит $5000. Математика простая.

Vibe Testing - это не про замену аналитиков. Это про то, чтобы дать им суперсилу. Силу видеть сквозь текст. Находить то, что спрятано между строк. И останавливать катастрофы до того, как они стали катастрофами.

Попробуй. Первый баг в ТЗ, найденный LLM, вызывает тот же восторг, что и первая успешная сборка после недели дебага. Только без недели дебага.