Первое, с чем сталкивается инженер на новом проекте, — незнакомый код: сотни файлов, чужие решения, ноль контекста. Раньше на это уходили недели. Агент, который умеет читать репозиторий, сокращает это до часов — но только если пользоваться им правильно, а не просить «объясни весь проект».

Идти сверху вниз

Не начинайте с деталей. Просите агента строить понимание слоями, от общего к частному:

  1. Карта проекта. «Опиши структуру: какие модули есть, за что каждый отвечает, где точки входа». Это даёт скелет.
  2. Ключевые потоки. «Проследи путь запроса на создание заказа: от контроллера до базы, какие классы участвуют». Так вы видите, как части соединяются.
  3. Конкретный кусок. «Разбери, что делает этот метод и кто его вызывает». Теперь у вас есть, куда это встроить.

Такой порядок повторяет здоровое погружение в проект: сначала карта, потом маршруты, потом дом. Обратный порядок (сразу в детали) оставляет вас с фрагментами без картины.

Задавать вопросы, а не только «объясни»

Агент полезнее всего не как рассказчик, а как отвечающий на конкретные вопросы:

  • «Где обрабатывается отмена заказа?»
  • «Что произойдёт, если сюда придёт пустой список?»
  • «Кто меняет статус заказа и в каких местах?»
  • «Почему здесь два разных способа делать одно и то же?»

Эти вопросы — то же, что вы задали бы коллеге, знающему проект. Разница в том, что агент отвечает за секунды и не устаёт от «глупых» вопросов.

Проверять ответы по коду

Ключевое предостережение: агент может уверенно ошибиться. Он способен пересказать логику, которой нет, или пропустить ветку. Поэтому:

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

Агент, читающий код напрямую (через инструменты — поиск, чтение файлов), надёжнее, чем модель, отвечающая «из головы»: он опирается на настоящий код, а не на догадку.

Где это особенно выручает

  • Унаследованный код без документации — агент читает то, что никто не описал.
  • Быстрое погружение — новый человек за день понимает то, на что уходила неделя.
  • Локализация проблемы — «в каком месте формируется эта сумма?» вместо ручного грепа по всему репозиторию.
  • Перед изменением — «что я задену, если поменяю этот метод?» снижает риск сломать соседнее.

Что это значит на практике

Агент превращает чужую кодовую базу из стены в карту, по которой можно задавать вопросы. Продукт-инженер использует его, чтобы за часы получить картину, ранее стоившую недель, — но проверяет ключевые ответы по самому коду, потому что уверенный пересказ и правда — не одно и то же. Понял систему → можешь осознанно её менять.

Дальше

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