How to prepare a legacy codebase for an LLM feature

Before adding an LLM feature to a legacy application, find where a failure could spread. A request might cross an API, a queue, a permissions layer and several older services before it returns an answer. Those connections matter more than the age of any single module.

One important distinction: Tomosu AI’s documented reliability measure is the Production Reliability Index (PRI). The product facts available for this guide do not establish a Tomosu Fragility Index (FI) score. Don’t look for an FI dashboard or treat FI as a Tomosu capability. Instead, use PRI as a reliability baseline and make a small, explicit inventory of the architectural risks in the feature path.

1. Establish a baseline before editing

Start by scanning the repository for its PRI score with Tomosu AI. The score gives the team a reliability reference point before the LLM work changes the codebase. Record the result alongside the commit or release candidate you assessed. A score is useful for comparison; it is not a substitute for understanding which modules the feature will touch.

Then state the feature boundary in plain terms: what starts the request, which components handle it, what data they read or write, and what happens if the model call is slow, unavailable or returns an unusable answer. Keep the map limited to the actual request path. A sprawling review of unrelated legacy code makes it harder to identify the risk that matters now.

2. Make a team-owned fragility inventory

For each module on that path, note the dependencies it calls, the data it can change, and the failure behavior the team can verify. Look for practical warning signs: multiple services writing the same state, hidden coupling through shared tables, unclear ownership, retries that can repeat a side effect, and error handling that turns a failed model call into an ambiguous success.

This is a review worksheet, not a Tomosu FI score. Keep the format simple: module, observed risk, evidence, and proposed action. Evidence might be a call path, a test gap or an incident record. Avoid assigning a numerical fragility rating unless your team defines what the scale means and uses it consistently. A made-up number can look precise while obscuring the actual failure mode.

3. Harden the smallest useful boundary

Choose the narrowest module that can contain the new behavior. Put the model interaction behind a clear interface, and keep authorization and validation in code paths the team already understands. Make the behavior on timeout, malformed output and downstream failure explicit. If the feature writes data or triggers another action, check that retries cannot perform that action twice.

For legacy code, prefer a small seam over a broad rewrite. Add or improve tests around the existing behavior before changing it, then test the new boundary and its failure cases. If a module has several unrelated responsibilities, separate only what the feature needs to isolate. The goal is to limit how far a defect can travel, not to turn an LLM launch into an unbounded refactoring project.

4. Put evidence at the merge boundary

Once the change is ready for review, compare it with the baseline and the inventory. Ask reviewers to verify that the change stays within the stated boundary, that the failure cases have tests, and that the risky dependencies are understood. Tomosu AI describes its governance layer as a way to gate risky merges with evidence. Use that approach to make the reason for a risky change visible at the merge boundary, rather than relying on an informal claim that the code looks safe.

Keep the policy consistent across the tools the team uses. A shared merge boundary matters more than assuming that development environments behave identically; the case for a common governance workflow is useful background when standardizing that process.

5. Watch the deployed path and feed learning back

After deployment, watch the signals that correspond to the risks you listed: failed requests, latency, unexpected writes and support reports. Tomosu AI integrates with Datadog, Sentry, Jira and Slack, among other tools, and automates L1 and L2 incident resolution. Those integrations can support an operational loop, but the team still needs to decide what it will monitor and what outcome requires escalation.

When an incident does occur, update the inventory with what the evidence showed. Fix the narrowest underlying cause, add a test or guardrail where appropriate, and reassess reliability rather than assuming the initial review remains valid. Tomosu AI’s PRI can provide a consistent score to track; the architecture review supplies the local detail that a single score cannot.

The practical measure of readiness is not a low FI number. It is a bounded feature path, explicit failure behavior, reviewable evidence and a plan for learning from production. That gives a team a defensible basis for shipping an LLM feature into an older system without pretending the system is simpler than it is.