Модуль 6 · Урок 17 · ~10 минут

Как читать код, не читая код

Одна идея этого урока: чтобы оценить работу агента, не нужно читать каждую строку – сеньор оценивает структуру, поведение и симптомы, а детали делегирует инструментам.

Знакомая ситуация

Ты попросил агента добавить в телеграм-бот школы кнопку «Отменить запись». Агент отчитался: «Готово», а внизу отчёта – список из 14 изменённых файлов. Открываешь изменения и видишь стену кода. Читать всё? Ты не программист, и даже программист тут увязнет. Принять вслепую? Уже обжигался.

Кажется, что выбор такой: либо читать построчно, либо доверять на слово. Но это ложный выбор – у сеньоров давно есть третий путь.

Ревью кода (code review) – это не чтение строк, а проверка решений. Гайд Google прямо говорит: самое важное на ревью – дизайн изменения, его уместность и понятность, а не построчная вычитка. Это можно оценить, не читая код.

Сигналы тревоги, видимые без чтения кода

Эти симптомы заметны по одному только описанию изменения – по списку файлов, размеру и словам агента:

1
Изменение раздулось scope creepПросил мелочь – агент переписал полпроекта. Кнопка «Отменить запись» не должна трогать 14 файлов. Либо агент увлёкся, либо структура проекта больна (вспомни «изменение против шерсти» из урока 1).
2
Дубли похожей логики duplicationВ отчёте мелькает «добавил функцию отправки уведомления», а ты помнишь, что такая уже была. Два куска кода, делающих одно и то же, разъедутся при первой же правке.
3
«Магические» значения magic numbersВ коде появились голые числа и строки без имени: таймаут «86400», статус «3». Через месяц никто (включая агента) не вспомнит, что они значат.
4
Файл-гигантОдин файл разросся на сотни строк и притягивает каждое новое изменение. Это будущий центр запутанности: любая фича будет проходить через него.

Заметь: чтобы увидеть все четыре сигнала, не нужно понимать ни одной строки. Достаточно смотреть на размер, имена и повторы.

Три приёма неписьменного ревью

Твоё главное преимущество: исполнитель, написавший код, готов бесконечно отвечать на вопросы. Используй это:

1
Объяснение простым языком«Объясни, что ты изменил и почему, без технических терминов». Если объяснение путаное или длиннее самой задачи – это сигнал: решение, скорее всего, тоже путаное.
2
Вопрос «что может сломаться?»Заставляет агента перечислить рискованные места. Ответ «ничего» – плохой знак: значит, о рисках он не думал. Хороший ответ называет конкретные сценарии, которые можно проверить.
3
Самокритика self-review«Сделай ревью собственного кода как строгий сеньор». Агент в роли критика находит у себя дубли, раздутость и магические значения – то самое, что искал бы живой ревьюер. Саймон Уиллисон формулирует правило честно: проверять написанное LLM – твоя работа, но проверка не обязана быть построчной.

Как думают три уровня

ДжунСмотрит только «работает или нет»: прокликал фичу – принял. Структурные проблемы копятся невидимо, пока не рванёт.
МидлЧестно читает строки и вязнет в деталях: час на ревью, силы ушли на запятые, а раздутость изменения и дубль логики остались незамеченными – их не видно с высоты одной строки.
СеньорСначала оценивает дизайн: уместно ли изменение, не раздулось ли, понятны ли имена. Задаёт вопросы про риски. Детали делегирует инструментам – тестам, линтерам, самокритике агента.

Проверь себя

1. Ты попросил агента поправить текст письма-напоминания, а он отчитался: «Готово, заодно отрефакторил модуль рассылки и обновил работу с базой». Что сделает сеньор?

2. На вопрос «что может сломаться из-за этого изменения?» агент отвечает: «Ничего, я всё проверил». Как это читать?

3. У тебя 20 минут на приёмку большого изменения от агента. Как потратить их с максимальной пользой?

Что говорить агенту уже сегодня

Источники