Every agency I've talked to has the same story.
Client calls on a Friday. Site is down or flagged by Google Search Console. You SSH in, find WP_DEBUG = true in production, turn it off, deploy, done. Twenty minutes gone. Next week, different client, same thing.
I run a small web agency tool called SiteBrief — it monitors uptime, SSL, PageSpeed, SEO, and security headers across client sites. After six months of watching the same issues appear on the same types of sites, I built DevLab: a section that not only detects problems but generates the fix and opens a GitHub PR (or GitLab MR) for your review.
The workflow
Detect → Explain → Preview fix → Open PR → You approve
- Detect — SiteBrief continuously scans for security header gaps, SEO problems, PageSpeed issues, WordPress misconfigs, broken crawl settings
- Explain — every issue gets a plain-English description, severity level, and a confidence score (more on that below)
- Preview fix — click "Preview fix" and you see the exact file, the exact change, and what it will do — before anything happens
- Open PR — confirm in the modal, SiteBrief opens a pull request on your repo with a descriptive title, full context in the body, and a dedicated fix branch
- You approve — review the diff on GitHub/GitLab as you normally would. Nothing merges automatically.
Confidence scores
This was the part I spent the most time thinking about. "AI generates fixes" sounds scary. The honest answer is: some fixes are deterministic (swap true for false in one line), others are educated guesses (write an SEO title for a site you've never seen).
So every fix has a confidence score:
| Issue | Fix | Confidence |
|------------------------------|------------------------------------------|------------|
| WP_DEBUG = true | define('WP_DEBUG', false) in wp-config | 95% |
| robots.txt missing | Valid file with User-agent: * / Allow: / | 90% |
| Missing security headers | HSTS, X-Frame-Options, CSP | 88% |
| Missing viewport / canonical | Correct meta tag added | 85% |
| No cache headers | Cache-Control: max-age=31536000 | 75% |
| Missing SEO title/desc | Placeholder — needs your review | 62% |
Green (≥85%) = safe to merge after a quick look. Amber (≥70%) = test on staging. Orange (<70%) = treat as a starting point, edit before merging.
Auto-detecting the right file
One thing I didn't want to do: assume everyone is on Netlify.
When DevLab generates a security header fix, it reads your repo and tries candidate files in order:
netlify.toml → adds a [[headers]] block
.htaccess → adds Header always set inside mod_headers
nginx.conf (or nginx/default.conf) → injects add_header into the server block
For SEO fixes it detects the framework:
Next.js App Router → edits app/layout.tsx using the metadata export
Plain HTML → injects tags into
Why I built the preview step
My first instinct was to make "Generate PR" a single button. Ship it, done.
Then I showed it to three agency owners. All three asked: "But what exactly is it going to change?" That was the signal. Nobody wants a black box touching client repos.
So now the flow is:
Click "Preview fix"
Modal shows: action description, exact file path, confidence bar with color coding, a safety note ("this adds headers to netlify.toml — it will not touch your application code"), and the "Nothing merges automatically" guarantee
Click "Open PR" to proceed — or just close the modal
The PR opens on a dedicated branch (sitebrief/fix-security-headers style), so it's isolated and easy to close if you change your mind.
One-click rollback
If you open a PR and then decide against it, there's a Close button directly in the DevLab history panel. It calls GitHub's PATCH /pulls/{number} (state: closed) or GitLab's PUT /merge_requests/{iid} (state_event: close) and marks the fix as rolled back in our records.
No need to go to GitHub just to close a PR.
What's next
Short-term:
Staging branch deploys — open the fix PR against a staging branch, not main
Dependency security updates — scan package.json / composer.json, PR with safe version bumps
Scheduled digest — weekly email: all issues + open fix PRs across your portfolio
If you run a dev shop with multiple client sites and you're tired of playing whack-a-mole with the same misconfigs every month — that's exactly who DevLab is for.
Happy to answer questions about the implementation, the PR flow, or how the file detection works.
Top comments (2)
Love the preview + confidence score approach. The PR part is cool, but showing the exact file + change before opening it feels like the real trust builder for agency workflows.
Thanks Bhavin! Exactly — the "show me what changes before you touch my repo" part was the main design goal. Agencies need to trust the tool before merging anything. Confidence score helps filter out the noise too. Glad it resonates