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 (0)