Когда кто-то говорит, что в одиночку выпустил 335 живых страниц в 26 репозиториях за 29 дней, первым делом хочется спросить, как ему удалось двигаться так быстро. Но правильнее спросить: что при этом сломалось.

Цифры реальны: 1 549 коммитов, 26 репозиториев, 29 дней, один разработчик с Claude Code. Но сама скорость мало чему учит. Важна природа сбоев, потому что это были не те ошибки, которые можно поймать в стек-трейсе. Это были структурные разломы. Их замечаешь, только когда отходишь от редактора и смотришь на всю систему, работающую в продакшене.

Что сработало

Скорость не была иллюзией. Время выполнения определенных задач действительно сокращается в разы, когда поручаешь их ИИ, который не спит.

Классические алгоритмы превращались в готовые фичи за дни, а не недели. Решатель для 2048 и игры на основе minimax были реализованы быстро, так как паттерны их внедрения хорошо документированы. Модель не теряется в академических статьях; она пишет дерево поиска, эвристическую оценку, подсчет очков за ходы и идет дальше. Это решенные задачи, а ИИ-парный программист справляется с ними с невероятной эффективностью.

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

Настоящим сюрпризом стала последовательность. Когда просишь ИИ сгенерировать десятки лендингов, отклонения неизбежны, если их не ограничить. Я использовал небольшие файлы памяти, чтобы зафиксировать единую систему бренда: правила тональности (voice rules), названия цветовых токенов, ограничения компонентов и архетипы страниц. Модель считывала эти ограничения в начале каждой соответствующей задачи и выдавала результат, который выглядел так, будто его сделал один человек, а не двадцать девять разных личностей.

Что на самом деле сломалось

Сбои были архитектурными. Ни одна сборка не падала из-за пропущенной точки с запятой. Вместо этого система постепенно вводила меня в заблуждение, создавая иллюзию, что всё в порядке.

Первой ударила SEO-каннибализация. ИИ создал новый хаб инструментов по новому URL, в то время как старый хаб всё еще находился по своему прежнему адресу. Каждая отдельная страница была оптимизирована. Заголовки были четкими. Мета-описания — уникальными. Контент — полезным. Но все они нацеливались на один и тот же поисковый интент. Поисковые системы видели два авторитетных ресурса по идентичным запросам и не ранжировали ни один из них. Идеальные страницы аннулировали друг друга, потому что никто не смотрел на сайт как на единое целое, а не как на набор файлов.

Затем возникли несоответствия URL. Разные репозитории использовали слегка отличающиеся структуры папок для одного и того же логического контента. В одном репозитории инструменты находились в /tools/utility-name, в другом — в корне /utility-name. CDN видел оба варианта, создавал цепочки редиректов для их разрешения и начинал выдавать ошибки на границе (at the edge). Страницы в итоге загружались, но каждый редирект сжигал краулинговый бюджет и терпение пользователей. Код был верным. Топология — хаотичной.

Затем возникла ловушка синхронизации. Я обновил зеркальный сайт — стейджинг или бэкап — но забыл перенести эти изменения обратно в исходный репозиторий. Когда позже я попросил ИИ синхронизировать среды, он воспринял зеркало как истину в последней инстанции (ground truth). Простая команда синхронизации могла перезаписать рабочую базу данных или набор файлов устаревшими данными из зеркала. ИИ выполнял то, что я описывал, а не то, что я имел в виду. Намерения не поддаются сравнению (diff), в отличие от файлов.

Сами инструменты аудита лгали. Поскольку я автоматизировал проверку, я полагал, что результаты будут чистыми. Это было не так. Написанные ИИ скрипты аудита содержали тонкие баги: ошибки на единицу (off-by-one), неверные предположения о кодах состояния редиректов, фантомные ошибки, вызванные таймингами или заголовками, а не реальными ошибками конфигурации. Они сообщали о проблемах, которых не существовало, заставляя меня гоняться за призраками. Я научился не доверять статическому анализу, пока не проверю живой сайт вручную и не подтвержу симптом в браузере или через прямой curl.

Скрытая цена

Вот цифра, о которой никто не говорит: 93 процента моих затрат на токены ушли на повторное чтение кэшированного контекста.

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

Это не причуда. Это прямой налог на плохую гигиену сессий.

Как это исправить

Решения оказались простыми, как только я сформулировал проблемы.

Рассматривайте одну сессию как одну задачу. Когда характер работы меняется, начинайте с чистого листа. Искушение сохранить контекст «теплым» велико — кажется, что вы экономите время на настройке — но на самом деле вы берете память в аренду под сложные проценты.

Храните знания в небольших специализированных файлах памяти. Не позволяйте модели тащить брендбуки, библиотеки компонентов или SEO-правила внутри контекста диалога. Записывайте их на диск в кратких файлах и ссылайтесь на них явно. Это переносит информацию из дорогого волатильного контекста в дешевое постоянное хранилище.

Между разными задачами очищайте рабочее пространство. Закрывайте сессию. Открывайте новую. Тридцать секунд на настройку сэкономят доллары и предотвратят галлюцинации в будущем.

Уроки масштабирования

Если вы собираетесь работать в таких объемах, вам нужны защитные механизмы, которые рассматривают системой, а не файлом, единицу проверки.

Проводите бенчмарки перед публикацией. Не предполагайте, что страница работает только потому, что она отрисовывается. Проверяйте время загрузки, мобильную верстку и ключевые метрики по развернутому URL. Красивый компонент в локальной разработке может «развалиться» в реальных сетевых условиях.

Сверяйте diff перед копированием. Никогда не запускайте массовую синхронизацию или операцию копирования вслепую. Смотрите на дельту. Понимайте, в каком направлении движутся данные. ИИ не предупредит вас о том, что вы вот-вот перезапишете живые данные клиентов.

Проверяйте живые сайты, прежде чем доверять аудиту. Статический анализ — это гипотеза. Живой запрос — это доказательство. Если инструмент аудита сообщает о битой ссылке или циклической переадресации, проверьте это прямым запросом. У инструментов тоже бывают баги, особенно у тех, что написаны ИИ, работающим на основе предполагаемых паттернов.

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