Yet Another Salesforce Tech Blog

Salesforce debug logs contain valuable clues, but finding the cause of an error can mean digging through thousands of lines. GitHub Copilot or Claude Code in VS Code can help connect those clues to your Apex code, tests and automation.

With Salesforce CLI available, the assistant can retrieve debug logs from an authenticated org. Use @apexdevtools/apex-log-parser to turn them into a structured report with execution paths, query counts, timings and governor-limit usage. Give the LLM this report alongside the relevant source code.

The infamous “Too many SOQL queries: 101” error is a good example. Creating test data can repeatedly fire triggers and flows, consuming the query budget before the operation being tested begins. AI can trace repeated queries and suggest bulk inserts, leaner test data factories or improvements to application code.

The same approach can help investigate CPU time limits, excessive DML, unexpected exceptions, slow execution and interactions between Apex and flows.

Which model should you use?

My suggested starting point is Claude Sonnet 5.5 for everyday investigations in either Copilot or Claude Code. For difficult failures spanning multiple classes and automation, try Claude Opus 5.5, or GPT-6.1 Sol in Copilot. These are practical starting recommendations; model availability depends on your subscription and organisation settings.

Example prompts

Retrieve the log

Use Salesforce CLI with org alias <ORG_ALIAS> to find and export the debug log for <TEST_OR_OPERATION>. Match the execution time and user rather than assuming the latest log is correct.

Analyze the evidence

Use @apexdevtools/apex-log-parser to parse <LOG_FILE> and generate a compact report. Analyze the parsed output alongside the project source. Identify repeated queries, expensive execution paths and exceptions. Cite supporting events and source lines, and flag incomplete evidence.

Fix and verify

Propose the smallest fix supported by the evidence. For test failures, distinguish data setup from the operation under test and preserve assertions and bulk coverage. After applying the fix, rerun the relevant tests and compare newly parsed logs.

Also, check out this post on making sense of noisy Salesforce debug logs.