Во всех обсуждениях ценности ИИ-помощников в разработке ПО мне встречается одна печальная история: разработчик-джун, вооружившийся каким-нибудь LLM-инструментом, создаёт для своих коллег или мейнтейнеров опенсорс-проекта огромный нетестированный PR, ожидая, что всё остальное решится благодаря процессу код-ревью.

Такое поведение грубо, оно заставляет других людей впустую тратить время и идёт вразрез с долгом разработчика ПО.

Ваша задача — выпускать код, который доказанно работает.

Мы, разработчики ПО, не просто производим код; сегодня даже можно сказать, что для этого предназначены LLM. Мы должны выпускать код, который работает, и приложить к нему доказательство его работы. Если вы этого не делаете, то просто сбрасываете бремя настоящей работы на того, кто должен будет проверять ваш код.

Как доказать, что код работает

Доказательство работы кода состоит из двух этапов, каждый из которых обязателен.

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

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

По возможности я стараюсь сводить эти этапы к серии команд терминала, которые можно скопипастить вместе с их результатом в комментарий к код-ревью. Один из недавних примеров можно посмотреть здесь: https://github.com/simonw/llm-gemini/issues/116#issuecomment-3666551798.

Некоторые изменения продемонстрировать сложнее. Но вы всё равно обязаны это сделать! Запишите видео экрана и приложите его к PR. Покажите ревьюерам, что внесённое изменение действительно работает.

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

Второй этап доказательства — автоматизированное тестирование. Сегодня, когда у нас есть LLM-инструментарий, он стал гораздо проще, поэтому у пропускающих этот этап нет никаких оправданий.

Ваш долг — дополнить изменение автоматизированным тестом, доказывающим, что оно работает. Если откатить реализацию, тест должен перестать проходить успешно.

Процесс написания теста такой же, как и при ручном тестировании: приводим систему в изначальное известное состояние, выполняем код изменения, подтверждаем, что оно сработало корректно. Интеграция тестовой обвязки для продуктивного облегчения этого процесса — это ещё один ключевой навык, в развитие которого следует вложиться.

Не отказывайтесь от ручного тестирования, даже если считаете, что автоматизированный тест обеспечит достаточную проверку! Каждый раз, когда я сам так поступал, сожаления настигали меня почти мгновенно.

Пусть доказательством сначала займётся кодинг-агент

Самым важным трендом 2025 года в сфере LLM стал взрывной рост кодинг-агентов — инструментов наподобие Claude Code и Codex CLI, способных активно исполнять код, над которым они работают, чтобы проверять его работоспособность и итеративно решать проблемы.

Чтобы в совершенстве освоить эти инструменты, вам нужно научиться и тому, чтобы они сами доказывали работоспособность своих изменений.

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

Так как они роботы, автоматизированное и ручное тестирование для них — это, по сути, одно и то же.

Но всё-таки кое в чём они различаются. Когда я работаю над созданием CLI-инструментов, то обычно учу Claude Code самому запускать их, чтобы он мог выполнять одноразовые тесты, даже несмотря на то, что последующие автоматизированные тесты будут использовать системы наподобие Click CLIRunner.

При работе над изменениями в CSS я часто прошу кодинг-агента делать скриншоты, когда ему нужно проверить, что внесённое изменение имело должный эффект.

Здорово здесь то, что кодинг-агентов необязательно заставлять писать автоматизированные тесты. Если у вашего проекта есть тесты, то большинство агентов самостоятельно дополнит тестовый набор, даже если их об этом не просить. Кроме того, они позаимствуют паттерны из уже имеющихся тестов, поэтому упорядоченность тестового кода и добавление в него нужных вам паттернов — отличный способ помочь агенту в создании кода тестирования под ваши нужды.

Формирование хорошего вкуса в коде тестирования — ещё один из тех навыков, которые отличают сеньора от остальных.

Человек обеспечивает ответственность

Компьютер никогда не может нести ответственности. Вы человек, поэтому это ваша задача.

Почти кто угодно может написать промпт для LLM, позволяющий сгенерировать патч на несколько тысяч строк, и отправить его на код-ревью. Сегодня в этом уже нет никакой ценности. Теперь ценно создание кода, который доказанно работает.

Когда в следующий раз вы будете отправлять PR, приложите к нему и доказательство того, что он работает так, как должен.