The team you lose when you open Claude Code

I should know better

My site has been online since 2007. I recently rebuilt the whole thing as an archive of essentially everything I do online, with Claude in the driver’s seat. It was a wild and fast experience.

And every time I called a piece of it done, it went the same way. The page looks fine. I ship it. Then I find something I should have caught.

I’ve been doing this a while. I know how to build a website, and I know what it’s supposed to do. I care about design and a11y and progressive enhancement and all the cool stuff we earned from standards and the semantic web. I still can’t for the life of me hold the whole surface in my head.

It’s rarely big stuff. It’s the OG tags I half-remember (og:image or twitter:site, one of them is wrong, I never remember which), some a11y thing where the focus ring works on three buttons and not the fourth, the meta description that’s still whatever claude splatted out on v1 of 24, or missing entirely.¹ I keep a mental checklist of these things to check, but it doesn’t stay loaded (and is only getting worse as I age).

I missed the room of people I used to do this with… The teammate who wouldn’t let a PR merge with a broken aria-label. The marketer who’d freak out about a placeholder meta description two minutes before the announce email. The designer who’d roll their eyes at the tap targets I’d let slip into ridiculous territory on the external-link arrows. Now, it’s mostly just me and my agents.

So I built a way to put some of that team back in the room.

Claude Code is mostly structurally solo work, even when you’re on a team. The org chart does not enter the chat. The team comes back at PR review (if you still do them), after release, if you’re lucky in the standup the next morning. They’re not in the session. The window before the blast radius reaches real users is where you’re alone with your computer friends, instead of surrounded by the teammates who used to be your checks and balances.

Team, not checklist

A checklist is mostly reactive – a downstream artifact: I keep forgetting OG tags, so I write OG tags on a list. I miss alt text, I write alt text on a list. Each time I run through it, find it incomplete in some new way, and add a row. For years I honed checklists. They’d grow too big to finish, I’d skip them for speed (read: I’d forget), or they’d go stale and I’d stop trusting them.

It’s something, but it’s not enough.

What I’m actually missing is the way reviews work on a team that ships. Every teammate has pet pedantic things: I’m an ass about CSS complexity, semantic naming, and open standards. The number of times I’ve asked, “Did you really need a custom property for that?” – and the number of times somebody has rolled their eyes at me – is high. Harper is preternaturally gifted at vibe and laser-focused on it (a mix of tone, and design, and that certain je ne sais quoi). Another locks onto a11y. You get it.

Code review, pairing, and the rest of the collaborative stuff work on a healthy team in part because those pet concerns get distributed across people with different blind spots. Nobody has to catch everything. Together they catch most things.

What I built, eventually, is review-squad. A Claude Code plugin that dispatches panels of reviewers, each with their own pet concerns, against whatever I need reviewed. What I wanted back was the part of a team where your blind spots get covered by people whose pets aren’t yours. It runs inside a Claude Code session, at a checkpoint, before you push your mistakes out for the world to see.

My need started with the team I wish were still around me, so I built a panel of experts: technical specialists, each with their own pets. SEO, accessibility, security, performance, mobile UX, copy editing, social and meta tags, web standards. Each one is a separate subagent, dispatched in parallel.

Diversity is good

As I was building the experts panel, I saw an opportunity to address a few more failure modes I kept running into. All too often I get so deep in the weeds on one piece that I leave a mess everywhere else. Inconsistencies, logical leaps I’m quietly asking users to make on some other page I wasn’t looking at. I can’t see the forest for the trees. This is a thing that amazing product people I’ve worked with in the past have been able to really help with – stepping into the shoes of the user and guiding us to a place where those leaps are bridged, and consistency is… well… consistent.

It seemed like another squad or two could help.

So the normies squad was born. Cold visitors at different sophistication levels. Maybe a senior dev, a product manager, or a small-business owner, a college student, a retired teacher, a grandparent – or more to the point – all of them. They land on the site or the app or what have you and give a first-impression review.

The third squad is regulars, another group that good product thinkers have always spoken for on my teams. Faux users trying to do real things. A gift shopper trying to buy something. An RSS subscriber trying to actually subscribe. When I’m focused on fixing something in one part of the app, with no thought to how it’ll affect the other things users need it for, they’ll find it. Regular users have their own pet needs, much like the team would. I want to make sure they work before users know they’re broken.

As I started testing with these three panels, Harper suggested yet another great source of feedback.

Well-meaning assholes like me.

And so, the last of the initial squads: Well-Actually. They are, by design, insufferable pedants. The Typographer. The HN Commenter. The Pixel Cop. The UX Reply Guy. Each pedant gets its own rating scale, and the panel produces a two-part output: a roast and a fixlist. The roast is performative and frankly hilarious. The fixlist is frustratingly helpful.

Imagine all the benefit of getting flamed far and wide, but without the downside!

What it found on 2389.ai

We ran the squads against our own site. The results were wild. A snippet from the first PR addressing the findings:

Twenty-three commits. Forty-five issues fixed, five deferred because they needed a human call.

My favorite finding: our company name was mistyped as 2839 in the Privacy Policy and Terms of Service. We are 2389.

We had said 2839 in two different languages on two different legal pages, for an embarrassingly long time (months!), and none of us had caught it. We’d done multiple kinds of review against the site, dozens of different times. Honestly – even after it was surfaced, I had a hard time finding it even with a map.

It’s a funny little typo until you remember those are our legal docs.

And there were plenty more, ranging from silly to genuinely bad.

The rest of it, roughly in order of how much it mattered:

1. The CSP had frame-ancestors *, so anyone could iframe our site, wrap it in their own chrome, and present it as theirs – clickjacking, essentially. Tightened to 'self'. We added Strict-Transport-Security and a Permissions-Policy while we were in there.
2. Every page of a static site sent no-store. We were telling browsers not to cache HTML that barely changes.
3. og:site_name was wired to the wrong variable, and twitter:site rendered a full URL where Twitter wants an @handle. Our own link previews were misattributed.
4. hreflang links were missing, so search engines couldn’t tell the language versions apart – and the footer’s language nav did tell humans, then sent them to the wrong page.
5. Corrupted Japanese frontmatter on several posts. It didn’t show up in the rendered output at all, but it broke the links in our llms-full.txt – so agents got a broken version!
6. The homepage had no <h1>, which matters most to anyone navigating by heading in a screen reader, and two <title> elements, which isn’t even valid HTML.
7. The office carousel couldn’t be driven from a keyboard at all, and it ignored prefers-reduced-motion. So much for humanist technology.

None of those were hard to fix. All of them were sitting there in production.

This isn’t magic. There are tons of tools that cover some of this - Lighthouse, axe, etc. I know those tools, I even ran them on previous versions, but through a bunch of fast changes bad things reappeared. Any individual one of these is something a checklist or specialized tool could surface, if I’d remembered to run the right one and it knew what to look for.

That is kinda the point.

It’s not that review-squad has invented a new way to notice an <h1> is missing. It’s that I don’t have to hold SEO and CSPs and screen-reader behavior and caching headers and French navigation and whatever else in my head at once.

And then there are the things that are harder to encode ahead of time: something missing entirely, a flow nobody wrote a test for, the company name being wrong in a place nobody thought to grep.

All of these little issues together, frankly, make us look like noobs.

Defaults, not destiny

The squads have defaults, but the actual panel isn’t fixed.

Experts starts with a sensible panel based on what kind of thing you’re reviewing, then looks at the project and suggests whoever else might be useful. Normies starts with a range of sophistication levels. Well-Actually starts with its familiar cast of pedants. Regulars are built around the actual users and flows it finds.

Before anything runs, you see the panels. It asks if anybody is missing. You can add, remove, or adjust whoever you want. Harper often adds a cat to a panel. Sometimes Anna Karenina. Sometimes you just want a cat to tell you about your CSS.

On the site for the Hack Party we cohosted in Montréal it noticed that the site was bilingual and suggested adding an i18n reviewer. Lol, welcome reviewer number 27.

That reviewer found the headline bug.

Most of my examples here are websites because I build a lot of websites. I also ran all four squads against this post. Other people have thrown the same thing at images, desktop apps, kinda whatever. The point is the perspectives, not the DOM.

Convergence

Back in June I ran review-squad on the landing page for the Hack Party. A little bilingual Hugo site, all of five pages.

The session ran the panels and, when all 27 agents were back, handed me a consolidated report.

A tiny piece of the thing I actually got back:

That first one was a headline finding. The i18n Expert caught it. The a11y Expert caught it. And Sébastien, a French-speaking attendee persona in Regulars trying to actually click around, caught it.

Three reviewers, from two different panels, landed on the same bug.

When findings from separate lenses land on the same thing, the noise drops out and signal shines. A single voice can easily be wrong. Three reviewers across two panels, dispatched separately with different framing, landing on the same broken URL is def worth citing.

Redundancy is the price of coverage when you can’t know ahead of time which lens will catch which bug.

But there is an important wrinkle. The same run caught an inconsistency in the French register. Some copy used tu, other copy used vous. Multiple reviewers caught the inconsistency. Sébastien specifically recommended tu, reasoning that it fit the site’s Québécois casual register.

I went ahead and folded that in with the other changes. But, sitting with it, something felt off. I checked as many event landing pages in Québec as I could. They leaned vous, so I trusted that over Sébastien.

The individual panel reports preserve provenance pretty well. But review-squad doesn’t have some special fifth cross-panel-consolidation component. The main Claude session rolled all four reports together on its own, automatically, and in the flow of that giant report I treated one persona’s recommendation as though it carried more consensus than it actually did.

Worth being precise about where that went wrong: the panels flagged the inconsistency and logged Sébastien’s fix as one voice. Claude summarizing it blurred the two.

Three people agreeing that a URL is broken is useful. A single persona giving an opinion is still just opinion. You might still need to do your own research, lol.

Finding does not equal fix.

A good team surfaces what you’d miss, but doesn’t get to ship for you. The panel’s job is to keep you informed enough to make the call.

You still make it.

There is another nice consequence of this kind of review. Once it finds something that should be deterministic, you can make it deterministic.

The useful long-term output of the language-toggle bug isn’t that three agents found it. It’s the test you (read: your agent) write afterward that asserts /visit/ switches to /fr/visit/.

The review helps find test cases you didn’t know you needed yet. Then the tools we know and love can own them.

Back to the cluster

Which brings me back to my own site, the one that started all of this.

I pointed review-squad at it expecting a relatively tidy report. Twenty-six agents across four squads later, I had 60 findings, a remediation plan longer than I could personally handle, and a couple of things about myself I didn’t realize the site was telling people.

It surfaced five issues as show stoppers. The attributions are worth showing, because they are not all equally strong:

1. No search. Ten of the twenty-six reviewers: six of six Normies, the SEO Expert, three Regulars. The most-converged finding of the run.
2. Homepage hierarchy. Six of six Normies couldn’t distinguish posts from category or tag cards.
3. Confusing design. Earl, the grandparent persona: “like opening a junk drawer.”
4. No visible RSS link. Two reviewers, both in Regulars, and both scored it a partial rather than a failure. Weakest evidence of the five.
5. No About page. One persona – the Recruiter in Regulars, failed her “find professional info” task on this gap.

I wanted my site to be a bit of a digital junk drawer – that was intentional. But I can also do that in a way that gives people lifelines. I didn’t need an About page about me; I know who I am. However, I wildly underestimated how confusing the site would be for people without my context. I wasn’t trying to alienate anybody, and it was easy enough to address without changing the experience for those already in the know (read: me).

The audit also catalyzed a pile of adjacent cleanup it hadn’t explicitly asked for: image alt text, duplicate cleanup, slug cleanup. None of it was P0. The panel just made not doing it feel more expensive than doing it.

About that homepage being overwhelming… Linda, a small-business owner, said she’d leave in under two minutes. Margaret, a retired teacher, said the same thing in different words. Multiple Normies agreed that they didn’t care for it.

I kept the design anyway.

In this case busy is the point – it’s intentionally overwhelming. The panel surfaced a real reaction. I, the owner of the design intent, chose not to act on it.

Again: finding does not equal fix.

Where the findings went

Now.. did I actually use any of this?

Yes. Constantly.

The rough shape of the outcome of three runs looks like this:

I wouldn’t treat those numbers as a benchmark. Run the same panel tomorrow and you’ll get a somewhat different pile. This isn’t a deterministic scanner, the units get especially weird if you start mixing raw per-agent findings with a deduplicated consolidated report.

The shape matters more to me: a lot of things worth acting on, some things I consciously disagreed with, and a pile that was real but not worth or not ready for doing right now.

The skipped ones are the interesting ones. On dylanr.com, three were design calls (chip letter-spacing, type-scale consolidation, gallery keyboard scoping), each of which I looked at and said the agent is right that this is unusual; I’m fine with it. Four more were positions I held against the panel anyway.

On Hack Party, one was a magenta-on-chartreuse contrast issue. It fails AA. The brand colors were set, so…

On 2389.ai, Harper deferred everything that needed a human call and shipped the other forty-five in a single sitting… while we were hosting a party.

The backlog got turned into issues for later. That’s just the same old engineering triage.

When to reach for it

Run it as a checkpoint review. Before a merge that closes a meaningful task. When you’ve finished a chunk of work and are about to declare it done. Before you ship.

The default Claude Code session doesn’t bring your team’s perspectives into the room. This is a team-review pass inside that work, before the human code review, and well before the harshest review of all – actual users.

I don’t think of it as CI or a deterministic gate. A clean review-squad run does not prove your thing is good, and another run may notice something the first one didn’t.

It’s a generator of useful review.

Then, when it finds something that should never regress, turn that into a test, a linter rule, a checklist item, whatever boring deterministic thing is best suited to own it forever.

Timewise it’s minutes to hours, not days. I ran all four panels on this post before publishing it: 24 agents, nine minutes. The Hack Party site took about an hour with 27, because three of the four panels drive a real browser one persona at a time instead of reading in parallel.

If you pay per token, this post’s run was 17.2 million tokens (many of them cached, yay!), about $37 at API rates. Other runs are similarly token intensive. On my Max 20× plan, none of them really moved the needle. And frankly, the cost is far outweighed by the benefit.

If you’re only running a single panel, Experts is a decent place to start.

I usually just run ’em all.

On the findings - it’ll start with the show stoppers. Some really are blockers. As you move down the list, some are simple fixes, some are harder, some nuanced, some vital, some less so, and some are just the panel telling you, loudly, about a thing you have consciously decided to do anyway.

The easy-and-converged ones are generally quick fixes. Harder ones can be tracked and triaged and sit on a backlog to get done when you have time or clarity.

Or, honestly, you can do what I do and get the results and tell Claude:

sounds good. fix all that.

Try it

The shape of the work: install the plugin, ask for the squad you want, read what they tell ya, decide what to fix, ship.

For Claude Code, Codex, Pi, etc., you can install it like this:

npx skills add 2389-research/review-squad

Then just ask for it in normal language.

What I usually type is some variation of:

let’s throw all the review squad panels at this

or:

can we do all of the review squads?

Underneath that, the plugin ships four named skills:

review-squad:experts
review-squad:normies
review-squad:regulars
review-squad:well-actually

Throw the team at it and see what they catch that you didn’t.