Павел Булкин – Вайб-кодинг. Практический курс (страница 7)

• изменение в одном файле необъяснимо ломает другой модуль;

• нужно провести ревью перед доработкой, а не доработать вслепую.

Во всех этих случаях цель — не изменить код, а снизить неопределённость перед тем, как его менять. Это отдельная фаза работы, и смешивать её с генерацией нельзя.

Плохой подход: «объясни мне весь проект»

Первое, что хочется сделать в незнакомом проекте, — попросить:

Объясни мне весь проект.

Звучит разумно, а на деле это худший возможный запрос. Почему:

• слишком широко — агент не сможет быть конкретным;

• он будет обобщать — выдаст правдоподобное описание «типичного проекта», а не вашего;

• появятся галлюцинации — на широком вопросе модель додумывает связи, которых нет;

• результат невозможно проверить — вы не отличите правду от выдумки, потому что сами проект ещё не знаете.

Широкий вопрос даёт широкий, гладкий и непроверяемый ответ. А непроверяемый ответ в археологии хуже, чем отсутствие ответа: он создаёт ложную уверенность.

Хороший подход: ограниченный анализ

Сузьте область до одного модуля и потребуйте конкретики со ссылками на файлы:

Проанализируй только модуль tasks.

Код не менять.

Выведи:

1. какие файлы участвуют в создании задачи;

2. где проверяются права доступа;

3. где находится бизнес-логика;

4. какие зависимости есть у модуля;

5. какие места выглядят рискованными;

6. какие утверждения ты можешь подтвердить ссылкой на файл.

Два пункта здесь — несущие. Код не менять отделяет фазу понимания от фазы изменений: в археологии агент только читает. А шестой пункт — какие утверждения ты можешь подтвердить ссылкой на файл — превращает рассказ в проверяемый отчёт. Если агент пишет «права проверяются в TasksService», он обязан указать файл и строки. Нет ссылки — нет факта, есть предположение.

ГЛАВНЫЙ ПРИЁМ АРХЕОЛОГИИ

Не «расскажи мне», а «покажи, где». Любое утверждение агента о коде должно опираться на конкретный файл и место в нём. Ссылка — это то, что вы можете открыть и проверить за десять секунд.

Карта модуля: MODULE_MAP_TASKS.md

Результат анализа читатель оформляет в артефакт — карту модуля. Это не пересказ кода, а структурированная схема: что где живёт, как течут данные, где слабые места. Шаблон:

# MODULE_MAP_TASKS.md

## Назначение модуля

## Основные файлы

## Поток данных

## Где создаётся задача

## Где проверяются права

## Где пишутся данные в БД

## Зависимости

## Потенциальные риски

## Что неясно

## Что нужно уточнить у человека

Обратите внимание на два последних раздела — Что неясно и Что нужно уточнить у человека. В обычном пересказе их нет, и зря: именно они отличают честную карту от красивой галлюцинации. Карта без зон неизвестности почти всегда означает, что агент чего-то недопонял и закрасил пробел догадкой.

Ловушка: убедительные галлюцинации

Вот парадокс глубокого контекста, который нужно прочувствовать на собственной шкуре:

ЗАПОМНИТЕ

Чем больше контекста видит агент, тем убедительнее его ошибки. Глубокий анализ делает выдумку правдоподобной: модель ссылается на реальные имена классов и складывает их в связную, но неверную картину.

Разберём на конкретном примере. Агент уверенно заявляет:

Права доступа проверяются в TasksService.

Звучит логично — бизнес-логика и должна быть в сервисе. Но прежде чем записать это в карту, проверьте четыре вещи:

Файл существует? Откройте tasks.service.ts. Он вообще есть, и так ли он называется?

Проверка реально там? Найдите в файле собственно проверку роли. Может оказаться, что её там нет — она в guard'е или в контроллере.

Нет ли дублирования? Частая беда: проверка прав размазана и по контроллеру, и по сервису. Тогда «проверяется в сервисе» — полуправда.

Реальная архитектура или желаемая? Это главный вопрос. Агент мог описать, как права должны проверяться по канону, а не как они проверяются на самом деле.

Четвёртый пункт — суть всей главы. Модель обучена на «правильных» проектах, поэтому она охотно описывает идеальную архитектуру и выдаёт её за вашу. Ваша работа — ловить подмену «как есть» на «как принято».

Правила работы с глубоким контекстом

ЧЕТЫРЕ ПРАВИЛА АРХЕОЛОГА

• просите файлы и строки;

• отделяйте факты от предположений;

• требуйте список «не уверен»;

• анализ не должен менять код.

Финальный запрос: карта с разметкой достоверности

Собрав анализ, попросите агента оформить карту так, чтобы каждый вывод был помечен по уровню достоверности. Это превращает карту из «мнения ИИ» в рабочий документ, с которым можно идти к команде:

На основе анализа модуля tasks создай MODULE_MAP_TASKS.md.

Раздели выводы на четыре категории:

- подтверждено кодом (со ссылкой на файл);

- предположение;

- риск;