ИИ пишет код всё быстрее, но кто его проверяет?
AI Can Write the Code. Who Verifies It?
Исследование Faros на 22 000 разработчиков показало: при высокой вовлечённости ИИ пропускная способность растёт, но багов на 54% больше, время ревью PR выросло в пять раз, а инцидентов в три раза больше. Автор предлагает не отказываться от скорости, а строить автоматическую верификацию: линтеры, тесты, сканеры безопасности, агентное ревью и проверки инфраструктуры. Обзор инструментов — Superpowers, RoboRev, Claude Code Review, Codex Review, Copilot и Cursor Bugbot — и пример пайплайна на GitHub Actions.
Два агента могут согласиться с одним и тем же неверным ответом, упустить одно и то же требование или уверенно указать на баг, которого не существует.
- pianopatrick
Одна идея, которую я сейчас обдумываю: возможно, я захочу использовать линтер, чтобы ограничить ИИ использованием только подмножества различных языков, которое не потребует столь тщательной проверки.
Например, если я напишу веб-фронтенд, который допускает только определённые HTML-теги и определённые CSS-свойства и никакого JavaScript, я смогу полностью избежать определённых классов ошибок.
Или, например, в C, если запретить динамическое выделение памяти, вы также избежите целых классов ошибок.
Это проверки, которые, я думаю, можно настроить с помощью линтеров, и они дадут мне больше уверенности в том, что сгенерированный ИИ код не содержит определённых ошибок.
- alcomatt
Возможно, здесь следует задать вопрос: «Кто берёт на себя вину, когда всё идёт прахом?»
- salawat
Традиционно это была бы совместная работа выделенной команды QA, частично поддерживаемой инженерной командой, за которую никто не хочет платить...
- thisisthenewme
ИИ:
- пишет код
- проверяет код
- проектирует его
- превращает в продукт
- рекламирует его
- потребляет его
- simianwords
Я разговаривал с друзьями о том, как следует использовать CI/CD в $current_year, если вы полностью перешли на агентов.
Индустрия на удивление медленно адаптируется, и я пишу о двух возможностях, которые хотел бы стандартизировать в отрасли.
Я хотел бы стандартизации агентных тестов (знаю, звучит ужасно), но это тесты, которые шире и улавливают нечёткие намерения системы. Юнит-тесты, e2e-тесты сфокусированы и сложны в поддержке. Агентный тест (или поведенческий тест) — это когда агент понимает лежащее в основе поведенческое намерение и создаёт сценарии на лету и выполняет их.
Например, я представляю, что Claude Code проходит несколько агентных тестов, где сам Claude пытается использовать программное обеспечение с помощью управления рабочим столом. Это позволило бы отловить гораздо более широкий спектр ошибок, и это гораздо проще поддерживать, потому что вам нужно, чтобы тест содержал только описание намерения, а не всю сложную обвязку, необходимую в e2e-тестах и юнит-тестах (вроде моков, тьфу).
Я хотел бы фреймворк, где у меня был бы просто что-то вроде SCENARIOS.md, и фреймворк запускал бы сценарии, поднимая общую среду, необходимую для теста. Отрасли серьёзно не хватает такой возможности.
Следующее, чего не хватает, — это агентная проверка развёртывания.
Итак, представьте, что вы развёртываете свой сервис, и вам нужно проверить, что несколько метрик в порядке, прежде чем продвигать его на все серверы. Традиционно это делалось либо вручную разработчиком (утомительно и чревато ошибками […]