Как мы себя проверим: вопрос, который стоит задать до начала любой работы
Вопрос, который я задаю всегда
“Как мы можем себя проверить?” Этот вопрос я задаю всегда, когда делаю какую-то аналитику сам или прошу сотрудников и коллег что-то сделать. В аналитике и отчётах ответом могут быть простые итоговые значения, “тоталы”, которые должны сходиться.
Например, сумма по проектам должна совпасть с итогом портфеля, а помесячный план в сумме должен дать годовой бюджет. Сумма ставок по всем проектам не может оказаться больше числа сотрудников. Для таких сверок не нужны ни экспертиза, ни специальные инструменты. Нужна только договорённость, что они будут.
Нужны они по простой причине. Люди ошибаются, а ошибка в итоговой цифре редко остаётся в таблице и обычно уходит дальше, в отчёт, на комитет и в решение о деньгах. Поэтому проверки надо встраивать в любой результат, не только от агента, но и от человека. А от агента и подавно.
Многое решает момент, когда о проверке заходит речь. Если о ней договорились до начала работы, ответ может уложиться в одну фразу постановки задачи, например “в конце сверим сумму по проектам с итогом портфеля”. Исполнитель тогда с самого начала ведёт расчёт так, чтобы итоги сходились, и видит расхождение сразу, пока причину легко найти. Если вспомнили о ней, когда результат уже готов, проверку приходится придумывать задним числом, и она выходит дороже и слабее. Поэтому любая работа (своя, сотрудника, коллеги или агента) должна приходить вместе со способом её проверить, о котором договорились заранее.
Кто находит ошибку, если проверку не встроили
Ошибаются и самые аккуратные, и если проверка не встроена в работу, ошибку находит случай. Он может прийти поздно, а может не прийти вовсе. В 2010 году экономисты Кармен Рейнхарт и Кеннет Рогофф представили работу, по которой рост экономики резко замедляется, когда госдолг страны превышает 90% ВВП. На этот порог потом ссылались политики в Евросоюзе и США, отстаивая сокращение расходов. Ошибку в работе нашёл аспирант Массачусетского университета, которому дали учебное задание повторить расчёты какой-нибудь экономической статьи (историю подробно рассказывала BBC).
Повторить их он не смог, решил, что ошибся сам, и перепроверял себя снова и снова, пока по совету преподавателей не написал авторам и не получил их рабочую таблицу. В ключевой расчёт среднего роста попали 15 стран из 20. На знаменитый вывод сильнее повлияли другие найденные проблемы (пропуски в данных и способ усреднения), а сами авторы считали, что ошибка в таблице его не меняет. Но показательна именно она: её поймала бы простейшая сверка “сколько стран попало в среднее”, а нашёл её посторонний человек больше чем через три года. К тому времени на вывод уже успели сослаться в больших политических спорах.
Сколько стоит проверка до и после
В сентябре 2026 года модель GPT-6 Astra по заданию исследователя за два дня нашла ключ к немецкой армейской радиограмме от 10 июля 1941 года. С 2005 года это сообщение из 82 букв не поддавалось никому. Модель сама выбрала его среди нерасшифрованных сообщений архива и сама написала программы, чтобы перебирать настройки.
Ключ и расшифровку отправили на проверку исследователю Enigma, который ведёт архив с этой радиограммой, и, по его словам, сразу стало ясно, что они верные. По его же оценке, то, что модель сделала за два дня, у человека заняло бы недели или даже месяцы. Поиск был дорогим, а проверка почти бесплатной, потому что её даёт сама задача. Чтобы найти ключ, нужно перебрать огромное число вариантов настроек, а чтобы проверить найденный, достаточно выставить эти настройки и один раз прогнать сообщение.
В отчётах и расчётах такой готовой проверки нет, поэтому её приходится закладывать самому. Иначе получается ситуация из заметки про когнитивный долг: презентация из двадцати слайдов, встреча с клиентом через час, а на семнадцатом слайде расчёт, на проверку которого уйдёт целый день. Часто день уходит потому, что способ проверки придумывают после, и проверяющему приходится заново разбираться, откуда взялись цифры. Если бы о проверке договорились при постановке задачи, расчёт пришёл бы со строкой итогов, ссылкой на исходные данные и сверкой с прошлым периодом. Цена проверки зависит не столько от сложности работы, сколько от того, когда о проверке подумали.
Какую ошибку ловят итоги
Сходящиеся итоги ловят не всё. Автор статьи на Хабре о проверке правок ИИ нарочно составил грубый пример. В исходном тексте Анна получила 30 тысяч рублей, а Борис 50 тысяч. После правки суммы поменялись местами. В коротком примере это видно сразу, а в длинном документе такую перестановку легко пропустить.
Имена и числа на месте, поэтому сверка “ничего ли не потерялось” молчит, и утилита автора, которая ищет потерянные и добавленные числа, различий не нашла. Итог сойдётся до рубля: 80 тысяч и до правки, и после. Только каждый получил чужие деньги. Ловушка вполне житейская. В сводке по портфелю общий бюджет сойдётся и тогда, когда затраты двух проектов записаны друг другу.
Значит, за вопросом “как мы себя проверим?” стоит второй вопрос: какой ошибки мы боимся. Если боимся, что часть суммы потеряется, хватит итога. Если боимся перепутать получателей, нужна построчная сверка того, кто сколько получил. Проверку подбирают под ожидаемую ошибку, и это тоже решается до начала работы.
Удобнее всего выписать утверждения, которые должны сохраниться, прямо из исходного текста, пока новая версия ещё не прочитана и не кажется привычной. Так советует автор статьи о правках, и такой список работает дважды: он ставит задачу исполнителю и остаётся у того, кто принимает результат. Сверку чисел автор предлагает поручать программе, а утверждения, от которых зависят действия людей, читать целиком. По его словам, такой список полезен и при правке человеком. Для отчёта это могут быть несколько строк, например сколько проектов в работе, каков общий бюджет и какие проекты отстают больше допустимого.
Что меняется, когда работу делает агент
С агентами правило то же, только строже. Автор, отдавший свой сайт ИИ-агентам, замечает, что агент делает правки быстрее, чем человек успевает их прочитать, а самые опасные его ошибки звучат убедительнее настоящих находок. В одной находке аудита механизм был описан верно и номера строк указаны точно, а вывод был ложным: предложенная правка сломала бы ровно то, что якобы чинила. Отличить такую находку от настоящей, по словам автора, можно только открыв код, поэтому проверять её надо по исходникам, а не по тексту находки.
Заранее всё не предусмотришь, и автор этого не скрывает. Каждое из двенадцати правил, которыми он проверяет сайт при сборке, появилось после ошибки, доехавшей до рабочей версии. Одно из них сверяет счётчики категорий с данными, потому что однажды на витрине оказалось 18 проектов при 19 в источнике. Это те же сходящиеся итоги, только за это правило уже заплатили ошибкой.
Хуже другое. Агент может обойти проверку, если ему позволено её трогать. Когда GitHub переносил движок Copilot на новый язык, большую часть кода написали агенты (разбор на Хабре). Руководивший переносом инженер Microsoft Стивен Тауб держался простого правила: сначала новая программа ведёт себя как старая, а улучшать её можно потом, иначе при поломке не разберёшь, что виновато. Несколько раз он от этого правила отступал и потом жалел, потому что получал лишние ошибки и тратил время и деньги.
Однажды при переносе потерялась функция, которой пользовались другие программы, и автоматическая проверка совместимости остановила приёмку. Агент в ответ поставил служебную метку, разрешающую такую несовместимость, и проверка готова была пропустить потерю. Перед слиянием Тауб спросил, почему это допустимо. Оказалось, недопустимо: функцию просто забыли перенести.
Отсюда видно, как должна быть устроена проверка любой работы. Её договаривают до начала, исполнитель встраивает её в результат, принимает работу тот, кто её поручил, и менять проверку исполнитель не вправе. Агенту, чтобы подогнать проверку под себя, хватает доступа к ней. Человека к этому подталкивает заинтересованность. Так устроена у нас оценка рисков отказа от проекта: инициатор описывает, что потеряет компания, если проект не запустить, и ему выгодно сгустить краски, поэтому описание подтверждает владелец риска.
Так же работает и проверка самого себя. Когда считаешь сам, ты и исполнитель, и принимающий. Если до расчёта записать, с каким итогом должна сойтись сумма, то, увидев результат, ожидание уже не подправишь. Записанная заранее проверка работает как договорённость со вторым человеком, даже когда второго человека рядом нет.
С чего начать в понедельник
Новые системы и отдельный бюджет для этого не нужны. Когда поручаете работу сотруднику, коллеге или агенту, а также когда садитесь за расчёт сами, задайте вопрос “как мы можем себя проверить?” до начала работы и запишите ответ рядом с задачей. Затем подберите проверку под ошибку, которой боитесь. Чаще всего подходит один из четырёх видов.
- Итоги, которые должны сходиться. Сумма по строкам равна общему итогу, а в расчёт среднего попало столько объектов, сколько их в таблице.
- Сравнение с прежним результатом. При переносе отчёта или процесса в новую систему сначала добейтесь тех же цифр, а улучшайте потом, как при переносе Copilot.
- Пересчёт или проверка другим человеком, как в истории с таблицей про госдолг или с описанием рисков.
- Список утверждений, которые должны сохраниться, если результатом будет текст.
Проверка остаётся у того, кто принимает работу. Исполнитель может её предложить, но менять её или выписывать себе исключения не должен. Агенту ответ на вопрос о проверке пишут прямо в задание, и выполнить проверку он может сам, но решать, пройдена ли она, должен тот, кто поручил.
Прежде чем полагаться на проверку, нарочно подставьте ту ошибку, которой боитесь (например, поменяйте местами две суммы), и посмотрите, заметит ли её сверка. Утилита из истории с Анной и Борисом честно искала потерянные числа и поэтому перестановку не увидела, ведь проверка ловит только ту ошибку, под которую её строили. А если ошибка всё-таки проскочила, превратите её в проверку на следующий раз.
Бывает, что на вопрос о проверке ответить нечего. Например, поручение звучит как “оцени загрузку команды”, и никто не может назвать, с чем сверять ответ. Значит, ещё не договорились, что считать загрузкой: часы по табелю, назначения в плане проектов или ощущение руководителя. Исполнитель вернётся с правдоподобной цифрой, которую не с чем сравнить, и спор начнётся уже после работы. Ответ на вопрос о проверке здесь сам уточняет задачу, ведь фраза “сверим с часами по табелю за прошлый квартал” сразу говорит, что именно считать.
Если на вопрос о проверке нельзя ответить до начала работы, значит, пока неясно, что считать результатом. В истории с Анной и Борисом один и тот же список и ставил задачу, и принимал результат. С любым поручением так же. Пока не сказано, как его проверить, не сказано и что именно нужно сделать. Поэтому вопрос “как мы можем себя проверить?” проверяет не только результат, но и саму задачу.
