Code Review at Scale

Standard code review tools and AI coding assistants review code file by file, diff by diff. This is great for catching syntax errors, style issues, and isolated logic bugs. It's poor at catching architectural problems, inconsistencies across a feature branch, and patterns that only become visible when you see the full change at once. A large feature branch might span 50 files, 3000 lines of changes, and touch 8 different modules. A file-by-file review can miss that the authentication change in auth.service.ts creates an inconsistency with the permission check in middleware.ts that's only visible when you read both. Or that the new data model in models/user.ts creates a migration dependency that's not handled in the seed files. These cross-file, cross-module issues are where real production bugs live. Kimi's code review workflow: use repomix or git diff to generate the full branch diff as a single file. Include surrounding context (--context=10 flag for git diff) so Kimi understands the existing code the changes sit within. Feed the full diff plus a branch description to Kimi. The difference in review quality for large PRs is significant. Kimi has reviewed the entire change holistically and can reason about it as a system change, not a collection of isolated file changes. This is particularly valuable for changes that touch infrastructure, shared utilities, authentication, or data models — the high-risk, cross-cutting concerns.

The code review prompt needs to specify what kind of review you want. Different reviewers look for different things — a security-focused review, an architecture review, and a readability review will produce very different comments on the same code. Security-focused review prompt: 'Review this code change for security vulnerabilities. Specifically check for: SQL injection, authentication bypass possibilities, improper secret handling, unvalidated user input used in system commands, CORS misconfigurations, and any dependencies with known vulnerabilities. For each issue found, rate severity (Critical/High/Medium/Low), explain the exploit scenario, and suggest a fix.' Architecture review prompt: 'Review this feature branch for architectural quality. Check for: (1) violation of existing patterns used elsewhere in the codebase, (2) unnecessary coupling between modules, (3) functions that do too many things (SRP violations), (4) missing error handling, (5) any performance concerns at scale (N+1 queries, unbounded loops, missing indexes). Reference specific files and line numbers.' Pre-shipping review prompt: 'I'm about to merge this feature to main. Play the role of a skeptical senior engineer. What's the most likely thing to go wrong in production? What edge cases haven't been handled? What would you want verified before merging?' For open-source contributions specifically: 'Review this PR against the project's existing code style and architecture. Would a core maintainer of this project likely request changes before merging? What are the most likely change requests?' Always follow up Kimi's review with your own read of the critical findings — use Kimi's output as a structured starting point, then apply your engineering judgement.