Коротко
Почему «у меня всё работает» - самая дорогая фраза
Экран зелёный. Пользователь злой.
Так выглядит типичный первый месяц у непрограммиста, который собирает продукт с ИИ-агентом. Агент бодро отчитался: «Готово, всё работает». Ты открыл - действительно открывается. Через день пишет первый живой человек: «у меня не отправляется форма». И начинается разбор, почему «работает» оказалось «запустилось».
Разберём простым языком, откуда берётся расхождение. Агент считает задачу выполненной, когда результат выглядит готовым. Это его единственный сигнал, если ты не дал ему способ проверить себя. Твоя ситуация ровно такая же: ты видишь красивый экран и делаешь вывод обо всей системе.
И вот тут самое интересное. Ощущению скорости доверять нельзя - это измеряли.
Исследовательская организация METR провела контролируемый эксперимент: 16 опытных разработчиков, 246 реальных задач в их собственных больших проектах. С ИИ-инструментами задачи занимали на 19% больше времени, чем без них. При этом сами участники были уверены, что ИИ ускорил их примерно на 20%. Разрыв между ощущением и фактом - почти 40 процентных пунктов.
Честно оговорюсь: это замер на опытных инженерах, в старых кодовых базах, на инструментах начала 2025 года, и сами авторы отмечают, что более поздние модели давали другую картину. Мой вывод из него другой, более узкий: субъективное ощущение «стало быстрее» - плохой измеритель качества. Оно одинаково обманывает и разработчика, и предпринимателя.
На практике это значит вот что: проверка нужна не потому, что агент плохой. А потому, что ни ты, ни он не можете оценить результат изнутри процесса.
Что именно ты проверяешь, если не читаешь код
Главный страх звучит так: «я же не программист, я не пойму, где ошибка». Правильный страх. Но ты и не должен читать код построчно - это не твоя зона. Твоя зона выше.
Смотри, как это делится:
| Что проверяем | Вопрос, на который отвечаем | Нужен ли код |
|---|---|---|
| Сценарий пользователя | Человек с улицы дошёл до результата и получил ценность? | Нет |
| Реальные данные | Работает на настоящих данных, а не на трёх демо-строчках? | Нет |
| Границы | Что будет при пустом поле, длинном тексте, двойном клике? | Нет |
| Безопасность и деньги | Куда уходят данные, где лежат ключи, что списывается? | Нет |
| Архитектура и стиль кода | Насколько это поддерживаемо через год | Да, тут нужен инженер |
Первые четыре строки - зона предпринимателя. Ты годами принимал работу у подрядчиков: не разбирая, как устроена типография, а проверяя тираж. Здесь то же самое, только подрядчик - ИИ-агент.
Мой личный критерий готовности звучит так: продукт должен работать у пользователя, а не у меня. «Запустилось локально» - это ещё ноль. Первый посторонний человек попробовал, понял, что делать, и получил результат - вот единица.
Дальше - как этот критерий превращается в процедуру.
Приёмка в пять проходов
Не пытайся «проверить всё». Пройди пять коротких кругов - каждый ловит свой класс ошибок.
Пройди путь пользователя руками
Не «посмотри, открывается ли». Пройди сценарий целиком: зашёл, ввёл, отправил, получил письмо, вернулся, повторил. Каждый шаг, который делает живой человек, - в том же порядке.Скорми некрасивые данные
Пустое поле. Текст на 5000 знаков. Кавычки и эмодзи в имени. Дата 30 февраля. Двойной клик по кнопке. Именно тут ломается то, что выглядело готовым.Проверь на живом сервере, а не только у себя
Локально и в интернете - две разные среды. Часть ошибок физически не может проявиться на твоём компьютере.Спроси про деньги и доступы
Что подключено платного, сколько списывается, где лежат ключи, кто имеет доступ к базе. Один вопрос агенту: «покажи, какие внешние сервисы вызываются и что это стоит».Отдай свежему взгляду
Новая сессия, чистый контекст, задача - искать дыры, а не хвалить. Про это отдельный раздел ниже.
Проси у агента доказательство, а не отчёт. Не «всё готово», а «покажи, что именно ты запустил и что вернулось». Скриншот, вывод команды, результат проверки. Читать доказательство быстрее, чем перепроверять всё самому.
Пять проходов - это 20-30 минут. Час разбирательств с живым клиентом стоит дороже.
Три бага, которые видно только на живом сайте
Это не теория. Все три - из моих собственных проектов, все три выглядели как «работает».
1. Ссылка, которая ведёт в никуда. На своём статейнике я сделал короткие ссылки для репостов. Локально всё открывалось. На боевом сервере ссылка вела на внутренний технический адрес контейнера - для внешнего человека это просто битая ссылка. Причина: код строил адрес из данных запроса, а за прокси эти данные внутренние. Поймал только тем, что дёрнул живой сайт снаружи.
2. Поиск, который не ищет по-русски. Движок поиска был настроен на английские правила разбора слов. Формально поиск работал: запрос уходил, ответ приходил, ошибок ноль. Практически - по русским словам он находил не то, что нужно, потому что не понимал словоформы. Проверка на демо-данных этого не показывает, проверка на настоящих текстах - сразу.
3. Картинка, которой нет. Статьи публиковались корректно, но обложки при переносе на боевой сервер не переносились. Ни одной ошибки в логах: система честно делала то, что ей сказали. Просто результат для читателя был неполным.
Общее у всех трёх: агент не соврал. Он выполнил ровно то, что было сформулировано. Дыра была не в коде, а в определении «готово».
Любая функция, связанная с адресами, письмами, оплатой и языком данных, проверяется на боевом сервере отдельно. Локальный успех тут не доказательство, а совпадение.
Отсюда следующий шаг: сделать так, чтобы часть проверки агент выполнял за тебя.
Заставь агента проверять себя
Самый недооценённый приём - дать агенту критерий, который он может проверить сам. Не «сделай форму», а «сделай форму и проверь, что при пустом поле она показывает понятную ошибку; покажи результат».
Всегда обеспечивай проверку - тесты, скрипты, скриншоты. Если ты не можешь это проверить, не выкатывай.
Что именно годится в качестве проверки:
- Автотест - маленькая программа, которая прогоняет сценарий и говорит «прошло / не прошло». Просить у агента прямо: «напиши тест на этот случай и запусти».
- Сборка проекта - полная, а не быстрая проверка синтаксиса. У меня в правилах проекта записано: перед публикацией гнать полную сборку, потому что она ловит то, что беглая проверка пропускает.
- Скриншот результата - для интерфейса. «Сделай скриншот страницы и сравни с макетом, перечисли отличия».
- Самокритика - дешёвый приём для текстовых задач: «прожарь свой ответ, где ты мог ошибиться». Если запрос был сильным, агент найдёт слабые места сам.
Дальше это доводится до правил: то, что должно выполняться всегда, лучше зашить в файл-инструкцию проекта, чтобы не повторять каждый раз. Как это устроено, я разбирал в статье про память ИИ-агента.
Но у самопроверки есть предел, и он важный.
Свежий взгляд: почему проверяет не тот, кто писал
У себя в работе я довёл это до правила: закрыл кусок работы - приёмку делает не тот чат, который писал.
Логика простая. Сессия, которая писала код, помнит свои намерения. Она проверяет не результат, а память о результате: «я же делал это правильно». Свежая сессия видит только то, что получилось, и оценивает по факту.
Как это выглядит на практике:
Закрыл кусок работы
Фича готова, агент отчитался.Открыл новую сессию
Чистый контекст. Никакой истории обсуждения.Дал задачу приёмщика
«Вот что должно работать. Проверь сам, воспроизведи руками, найди расхождения. Ничего не чини и не публикуй - только отчёт с примерами».Вернул находки автору
Со списком: что не так, как воспроизвести. Автор чинит, приёмщик перепроверяет.
Приёмщика надо просить искать то, что влияет на работу продукта, а не стилистические придирки. Иначе он завалит тебя замечаниями «можно написать красивее» - и ты начнёшь переделывать то, что и так работает.
Этот же принцип работает и в командах людей: код-ревью делает не автор. Ты просто получил возможность собрать такую проверку в одиночку - вторая пара глаз стоит одну сессию. О том, как несколько агентов делят между собой роли, я писал в гайде про мультиагентные системы.
Чек-лист перед тем, как показать людям
Распечатай или держи в заметках. Прогоняй перед тем, как дать ссылку живому человеку.
- Прошёл весь путь пользователя руками, от входа до результата.
- Проверил пустые, длинные и странные значения в каждом поле ввода.
- Открыл продукт на телефоне, не только на компьютере.
- Проверил на боевом адресе: ссылки, письма, оплата, поиск.
- Убедился, что ключи и пароли лежат в отдельном файле и не уехали в репозиторий.
- Понял, какие платные сервисы подключены и сколько они стоят при росте нагрузки.
- Если собираются данные людей - проверил, законно ли и где они хранятся.
- Отдал результат на приёмку свежей сессии и разобрал её находки.
Последние два пункта - самые пропускаемые и самые дорогие. Тема хранения персональных данных подробно разобрана в статье про то, что делать после прототипа, а типовые уязвимости веб-приложений неплохо описаны в открытом рейтинге OWASP - его агенту можно давать прямо как критерий проверки.
Частые вопросы
Частые вопросы
Главный вывод
Если коротко, суть такая. Ты не сможешь поймать ошибку в коде - и не надо. Ты можешь поймать ошибку в результате, а это как раз то, что умеет предприниматель: пройти путь клиента и заметить, где он спотыкается.
Работает связка из трёх вещей. Первое: «готово» описано заранее и проверяемо - не «сделай форму», а «форма отправляется и присылает письмо». Второе: у агента есть способ проверить себя, и он показывает доказательство. Третье: принимает работу свежий взгляд, а не тот, кто её делал.
Ошибки после этого не исчезнут. Но они будут находиться до того, как их найдёт клиент, - а это и есть вся разница между «собрал игрушку» и «сделал продукт». С чего начинается сам путь сборки, я разбирал в гайде про 12 принципов вайбкодинга.
Как думаешь: приёмка результата у ИИ-агента - это временная мера, пока модели не научились проверять себя сами, или постоянный навык заказчика, который никуда не денется?
Если хочешь поставить такую дисциплину не себе одному, а команде - я провожу интенсив по нейросетям для бизнеса: работаем на ваших задачах, с проверкой результата, а не с демонстрацией возможностей.