Независимый верификатор

Кто это и зачем нужен

Независимый верификатор адверсариально проверяет результат свежим взглядом со стороны: делает ли изменение то, что заявлено, и — главное — не ломает ли соседнее. Его миссия — поймать то, что исполнитель пропустил из-за «замыливания» (когда ты сам писал код, ты видишь, что хотел написать, а не то, что написал). Это вторая, независимая пара глаз перед закрытием.

Боль, которую он закрывает: исполнитель проверяет себя предвзято — он уверен, что всё работает. Регрессии в соседнем коде, непокрытые края, «починил одно — сломал другое» проскакивают. Независимая проверка ловит это до пользователя.

Что ломается без него: задачи закрываются «на веру», регрессии всплывают позже, край не проверен, изменение ломает то, что рядом. Особенно опасно на risky/multi-file правках, где blast radius велик.

День из жизни

Утро. Берёт готовое изменение/дифф с заявленным результатом. Свежим контекстом (не зная «как задумывалось») воспроизводит заявленное: реально делает то, что обещано? День. Адверсариально ломает: happy path + края + ошибки. Проверяет регресс соседнего кода (что рядом могло сломаться). На risky/multi-file шагах — перекрёстное ревью с другим взглядом. Вечер. Пишет отчёт верификации: что подтверждено, что сломано/не покрыто, какие регрессии найдены. Не «выглядит ок», а воспроизводимое подтверждение или конкретный список проблем.

Ключевые навыки

Hard: адверсариальное тестирование, анализ диффа и blast radius, воспроизведение по сценариям, регресс-мышление, чтение чужого кода, проверка по критериям приёмки. Soft: независимость и скепсис (не верить на слово), свежий взгляд (не поддаваться логике автора), въедливость, конструктивность отчёта.

Артефакты, которые пишет

• Отчёт верификации — подтверждено / не подтверждено, с доказательством.
• Найденные регрессии — что и где сломалось.
• Замечания ревью — на risky/multi-file шагах. Проверяет по критериям из User Story и Definition of Done; опирается на Тест-кейс и Баг-репорт (как фиксировать найденное).

Как ИИ/вайб-кодинг усиливает роль

Это нативная роль ИИ-конвейера — отдельный проход свежим контекстом ловит то, что пропустил исполнитель:

1. Адверсариальная проверка. Промт: «Свежим взглядом проверь, делает ли это изменение <заявленное>. Вот дифф <…>. Воспроизведи happy path, края и ошибки. Не верь описанию — проверь по факту.»
2. Поиск регрессий. Промт: «Это изменение в <модуль> <дифф>. Что в соседнем коде могло сломаться? Дай список сценариев регресса для проверки.»
3. Проверка по критериям. Промт: «Сверь результат <…> с критериями приёмки <…>: какие выполнены, какие нет, что не покрыто.»
4. Критика на risky-шаге. Промт: «Это multi-file изменение <…>. Где скрытые риски, неучтённые случаи, нарушения инвариантов? Будь адверсариальным.»
5. Отчёт верификации. Промт: «Собери отчёт: что подтверждено (с шагами воспроизведения), что сломано/не покрыто, найденные регрессии, вердикт закрывать/нет.»

Путь развития: Junior → Middle → Senior → Lead

• Роль скорее функциональная, чем грейдовая — её исполняет QA/инженер/ревьюер с установкой на независимость.
• Базово: проверяет по чек-листу и критериям, фиксирует найденное.
• Зрело: мыслит blast radius, ловит тонкие регрессии и нарушения инвариантов, ведёт перекрёстное ревью.
• В команде — это культура «не закрывать на веру», которую задаёт QA Lead / Tech Lead.

Частые ошибки и как избежать

• Довериться логике автора. → Проверяй по факту со свежим контекстом, а не «как задумано».
• «Выглядит ок» = подтверждено. → Подтверждение = воспроизведённый результат, а не впечатление.
• Только happy path. → Адверсариально: края, ошибки, регресс соседнего.
• Пропустить blast radius на multi-file. → Чем шире изменение, тем шире проверка вокруг.
• Отчёт без конкретики. → Точные шаги воспроизведения и список проблем, а не «есть баги».

Что освоить (мини-программа)

• Концепции: адверсариальное тестирование, регресс и blast radius, верификация vs валидация, критерии приёмки, перекрёстное ревью.
• Инструменты: diff-просмотр, Playwright (воспроизведение веб-флоу), DevTools/логи, чек-листы.
• Почитать: материалы по code review (Google Eng Practices); «Lessons Learned in Software Testing»; практики adversarial review.

Зарплатные ориентиры (RU)

• Как функция входит в роли QA/инженера/ревьюера — отдельной вилки обычно нет.
• Ориентируйся на вилки QA Engineer / SDET / Tech Lead в зависимости от того, кто несёт функцию.

  Зависит от базовой роли, грейда, города и года — проверяй актуальное.

Маппинг на агента Laskoff

Прямой mapsTo: quest-verifier/reviewer. В Quest эту роль несут два агента: quest-verifier (независимая проверка результата свежим контекстом — happy path + края + ошибки + регресс) и reviewer (ревью кода). По house rules verifier обязателен на risky/multi-file шагах, а для высоких ставок — несколько независимых вариантов → критика → синтез. Это буквально «не закрывать на веру», встроенное в конвейер: проверка после КАЖДОГО шага.

🤖 Промт-персона

Ты — независимый верификатор с адверсариальным, скептическим взглядом. Помогаешь мне подтверждать, что изменение реально делает заявленное и НЕ ломает соседнее. Подходи свежим контекстом: не верь описанию «как задумано», проверяй по факту. Воспроизводи happy path, края и ошибки; отдельно проверяй регресс соседнего кода и blast radius (особенно на multi-file изменениях). Подтверждение = воспроизведённый результат с конкретными шагами, а не «выглядит ок». В отчёте чётко раздели: что подтверждено, что сломано/не покрыто, найденные регрессии и вердикт — закрывать или нет.