От редакции: Claude Fable 5 был выпущен 9 июня 2026 года. Anthropic позиционирует его как модель Mythos-уровня, специализирующуюся на долгосрочных задачах программной инженерии и обладающую улучшенными характеристиками безопасности.

После выхода новой модели разработчики быстро начали изучать её применение в реальных инженерных сценариях. Prompt для аудита репозитория, которым поделился @meta_alchemist, — яркий тому пример. Он заставляет Fable 5 не просто генерировать код, а систематически, как опытный технический руководитель, в четыре этапа анализировать репозиторий: сначала разобраться со структурой проекта и стеком технологий, затем на основе реальных файлов и номеров строк проверить архитектуру, безопасность, тесты, производительность, зависимости и документацию, после чего сформулировать стратегию улучшений и разбить её на вехи задач с приоритетами и оценкой трудозатрат. Некоторые пользователи уже с его помощью избавились от технического долга, обнаружили уязвимости безопасности и проблемы с эффективностью, пропущенные старыми моделями, а другие столкнулись с такими ранними проблемами, как нестабильность песочницы.

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

Далее следует оригинальный текст:

Вы уже используете Claude Fable 5?

Первое, что вам стоит сделать, — это использовать его для улучшения вашего ключевого проекта, чтобы значительно продвинуть все ваши текущие задачи.

Запустите в каждом важном для вас репозитории кода следующий «Промпт для аудита и улучшения проекта» (можно просто скопировать и вставить):

План аудита и улучшения репозитория кода

Вы — инженер-программист и эксперт по техническому аудиту мирового уровня, уровня ведущего инженера (Staff/Principal). Ваша задача — глубоко проанализировать данный репозиторий кода, предоставить честный отчёт об аудите и предложить выполнимый план улучшений с расстановкой приоритетов. Чётко следуйте четырём перечисленным ниже этапам по порядку, не пропускайте шаги.

Все выводы должны основываться на реальных доказательствах из файлов: указывайте путь к файлу и номер строки. Если что-то невозможно проверить, прямо укажите на это, а не строить догадки.

Этап 1 / Исследование и структурирование: сначала читаем, потом оцениваем

Прежде чем делать какие-либо выводы, систематически изучите весь репозиторий:

· Проанализируйте структуру директорий, определите тип проекта, используемые языки, фреймворки и цель запуска.

· Определите входные точки (entry files), ключевые модули, а также основные потоки данных и управления в системе.

· Прочитайте файлы манифеста пакета (package.json, pyproject.toml и т.д.), lock-файлы, конфигурации сборки, CI, конфигурации окружения/приложения, а также всю документацию, включая README, CONTRIBUTING, ADR и т.п.

· Определите назначение проекта: его цели, целевую аудиторию, а также текущий уровень зрелости — это прототип, внутренний инструмент, production-сервис или библиотека.

· Зафиксируйте уже принятые в проекте соглашения, включая стиль именования, границы модулей, паттерны обработки ошибок, стиль тестирования и т.д. Это позволит последующим рекомендациям соответствовать существующей инженерной культуре, а не противоречить ей.

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

Этап 2 / Аудит: на основе доказательств, с указанием степени серьезности

Проведите аудит по каждому из следующих направлений.

По каждому обнаруженному пункту зафиксируйте:

a) Что вы обнаружили

b) Где обнаружено, в формате: файл:номер_строки

c) Почему это важно, т.е. конкретные последствия, а не абстрактные принципы

d) Степень серьёзности: Critical (Критическая) / High (Высокая) / Medium (Средняя) / Low (Низкая)

Архитектура и дизайн

Границы модулей, степень связанности/связности, циклические зависимости, утечка абстракций, божественные объекты/файлы, нарушение слоёв (layering), узкие места расширяемости.

Качество кода

Дублирование кода, устаревший (мертвый) код, точки высокой сложности (hotspots), включая самые длинные функции и функции с наибольшим количеством ветвлений; непоследовательные паттерны; пробелы в обработке ошибок, например, проглоченные исключения, отсутствие проверки граничных случаев; уязвимости типобезопасности.

Безопасность

Жёстко запрограммированные секреты или учётные данные, риски инъекций, небезопасная десериализация, отсутствие валидации входных данных, слабые места аутентификации/авторизации, устаревшие зависимости с известными CVE, излишне разрешительные конфигурации.

Тестирование

Пробелы в покрытии тестами, особенно для ключевой бизнес-логики; качество тестов — проверяют ли они поведение или просто факт запуска; отсутствующие типы тестов (модульные, интеграционные, end-to-end); нестабильные (flaky) тесты; код, который сложно тестировать.

Производительность

Проблемы N+1 запросов, ненужные аллокации или копирования, блокирующие вызовы в асинхронных путях, отсутствие кэширования или индексов, проблемы неограниченного роста (например, памяти, файлов, очередей).

Зависимости

Устаревшие, неподдерживаемые, дублирующиеся или ненужные тяжёлые зависимости; риски лицензирования; состояние поддержки lock-файлов.

Опыт разработки и эксплуатации (DevEx & Ops)

Стоимость сборки/запуска, пробелы в CI/CD, отсутствие обязательных проверок линтером/форматтером, качество логов и наблюдаемости (observability), отчётности об ошибках, процесс деплоя.

Документация

Актуальность README, путь для новичков (onboarding), незадокументированное критически важное поведение, устаревшая документация, противоречащая коду.

Правила для этапа

Лучше предоставить 15 пунктов с высокой степенью уверенности, чем 50 спекулятивных.

Различайте факты и субъективные оценки. Например:

· Факт: «Эта функция не обрабатывает ошибки: src/api/client.ts:142»

· Оценка: «Границы ответственности этого модуля кажутся размытыми»

И чётко указывайте, что есть что.

Также перечислите сильные стороны репозитория. Преимущества не менее важны, так как определяют, что стоит сохранить.

Результат этапа: «Отчёт об аудите». Сгруппируйте выводы по направлениям, отсортируйте по степени серьёзности и включите раздел «Сильные стороны». Не забудьте указать на самые серьёзные проблемы, требующие первоочередного внимания.

Этап 3 / Стратегия улучшений

Синтезируйте результаты аудита в стратегию:

· Выделите 3–5 ключевых тем, которые объясняют большинство проблем, например, «Отсутствие чётких границ между слоями», «Обработка ошибок реализована фрагментарно и несистемно».

· Для каждой темы предложите целевое состояние и принципы, лежащие в его основе.

· Чётко обозначьте компромиссы: какие проблемы вы рекомендуете пока не исправлять, почему (например, несоответствие затрат и выгоды, высокий риск, текущий уровень зрелости проекта не требует этого).

· Определите, что означает «завершено» — приведите измеримые критерии, например, «Сборка в CI будет падать из-за ошибок линтера», «Покрытие тестами ключевых модулей ≥ 80%», «Количество проблем уровня Critical равно нулю».

Этап 4 / Подробный план задач

Превратите стратегию в исполняемый план:

Разбейте работу на отдельные задачи. Каждая задача должна включать:

· Заголовок и краткое описание

· Затронутые файлы/области

· Критерии приемки (acceptance criteria) — как проверить, что задача выполнена

· Оценка трудозатрат: S = менее 2 часов, M = полдня, L = 1–2 дня, XL = требует дальнейшей декомпозиции

· Риск самого изменения — может ли оно нарушить существующую функциональность

· Зависимости от других задач

Распределите задачи по вехам (milestones):

Веха 0

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

Веха 1

Критические исправления: проблемы безопасности и корректности.

Веха 2

Высокоэффективные улучшения: изменения, которые облегчат всю последующую работу.

Веха 3

Качество и полировка: оставшиеся проблемы средней и низкой приоритетности, которые стоит исправить.

Отдельно выделите «быстрые победы» (quick wins) — задачи с высоким эффектом, трудоёмкостью S, которые можно выполнить немедленно.

Для трёх задач с наивысшим приоритетом приведите краткую схему реализации, включающую подход, ключевые шаги и возможные подводные камни.

Формат итогового результата

Сформируйте единый документ, содержащий следующие разделы:

Краткая сводка (Executive Summary): не более 10 предложений. Дайте общую оценку здоровья проекта от A до F с обоснованием; перечислите Топ-3 главных риска и Топ-3 главных возможности.

Карта репозитория (Repo Map)

Отчёт об аудите (Audit Report)

Стратегия улучшений (Improvement Strategy)

План задач (Task Plan): включая вехи, таблицу задач и быстрые победы

Открытые вопросы (Open Questions): перечислите информацию, требующую принятия решений человеком, например, цели продукта, модули, которые можно упразднить, целевые показатели производительности и т.п.

Ограничения

В процессе данного аудита не вносите изменений в код. Только анализ.

Не заполняйте отчёт «для галочки». Если по какому-то направлению всё в порядке, ограничьтесь одной констатирующей фразой и двигайтесь дальше.

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

Анализируйте реальные потребности проекта и давайте рекомендации максимально практичным способом.

Если репозиторий очень большой, сосредоточьте углублённый анализ на самых ключевых 20% кода (которые выполняют 80% работы) и укажите, какие области были изучены поверхностно.