Код с AI-ассистентом: ревью и тесты — урок L3.9

Coding-ассистенты и агенты пишут код быстро. Отвечаете за код вы. Правило курса: можете объяснить каждую строку — можно сдавать. Не можете — критическая ошибка CE-03, даже если код работает.

Как работать с ассистентом:

Сначала сами формулируете, что должен делать код и как вы проверите, что он это делает (тест или пример входа и выхода).
Ассистент генерирует. Вы читаете код целиком, а не только запускаете.
Проверяете на краевых случаях: пустой вход, ошибка сети, неожиданный формат, большой объём.
Пишете или просите тесты, но проверяете, что тест действительно падает на сломанном коде. Тест, который проходит всегда, ничего не проверяет.

Что ассистенты пропускают чаще всего: обработку ошибок (особенно сетевых), таймауты, кодировки, утечку секретов в логи, SQL через склейку строк, except: без типа, устаревшие API библиотек (модель училась на старой документации).

pytest — минимум (PROG-07·F):

# tests/test_extract.py
import pytest
from filter_assistant.extract import normalize_order_id

@pytest.mark.parametrize("raw, expected", [
    ("№ 12345", "12345"),
    ("заказ 12-345", "12345"),
    ("", None),
])
def test_normalize_order_id(raw, expected):
    assert normalize_order_id(raw) == expected

Запуск: pytest -q. Тесты, которые требуют модели, используют echo-провайдер или подмену клиента: тесты должны проходить без сети и без денег.

Практикум

Лаба: ревью сгенерированного кода

Цель

Научиться пользоваться ассистентом для кода так, чтобы отвечать за результат: проверять сгенерированное ревью и тестами, а не тем, что «на одном примере работает».

Правила AI-assisted разработки

Вы — автор. Код, который вы закоммитили, — ваш, кто бы его ни написал. Не понимаете строку — не коммитьте её.
Сначала требования, потом код. Запишите, что функция должна делать, включая краевые случаи. Это и промпт, и чек-лист ревью.
Тесты — ваши. Попросить ассистента «написать тесты к своему же коду» — проверить ответ его же глазами: тесты повторят его ошибки. Хотя бы ключевые тесты пишите от требований сами.
Опасные конструкции — стоп-сигнал: eval/exec, except: без типа, shell=True, секреты в коде, SQL через склейку строк, отключённая проверка сертификатов.
Ассистент ничего не знает о вашем проекте, если вы не дали контекст: версии библиотек, соглашения, ограничения. Вымышленные функции и устаревший API — частая ошибка (пример: код под SDK mcp v1 на проекте с v2 — L7.6).

Шаги

1. Ревью без запуска (1,5 ч)

Откройте generated_orders.py. Запрос к ассистенту записан в docstring. Прочитайте код построчно и сверьте с запросом. Найдите минимум три дефекта. Для каждого запишите:

строку;
что не так и почему это проблема (корректность, безопасность, требование);
как бы вы это заметили без ревью — какой симптом увидит пользователь.

2. Тесты от требований (2 ч)

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

pytest -q test_orders.py   # на коде ассистента — красные

3. Исправление (1,5 ч)

Исправьте код так, чтобы все тесты стали зелёными, и объясните каждое изменение. Можно снова попросить ассистента, но с вашими тестами и списком дефектов в промпте — и снова провести ревью результата.

4. Рефлексия (1 ч)

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

Definition of Done

[ ] Найдены и описаны ≥ 3 дефекта со строкой, причиной и симптомом.
[ ] Тесты от требований: на коде ассистента краснеют, каждый ловит свой дефект.
[ ] Исправленный код проходит тесты; каждое изменение объяснено.
[ ] Рефлексия с улучшенным промптом.

Квиз 2 (L3.5–L3.9)

10 вопросов, зачёт — 7.

Ассистент даёт странные ответы про гарантию. В базе текст «Гаран тия 24 ме сяца». Какой слой системы виноват в первую очередь?
- а) модель
- б) извлечение и нормализация текста (ingestion)
- в) промпт
- г) эмбеддинги
Зачем хранить хеш содержимого документа в метаданных?
- а) для шифрования
- б) этого требует SQLite
- в) так быстрее поиск
- г) чтобы не обрабатывать повторно неизменённые документы и замечать изменения
Как правильно передать имя файла в SQL-запрос?
- а) f-строкой
- б) конкатенацией
- в) через eval
- г) параметром запроса (?)
Почему запросы и документы нужно кодировать одной и той же моделью эмбеддингов?
- а) так дешевле
- б) векторы разных моделей лежат в разных пространствах и несравнимы
- в) так требует NumPy
- г) это не обязательно при одинаковой размерности
Какой запрос эмбеддинг-поиск найдёт хуже всего?
- а) «вода пахнет странно»
- б) «артикул АК-3/2025»
- в) «как ухаживать за фильтром»
- г) «сколько служит картридж»
Что измеряет hit@5?
- а) скорость поиска
- б) долю запросов, где хотя бы один релевантный документ в первых 5 результатах
- в) точность ответа модели
- г) число документов в базе
На golden set из 20 кейсов версия A дала 0,80, версия B — 0,85. Какой вывод корректен?
- а) B точно лучше
- б) eval сломан
- в) A лучше
- г) разница — один кейс, может быть случайной; нужен больший набор или повторные прогоны
Зачем в golden set вопросы, ответа на которые в базе нет?
- а) для объёма
- б) проверить, что система честно отвечает «не знаю», а не выдумывает
- в) они не нужны
- г) чтобы снизить метрику
Что проверить в model card open-weights модели до использования в коммерческом проекте?
- а) число звёзд на GitHub
- б) лицензию и ограничения использования
- в) цвет логотипа
- г) дату последнего коммита
Ассистент написал функцию и тест к ней, тест зелёный. Что ещё нужно сделать до сдачи?
- а) ничего
- б) удалить тест
- в) переписать код вручную
- г) убедиться, что тест падает на сломанном коде, прочитать код и уметь объяснить каждую строку

Квиз входит в гейт уровня, поэтому ответы здесь не публикуются. Ответ на каждый вопрос есть в уроках L3.5–L3.9.

L3.9. AI-assisted разработка