How Al Chen Uses Claude Code and 15 Repos to Answer Any Customer Question

The public docs were not enough. Al Chen works with enterprise customers deploying Galileo into locked-down Kubernetes environments. When one of those customers asks how the API, authorization service, images, secrets manager, sidecars, and network rules cascade together, a generic help-center answer is not an answer.

Al is on Galileo's field engineering team, not the product engineering team. He had never held an engineering role. But he realized the source of truth he needed was already available: the code itself.

In this episode of How I AI, Al shows how he put roughly 15 repositories into one Claude Code workspace, combined them with Confluence and customer notes, and nearly eliminated the stream of technical questions he used to send back to engineering.

The job was not finding documentation. It was reconstructing the product

Galileo is an observability platform for AI applications. Its self-hosted product is made of several services, and each service lives in a separate repository. A customer question can cross the UI, API, authorization, deployment images, and infrastructure configuration before it reaches a useful answer.

That is why searching one document or one repo failed. Customers did not want the docs answer. They wanted the step-by-step explanation of how the services worked together in their environment.

Al cloned every relevant repository under one parent Galileo directory and opened that directory in VS Code. Claude Code could now traverse the product instead of reasoning from one isolated service. If the answer was not in the API repo, it could inspect authorization or another sibling repository without Al manually switching projects.

The practical setup is captured in the full-codebase customer-answer workflow. The important move is opening the editor at the level of the question. Sometimes that means one focused directory. For a cross-product customer issue, it means moving up until every relevant repo is in scope.

Keep the code current

Code only works as documentation if it reflects the product customers are running. Galileo ships multiple changes a day. Al initially ran git pull origin main in every directory by hand, which was absurd once the workspace reached about 15 repositories.

He asked Claude Code to solve it: help me pull the latest main branches into all of my local repos. Claude produced a script of about 16 lines. Al now runs one command, pull all, to refresh the entire workspace.

This sounds like a tiny automation, and it is. It is also load-bearing. A beautifully reasoned answer based on stale code can be more dangerous than an obviously incomplete docs answer.

Code is only one layer of the customer answer

The next unlock was giving Claude access to the messy context around the code. Al uses a custom Claude Code command called DPL for deployment questions. The command starts with Confluence through the Atlassian MCP, then moves into the repositories when the written guidance is not enough.

His example prompt was concrete: a customer cannot use CDS, stores secrets in Google Secrets Manager, and wants to deploy the Wizard image. Give me the step-by-step process. The real questions are usually more detailed, but the pattern is the same: identify the customer, name the environmental constraints, and tell Claude where to look first.

Al also maintains a Confluence page of enterprise customer quirks. Each customer gets a compact list: how it manages secrets, Kubernetes namespaces, sidecars, service-to-service encryption, seccomp profiles, node affinity, and other requirements that would never belong in generic public docs.

The DPL command checks that page whenever Al names a customer. The answer is grounded in three different kinds of truth:

• The current implementation across the relevant repositories
• Team-maintained deployment guidance in Confluence
• Customer-specific constraints captured from previous conversations

The result is not another Kubernetes explainer a customer could find with a web search. It is a deployment plan that says, in effect: I heard you, I remember your environment, and I have already accounted for the constraints you told us about.

You can be less precious about the perfect source of truth

Teams have spent years pruning Confluence gardens, reorganizing Slack channels, and arguing about which system owns a fact. My takeaway from Al's setup is more pragmatic: AI can navigate a little more chaos.

A useful answer can live in code, an official page, a rough customer note, or a Slack thread. The human job is to capture the information somewhere accessible and point the model toward the likely sources. The model's job is to traverse them and assemble the answer.

That does not mean information architecture stops mattering. Permissions, freshness, and provenance still matter enormously. It means a rough bullet list can now be valuable context instead of waiting forever to become a perfect canonical document.

One support answer should improve the next one

Al's second system starts after the customer question is resolved. Galileo uses Pylon for support conversations in Slack. When a thread contains an answer another customer may need, Pylon can turn it into a help-article draft without copying the conversation into a separate tool.

The Slack-to-knowledge-base workflow takes the useful support thread, generates a customer-safe draft, removes company-specific details, and sends it to a public Pylon knowledge base.

These articles are intentionally lighter weight than Galileo's official docs process. Updating formal documentation requires editing the docs repository, opening a pull request, and waiting for review. The Pylon knowledge base can capture an in-the-weeds deployment answer while it is still fresh.

I describe this as an "and then" workflow. A customer asks a question. And then you answer it. And then you turn the answer into an article. And then you share it with the customer team. And then you cluster recurring questions into product insights, training material, or long-tail content. AI makes each additional step cheap enough that the chain can actually happen.

The real advantage is customer experience

Most AI coding stories compete on engineering velocity: more pull requests, faster prototypes, fewer manual tests. Al is using the same substrate to compete on the quality of the customer relationship.

A technical enterprise customer can tell the difference between a team that forwards the docs and a team that understands its architecture, security model, and deployment history. Al's system lets a field engineer show up with the second kind of answer without keeping a product engineer permanently on call.

At Galileo, Al says the engineering-question traffic he used to create has fallen almost to zero. That is the internal return. The external return is a more precise, current, and trustworthy answer.

The caveats are real

This is not permission to copy proprietary code into an unapproved model or send generated answers to customers without reading them. Repository access, model policy, customer-data handling, and the review bar must be explicit.

Technical fluency also helps. The hardest part is setting up Git, the repositories, the editor, MCP access, and permissions. Once that environment works, asking Claude questions feels like using any chat interface. But customer-facing teams still need enough curiosity to inspect code, understand the answer, and notice when something is off.

Al is relentless when an answer feels weak. He tells Claude to think hard, explain why the answer is correct, and cite the sources behind its reasoning. Sometimes he adds the stakes: the customer may churn, or the deal depends on getting this right. The useful part is not the drama. It is forcing a second pass through the evidence.

Start with the question engineering keeps answering

The best entry point is not a grand knowledge-management project. Find the customer question that repeatedly interrupts engineering. Put the repos that contain the answer in one workspace. Add the smallest amount of customer and documentation context Claude needs. Then require sources and read the result before it leaves the company.

Once that works, add the next loop: capture the resolved conversation so the next customer, field engineer, and product team do not start from zero.

Your code is already a detailed description of the product. The opportunity is to make that truth available to the people responsible for explaining the product, while keeping the permissions and judgment that make the answer safe.