Опубликовано: 2026-10-21

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

Причина: рост объёма кода

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

Сводка пересмотренных принципов

1. Комментарии заменяются минимальным кодом

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

Его команда теперь запрещает комментарии в скриптах сборки. Команда запрещает все комментарии в проектах на Haskell и JavaScript. В проектах на Java команда движется к полному запрету. Исходный код в проектах команды не содержит комментариев.

2. Легаси-код возрождается

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

• Статический анализатор. Спикер создал статический анализатор для Java 10–12 лет назад. Проект широко использовался, но его поддержка стала дорогостоящей. За 10 лет в бэклоге накопилось более 400 тикетов. Весной он попросил Claude Code исправить все 400 ошибок, восстановить кодовую базу, обновить её, обновить зависимости и преобразовать её в чистый современный проект. Работа заняла около недели. По его словам, код он не редактировал вручную. В результате проект восстановлен, бэклог очищен, а дефектов осталось всего несколько.
• Второй проект. Спикер ссылается на безымянного автора, который потратил полтора года на похожую задачу. Затем этот автор завершил восстановление за три недели и потратил на это несколько тысяч долларов.

Спикер делает вывод, что команда больше не относит репозитории к легаси. Оставшийся старый код он описывает как код, который ещё не обработан Claude Code или другим агентом.

3. Агенты заменяют ручную сортировку и ревью

Ранее докладчик придерживался мнения, что основные обязанности мейнтейнера таковы:

1. Сортировка (triage): определение того, является ли поступивший отчёт дефектом, и либо направление его в бэклог, либо отклонение.
2. Ревью: оценка диффов в запросах на изменение и решение о том, принимать ли их.

Он утверждает, что личное участие в этих задачах теперь вредит проекту, поскольку объём слишком велик. Он приводит следующие показатели для одного из своих репозиториев:

• Около 1 500 звёзд.
• Около 100 новых отчётов об ошибках каждое утро.
• Около 10 активных репозиториев такого рода, что в сумме составляет около 1 000 отчётов об ошибках в день.

Он заявляет, что не может обрабатывать такой объём вручную.

Его текущая система использует агентов, которые запускаются каждое утро или несколько раз в день. Агенты:

• Проверяют поступающие отчёты об ошибках, принимают те, что описывают реальные ошибки, и принимают их от его имени.
• Проверяют pull request'ы и автоматически сливают их.

Он сообщает, что 40–50 pull request'ов ежедневно попадают в кодовую базу без его ревью. Он описывает проект как активный, находящийся в продакшене и используемый.

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

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

4. Жёсткий отказ вместо вежливости

Ранее докладчик учил студентов, что с участниками open source следует обращаться вежливо. Он советовал при отклонении вкладов использовать вежливые формулировки, например «спасибо», «пожалуйста» и «извините». Он отмечал, что участники проекта — ценный ресурс и могут вернуться с новыми изменениями.

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

• Отклонять изменения, не соответствующие направлению проекта, без переговоров.
• Использовать для этого инструменты автоматического отклонения.

Он утверждает, что никто не будет обижен, так как, по его мнению, программиста на другой стороне нет.

5. Автоматические ограничения на размер запросов на слияние

Ранее команда придерживалась мнения, что запросы на слияние (pull requests) должны быть короткими. Изменения объёмом от 100 до 200 строк считались приемлемыми. Запросы на слияние объёмом 1000 строк и более считались по своей природе плохими. Члены команды спорили о том, нужно ли разбивать большие функции. Некоторые утверждали, что большую функцию невозможно разделить на пять запросов на слияние и что необходим один запрос объёмом 1000 строк.

За шесть месяцев до доклада команда добавила автоматическую проверку на свою платформу GitHub. Проверка применяется к каждому запросу на слияние:

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

Докладчик заявляет, что команда планирует добавить новые автоматические средства контроля, чтобы достичь нулевой терпимости к некачественным изменениям.

6. Читаемые человеком тестовые артефакты и метрики воздействия

Дизайн тестов

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

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

• Прежний подход: Большое количество тестов на Java, каждый из которых содержал входной блок кода и ожидаемый XML-вывод, и сравнивал их.
• Текущий подход: Команда оставила один тест и большое количество YAML-файлов, называемых тестовыми фикстурами. Каждый файл содержит фрагмент кода для разбора и XML-фрагмент, который из него должен получиться.

Когда поступает pull request, докладчик просматривает изменения в YAML. Он не читает изменения в коде, которые, по его словам, больше не может понимать, в том числе код, написанный его агентами. Он сообщает, что читает YAML-диф, проверяет пары входных и выходных данных и принимает изменение, если результат верен. Он отклоняет изменения, если вывод неверен.

Докладчик утверждает, что код трудно читать, а YAML читается легче. Он описывает текстовые файлы как следы выполнения тестов. Тесты либо генерируют эти файлы, либо читают их как источник.

Он говорит, что десяток изменений в YAML в день можно быстро проверить. Он описывает это как решение проблемы объема.

Замена проверки диффов метриками воздействия

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

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

Он рекомендует настроить CI так, чтобы каждый pull request сообщал о своем воздействии. Отчет должен включать:

• Изменения производительности.
• Изменения визуальных артефактов.
• Изменения объема кода.
• Изменения других измеримых показателей качества.

Докладчик утверждает, что отчет должен описывать последствия изменения в читаемых человеком метриках, а не механику изменения. Он считает, что командам следует сосредоточиться на инструментах контроля воздействия, а не на ручной проверке и анализе дефектов.

7. Скорость вытесняет стабильность в непрерывной интеграции

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

Команда перешла на предварительную сборку (preflight build). В этом процессе робот сборки, а не ИИ-агент, сливает ветку в master, запускает сборку и отправляет изменения в master только в том случае, если код компилируется.

Докладчик утверждает, что для команды этот подход больше не работает:

• Команда получает около 100 pull request в день.
• Каждая сборка занимает около 10 минут.
• Поскольку каждый принятый pull request меняет master, последующие pull request необходимо пересобирать после него. Сборки, таким образом, выполняются последовательно, что в сумме составляет около 1 000 минут в день.
• GitHub Actions считает любое изменение master недействительным для открытых pull request, поскольку их результаты CI относятся к предыдущему состоянию master. Авторам тогда приходится выполнять операцию обновления ветки.
• GitHub не позволяет запускать такое количество одновременных сборок, которое требуется при данной нагрузке.

Команда попыталась сократить время сборки, разделив проект. Докладчик утверждает, что 10 минут — это минимум для кодовой базы в 100 000 строк.

Докладчик делает вывод, что стабильность при таком объёме недостижима и что объём будет продолжать расти. Он говорит, что теперь команда исходит из того, что master сломан. Master ломается примерно два раза в день. Команда использует следующую процедуру:

1. Скрипты отслеживают master и определяют момент, когда он становится красным.
2. Когда появляется сбой, немедленно запускается Claude Code.
3. Claude Code исправляет дефект и отправляет новый pull request.
4. Команда принимает исправление, и разработка продолжается.

Докладчик утверждает, что в новой реальности master почти всё время сломан. Он говорит, что не знает другого способа справляться с этим состоянием. По его словам, команда пришла к выводу, что стабильность — это идея прошлого, а текущий приоритет — скорость. Код должен быстро попадать в master, даже ценой стабильности.