The problem: "looks finished" isn't the same as "works"
Claude will happily hand you something that looks completely done. Clean layout, no errors on screen, a confident summary of what it just built. None of that tells you whether the login can be bypassed by editing a browser value, whether the database is readable by any stranger with the URL, or whether a first-time user can actually find the button you're proudest of.
I'm not a developer, so I can't read the code and just know. For a while my only check was using the thing myself and seeing if it felt right. That catches the obvious breaks. It does not catch a security hole, a data leak, or a UX dead-end, because I'm not looking for those, and neither is the model that just built the feature. The same model checking its own work has an obvious blind spot: it's grading its own homework.
Why evaluation has to be built in, not bolted on
The fix wasn't "be more careful" or "write better prompts." It was giving the checking job to a completely separate agent with a different mandate and no stake in the build being good. An agent whose only job is to find what's wrong will find things that an agent whose job was to finish the feature never will, because they're not looking at the same thing at all.
That's the whole argument for verification as a habit rather than an afterthought. If the only quality check on an AI build is the same AI telling you it went well, you've built a system that can't tell you no. A second, independent, adversarial pass is what actually catches that.
Three reviewers, three angles
Each one is a specialised agent with its own written standard it reads before every single run, so its judgement isn't just vibes, it's a checklist that gets enforced the same way every time.
🛡️ Aegis, the defender
Question: are the locks actually installed? Checks for leaked secrets and API keys, in the code and in git history, open cloud database rules, missing sign-in checks, and anywhere personal data could sit exposed. Fixes what's safe to fix itself, and hands back a plain-English verdict: can a stranger reach this data, yes or no.
⚔️ Ares, the attacker
Question: here's how I'd get in anyway. Takes the app as built and actively tries to break it: tampering with values the app trusts, tricking an AI feature into ignoring its instructions, faking its way into someone else's data, running up an API bill. Every real finding comes with the exact steps to reproduce it. It doesn't patch anything, only reports.
🪽 Hermes, the messenger
Question: can a real person actually use this? Renders the app, screenshots it on phone, tablet, and desktop, runs an accessibility scan, and reviews it the way a first-time user would experience it, not the way I know it's meant to work.
Aegis and Ares are a matched pair, deliberately: a shield and a spear. Aegis checks the locks are installed. Ares tries to pick them anyway, because a perfectly configured setting can still be defeated by a crafted input, and you only find that out by actually trying. I run both before anything with real data or a public link goes live.
How they get sharper over time
Each reviewer works from a written authority file, a playbook for Ares, a checklist for Aegis, a rubric for Hermes, and that file is not fixed. Whenever a run turns up a new trick worth catching next time, a new way my own apps tend to fail, that gets written into the file permanently. The next run, on any project, inherits it automatically.
So the standard compounds instead of resetting every time. A red-team run on one app that finds a new way to fake authentication becomes a permanent line in Ares's playbook, and gets checked on every app after that, not just the one where it was found. That's the difference between "run a test once" and "build a reviewer that actually learns what I keep getting wrong."
What I'm building next
The suite grows the same way: a new god, a new subagent, a new authority file, and only when a real gap keeps recurring, because every added reviewer is more maintenance, not less. The candidates on the list right now:
- A performance reviewer. Load time, bundle weight, the kind of jank that doesn't show up until you're on a slower connection or an older phone.
- A data-integrity reviewer. Edge-case inputs, corrupted state, what happens when the connection drops mid-save, the stuff that only breaks under conditions I don't normally test.
- A deeper accessibility reviewer. Hermes already runs a WCAG scan, but a dedicated pass would go further: screen-reader behaviour, keyboard-only navigation, the things an automated scan alone tends to miss.
- A content and writing reviewer. Checking voice and, just as importantly, that nothing I publish claims a capability or credential that isn't actually real.
None of these get built just because the list exists. The bar is the same one that got Ares built in the first place: a distinct angle the current three genuinely don't cover, showing up often enough that a dedicated reviewer earns its keep.
The point
None of this is really about security tooling or UX audits. It's about what happens when you can't read the code yourself. If your only quality check on an AI build is that same AI telling you it went well, you have no way to know when it's wrong. Building agents whose entire job is scepticism, run every single time, is what actually closes that gap. Not a better prompt. A second opinion that has to earn it.