/teachme and /quizme
The two Claude skills that changed how I do reviews
I Used to Be the “Final Boss” of Code Reviews
That’s how a teammate put it once. Engineers would open a PR and I would go deep into reviewing them. Half a day sometimes just reviewing PRs.
I was the one who nitpicked, and I owned it. My reasoning was that nitpicking kept me close to the code. Understanding the “why” behind every small choice.
That worked well. Engineers generally found them helpful and appreciated the effort.
Then AI coding tools arrived.
First, the obvious problems mostly went away
The low-level issues that used to fill my review comments? Largely gone. The code quality baseline seemed to go up. Then the size of the PRs grew. As well as complexity. Engineers were empowered to tackle problems they might have avoided before, that would have taken a lot of time to figure out. Even if they could not explain every corner of the PR.
I would still catch things. In our n8n Typescript-based codebase, agents would often take shortcuts around types, reaching for as SomeType casts instead of resolving the actual type or using type guards. We never formalized this as a lint rule (as there are usecases where this pattern is useful), but as a guideline. We put it into our Claude.md files, into our AI Reviewers, but it would still crop up. But that’s a narrow category compared to the number of issues that I would catch before.
But the deep review work didn’t go away. If anything, it got harder.
The new problem
Here’s what changed though. As software engineers, we are pushing into unfamiliar territory because coding agents can handle the hard parts.
We are moving faster, creating larger PRs and bigger features, without deep understanding, i.e the kind of understanding that comes from running into walls as one solves a problem. Leading to a growing “comprehension debt”, where engineers can no longer answer simple questions about the systems they are building.
I now find myself embarrassed when a question comes up on a PR that I “wrote”, but cannot explain that decision.
And as a PR reviewer, reviews got harder. I’m often reviewing PRs outside my comfort zone, with unfamiliar context. Simply because I am missing that that deep understanding that’s gained through hands-on learning.
Or I was simply forced to rubberstamp to move on.
As such, I needed to find new ways to improve my understanding of the codebase I was working with.
Two skills that changed how I review
I’ve been using two custom skills in my Claude Code setup: /teachme and /quizme.
/teachme takes a PR and builds a syllabus from it. Then it walks through section by section, explaining what’s happening from the perspective of someone presenting the work. Not hunting for bugs, but explaining. And that small difference matters more than I expected.
Because it’s not adversarial, I have to bring the adversarial thinking myself. I’m listening to the explanation and forming my own judgments in real time. I think harder, not less. And I consistently find deeper issues this way than I do when I’m scrolling through diffs looking for red flags.
Afterwards, I can walk through the code, quickly understanding since I have enough context.
Even when reviewing a PR in unknown codebase, /teachme gives me enough grounding to actually have an opinion about it.
/quizme tests my limits of my knowledge
/quizme follows a similar pattern: it generates questions about the PR or a section of the codebase.
I even use it on my own PRs, to confirm I understand what I just built. When I’ve been vibe coding with an agent and I want to confirm I actually understand what it built, /quizme forces that reckoning. It asks questions I’d be embarrassed not to answer about my own code. Sometimes I can’t. That’s the point.
I also use it after I finished a /teachme session, which helps to solidify what I just learned. At the end, it gives a report showing where my gaps are.
AI Code Reviewers are not the answer, yet
We surveyed our team recently about whether human code reviews were still worth the time. The answer was unambiguously yes. Engineers said they regularly catch issues that coding agents and AI review tools both missed.
We’ve tried quite a few dedicated PR review tools (Cubic, Claude in Github, Cursor), and they’re useful up to a point. But the cases that matter most still need system understanding that these agents usually lack.
Am I faster now?
In reviews? A little, maybe. But that’s not what I’m optimizing for.
What I care about is that reviews are doing real work again, and that I feel closer to the code than I did when I was handing everything off to agents. Because that’s where the learning and growth is.