Если ты регулярно пользуешься современными инструментами автономного кодинга вроде Claude Code CLI, Cursor Composer или Aider, то наверняка ловил себя на привычке к ленивому итеративному промптингу. Вместо того чтобы писать четкое инженерное ТЗ с описанием архитектуры и граничных условий, мы просто бросаем в терминал лаконичные фразы: «Сделай лучше», «Добавь функционал», «Отполируй верстку».
И поначалу кажется, что это работает: нейросеть услужливо правит стили, добавляет плавные анимации и наводит порядок в коде. Но что произойдет, если этот цикл запустить на полную катушку и не останавливать?
Технический обозреватель и разработчик Нейт Херк решил провести жесткий эмпирический стресс-тест. Он взял базовую заготовку сайта локальной кофейни (простой статический проект на HTML, CSS и JavaScript) и принудительно скормил терминальному агенту Claude Code ровно сто последовательных итераций с единственной инструкцией: «Make this website better. Focus on improvements».
В эксперименте лоб в лоб столкнулись две флагманские модели Anthropic: сбалансированная Claude Sonnet 5.5 и тяжелая рассуждающая модель Claude Opus 5.5. Результаты наглядно показали, почему слепое доверие автономным агентам смертельно опасно для любого живого проекта.
Sonnet 5.5 против Opus 5.5: скромный перфекционист против безумного архитектора
Поведение моделей с первых же шагов разошлось по диаметрально противоположным траекториям.
Как вела себя Claude Sonnet 5.5:
- Первые 15 итераций модель действовала исключительно прагматично: вычистила семантическую разметку, улучшила доступность интерфейса для скринридеров (стандарты a11y), оптимизировала размеры шрифтов и добавила ненавязчивые микроанимации при наведении на карточки меню.
- В районе 35–45 итераций Sonnet фактически стабилизировал кодовую базу. Модель начала сообщать, что проект уже отполирован до предела, и перешла к микроправкам: корректировала комментарии к функциям, форматировала отступы и заменяла hex-цвета на переменные.
- Итоговый объем проекта удержался в разумных пределах: от исходных 800 строк кодовая база выросла всего до 1600–1800 строк чистого, читаемого кода.
Что натворил Claude Opus 5.5: Opus воспринял фразу «сделай лучше» как карт-бланш на безудержную экспансию. У модели начисто отключилось чувство меры:
- К 30-й итерации на простом сайте кофейни появились интерактивный калькулятор стоимости обжарки зерен с выбором высоты произрастания кофе, система онлайн-бронирования столиков с выбором зала и анимация поднимающихся частиц пара над чашкой на Canvas;
- К 60-й итерации Opus внедрил симуляцию корзины с фейковым платежным шлюзом, многоуровневую систему лояльности с начислением виртуальных бонусов и генератор персональных рецептов кофе;
- К 80-й итерации объем проекта превысил 21 000 строк кода!
И вот здесь наступил неизбежный коллапс. Новые модули начали намертво конфликтовать со старыми зависимостями. Сборщик Vite стал падать с циклическими ошибками импорта, стили в CSS начали хаотично перетирать друг друга, а некогда легкий сайт превратился в перегруженную, тормозящую цифровую кашу. Это хрестоматийный пример синдрома раздувания кода (Code Bloat) и так называемого AI Slop.
Парадокс инструментального ступора: почему модели не пошли в веб
В ходе эксперимента вскрылась поразительная деталь, о которой стоит знать всем архитекторам агентных пайплайнов.
В окружении Claude Code был штатно активирован инструмент веб-поиска. Казалось бы: получив абстрактную задачу «сделать сайт лучше», модель должна была пойти в интернет, посмотреть тренды веб-дизайна 2026 года, изучить реальные сайты премиальных кофеен или проверить актуальные версии библиотек.
Но ни Sonnet, ни Opus ни разу не воспользовались веб-поиском! Модели проявили классический инструментальный ступор (Tool Hesitation), опираясь исключительно на внутренние веса и галлюцинируя новые фичи из головы.
Как автоматизировать контроль и защитить проект через CLAUDE.md
Для замера метрик роста объема кода Нейт написал простой автоматический bash-скрипт, который запускал итерации в цикле и собирал статистику строк через команду wc:
#!/usr/bin/env bash
# Цикл итеративного промптинга с фиксацией строк кода
set -euo pipefail
LOG_FILE="bloat_metrics.csv"
echo "iteration,lines_of_code,files_count" > "$LOG_FILE"
for i in $(seq 1 100); do
echo "--- Итерация $i / 100 ---"
claude -p "Make this website better. Focus on improvements." --dangerously-skip-permissions
LOC=$(find src -type f ( -name "*.js" -o -name "*.css" -o -name "*.html" ) -exec cat {} + | wc -l)
FILES=$(find src -type f ( -name "*.js" -o -name "*.css" -o -name "*.html" ) | wc -l)
echo "$i,$LOC,$FILES" >> "$LOG_FILE"
done
Главный практический вывод из этого эксперимента: автономным кодерам категорически нельзя выдавать неограниченную свободу действий. В любом проекте, где задействован Claude Code, в корневой директории обязан лежать файл правил CLAUDE.md с жесткими ограничителями:
# Архитектурные правила проекта (Guardrails)
- Запрещено добавлять новые пользовательские фичи без явного запроса.
- Максимальный размер любого исходного файла: 300 строк кода.
- При получении абстрактных команд («сделай лучше») агент обязан:
1. Выполнять только оптимизацию производительности и устранение багов.
2. Не создавать новые зависимости в package.json.
3. Сохранять текущую архитектуру компонентов.
Если не установить эти границы, рассуждающая модель вроде Opus превратит аккуратный лендинг в монструозный комбайн, который ни один живой программист потом не сможет распутать.