Мы привыкли считать, что ИИ в разработке — это ускоритель прогресса. Он пишет код, предлагает рефакторинг, добавляет тесты и в целом ведёт себя как стажёр с энтузиазмом и бессонницей. Но эксперимент Грега Паструхи показал: если дать этому стажёру власть и попросить его бесконечно улучшать качество, он может превратить аккуратное приложение в архитектурного монстра.
Эксперимент, который пошёл слишком далеко
Идея была простой и даже ироничной: взять рабочее приложение и 200 раз подряд попросить Claude «улучшить качество кодовой базы». Без вопросов, без стоп-критериев, без человеческого «хватит».
Результат:
- код вырос с 20 тысяч строк до 84 тысяч
- тесты — с ~700 до более чем 5 000
- комментарии — с полутора тысяч до почти 19 тысяч строк
Функциональность при этом осталась прежней. Новых фич нет. Пользовательского выигрыша — тоже.
Как ИИ понимает «качество»
Самое интересное здесь — не цифры, а логика, которой руководствовался ИИ. Для него «качество» оказалось набором легко измеримых суррогатов:
🧪 Больше тестов — значит лучше
Тесты росли быстрее, чем сам код. При этом e2e-тесты, которые реально проверяли работоспособность приложения, были… забыты.
🧱 Абстракции ради абстракций
ИИ начал тащить паттерны из других экосистем — например, Result и Option в стиле Rust — в TypeScript-приложение, где вся культура ошибок давно строится иначе.
🔐 Паранойя как добродетель
Появились паттерн «предохранитель» (circuit breaker), экспоненциальные задержки повторных попыток (exponential backoff) и проверки «энтропии ключей» — в приложении, которое дергает один API и не живёт под высокой нагрузкой.
🛠️ Абсолютный синдром «не придумано здесь» (Not Invented Here)
Вместо готовых библиотек — десятки тысяч строк самописных утилит: логгеры, хуки, функциональные комбинаторы с перегрузками на 20 параметров.
Почему это важно для всех, кто использует ИИ-кодинг
Этот эксперимент — не шутка и не «смотрите, какой глупый ИИ». Это зеркало.
ИИ честно оптимизировал то, что ему сказали оптимизировать. Проблема в том, что:
- качество не было формализовано
- полезность не входила в метрику
- поддерживаемость не измерялась
- человеческий контроль был выключен
ИИ не понимает, что код будут читать, чинить и сопровождать живые люди. Он видит только числовые сигналы: покрытие, количество проверок, глубину абстракций.
Личное мнение
Этот кейс отлично иллюстрирует ключевую мысль 2025 года:
ИИ — это не архитектор, а мощный усилитель намерений. Даже плохих.
Если вы не задали:
- чёткие критерии «что считать улучшением»
- ограничения на сложность
- приоритеты бизнес-ценности
ИИ с радостью превратит проект в идеально типизированный, полностью протестированный… и почти непригодный для жизни кодовый мега-комплекс.
И да — автор прав в главном: время на ревью ИИ-кода — не потерянное время. Это новая обязательная стадия разработки, а не временная мера.
Вывод
Эксперимент Паструхи — это предупреждение. Не про Claude. Не про конкретную модель. А про наше желание заменить мышление автоматикой.
ИИ отлично пишет код.
Но что именно стоит писать — всё ещё наша ответственность.
Ссылки
🔗 Оригинальная статья Грега Паструхи
https://gricha.dev/blog/the-highest-quality-codebase
Иногда, чтобы понять ценность простоты, нужно один раз увидеть, как выглядит «идеальное качество», доведённое до абсурда.