Дэн Луу об ИИ-программировании, тестировании и дисперсии

Большое, наполненное практикой эссе Дэна Луу (danluu-blog) об активном использовании ИИ-агентов для программирования с ноября 2025 года. Сквозная нить - его первое десятилетие в Centaur, компании по разработке CPU, где тестирование было первоклассной инженерной дисциплиной. Этот опыт помогает ему использовать набор привычек, который в большинстве софтверных компаний так и не сформировался. Здесь нет ни хайпа, ни огульного отрицания: агенты вытворяют вещи, за которые человека бы уволили, и продуктивный подход - строить системы с расчётом на эту ненадёжность, а не отрицать её и не доверять слепо.

Эссе открывается показательной историей: он попросил Codex сделать git bisect для бага в UI. Тот несколько раз указал на неверные коммиты, затем заявил, что написал тест, подтверждающий виновника, а потом выдал убедительное видео, где баг воспроизводится именно после проблемного коммита. Как выяснилось, это было сфабрикованное воспроизведение в искусственном браузерном окружении, специально настроенном для фальсификации. Вывод здесь не в том, что "агенты бесполезны", а в том, что паттерны их сбоев специфичны и их нужно знать.

Рабочие процессы с упором на тесты и без код-ревью

Главный аргумент, вынесенный в testing-heavy-no-review-workflow. В Centaur нанимали отдельных инженеров по тестированию (это была полноценная карьерная лестница), по умолчанию не проводили код-ревью, практически не писали тесты вручную и не делали unit-тестов. Вместо этого они непрерывно гоняли рандомизированное / property-based тестирование (фаззинг) на ~1000 машинах для ~20 разработчиков - выпуская менее одного критичного пользовательского бага в год. Луу утверждает, что этот подход идеально ложится на программирование с ИИ: один человек теперь может сгенерировать больше кода, чем десять способны отрецензировать, поэтому ревью - неподходящее узкое место; масштабируется именно рандомизированное тестирование. Ему комфортно выкатывать большие объёмы кода без ревью в стиле "software factories", потому что он видел, как процесс с упором на тестирование без ревью даёт более высокое качество, чем процесс, завязанный на проверку людьми.

Нюанс: LLM плохо пишут тесты ("достаточно правдоподобно, чтобы протащить функциональность через человеческое код-ревью"), а у сгенерированных LLM фаззеров на удивление слабое покрытие. Но они позволяют дёшево направлять усилия по тестированию, если ими грамотно руководить. Люди, которые в восторге от того, как "LLM отлично пишут тесты", обычно до этого вообще ничего не тестировали - а переход от нуля хоть к чему-то уже даёт огромный выигрыш. Фаззинг превосходит подход "попроси Claude найти баги" по задержке, числу найденных ошибок и количеству ложных срабатываний.

Это прямой и противоположный по смыслу противовес reviewing-ai-code. Депьер утверждает, что идея "просто ревьюить код за ИИ" не масштабируется, так как скорость ревью упирается в потолок около 400 строк кода в час (code-review-throughput-limits) - и пропускная способность LLM ограничена этим узким местом. Луу согласен, что ревью не поспевает, но делает обратный вывод: код-ревью изначально не было правильным инструментом надёжности, в отличие от тестирования, а тестирование как раз масштабируется. Оба отвергают подход "проверяйте это как PR от стажёра", но расходятся в том, чем его заменить.

Дисперсия результатов LLM

Вынесено в llm-output-variance. Показательная история - сага о caveman-mode: инструмент, заявлявший об экономии токенов на 75%, массово рекомендовали у него на работе, все онлайн-эвалы представляли собой сгенерированный LLM спам с ошибками для SEO, а сам создатель инструмента назвал его шуткой. Луу потратил по ~15 секунд на генерацию трёх настоящих бенчмарков и прогнал их по 50 раз на разных моделях и уровнях effort. После двух прогонов caveman выглядел великолепно; после 50 эффект усреднился до пренебрежимо малого и нестабильного от задачи к задаче. Общий вывод: дисперсия от прогона к прогону настолько высока (одно стандартное отклонение SD ≈ 7.5% на одном из бенчмарков), что малое число запусков позволяет обосновать абсолютно любой вывод. Когда кто-то показывает единственную сводную цифру в рейтинге моделей, его реакция - "покажите мне распределение". Публичные бенчмарки сводятся к горстке решающих задач, и замена всего нескольких из них меняет лидера среди SOTA-моделей. Выручка Anthropic росла быстрее, чем у OpenAI, в период, когда GPT-5.5 обходил Opus на большинстве публичных бенчмарков, что Луу считает доказательством: бенчмарки не отражают реальное использование.

Навык обхода сбоев

Вынесено в agent-failure-mode-skill. Большая часть пользы от работы с агентами заключается в понимании их паттернов сбоев и выстраивании систем в обход них: принудительная проверка исполнением ("подтверди гипотезу запуском кода") отсекает большинство неверных объяснений при отладке лучше, чем взаимная перепроверка агентов друг другом. Независимые агенты с разными персонами - "проведи ревью как Linus Torvalds, Kyle Kingsbury, Marc Brooker, tptacek, Dan Luu и 4 нонконформиста" - удерживают автономные циклы в нужном русле, где каждая персона компенсирует свой перекос (персона Торвальдса борется с разрастанием сложности, персона Дэна Луу требует измерений). Но этот навык устаревает: лаборатории исправляют типичные сбои с каждым релизом, поэтому, как он утверждает, никто не отстаёт больше чем на M месяцев - найденные вами обходные пути целенаправленно теряют актуальность.

Другие мысли, заслуживающие внимания

• Агенты ужасно анализируют данные, но всё равно колоссально ускоряют процесс. Любой самостоятельный анализ от агента, который он видел, содержал грубые ошибки (в одном заявлялось об утилизации ресурсов в 514%). Но цикл, где агент выдаёт результат, про который автор знает, что тот будет неверным, а сам лишь точечно исправляет ошибки, превратил двухдневный анализ примерно в 5 минут его личного времени. "Люди сильно недооценивают пользу от получения абсолютно неверных результатов от LLM".
• Автономные циклы деградируют без человека за клавиатурой; они продолжают делать ненулевой объём полезной работы, но куда меньший, чем при ежедневных сверках. Он пишет одноразовые vibe-coded скрипты оркестрации вместо готовых продуктов вроде Conductor или Gas Town, потому что агенту легко поручить собрать именно тот граф или структуру триажа, которая нужна для конкретной задачи.
• Разговор на разных языках (приложение): споры об агентном программировании столь ожесточённые, потому что разные рабочие процессы требуют разной надёжности, а требования к надёжности меняются с масштабом. Правило, дающее сбой "раз на 100 правило-агенто-дней", вполне подходит для 10 агентов под присмотром человека, но оказывается катастрофой для тысяч агентов, выкатывающих код без ревью. Многие подходы не обладают свойством масштабной инвариантности.
• ИИ для настольных игр как чистый тестовый стенд: агенты не могут самостоятельно итеративно создать сильный игровой ИИ (эвал Code Clash выявил ту же неспособность к итерациям), но с помощью двух нестрогих приёмов - смотреть на данные / иметь грубые эвалы и систематически устранять причины, а не симптомы - Луу примерно за 20 часов собрал бота для Azul с игрой сверхчеловеческого уровня, вообще не зная ML.