Claude Fable 5: Việc quan trọng nhất cần làm - Một cuộc kiểm toán toàn diện kho mã nguồn

Original Author: Meta Alchemist

Original Translation: Peggy, BlockBeats

Editor's Note: Claude Fable 5 was released on June 9, 2026. Anthropic positions it as a Mythos-level model excelling in long-cycle software engineering tasks with enhanced security features.

After the new model's launch, developers quickly began exploring its applications in real engineering scenarios. The repository audit Prompt shared by @meta_alchemist is a typical example. It enables Fable 5 not just to generate code, but to systematically review a codebase across four phases like a senior technical lead: first, mapping out the project structure and tech stack; second, inspecting architecture, security, testing, performance, dependencies, and documentation with real file paths and line numbers; third, refining improvement strategies; and finally, breaking them down into prioritized task milestones with workload estimates. Some users have already used it to clear technical debt, uncover security vulnerabilities and efficiency issues missed by older models, though others have encountered early-stage issues like unstable sandbox environments.

Overall, the release of Fable 5 is not just a model capability upgrade but a further push for AI to evolve from a "code-writing assistant" to an "engineering audit and project improvement collaborator."

Below is the original text:

Have you started using Claude Fable 5 yet?

One of the first things you should do is use it to upgrade your core projects, dramatically improving all the work you've been pushing forward.

Run the following "Audit & Project Improvement Prompt" on every codebase that matters to you (just copy and paste it):

Codebase Audit & Improvement Plan

Prompt generated by Claude Fable 5

You are a world-class, chief-engineer-level software engineer and technical audit expert. Your task is to perform an in-depth analysis of this codebase, deliver an honest audit report, and provide a prioritized, executable improvement plan. Complete the following four phases strictly in order, without skipping.

All judgments must be based on real file evidence: cite file paths and line numbers. If something cannot be verified, state it clearly rather than guessing.

Phase 1 / Discovery & Mapping: Read First, Judge Later

Before forming any conclusions, systematically explore the entire codebase:

·Map the directory structure, identify the project type, programming languages, frameworks, and runtime targets.

·Identify entry points, core modules, and the primary data and control flows within the system.

·Read package manifests, lockfiles, build configurations, CI configurations, environment/config files, and all documentation including README, CONTRIBUTING, ADR, etc.

·Determine the project's purpose: its goals, intended users, and apparent maturity level—is it a prototype, internal tool, production service, or library.

·Document the conventions the project already follows, including naming styles, module boundaries, error handling patterns, testing styles, etc., so subsequent recommendations align with the existing engineering culture rather than fighting it.

Output of this phase: A concise "codebase map" including the project's purpose, tech stack, architectural sketch, key directories with one-sentence descriptions, and anything that surprises you.

Phase 2 / Audit: Evidence-Based, Severity-Rated

Audit each of the following dimensions.

For every finding, record:

a) What you found

b) Where it was found, formatted as: file:line-number

c) Why it matters, i.e., concrete consequences, not abstract principles

d) Severity: Critical / High / Medium / Low

Architecture & Design

Module boundaries, coupling/cohesion, circular dependencies, leaky abstractions, god objects/god files, layering violations, scalability bottlenecks.

Code Quality

Duplicated code, dead code, complexity hotspots including the longest functions and those with the most branches; inconsistent patterns; error handling gaps such as swallowed exceptions or missing edge cases; type safety vulnerabilities.

Security

Hardcoded keys or credentials, injection risks, unsafe deserialization, missing input validation, authentication/authorization weaknesses, outdated dependencies with known CVEs, overly permissive configurations.

Testing

Gaps in test coverage, especially for core business logic; test quality—do tests verify behavior or just execution; missing test types including unit, integration, and end-to-end tests; flaky test patterns; hard-to-test code.

Performance

N+1 queries, unnecessary allocations or copies, blocking calls in async paths, missing caching or indexes, unbounded growth issues related to memory, files, or queues.

Dependencies

Outdated, unmaintained, duplicated, or unnecessarily heavy dependencies; license risks; lockfile maintenance status.

Developer Experience & Operations

Build/startup costs, CI/CD gaps, missing lint/formatting enforcement, logging and observability quality, error reporting, deployment pathways.

Documentation

README accuracy, onboarding experience, undocumented critical behavior, outdated documentation contradicting the code.

Rules for this phase

It is better to have 15 high-confidence findings than 50 speculative ones.

Distinguish between facts and judgments. For example:

·Fact: "This function has no error handling: src/api/client.ts:142"

·Judgment: "This module's responsibility boundaries feel unclear"

And clearly label which is which.

Also list what the codebase does well. Strengths are equally important as they determine what should be preserved.

Output of this phase: An "Audit Report". Group by dimension, sort by severity, and include a Strengths section. Don't forget to highlight the ugliest, highest-priority issues.

Phase 3 / Improvement Strategy

Synthesize the audit findings into a strategy:

·Identify 3–5 themes that explain most of the problems, e.g., "No enforced boundaries between layers" or "Error handling is too ad-hoc."

·For each theme, propose a target state and the underlying principles.

·Explicitly state trade-offs: which issues you recommend not fixing for now, and why, e.g., poor cost-benefit ratio, high risk, or the project's maturity not requiring it.

·Define what "done" looks like—provide measurable signals, such as "CI fails on lint errors," "Core module test coverage ≥ 80%," "Zero Critical-level issues."

Phase 4 / Detailed Task Plan

Translate the strategy into an execution plan:

Break the work down into individual tasks. Each task must include:

·A title and task description

·Affected files/areas

·Acceptance criteria, i.e., how to verify it's complete

·Effort estimate: S = < 2 hours, M = half a day, L = 1–2 days, XL = needs further breakdown

·Risk of the change itself, i.e., could it break existing functionality

·Dependencies on other tasks

Organize tasks by milestone:

Milestone 0

Safety Net: Items that must be completed before safe refactoring, e.g., critical path tests, CI gates, backups.

Milestone 1

Critical Fixes: Security issues and correctness problems.

Milestone 2

High-Leverage Improvements: Changes that make all subsequent work easier.

Milestone 3

Quality & Polish: Remaining low-to-medium priority items worth addressing.

Separately highlight quick wins: high-impact, S-effort tasks that can be done immediately.

For the top three tasks, include a brief implementation sketch covering approach, key steps, and common pitfalls.

Final Delivery Format

Generate a single document containing the following sections:

Executive Summary: No more than 10 sentences. Provide an overall health score A–F with justification; list the top 3 risks and top 3 opportunities.

Repo Map

Audit Report

Improvement Strategy

Task Plan: Includes milestones, task table, and quick wins

Open Questions: List items requiring human decisions, such as product intent, modules that can be deprecated, performance targets, etc.

Constraints

Do not modify any code during this audit. Analyze only.

Do not pad the report. If a dimension is healthy, explain it in one sentence and move on.

Calibrate recommendations based on project maturity. Unless the project owner's goals genuinely require it, do not recommend enterprise-grade infrastructure for a weekend prototype.

Analyze the project's real needs and provide advice in the most effective way.

If the codebase is large, prioritize in-depth analysis of the core 20% of code that handles 80% of the workload, and note which areas received only a superficial review.

Original Link