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 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. SiteBrief is in early access — sitebrief.io