Сравнение Claude Code Fable и Codex в реальной разработке

Claude Code Fable вернулся в рабочий цикл, и автор сразу погнал его по проекту

По словам автора поста, модель Claude Fable 5 снова доступна в свободном режиме до или по 7 июля. Он использовал этот период для доработки текущего мобильного приложения и описал ощущения как тот самый режим, где разработчик формулирует задачу, а модель делает реализацию.

Важная оговорка: это не бенчмарк, не лабораторный тест и не таблица с метриками. Это полевой отчёт одного разработчика по одному проекту. Но именно такие отчёты часто ближе к реальности, чем стерильные промо-демо: там есть документация, старые решения, правила проекта, усталый контекст и вечная грязь вокруг кода.

Автор пишет, что технических ошибок у Claude Code Fable в его сценарии «просто нет», а архитектурные промахи встречались, но правились за одну-две итерации. Для команды это звучит не как «можно уволить разработчиков», а как нормальный сигнал: модель может быстро закрывать прикладные задачи, если ей дать рамки. Без рамок она, как любой джун на энергетиках, начнёт строить храм из абстракций там, где нужен один метод и тест.

Codex подтянулся в коде, но вокруг кода, по наблюдению автора, шумит сильнее

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

По его описанию, обе системы многословны, но у Codex больше «разбрасывания в стороны»: он цепляется за незначительные детали, теряет главное и слабее держит инструкции. Claude Code Fable, наоборот, в этом прогоне выглядел жёстче: лучше следовал правилам, меньше уходил во второстепенное, давал более простой и понятный чек-лист.

Тут нет магии. Если ассистент пишет хороший код, но генерирует мусорную документацию, у вас всё равно проблема. Мусорная документация живёт дольше плохого коммита. Коммит можно откатить. А README, где половина текста — декоративный туман, потом копируют в onboarding, таски и внутреннюю wiki. Через месяц команда уже дебажит не баг, а мифологию.

Отдельная деталь: автор не использовал MCP, RAG, скилы и хуки. Он пишет, что «зашил всё в память»: общую пользовательскую память, описание проекта и правила работы. Это хороший практический маркер. Перед тем как городить интеграции, стоит проверить базовую дисциплину: есть ли у модели стабильные правила проекта, понимает ли она структуру, не забывает ли ограничения между задачами.

Контекстное окно стало наблюдаемым — и это полезнее, чем гадать по тормозам

Самая прикладная часть поста — команда /context в чате Claude Code. Автор пишет, что теперь в desktop-версии можно посмотреть процент загруженности контекстного окна и увидеть, чем именно оно занято. Раньше, по его словам, приходилось ориентироваться по тормозам чата или спрашивать саму модель, не пора ли начинать новый диалог.

Для разработчика это почти лог уровня df -h, только для мозгов ассистента. Не надо гадать, почему модель внезапно стала хуже держать задачу: контекст забит, фокус поплыл, старые решения смешались с новыми. Дальше начинается обычная инженерия: новый чат, короткое резюме состояния, актуальные правила, ссылка на нужные файлы, без свалки из прошлых обсуждений.

Минимальный порядок перед тем, как звать AI в проект:

git status
git switch -c ai-polishing
git diff --stat
npm test

После пачки правок:

git diff
git log --oneline -5
npm run lint
npm test

Если модель трогала архитектуру — не верьте словам, верьте диффу. Если писала документацию — режьте воду. Если чат распух — проверяйте контекст и заводите новый. И да, перед экспериментами делайте бэкап. AI-ассистент может быть полезным напарником, но git reset --hard всё ещё не психотерапевт.