Вайб-кодинг изменил круг людей, способных создавать приложения, выглядящие работоспособными. Один промпт может сгенерировать экраны, подключить API и собрать правдоподобный рабочий процесс ещё до того, как традиционная инженерная команда завершит первый этап проверки дизайна.

Такая скорость создаёт новую проблему для найма и поставки: демонстрация больше не является весомым доказательством качества программного обеспечения. Работодатели всё чаще будут задавать более сложный вопрос: может ли эта система, созданная ИИ, корректно работать, когда входные данные неидеальны, зависимости выходят из строя, пользователи повторяют действия, а базовая модель меняется?

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

Бенчмарк — это доказательство, а не место в таблице лидеров

Бенчмарки для агентов программирования с открытым исходным кодом дают полезную отправную точку, но измеряют разные способности. SWE-bench использует реальные задачи GitHub и снимки репозиториев, поэтому он релевантен для задач сопровождения. Terminal-Bench проверяет взаимодействие с командной строкой. Другие перечисленные бенчмарки, включая SlopCodeBench и ProgramBench, нацелены на различные аспекты сгенерированного кода и поведения агентов.

Эти бенчмарки могут помочь сравнивать инструменты или установить базовый уровень, но работодателям следует осторожно относиться к любому отдельному баллу как к доказательству готовности к эксплуатации. Модель, решающая задачи в репозитории, всё ещё может создать небезопасную логику авторизации. Агент, выполняющий задачи в терминале, может не сохранить состояние в ходе длительного рабочего процесса. Отполированное веб-приложение может пройти демонстрацию по благоприятному сценарию, но неправильно обработать повторы попыток или дублирующиеся платежи.

Поэтому убедительное портфолио или внутренняя проверка должны включать набор оценочных заданий, специфичный для конкретной задачи. В него могут входить типичные отчёты об ошибках, обычные пользовательские сценарии, некорректные входные данные, границы разрешений, сбои зависимостей и ранее исправленные регрессии. Для каждого случая должен быть явно указан ожидаемый результат, а не просто приложен скриншот, который выглядит правильно.

Минимальный набор тестов для программного обеспечения, созданного ИИ

Для небольшого приложения полезный набор проверок качества можно собрать без сложной исследовательской лаборатории:

  • Приёмочные тесты: проверяют видимое пользователю поведение наиболее важных рабочих процессов, включая успешные и неуспешные результаты.
  • Модульные и интеграционные тесты: проверяют бизнес-правила изолированно и подтверждают, что базы данных, API, очереди и аутентификация работают вместе так, как задумано.
  • Негативные тесты: отправляют отсутствующие, некорректные, слишком большие, дублирующиеся входные данные, а также данные без соответствующих разрешений. Сгенерированный ИИ код часто выглядит лучше всего на пути, показанном в промпте, поэтому непредусмотренные пути имеют значение.
  • Регрессионные тесты: превращают каждую обнаруженную ошибку в постоянный тест. Зелёной демонстрации после исправления недостаточно, если тот же сбой может вернуться в следующем сгенерированном изменении.
  • Проверки безопасности: тестируют контроль доступа, работу с секретами, защиту от инъекций, уязвимости зависимостей, а также возможность влияния ненадёжного содержимого на вызовы инструментов или привилегированные действия.
  • Операционные проверки: проверяют тайм-ауты, повторы попыток, идемпотентность, журналирование, оповещения и безопасное поведение при недоступности зависимости.

Это близко к подходу QA-инженерии, описанному в рассказе Stack Overflow об агентном жизненном цикле разработки программного обеспечения. Важен культурный сдвиг: обеспечение качества — не финальная проверка после того, как ИИ написал код. Это структура, которая делает быстрое создание достаточно безопасным для использования.

Тестируйте оркестрацию, а не только результат

Когда программное обеспечение включает ИИ-агента, обычные тесты приложения необходимы, но недостаточны. Система может дать сбой потому, что модель неправильно поняла запрос, но также и потому, что окружающая оркестрация потеряла контекст, дважды вызвала инструмент, приняла некорректный структурированный вывод или так и не завершила работу.

Рекомендуемые дайджестом области регрессионного тестирования перед развёртыванием образуют практический контрольный список: потеря контекста, идемпотентность инструментов, промпт-инъекции, структурированный вывод, незавершение работы, заземление поиска и восстановление состояния. Это проверяемые инженерные свойства.

Например, тест может дважды выполнить один и тот же запрос и подтвердить, что вторая попытка не создаёт дублирующий заказ. Другой тест может прервать работу агента в середине рабочего процесса, перезапустить его и проверить, что он возобновляет работу из корректного состояния, а не повторяет необратимое действие. Тест поиска может требовать от системы ссылаться только на информацию из утверждённого набора источников или возвращать только такую информацию. Тест структурированного вывода может передать некорректный ответ и подтвердить, что приложение безопасно отклоняет его, а не молча считает допустимыми данными.

Для длительно работающих систем и систем с несколькими агентами особенно важны чёткие записи о сбоях. Исследователи работают над автоматизированным определением причин сбоев, поскольку бывает трудно установить, какой агент вызвал сбой и на каком этапе длинной цепочки взаимодействий это произошло. На практике командам следует сохранять вызовы инструментов, входные данные, выходные данные, версии моделей, временные метки, переходы состояний и итоговые решения в журнале аудита с учётом требований конфиденциальности. Без этих свидетельств красный тест говорит, что что-то сломалось, но не указывает, с чего начать исправление.

Воспроизводимость станет карьерным преимуществом

Код, сгенерированный ИИ, непостоянен. Повторный запуск может создать другую реализацию; обновление модели может изменить поведение; сбой у провайдера может повлиять на маршрутизацию или задержку. Поэтому работодатели будут ценить кандидатов, способных сделать оценки воспроизводимыми.

Это означает, что по возможности нужно фиксировать снимки моделей, записывать промпты и конфигурацию, контролировать случайность, когда платформа это позволяет, и проводить несколько испытаний для задач с изменчивыми результатами. В дайджесте особо отмечаются зафиксированные снимки, низкая или нулевая температура, где она доступна, и ограничители CI/CD с заданными границами уверенности как полезные меры защиты.

Практический отчёт должен различать как минимум три результата:

  1. Процент успешных прохождений: сколько случаев завершились успешно.
  2. Согласованность: как часто один и тот же случай завершается успешно при повторных запусках.
  3. Серьёзность: являются ли сбои косметическими, неудобными, приводящими к повреждению данных, связанными с безопасностью или способными вызвать небезопасное внешнее действие.

Система, успешно проходящая 19 из 20 низкорисковых проверок форматирования, не обязательно лучше системы, которая проходит 18 из 20 случаев, но никогда не пересекает границу авторизации. Планка качества должна учитывать последствия сбоев.

Проверка человеком должна быть направлена на риски, а не на каждую строку

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

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

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

Такая запись нужна не ради бюрократии. Она позволяет отличить впечатляющую демонстрацию от контролируемого изменения, которое сможет поддерживать другой человек.

Что включить в портфолио или рассказать на собеседовании

Для кандидатов лучшей демонстрацией будет небольшая система с намеренно прозрачной историей качества. Включите репозиторий, инструкции по настройке, заметки об архитектуре, команды для запуска тестов, репрезентативные тестовые случаи, известные ограничения и краткий отчёт о сбоях. Покажите одну или две найденные ошибки, превращённые в регрессионные тесты. Укажите, какая модель или агент для программирования использовались, но не представляйте инструмент автором инженерных решений.

Если в приложении используется агент, задокументируйте разрешения инструментов, модель состояния, политику повторных попыток, условие завершения и точки одобрения человеком. Если используется поиск по источникам, покажите, как выбираются источники и что происходит при отсутствии подтверждающих данных. Если приложение обращается к внешним сервисам, продемонстрируйте поведение при тайм-ауте и повторном запросе.

Не утверждайте надёжность на основании одной успешной записи. Проверяемое утверждение звучит скорее так: «В 30 записанных запусках по этим 12 сценариям система соответствовала критериям приёмки в 28 случаях; два сбоя были связаны с неоднозначным вводом даты, и оба задокументированы». Само число менее важно, чем метод, границы и честное описание того, что ещё не протестировано.

Новое определение скорости

ИИ снижает стоимость создания первой версии. Но он не устраняет стоимость проверки того, заслуживает ли эта версия доверия. Более того, ускорение генерации может сделать оценку ещё важнее, поскольку между развёртываниями может накапливаться больше непроверенных изменений.

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

Поэтому планка качества — не «Можете ли вы создать приложение с помощью ИИ?», а «Можете ли вы доказать, что делает приложение, обнаружить, когда оно перестаёт это делать, и спроектировать ограничения, которые не позволят сбою превратиться в инцидент?»