How I AIClaude Code + 15 repos: how a non-engineer answers every customer question | Al Chen
CHAPTERS
- 4:23 – 6:03
Cloning 15 repositories into one VS Code workspace
Galileo’s platform spans many services and repositories rather than a monorepo. Al’s key unlock was pulling ~15 repos into a single parent directory and opening them together so Claude Code can traverse the whole product surface area.
- •Galileo is multi-repo: one service per repo (UI, API, AuthZ, etc.)
- •Al opens all repos under a single root directory in VS Code
- •This setup enables cross-repo queries for end-to-end product behavior
- 6:03 – 8:00
How Claude Code answers questions by traversing the full codebase
Al explains his workflow: ask Claude Code to inspect specific repos (e.g., API + AuthZ) and expand to others as needed. This reduces constant Slack pings to engineering and helps Al learn the system while answering customers.
- •Claude Code can search multiple repos and connect behaviors across services
- •Prompts can direct Claude to check specific repos first, then broaden scope
- •Result: fewer engineering interruptions and faster customer responses
- •Secondary benefit: continuous learning for non-engineers
- 8:00 – 8:31
Why “current code” beats docs as the source of truth
Claire highlights that code changes daily and documentation often lags. Using the main branch as the canonical reference helps ensure answers reflect what the product actually does right now.
- •Fast shipping makes documentation stale quickly
- •Main branch code is the most reliable “source of truth”
- •Better for high-stakes technical questions where accuracy matters
- 8:31 – 9:54
The 16-line ‘pull all’ script to keep 15 repos up to date
Al shares how he automated staying current: Claude Code generated a short script to git-pull main across every local repo. This replaced a manual, unscalable routine of pulling each repo one-by-one.
- •Daily freshness matters when using code to answer customers
- •Claude Code wrote a simple multi-repo update script (~16 lines)
- •Automation prevents drift and keeps local context aligned with production reality
- 9:54 – 11:40
Opening projects at the right level: multi-repo vs monorepo context strategy
Claire and Al discuss an underused tactic: opening the IDE at the correct directory level for the question at hand. Going “up a level” can enable cross-service reasoning, though it may introduce context bloat if too broad.
- •Open the workspace at the level that matches the problem scope
- •Multi-repo workspaces allow traversal across services without manual switching
- •Balance broader context with potential context bloat/performance concerns
- 11:40 – 13:25
Live demo workflow: deployment Q&A using Confluence MCP + codebase
Al demos a deployment-focused custom command (“DPL”) that starts by pulling relevant Confluence guidance and then falls back to scanning repos for missing specifics. The result is a step-by-step plan tailored to a customer’s constraints (e.g., no CRDs, Google Secrets Manager).
- •Custom command routes: Confluence first, then code for deeper details
- •Uses Atlassian MCP to retrieve Confluence context inside the IDE
- •Produces actionable deployment steps customized to the customer environment
- 13:25 – 15:00
The ‘customer quirks’ system: micro-documentation that drives personalized answers
Al maintains an evolving Confluence page with per-customer constraints—air-gapped rules, secret storage, namespace patterns, encryption requirements, etc. Claude incorporates these quirks to generate responses that build trust and avoid generic guidance.
- •Centralized “customer quirks” page captures enterprise-specific constraints
- •Prompts instruct Claude to apply quirks when a customer is referenced
- •Tailored guidance beats generic Kubernetes/infra advice customers can Google
- 15:00 – 17:03
Living with more chaos: AI as the cross-system information navigator
Claire argues teams can be less rigid about “one source of truth” because AI can traverse Slack, Confluence, Notion, and code. Al reinforces: save valuable answers wherever they occur, then feed them back as context via MCPs and summaries.
- •AI reduces the need for perfect information architecture
- •Slack threads, notes, and docs can all become queryable context
- •Slack MCP can summarize threads; Confluence/Notion can store long-lived memory
- 17:03 – 18:20
Competing on customer experience, not only product velocity
Claire reframes AI leverage as a customer-experience differentiator, not just an engineering accelerator. Al’s approach helps customers feel heard through bespoke, environment-aware answers that reduce time-to-deploy and increase confidence.
- •AI can create a competitive moat in responsiveness and quality of support
- •Customized answers improve trust and adoption for complex enterprise buyers
- •Better support workflows can be as strategic as faster feature shipping
- 18:20 – 20:05
Should customers query the code directly? Open-source vs proprietary tradeoffs
Al explores the logical endpoint: if customers could query the code, he wouldn’t be a bottleneck. He cites LangChain’s open-source support patterns, but notes proprietary code and security make direct access difficult—suggesting sanitized or limited-access alternatives.
- •Idea: remove the “middleman” by letting customers query repos themselves
- •Constraint: proprietary code and security/compliance considerations
- •Open-source ecosystems (e.g., LangChain) already enable this model
- •Potential future: sanitized/internal-to-external query surfaces
- 20:05 – 25:46
Where humans still add value: judgment, tone, verification, and relationships
Al emphasizes he doesn’t blindly paste AI outputs—he edits for brevity, clarity, and human tone, and sanity-checks with engineers for edge cases or upcoming refactors. Claire adds the relationship factor: customers still want a trusted human counterpart.
- •Humans trim verbosity and adapt answers to ‘bottom line up front’ needs
- •Verification loop: engineers confirm when code or AI may be misleading
- •Some truths live outside code (meeting notes, hallway decisions)
- •Trust and relationship-building remain critical in enterprise contexts
- 25:46 – 32:07
Reactive Slack support to knowledge base: Pylon workflow + the ‘and then’ loop
Al shows how Slack-based customer support can become durable documentation using Pylon to generate help-article drafts from threads. Claire describes the broader “and then” mindset—turn each solved question into training, documentation, SEO, and roadmap signals.
- •Pylon converts long Slack threads into draft help articles in one interface
- •Articles become a fast, living knowledge base (often more current than polished docs)
- •“And then” chaining turns one answer into reusable organizational assets
- •Support data can cluster into themes that inform product roadmap decisions
- 32:07
Scaling the workflow across the team + lightning round prompting tactics
Al explains adoption is informal but driven by sharing results and coaching teammates to clone repos, index code, and use Claude Code effectively. In lightning round, they cover repo access concerns, raising technical literacy, and prompting techniques like ‘think harder’ plus sourcing/citations.
- •Scaling via internal evangelism: tips, enablement, and shared wins
- •Engineering buy-in: reduces interruptions and support toil if others self-serve answers
- •Expectation shift: non-engineers should learn Git/IDE basics in the AI era
- •Prompting: demand citations, line-of-code references, and deeper reasoning (‘think hard/think harder’)
Meet Al Chen: field engineering on the front lines of enterprise AI observability
Claire Vo introduces Al Chen from Galileo’s field engineering team and frames the episode around using code as a customer-support advantage. The focus is on answering nuanced enterprise questions faster and more accurately by querying real product internals.
- •Al supports highly technical enterprise customers despite not being a formal engineer
- •Episode theme: using code as an asset for customer-facing support and documentation
- •Goal: faster, more trustworthy answers than what public docs can provide
Why documentation and generic AI answers failed customers
Al describes the moment he realized public documentation—even when summarized by ChatGPT/Claude—still didn’t produce what customers needed. Customers wanted the real “how it works” flow across services, not a high-level docs response.
- •Public docs didn’t address deep, situational technical questions
- •Customers want step-by-step, system-level explanations across services
- •AI over docs alone still missed the nuance customers expected
