Skip to content
Bernhard Götzendorfer
AI Deep Dives

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.

Editorial ink drawing in dark sepia and amber tones on an off-white background: several agents inspecting a website grid, a hand marking the final approval, focus on human triage
AI-generated illustration

TL;DR

Four bugs on a phone screenshot and one command: /discovery all. On 3 July 2026 I had several agent runs audit my own website, including a live-browser test, while I went to get coffee. Dozens of raw findings became twelve real issues after my triage: GitLab #257 through #268. The agents found and proved. I decided. That division of labour is the point: a tool finds and proves, the human triages and approves. This piece shows how such an audit runs, what it caught, and why the triage brake cannot be optimised away.

The Problem: A Website Ages in the Dark

A website is never finished. I change copy, swap images, move a section, deploy a new variant. Each single change is harmless. The sum across months is not. At some point a video reads "unavailable", a button vanishes on a dark background, a sitemap points into the void, and nobody notices, because nobody looks systematically.

The naive route is: I click through myself, spot three things, prompt an agent, fix, move on. That does not scale. I see what stands out to me, not what is broken. And my attention is the scarcest resource I have. I wrote about that bottleneck moving from production to verification in The Scarce Skill Is Not Typing, It Is Verification.

What is missing is a process that checks broadly and stubbornly without me making every click. That is exactly what the /discovery skill in session-orchestrator does, my own open-source tool. How the loop around it works I described in How session-orchestrator Matured in 9 Days. This is about a single run against a single target: my own website.

One Command, Several Probes

The trigger was unremarkable: a screenshot dump from my phone, four things that had nagged me over weeks, and a suspicion that more was hiding. One command:

/discovery all

What then runs is several parallel probes, each aimed at a different class of fault: code, infrastructure, UI, architecture, the live site in a real browser, and SEO. They work read-only. None of these probes may change anything. They collect, prove, link the source location. The live-browser part surprised me most: an agent opens the deployed page, actually renders it, and checks computed styles instead of only reading source code. That exact run happened while I stood in the kitchen getting coffee.

What comes out at the end is not a clean result but a pile. Dozens of raw findings, many of them duplicates, some noise, some real hits. The tool de-duplicates and hands me a list. My job starts right here: triage turns the pile into a short, hard list. In this case twelve issues, which I filed as GitLab #257 through #268.

What the Runs Actually Found

Four of the twelve findings tell the story best, because they show which fault classes a human reliably misses while clicking through:

  • Invisible buttons on dark CTA slabs (#258). On the dark call-to-action slabs the secondary button used shadcn's outline variant. On a dark background the button colour merged with the background. The button was there, clickable, and effectively invisible. This was found not in the code but in the live browser: a computed-style check where the text colour equalled the background colour. A static code scan would have declared the button present. It was present. Just not visible.
  • CSP blocked the badges on the manifest page (#259). The manifest page of the time loaded status badges from shields.io. My Content Security Policy did not allow the source, so the badges were silently blocked. No error, no crash, just an empty patch you do not register on a quick skim.
  • YouTube embeds showed "Video unavailable" (#257). Embedding was disabled on the uploads. The video existed and played on YouTube, just not embedded. A dead player in the middle of the page.
  • hreflang and sitemap 404s from an unused translationSlug (#260). An orphaned translation slug in the metadata generated hreflang references and sitemap entries for pages that did not exist. Invisible to a visitor, a 404 signal to search engines.

None of these four bugs would have caught my eye during a comfortable click-through. The invisible button is invisible by definition. The blocked CSP source is a non-event. The dead hreflang reference lives in a file no human reads voluntarily. Agents are not smarter than me here. They are just tireless and look in places I skip.

The Triage Brake: The Human Decides

And here comes the part that matters to me more than the bug list. Dozens of raw findings became twelve issues. The rest fell away, and through me, not through the tool.

Some of the raw findings were duplicates, three probes reporting the same fault from three angles. Some were plainly wrong: neatly phrased, with a source location, and still not a real problem. That is the most dangerous output an agent can hand you, the one that looks like a find and is not. Had I poured every finding blindly into an issue, I would have built myself two dozen ghost tickets and burned time on non-problems.

So my rule is hard and simple: an agent may find and prove. Filing and fixing I decide. For the four bugs above I checked the evidence before each fix, the computed style, the blocked request, the 404. Where the evidence held, it became an issue. Where it did not, it was discarded.

Agents find and prove. Deciding is mine.

This is no ornament. It is the line between a tool and a boss. An audit run that flows straight into fixes without a human triaging is not progress, but a faster way to deploy nonsense. The runs give me reach. The triage gives me back the responsibility I cannot and will not hand off.

The Process Is the Product

There is a punchline to this story that means more to me than any single fix. The tool that audited my website is my own. session-orchestrator is MIT-licensed, public at github.com/Kanevry/session-orchestrator, and /discovery is one of its skills. If you want to know whether I really work this way, you do not have to take my word for it. You can read the tool, install it, and run the same pass against your own site.

That is why I describe these runs in public at all. Not because four fixed bugs are worth an announcement, but because the process is the proof. I do not show a polished result but the workbench: one command, several probes, a pile of raw data, a human triage, twelve issues, clean fixes. No demo theatre. The real state of the work.

And it repeats. The next run against my website will find different things, because the site keeps changing. The process stays the same. That is what I mean when I say the process is the product: it is not the one bug list that counts, but the ability to reproduce it any time, and the discipline to send every finding through the human brake before approval.

Conclusion

A website audit by several agent runs is broad and stubborn. But its value only appears at the point where a human decides:

  1. Agents find what the human misses. Invisible buttons, blocked requests, dead hreflang references, orphaned sitemap entries: fault classes no click-through reliably catches. Breadth and stamina are the strength of the runs.
  2. The triage cannot be optimised away. Dozens of raw findings became twelve real issues. The filter was me, not the tool. The plausible-but-wrong finding is the most expensive one when nobody sorts it out.
  3. The process is the proof. The audit tool is open source and public. Anyone in doubt runs the pass themselves, and that is more honest than any slide.

AI is a tool here too: powerful, but no miracle. It gives me reach across the whole site. The decision about what counts stays with me.

← Back to blog