Проверка вместо надежды: HTML-артефакты и verify

Отправная точка простая: агенты становятся всё способнее, потому что способнее становятся модели. Значит, агентам можно поручать более сложные задачи и давать им работать дольше. Но у этого есть цена. Чем дольше работает агент, тем важнее дать ему полное и точное задание — и тем дороже обходится ошибка, замеченная в конце: агент успеет потратить много токенов на путь, который вам не нужен. Поэтому главная идея урока — перенести проверку вперёд, в ту точку, где ошибку ещё дёшево исправить, и оформить её в удобной для человека форме. Такой формой удобно сделать HTML-файл.

Меньше ограничений: пусть Claude сам задаёт вопросы

Первый уровень — отношение к требованиям. Здесь полезно вспомнить принцип «The Bitter Lesson» Ричарда Саттона. Мысль статьи: можно потратить всё время на ручные ограничения системы, но больше данных и вычислений в итоге дают больше, чем любые заранее придуманные человеком рамки. С агентами логика похожая: чем способнее модель, тем сильнее стоит сопротивляться желанию ограничивать её заранее.

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

Разберём это на примере приложения для деления счёта между друзьями. В промпте стоит указание использовать инструмент ask_user_question: Claude по очереди задаёт вопросы — для кого приложение, есть ли вторая аудитория, — получает ответы и только после этого пишет спецификацию.

Режимы Claude Code, которые пригодятся по ходу

По ходу работы пригодится несколько режимов Claude Code. Команда /effort задаёт уровень усилий модели: чаще всего подходит значение «X high», есть и «max». Команда /fast включает быстрый режим. Авто-режим включается сочетанием Shift+Tab — его стоит освоить в первую очередь. Отдельно есть команда /goal.

HTML вместо длинного markdown

Второй уровень — понимание и план. Планы и спецификации принято писать в markdown — его часто называют общим языком разработки, построенной вокруг ИИ. Но у формата есть предел — файлы длиннее примерно двухсот строк никто не читает, ни вы, ни ваши коллеги. HTML плотнее по информации и удобнее для человека: макет можно открыть в браузере, покликать, сделать скриншот и вернуть его Claude как обратную связь.

Как это выглядит на практике: можно попросить Claude проработать несколько разных дизайн-направлений для приложения деления счёта — например, стили вроде брутализма, «Токио» и финтеха — и сгенерировать их как HTML-страницы для сравнения бок о бок. Давать обратную связь по живому макету заметно проще, чем выводить внешний вид приложения из текстового описания. Отдельное замечание про скриншоты: более мощные модели лучше работают с изображениями, поэтому скриншоты как канал обратной связи работают надёжнее.

Каркас проверки: verify, а не test

Третий уровень — самый глубокий: как встроить проверку в само приложение, чтобы её мог вести агент. Важно, что речь именно о проверке (verify), а не о тестах: цель — убедиться, что вещь ведёт себя так, как ожидает человек, и сделать эту проверку частью артефакта. Разберём каркас на небольшом списке дел, написанном на React, со Storybook-фикстурами.

Ключевой приём: компоненты публикуют своё состояние в атрибуты DOM — например, сколько пунктов выполнено и сколько активно. Агент читает этот контракт напрямую, а не выуживает данные из разметки. Поскольку состояние опубликовано отдельно от внутренностей React, проверку можно запускать независимо от того, в каком состоянии находится приложение. У каждого компонента есть схемы, фикстуры — известные состояния, — инварианты, то есть условия, которые должны выполняться всегда, и «пробы» (probes), которые намеренно уводят проверку со «счастливого пути», где всё работает.

Одна проверка — три способа запуска

Одну и ту же проверку можно запустить с трёх поверхностей. Первая — панель для человека: вы открываете её в браузере и прогоняете проверки по одной или все сразу. Вторая — запуск агентом из браузера: Claude читает тот же контракт из DOM и прогоняет проверки сам. Третья — запуск из командной строки без интерфейса, командой run verify, как это делалось бы в системе непрерывной интеграции.

Чтобы увидеть, как ловятся ошибки, полезно заранее встроить заведомо сломанную проверку: условие «3 плюс 4 равно 10» не выполняется, и это фиксируют все способы запуска. Прогоны проверок можно записывать в виде видеоклипов и хранить, например, в S3 или делиться ими с коллегами — удобный способ фиксировать изменения во фронтенде. В итоге Claude способен самостоятельно, без участия человека, через Playwright MCP найти и объяснить причину сломанной проверки.

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