161–166 of 166 posts
Earlier quoted context omitted.
Because your local agent can already see the full codebase; the code review only needs to see what's changing and evaluate the change.
That’s strange. So your policy is “trust me bro my local agent knows best”?
I was using Copilot Code Review pretty religiously for a while, as I get access for free (the $10 plan) due to my Open Source work, but it recently introduced a monster of a misfeature that caused a massive increase in complexity over time, while I wasn't paying close enough attention to it. Every subsequent model saw that change and the explanation for it in the changelog and assumed it was policy rather than a mode…
Earlier quoted context omitted.
That’s strange. So your policy is “trust me bro my local agent knows best”?
This tactic has somewhat broad acceptance in the AI code review sphere, but looks to me like it might trade off accuracy for context reduction/speed.
I found diff reviewers so heavy in false positives, all my coworkers just ignored them.
AI should be used for code review but not in CI. You should already have 2+ developers looking at most PRs. And these developers should absolutely use AI. The PR author should use AI. But what you should not do is pipe the AI output directly into the PR and tell the PR author to deal with it. That's adding noise to the PR review process. Everything it says is something the PR author needs to validate as relevant, hel…
Earlier quoted context omitted.
This tactic has somewhat broad acceptance in the AI code review sphere, but looks to me like it might trade off accuracy for context reduction/speed.
Interesting. For example, GitHub’s built in Copilot review for example will checkout the whole repo and do a broad review. I found it to be WAY better than our prior CI reviews that just looked at diff and had TONs of false positives. (We have also built our own review tools like Copilot that check out repo and they are similarly league ahead IMO than diff reviewers.) I found diff reviewers so heavy in false positive…
The way we set it up was that the code review responded to two signals:
1. GH PR webhook
2. The exact same review agents running as an MCP tool that the local agent can invoke before pushing.
Practically, what this means is that it's OK to have a false positive because the local agent can make the check with the full context.
This would be the same as if the entire team used Codex and, for example, had a sub-agent configured to run code reviews using a smaller model. In this case, the benefit to this tool-based approach is that the exact same agent works for all harnesses across a team and also works in the PR itself.
Earlier quoted context omitted.
Interesting. For example, GitHub’s built in Copilot review for example will checkout the whole repo and do a broad review. I found it to be WAY better than our prior CI reviews that just looked at diff and had TONs of false positives. (We have also built our own review tools like Copilot that check out repo and they are similarly league ahead IMO than diff reviewers.) I found diff reviewers so heavy in false positive…
This is only true if you only run the code reviewer in the final PR. The way we set it up was that the code review responded to two signals: 1. GH PR webhook 2. The exact same review agents running as an MCP tool that the local agent can invoke before pushing. Practically, what this means is that it's OK to have a false positive because the local agent can make the check with the full context. This would be the same…