I Gave Claude Opus 4 Access to My CI Pipeline — It Found Bugs I Missed for Months
Suneet Malhotra
Mar 9, 2026
I Gave Claude Opus 4 Access to My CI Pipeline — It Found Bugs I Missed for Months
There's a moment every QA engineer knows — that sinking feeling when a production bug lands and you realize it was hiding in plain sight. A flaky test you ignored. A log pattern you scrolled past. A race condition buried in a 400-line diff.
Last month, I decided to try something unconventional: I gave Claude Opus 4 direct access to my GitHub Actions CI pipeline and told it to review every failed run, every flaky test, and every warning I'd been ignoring. What happened next genuinely surprised me.
The Setup: LLM-in-the-Loop CI
The architecture was simpler than you'd think. I built a lightweight GitHub Action that triggers on every CI failure. It collects the build logs, test output, recent diffs, and any relevant stack traces — then ships them to Claude Opus 4 via API with a carefully crafted system prompt.
The prompt was the secret sauce. Instead of asking "what went wrong?" I asked: "Analyze this failure as a senior QA engineer with 20 years of experience. Classify it as: flaky test, real regression, environment issue, or test gap. If it's a test gap, suggest what test is missing."
The response gets posted as a GitHub comment on the failing commit. Simple, effective, and surprisingly accurate.
Week One: The Low-Hanging Fruit
In the first week, Claude flagged 14 flaky tests I'd been manually re-running for months. But it didn't just say "this is flaky" — it explained why. Three were timing-dependent waitForSelector calls that occasionally hit slow network responses. Two were test-order-dependent state leaks. One was a genuine Playwright bug with page.reload() in headless Chromium.
I fixed all 14 in a single afternoon. My CI pass rate went from 87% to 96% overnight.
Week Two: The Hidden Regression
This is where things got interesting. Claude flagged a test that had been passing for weeks — but it noticed the assertion was wrong. A price calculation test was asserting $99.99 when the business logic had changed to $99.95 three sprints ago. Someone had updated the expected value to make the test pass without verifying the actual business requirement.
That's not something a traditional CI tool catches. The test was green. The pipeline was happy. But the behavior was wrong. Claude caught it because it could read the PR description from three months ago and compare the stated intent with the current assertion.
Week Three: Predictive Failure Analysis
By week three, I started feeding Claude not just failures but successes with warnings. Deprecation notices. Slow test times trending upward. Memory usage patterns.
It predicted — correctly — that two of my E2E test suites would start failing within a week due to a Playwright version incompatibility with an upcoming Chromium update. I upgraded proactively. Zero downtime. Zero surprise failures.
The Numbers After 30 Days
Here's the honest scorecard:
- CI pass rate: 87% → 97%
- Mean time to diagnose failures: 45 min → 8 min
- Flaky tests eliminated: 14
- Hidden regressions caught: 3
- False positives from Claude: ~12% (mostly over-flagging intentional changes)
- Monthly API cost: ~$180
That $180 saved me roughly 20 hours of manual debugging. At any senior engineer's hourly rate, that's an absurd ROI.
What Didn't Work
It's not all magic. Claude occasionally hallucinates root causes, especially with complex multi-service failures. It once confidently blamed a database timeout on a "misconfigured connection pool" when it was actually a Docker networking issue. The 12% false positive rate means you still need human judgment in the loop.
I also learned the hard way that you need to limit context window carefully. Dumping 10,000 lines of build logs doesn't help — Claude performs best with curated, relevant snippets under 4,000 tokens.
The Bigger Picture for QA in 2026
What excites me most isn't the bug-finding. It's the shift in what QA engineers spend time on. Instead of being log parsers and flake wranglers, we become AI supervisors — designing prompts, curating context, and making judgment calls on the 12% of cases where the model isn't sure.
This is the real AI-driven quality engineering transformation. Not replacing QA engineers, but giving them an always-on, tireless junior analyst that catches the stuff humans miss when they're tired, rushed, or just having a bad day.
If you're a QA lead who hasn't experimented with LLMs in your CI pipeline yet, start small. Pick your top 5 flaky tests. Feed them to Claude. You'll be hooked.
Fight On! ✌️
Suneet Malhotra — QA automation leader, AI enthusiast, and USC Trojan who believes the future of testing is agentic.
Share this post
You Might Also Like
The Test That Cannot Name What It Expects
An LLM step is not a pure function, so no gate in this routine can assert what the post says. Every check I run is a property the output must obey, never a value it must equal.
AI & AutomationThe One Step I Never Hand to a Subagent
My content routine dispatches a fleet of subagents to gather, then hands none of them the draft. A fleet parallelizes retrieval. It cannot parallelize a voice.
Quantitative TradingA Retry Is Not a Trading Decision
A rejected order is a decision. Retrying it without preserving the reason can turn a risk control into a duplicate trade.
Agentic AIThe Log Is Part of the Agent's Interface
An agent that can act but cannot leave a useful decision record is not autonomous. It is an opaque process with write access.
Latest Blog Posts
A Retry Is Not a Trading Decision
A rejected order is a decision. Retrying it without preserving the reason can turn a risk control into a duplicate trade.
The Log Is Part of the Agent's Interface
An agent that can act but cannot leave a useful decision record is not autonomous. It is an opaque process with write access.
The Market Is Closed Is Not a Trading Rule
A backtest can know the exchange hours and still schedule a trade into a holiday, an early close, or a stale session. Calendar state is market data.
Related Tools & Demos
The QA Field Manual to Language Models
A free 24-chapter book. Start at “what is AI, really?” and finish with a small language model you built yourself — one that reads a failing Playwright test and proposes a fix you can run. Read it in your browser, or download the PDF or the Mac app.
View Source Code →Multi-Model LLM Harness
One interface to call any AI model — capability routing, fallback chains, budgets, circuit breakers, and a quality feedback loop. A practical architecture pattern write-up.
Automated Trading System
Multi-engine trading platform with real-time risk management, regime-based strategy selection, and automated order execution.
View Source Code →
Stay in the Loop
Get weekly insights on AI-driven QA, engineering leadership, and automation strategies.
No spam, ever. Unsubscribe anytime.