A model writes the change. A model reviews the change and says it looks good. The pull request now has two positive signals on it, and it feels lik...
For further actions, you may consider blocking this person and/or reporting abuse
speaking of which please review my stock website integralstocks.com i will take any feedback. I am a kid who is just looking for some help actualy getting ppl on my website.
Hey William, happy to take a look. Getting people to visit a new site is tough, so don't get discouraged. I'll check it out and give you some honest feedback on the site itself and what might help attract users.
thanks so much for your feedback. it really helps
Of course! Keep building and experimenting. You're already doing something right by putting your work out there and asking for feedback. That's how you improve. Keep it up!
A reviewer built from the same model and the same context as the author is not a second opinion, it is the same blind spot measured twice. Real independence comes from differing prompts, differing context windows or a different model. Without that, the review stage only adds latency and a false sense of coverage to the merge.
I agree, although I'd add that using a different model alone doesn't guarantee independence either. If both models get the same incomplete requirements, they can still miss the same thing. Different context and a review that starts from the actual security requirements matter just as much. Otherwise we're mostly paying twice for the same assumptions.
Independence is the missing variable. A review model that shares the author model’s prompt, context, and assumptions can repeat the same blind spot with more confidence. Use a contrast set with hidden defects and measure disagreement by defect class, not just whether the reviewer produces plausible prose.
I like the idea of measuring disagreement by defect class rather than judging how convincing the review sounds. That's a much better way to test whether the reviewer brings something different to the table. A model that writes convincing explanations but misses the same categories of bugs isn't adding much independence.
Exactly. Defect-class disagreement is a much stronger signal than persuasive prose. I would also retain a small set of seeded regressions by class, so the independence claim is tested against known failures rather than inferred only from live review output.
That's a good addition. Seeded regressions give you a repeatable baseline, so you can actually see whether a reviewer improves or starts missing things after a model or prompt change. I'd rather have a reviewer that consistently catches known classes of defects than one that sounds convincing but is impossible to evaluate.
The invoice endpoint example is the one that got me — auth enforced, ORM clean, and still the wrong person's invoice. That's exactly the blind spot a second model shares, because it read the same ticket. The seeded-helper walkthrough in the comments feels like the only check that actually breaks the loop. Do you do that kind of walkthrough on every role change, or just the ones that touch money?
I'd say every role change deserves at least some level of walkthrough, not just the ones touching money. Permissions tend to have side effects that aren't obvious from the code. The depth of testing can vary with the risk, but I'd always test what the new role can actually see and do, including what it shouldn't be able to access.
AI review was nearly the only check once, on an event app I build. An agent reviewed the new helper role's grant table and tests and reported no permission bugs. I asked for a pass on staging as a seeded helper, clicking through everything. That found a ticket-pricing page showing sales totals to helpers and crew, plus an unrelated double booking. The grants matched the written spec the whole time, and the problems only showed up once a helper opened the screens.
That's a great example of something that's easy to miss when reviewing code in isolation. The grants can be perfectly correct against the spec and you can still have problems in how the app actually behaves. The seeded helper walkthrough is exactly the kind of independent check I had in mind. It tests the experience and the boundaries, not just whether the implementation matches what was asked for.
Your rule that AI review should never count as an approval stood out to me. GitHub’s new Copilot approval option goes the other way: it can now count toward required reviews. It’s off by default and admins choose the file paths, but if AI wrote the code and AI also approves it, aren’t we essentially counting the same opinion twice? Would you consider enabling it for low-risk changes like documentation, or keep it disabled entirely?
I think documentation is a reasonable place to experiment with it, as long as the scope is tightly controlled. But I'd still distinguish an AI approval from a human approval in the process. My concern isn't that AI review has no value, it's that we start counting it as independent assurance when it might not be. The label matters less than being honest about what was actually checked.
The invoice endpoint is a perfect example because every statement the reviewer made was true. Login was enforced and the ORM was safe, and any logged in user could still read anyone's invoice. A reviewer that starts from the same ticket inherits the same shortcut.
I agree with your point that the useful check starts at the requirement: who is allowed to read this? That question has to be written down somewhere before review can test against it.
Jackson's seeded helper walkthrough on staging is the kind of check that is independent by construction, since it exercises the running app rather than reading the diff. Alex's idea of measuring disagreement by defect class is a good way to test whether a second model adds anything at all.
On builds at Ascendra Ventures we write the access rules into the acceptance criteria for exactly this reason, so a reviewer, human or not, has something outside the diff to check. Where would you draw the line on letting an AI approval count toward a required review?
I'd draw the line at whether the approval provides genuinely independent assurance. For documentation or formatting changes, I'm comfortable with AI approval counting as a lightweight check, provided the scope is restricted. For anything involving auth, permissions, payments, secrets or personal data, I'd always require a human approval. The important thing is that we don't let a green AI status quietly become a substitute for someone taking responsibility for the merge.
Different model is not enough. A second review helps when it starts from the threat model instead of the diff.
Exactly. Starting from the diff means you're mostly checking the implementation. Starting from the threat model means you're questioning whether the implementation is safe in the first place. That's a much more useful kind of independence, regardless of which model is doing the review.
Exactlyyy