TDD в мире AI: тесты как язык общения с моделью Ссылки в этот раз не будет, чисто мое мнение. Вообще, я давний фанат TDD подхода, классический TDD - это сначала тест, потом код. Это сильно забустило в свое время меня и как инженера (написание тестов перед кодов позволяют задумываться о архитектуре до написания кода) и как продакта (продумываение требований и граничных условий для написания тестов позволяет продумать многие аспекты, которые всплывали у многих только ближе к тестированию). В мире, где код всё чаще пишет AI, формула меняется, но суть та же: тесты задают правила игры. Тесты как протокол общения с AI Обычно взаимодействие с моделью выглядит так: Создай модуль для работы со списком... ✨ магия ✨ Получаем код, который «вроде работает». Но не знает, где у вас деньги, регуляторика, странные бизнес‑правила и больные edge‑кейсы. Работа с AI-TDD 1. Сначала пишем тест-кейсы, можно использовать на этом этапе AI, он уже не плохо справляется с этой задачей, особенно при наличии ТЗ а не только пользовательского сценария 2. Просим агента написать тесты исходя из тест-кейсов, тут важно проверять самостоятельно соответствие тест-кейсам и предупредить модель что вы работаете по TDD и тесты должны опираться на модели и будут красными 2. Даём промпт в духе: «Вот набор XCTest‑кейсов. Напиши/обнови реализацию так, чтобы все они проходили. Код можно менять как угодно, но сигнатуры публичных методов оставь.» Роль тестов здесь меняется: это уже не «страховка на потом», а контракт, который мы предъявляем модели. В классическом цикле TDD: red → green → refactor С AI он становится больше похож на: test → prompt → code → run tests → new prompt / refactor Мини‑флоу на примерной задаче: 1. Формулируем поведение через тесты Например, парсер промокодa, калькулятор скидки, валидатор формата. 2. Отправляем в AI: 🟣описание задачи 🟣список тестов 🟣ограничения (Swift, без сторонних зависимостей, таргет iOS такой‑то). 3. Генерим реализацию и гоняем тесты. 🟣что упало — идёт обратно в модель 4. Итеративно уточняем промпт, пока не станет зелёным: 🟣добавляем новые кейсы в тесты, если понимаем, что что‑то не учли; 🟣ужесточаем формулировки («не используй force‑unwrap», «без глобального состояния»). Фокус смещается: важно не то, кто написал конкретную строку кода, а насколько хорошо мы задали контракт и тестами, и промптом. Что мне еще нравится в таком подходе с тестами, так это обесопашивание своего кода от вмешательства. В больших проектах нет твоего кода, есть блоки которые ты можешь ревьювить и если твой блок достаточно большой, то достаточно отслеживать изменение в тестах и если при изменении кода тесты не менялись и прошли, значит, как минимум, ничего сломаться не должно.