Новый класс ошибок, о котором не предупреждают

Теперь честная часть.

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

У нас это случилось четыре раза. Последний — в первом же шаге первой сборки. Экран говорил: «поиск по подфразе сужает результат поиска». Заказчик ответил «да» — и тут же дописал: «не ищет по телефону, при вводе 90011 пишет, что карты нет».

Проверили: он прав. Фильтр искал одну подстроку по склейке полей. Два слова не находились никогда, телефон — только в том виде, в каком записан на экране.

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

Причина у всех четырёх случаев одна: проверка, написанная тем же способом, что и экран, сверяет текст с текстом. Она подтверждает, что на странице есть нужные слова, а не что за словами что-то стоит.

Второй случай того же рода — ещё нагляднее. Кнопка «Собрать замечания» молча не работала во всех десяти сборках: удаляя анкету, мы оставили цикл по ней внутри функции сбора. Клик падал до открытия окна — ни диалога, ни ошибки, страница выглядит исправной. Заказчик поэтому и отвечал фотографиями экрана, а мы три раунда строили теории про его привычки. Ни одна из 460 проверок ни разу не нажала эту кнопку: проверялось, что анкета удалена, а не то, что сбор после удаления жив.

Что с этим делать — три правила, каждое выстрадано:

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

Самая дорогая ошибка оказалась не технической

Шесть раундов, 285 решений, десять сборок. А потом мы сделали простую вещь: сверили список модулей системы со списком того, о чём вообще спрашивали.

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

Почему? Потому что мы шли за повесткой заказчика. А заказчик говорит о том, что болит каждый день. Этот модуль у него работает — поэтому он не заговорил о нём ни разу, а мы не спросили.

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

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

Что я бы сказал, если бы можно было одно предложение

AI не избавил нас ни от одного часа разбора требований — 285 решений разобраны руками, и каждое стоило времени. Он убрал стоимость переделки того, чем спрашивают. Внимание заказчика осталось таким же дефицитным, как раньше; изменилось то, что на каждую единицу его внимания приходится гораздо лучше подготовленный вопрос.

А дальше начинается работа, которая никуда не делась: проверять, что ваш быстрый артефакт не врёт, и время от времени спрашивать не то, что болит заказчику, а то, что вы обязаны знать сами.