12 сентября 2026 г.
Код от Claude в продакшне держится на правилах: 4 шага и /verify перед каждым PR
12 сентября 2026 Addy Osmani указал, что качество продакшн-кода от Claude держится на ограничениях, а не на обещаниях модели. Сначала задайте итог, границы и невозможные изменения. Затем дайте Claude точные команды `build`, `test`, `lint` и отбрасывайте плохой вариант до открытия PR.
Addy Osmani
@addyosmani
Как вы держите планку на коде для продакшна? 1. Сначала согласуйте итог и ограничения. Что значит «готово»? Что нельзя трогать? Проще ли сделать рефакторинг или переиспользовать то, что уже есть? Только после этого дайте Claude готовить результат. Не нужен длинный ритуал планирования на каждом новом релизе модели. Нужен фильтр, который выбросит плохое изменение прежде, чем оно станет PR. 2. Дайте Claude способ проверить свою работу. Впишите точные команды сборки, тестов и линтинга. Превратите отклонённые замечания ревью в навыки: /verify, e2e, schema checks и так далее. Запускайте это перед открытием PR. Используйте /code-review. Качество живет в рамках, которые вы задаете агентам, и это стоит потраченного времени. 3. Ваше задание — дизайн и планка. Радиус влияния определяет глубину чтения. Код-черновик с маленьким риском можно держать как чёрный ящик. Продакшн-код, который пишет Claude, должен иметь более высокий порог, особенно если он касается денег, авторизации или пользовательских данных. 4. Если Claude ошибся, не чините это вручную и втихую. Запишите урок в CLAUDE.md или skill. Если ошибка повторяется, подключайте самую новую frontier-модель, увеличивайте усилие или просите Claude закрыть долг и сделать кодовую базу проще для работы. Начните с одной проверки, которая у вас уже должна запускаться на каждый PR сегодня. Остальное нарастит само.
Привет. Я думаю, есть место для обоих подходов. 1. Прототипы и другой выбрасываемый код можно считать полностью чёрным ящиком. Если его всё равно выкинуть, и если радиус разрушения при падении мал, он не обязан быть идеальным. 2. Код для продакшна, написанный Claude, должен иметь более высокий стандарт, чем код, написанный человеком. В Anthropic для этого включены множество ограждений: много правил линта, много тестов, e2e-тесты от Claude, ежедневные fuzzers от Claude, автоматические code reviews и security reviews, автоматический рефакторинг и так далее.
· 7,2 тыс. просмотров
Раньше кодовые изменения часто проходили через эксперименты, а отбраковка начиналась уже после подачи PR. Теперь контроль перестраивают в обратную сторону: сначала рамка задачи и критерии done, потом проверочный цикл. В фактуре Addy на 12.09.2026 это зафиксировано как 4 вопроса в `CONSTRAINTS.md`, `/verify` с базовым бюджетом 90 секунд и перенос правил в `CLAUDE.md` или skill, чтобы проверка повторялась в каждом репозитории. Добавить сюда нужно меньше случайности и больше повторяемых барьеров для продакшн-частей.
Дальнейшая линия: такие правила будут внедряться в инженерный процесс как обязательный контур для задач с деньгами, авторизацией и пользовательскими данными.
Первоисточник
