Debug a Failing CI Build with AI, Safely
Turn a CI failure into a small, reviewable fix: isolate the first error, test the diagnosis, and keep repository secrets out of the prompt.
Start with evidence, not a vague prompt
A failed build is only useful once you separate the first real error from the cascade below it. Copy the command that failed, the package manager and runtime version, the first error block, and the smallest relevant file. Leave out access tokens, customer data, private URLs, lockfiles, and the rest of the repository.
The goal is not to ask an AI assistant to repair everything. It is to turn a confusing failure into two or three concrete hypotheses you can test yourself. A serverless model is a good fit because you can send this narrow diagnostic request without managing a GPU service or a long-lived agent.
- The exact command and its exit code
- The first actionable error, plus 20 to 40 lines of context
- Runtime, package-manager, framework, and dependency versions
- Only the smallest code excerpt needed to understand the failure
- One stopping point: end the request after a diagnosis, before asking for a patch
- Complete the linked OpenCode setup, including its permission file and denied-action test. Use a disposable folder and submit only approved excerpts.
- Copy the diagnostic prompt below into that session. Replace each bracketed field with the failing command, versions, and approved redacted excerpts. Submit once and save the hypotheses.
- In your original project terminal, run one proposed verification after reviewing what it changes. Record its result before requesting a patch.
Make a diagnostic request the model can answer
Ask for ranked hypotheses, evidence from the log, one low-risk verification step for each hypothesis, and no code changes. This constrains the output to investigation instead of encouraging a confident but unreviewed patch.
Use a model access key with the smallest practical scope and keep it in your deployment secret manager or local environment, never in the prompt, source code, or browser bundle. DigitalOcean Serverless Inference accepts direct model requests, so a short server-side route is enough for this workflow.
You are reviewing a build failure. Do not suggest edits yet.
1. Identify the earliest likely root cause.
2. List up to three hypotheses in likelihood order.
3. Cite the log line that supports each one.
4. Give one reversible verification step per hypothesis.
5. State what information is missing.
Environment: [runtime and package versions]
Command: [failed command]
Log excerpt: [redacted first error]
Relevant file: [small redacted excerpt]Verify the diagnosis before accepting a fix
Run the suggested verification yourself. For example, inspect the resolved dependency version, run the failing command against a clean install, or check whether a configuration option changed names. If the evidence does not support the leading hypothesis, send the new result back and ask the model to revise its ranking.
Only after the cause is clear should you request a patch. Limit it to one file where possible, ask for a unified diff, and compare it with the framework documentation. Run the original build command and the narrowest relevant test after applying it.
A reproducible failure and its fix
In a disposable folder, create app.cjs with the contents below, then run node app.cjs yourself. Node reports ReferenceError: greeting is not defined. Put that error into the diagnostic prompt. Check the hypothesis by comparing the declared name, greting, with the name being read, greeting. Fix only the declaration and rerun the same command. Expect Hello.
const greting = "Hello";
console.log(greeting);node app.cjsA practical boundary for AI-assisted debugging
Do not paste production logs containing personal data, credentials, signed URLs, internal hostnames, or proprietary source files. Redact values rather than replacing the whole log with a summary, because structure is often the clue that matters.
Treat the model as a fast second set of eyes. It can reduce time spent on familiar dependency, type, and configuration failures, but the person who understands the codebase should still choose and review the fix.
Check your result
- Expected result
- You receive a short diagnosis tied to the supplied log lines, not a speculative patch.
- Stop if
- Reject a response that cites no log evidence, asks for secrets, or proposes a broad repository rewrite.
- Next step
- Run the highest-confidence reversible check before accepting any code change.