AI in the Codebase: How Analysts Read a Repository They Did Not Write

Point an AI assistant at the repository and ask for locations, not explanations: which files decide this rule, quote the condition with file and line, what does this pull request change for the business. Then open the file and read the line yourself. The code is the only document that cannot be out of date, and an analyst who can read it settles arguments the specification cannot.

Every analyst has had this week. The specification says refunds over ninety days are rejected. Operations say they process them all the time. The developer who wrote it left in 2023. You book a meeting, three people speculate for forty minutes, and the output is an action to investigate.

The answer was in a file the whole time. This is part four of The AI Analyst, and it is where the series stops being about writing and starts being about verification. In part two you built a context pack out of documents. Documents drift. The repository does not, because it is what runs.

Why is the codebase the best source an analyst has?

Because it is the only artifact that is definitionally current. A specification describes what somebody intended in March. A wiki page describes what somebody remembered in June. The code describes what production does right now, this second, for real customers.

Analysts avoid it for two reasons, both of which AI has quietly removed. The first is volume: nobody reads 400,000 lines to find one condition. An assistant reads it in seconds and tells you which four files matter. The second is fluency: a Java service with dependency injection and three layers of abstraction is genuinely hard to navigate if you do not write Java daily. An assistant translates the path for you.

What is left is the part you were always able to do: read one conditional statement and decide whether it matches the requirement. That has never required being a developer. It requires being able to read if (daysSincePayment > 90 && !override) and understand what it means, which you can do today.

What do you need to set this up?

Less than an hour, and one skill.

The skill is git. Clone a repository, switch branches, read a diff, search history. Twelve commands. Git for analysts covers exactly the set you need and nothing you do not.

The tool is an assistant that can read a whole local folder: Claude Code in your terminal, GitHub Copilot in Visual Studio Code, Cursor, or whatever your organization has approved. The critical capability is reading the repository from disk, not you pasting files one at a time. Pasting does not scale past one file and it makes you choose which files matter, which is the thing you did not know.

The permission comes first. Source code is company property and often contains committed secrets somebody should not have committed. This is tier 2 access in the guardrails: approved tool, enterprise agreement, and a clear answer to where the code goes. Ask before you clone. In most banks the answer in 2026 is that there is an approved assistant and nobody told the analysts they were allowed to use it.

Then:

git clone https://github.com/yourorg/payments-service.git
cd payments-service
git log --oneline -20        # what has changed recently
git branch -a                # what else is in flight

You are now in the same position as a new developer on their first day, except you have a reader who has already finished the whole codebase.

The three questions worth asking a repository

Not “explain this service.” That gets you a fluent summary you cannot check, which is worse than nothing because it feels like understanding. Ask questions whose answers are locations.

Question 1: where does this rule actually live?

This repository is a payments service. I need to know what actually
decides whether a refund is rejected.

Find every place in the code where a refund can be rejected. For each:
- the file path and line number
- the exact condition, quoted
- what rejection reason or status is set
- what calls it, and in what order relative to the others

Do not summarise the business logic. Give me the list, and mark
anything you are inferring rather than reading directly.

The ordering clause is the one that earns its place. Specifications almost never say which validation runs first, and it decides which error the customer sees. I have found three separate programmes where the documented error was unreachable because an earlier check always fired first, and every one of them was a customer complaint theme nobody had traced.

Then you open the files. All four of them. You read the conditions. That is ninety seconds and it converts “the AI says” into “I checked.”

Question 2: what does this status actually mean?

Status fields are where documentation and reality diverge fastest, because every incident adds a value and no incident updates the wiki.

Find the enumeration or constant set for payment status in this
repository. For each value:
- where it is defined
- every place it is SET, with file and line
- every place it is READ or branched on
- whether anything outside this service depends on it (API responses,
  events published, database columns)

Flag any value that is set but never read, or read but never set.

That last flag is a gift. A value that is set but never read is usually a dead path from a feature that was half-removed. A value that is read but never set is usually a downstream system waiting for something that will never arrive, which is an outage in slow motion. Both are findings you can take to a design discussion, and both are invisible in every document.

This pairs directly with state machines for payments: the code gives you the real transition table, and you draw the diagram the specification should have had.

Question 3: what does this pull request change for the business?

This is the one that changes your week. Instead of waiting for a demo, read the change while it is still a change.

Here is a pull request diff: [paste, or point at the branch]

Explain, in business terms:
1. What behavior changes that a user or an operations team would notice.
2. Any change to an API response, an event payload, or a database
   column, because those affect downstream systems.
3. Any validation rule added, removed, or reordered.
4. Anything in this diff that is NOT described by the linked ticket.

For each point, cite the file and line. If the diff does not support
a claim, do not make it.

Point four is where the value concentrates. Scope creep is not usually malicious; a developer fixes an adjacent thing while they are in the file and nobody thinks to mention it. Finding that before release is the difference between a planned regression test and a surprise on Monday. It feeds directly into regression testing in payments and into your go/no-go call.

A worked example: the ninety day refund

Back to the argument from the opening. Here is how it actually resolves, in about ten minutes.

You ask question one. The assistant returns four locations. Three are what you expected. The fourth is in a scheduled job, not in the refund service at all: a nightly reconciliation that reverses refunds older than ninety days that were approved through the operations console, because the console bypasses the service validation entirely.

You open the file. The condition is there, at line 112. You check the git history with git log -p --follow src/jobs/ReconcileRefunds.java and find it was added in 2023 with a commit message referencing an incident number.

Now you know three things nobody in the meeting knew: the rule exists, it does not live where the specification says, and there is a second entry path that skips validation. The specification was not wrong about the rule. It was wrong about the architecture, which is a much more expensive kind of wrong.

That is a real finding, it took ten minutes, and you produced it without a developer’s time. Write it up with the file paths quoted, and you will find developers start replying to your messages faster, which is a compounding benefit discussed properly in working with developers.

If you want the broader technical grounding that makes this kind of investigation routine rather than occasional, The Technical Skills Guide for BAs covers reading code, SQL, and APIs as one connected skill set.

What about the database and the configuration?

The same method, and often higher value, because business rules hide in configuration far more than analysts expect.

Find every configuration value in this repository that affects
business behavior: timeouts, thresholds, limits, cut-off times,
feature flags, retry counts.

For each: the file, the key, the default value, whether it is
overridden per environment, and what behavior it changes.

Cut-off times, retry counts, and amount thresholds are business rules that happen to live in YAML. They are almost never in the specification, they change without a ticket, and they cause the incidents that start “it worked yesterday.” A list of them is one of the most useful documents an analyst can own, and it takes one prompt plus a verification pass.

Do the same for the schema. Point the assistant at the migration files and ask for every table, column, type, constraint, and index, and you have the beginnings of a real data dictionary extracted from the source of truth rather than from a document somebody maintained for six weeks in 2024.

Where does this go wrong?

Four failure modes, in the order you will meet them.

Accepting an explanation instead of a location. The model will happily narrate how the system works. The narration is a reconstruction, and it is right often enough to be dangerous. Always demand file and line, and always open one.

Missing the code that is not in this repository. Microservice estates spread one business flow across six repositories, plus a stored procedure, plus a job in a scheduler nobody owns. An assistant reading one repository will confidently describe a complete flow that is actually a third of the flow. Ask explicitly: what does this service call that is not in this repository, and what calls it.

Trusting the test suite as a specification. Tests describe intended behavior at the time they were written, and skipped tests describe nothing at all. Ask which tests are disabled, and read the ones that matter rather than the count.

Quoting code you never opened. This is the one that costs you standing. If you tell a developer their service does X because an assistant said so, and it does not, you will not get a third chance. Open the file. It takes ninety seconds and it is the entire difference between the analyst who reads code and the analyst who repeats a chatbot.

How does this change your job?

It changes what you bring to a room. Refinement with “what happens if the currency is missing?” is a question. Refinement with “the validator rejects a missing currency at line 84, before the amount check, so the error the requirement specifies is unreachable” is a finding, and it moves the whole conversation up a level. That shift, from asking to establishing, is the substance of what a developer analyst actually is and it is the fastest route from analyst to technical analyst on your team’s internal ranking.

It also feeds everything downstream in this series. The rules you find become test cases in part nine. The configuration list becomes your non-functional requirements. The status transition table becomes the sequence diagram that finally makes the flow legible to the business.

The takeaway

Use AI to read the repository you did not write, and ask for locations rather than explanations: which files decide this rule, quote the condition with file and line, what does this pull request change for the business, which configuration values alter behavior. Then open the file and read it yourself, every time, because your credibility is built on having checked.

Start with one question this week: pick the business rule you argue about most, and find out where it actually lives. You will usually find that it does not live where the document says it does, and that single finding tends to be worth more than the last three specifications you wrote.

Next: part five, where the same read-only discipline gets applied to Jira and Confluence through the Model Context Protocol, so the assistant can see your tickets and pages as well as your code. The full path is on The AI Analyst.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Artificial Intelligence, Software Development, Git, Technical Analysis