./новости · 30 июля 2026 г.
новость
Качество кода больше не живёт в самом коде: агенты пишут быстрее, чем люди читают
источник: @addyosmani · X·
машинная выжимка · сверена с источником
Addy Osmani
@addyosmani
Качество софта теперь зависит от ограничений, которые вы ставите вокруг своих агентов. Когда основную часть кода писали люди, качество было видно в самом коде. Чисто ли написано? Продуманно ли? Быстро ли работает? Разберётся ли другой инженер? Есть ли тесты? Агенты уже генерируют больше кода, чем люди успевают прочитать. Когда генерация кода обгоняет ревью, качество - проверки на корректность, поддерживаемость, безопасность, производительность и прочее - всё больше приходится держать в другом месте. Оно переезжает в обвязку, окружение и операционную систему вокруг агента. Это могут быть тесты и детерминированные проверки, которые решают, что системе позволено делать (и не только они). Именно ваши ограничения в итоге позволят циклам агентов надёжно выпускать production-софт. Сюда входят юнит-тесты, property-тесты, приёмочные тесты, мутационное тестирование и метрики качества. Такое обратное давление даёт системе отбить плохую работу до того, как она станет чьей-то ещё проблемой. Ставьте ограничения. Они решают, достаточно ли хорош код ваших агентов, чтобы его выкатывать.
· 10 тыс. просмотров
Эдди Османи 30 июля сформулировал: агенты выдают больше кода, чем человек успевает прочитать. Значит проверка качества переезжает из ревью в обвязку вокруг агента: юнит-тесты, property-тесты, приёмочные тесты, мутационное тестирование, метрики качества. Эти проверки и решают, что системе вообще позволено сделать.
Почему это важно: Пока код писали руками, качество смотрели глазами: чисто ли написано, есть ли тесты, разберётся ли следующий инженер. Ревью было узким местом и одновременно фильтром. Агент этот фильтр снимает: читать весь его выхлоп никто не станет. Османи предлагает перенести фильтр в среду, где тесты и детерминированные проверки создают обратное давление и не пускают плохую работу дальше по цепочке. Порогов он не называет ни одного: ни покрытия, ни минимального набора проверок.
Что дальше: Замерь свою обвязку на одном модуле: прогони мутационное тестирование и посчитай, сколько внесённых поломок тесты пропустили. Это число и есть планка, ниже которой мерж от агента принимать нельзя.
первоисточник