Fable 5 против Opus 5: что 24 часа реального кода рассказали о выборе модели

На неделе в комьюнити Claude Code разошлись два наблюдения, которые на первый взгляд не связаны, но на деле бьют в одну точку: как AI-инструменты меняют наши критерии качества кода и то, кого — модель или линтер — стоит спросить перед тем, как коммитить.

Fable 5 или Opus 5 для кода: сравнение на практике

Разработчик под ником adocomplete провёл около суток, работая параллельно с Fable 5 и Opus 5 над одним и тем же проектом, и опубликовал наблюдения без маркетинговой шелухи — просто то, что увидел. Итог: обе модели пишут отличный код, но ведут себя по-разному в условиях неопределённости. Fable 5 заметно лучше справляется с open-ended промптами и чаще попадает в цель с первого раза — модель тратит время на то, чтобы разобраться в кодовой базе, и не стесняется спорить, если видит более удачное решение, чем то, что попросили. Opus 5 выдаёт сопоставимое качество, но требует более точной постановки задачи: получив чёткие инструкции, он справляется ничуть не хуже, однако склонен делать ровно то, что сказано, даже когда есть путь получше.

Почему это важно для выбора модели в Claude Code

Разница — не про «сильнее/слабее», а про профиль поведения, который стоит учитывать при выборе модели под задачу. Для исследовательских шагов — рефакторинг незнакомого модуля, архитектурные решения, задачи с расплывчатым ТЗ — модель, которая сначала разбирается и готова возразить, экономит часы отладки чужих (в данном случае — своих же) поспешных решений. Для рутинных, хорошо специфицированных задач — миграции, генерация тестов по шаблону, точечные правки — модель, которая делает ровно то, что просят, предсказуемее и быстрее. На практике это довод в пользу гибридного использования: не искать «лучшую» модель раз и навсегда, а подбирать её под фазу работы, в том числе через subagents с разными моделями внутри одного проекта.

Ruff 0.16 и новая планка чистоты Python-кода

Второе наблюдение — от Саймона Уиллисона, известного своими экспериментами на стыке Python и LLM-инструментов. Свежий релиз Ruff 0.16.0 от Astral увеличил число включённых по умолчанию правил линтинга с 59 до 413 — почти в семь раз. Результат не заставил себя ждать: в одном только проекте sqlite-utils новый набор правил высветил 1618 предупреждений, которые раньше просто не проверялись.

Что это значит для AI-ассистированной разработки

Для проектов, где значительная часть кода генерируется с участием Claude Code или других агентов, это важный сигнал. Линтер — один из немногих объективных фильтров, стоящих между «модель написала работающий код» и «код соответствует принятым в экосистеме стандартам». Резкое расширение дефолтных правил означает, что код, который вчера проходил проверку без единого замечания, сегодня может обнажить сотни скрытых огрехов — не потому что стал хуже, а потому что планка выросла. Это ровно та ситуация, где вести CI без строгого линтинга становится рискованнее: агент способен быстро наштамповать код, но самостоятельно не подтянется под новый стандарт, пока линтер явно не укажет на проблему.

Вывод

Оба сюжета — про одно и то же смещение ответственности. Чем активнее в разработке участвуют модели вроде Fable 5 и Opus 5, тем важнее становятся два человеческих решения: какую модель дать задаче и какими правилами проверять то, что она выдаёт. Первое — вопрос профиля поведения модели, а не абстрактного рейтинга. Второе — вопрос того, готовы ли ваши инструменты линтинга расти вместе с объёмом сгенерированного кода. Игнорировать любой из этих двух вопросов — значит рано или поздно получить код, который «работает», но не выдерживает более пристального взгляда.