How Agents Audited My Own Website
One /discovery run, several parallel agents, a live-browser test: how I had my own website audited, and why a human still makes every final call.
TL;DR
On 3 July 2026 I ran several read-only audits against my website with one /discovery all command. The run checked code, infrastructure, UI, the deployed site, and SEO. Dozens of raw findings became twelve GitLab issues after manual triage. Four examples show why both steps matter: the agents covered more surfaces than one browser pass, and I discarded duplicates and incorrect findings before anything was fixed.
Why I Ran It
The trigger was a set of phone screenshots and four things that had bothered me over several weeks. The site had changed through many small copy, image, and layout updates. I wanted one pass across the repository and the deployed pages instead of checking each surface separately.
I used the /discovery skill in session-orchestrator, my MIT-licensed orchestration tool. The wider workflow is described in How session-orchestrator Matured in 9 Days. This article covers one run against this site.
One Command, Several Read-Only Checks
The command was:
/discovery all
It started parallel checks for code, infrastructure, UI, architecture, the live site, and SEO. The probes were read-only. They returned findings with a source location or browser observation; they could not change the site.
The live-browser check rendered the deployed pages and inspected computed styles. That catches a different class of problem from a source scan. At the end, the run returned dozens of findings. Some described the same fault from different angles, and some did not hold up when checked. After triage, I filed twelve issues as GitLab #257 through #268.
Four Findings from the Run
- Invisible buttons on dark CTA sections (#258). The secondary button used shadcn's outline variant. Its colour merged with the dark background. It was present and clickable, but the computed-style check showed that its text colour matched the background.
- CSP blocked badges on the manifest page (#259). The page loaded status badges from shields.io, but the Content Security Policy did not allow that source. The result was an empty area rather than a visible error.
- YouTube embeds showed “Video unavailable” (#257). The uploads played on YouTube, but embedding was disabled.
- hreflang and sitemap links returned 404 (#260). An unused
translationSluggenerated references to pages that did not exist.
The examples came from different layers: CSS, browser policy, external media configuration, and content metadata. That spread was the useful part of running several focused checks together.
Manual Triage
I reviewed the raw findings before filing or fixing anything. Duplicate reports were combined. For the four examples above, I checked the computed styles, the blocked request, the player behaviour, and the 404 responses. Findings without enough support were discarded.
That separation stays explicit in the workflow: agents collect and check; I decide which finding becomes work. A plausible report can still describe a non-problem, so an audit result does not move directly into an automated fix.
Repeating the Pass
The /discovery skill is in the public session-orchestrator repository. It can run against another site, though the useful checks depend on the stack and deployment. My next run will also return a different list because this site keeps changing.
The repeatable sequence is simple: run focused probes, keep the source locations, triage the combined list, then fix the confirmed items. Verify AI output reliably covers the same review principle outside website audits.
The agents expanded the surface I could check in one run. Manual triage reduced the output to twelve issues I was prepared to act on. Both parts were necessary for this audit.