Intern Code Review Checklist: 3 Diffs We Shipped to Production

The Intern Code Review Checklist: 3 Diffs We Shipped to Production

At Agentic Academy Labs in Sikar, our internship runs on a hard constraint: every PR must be under 400 lines, have a named owner, and ship to a deploy you can show. This rule came from a client who needed weekly releases with zero production incidents. It forced us to rethink review culture from the ground up.

The Constraint That Changed Everything: Small Diffs, Named Owners

We used to let interns submit 800-line PRs. Reviews took days. Bugs slipped through. Then a fintech client in Jaipur told us: weekly releases, zero incidents, or the contract ends. We responded with a rule: 400 lines max per PR, named owner required, deploy must be demonstrable.

This wasn't theoretical. It came from real pressure. And it worked. Here are three diffs that shipped to production, what broke, and what we learned.

Diff 1: The Pagination Bug That Looked Clean

What we tried: A frontend intern added pagination to a customer list endpoint. The PR passed all tests, the diff was under 200 lines, and the reviewer approved it quickly.

What actually failed: In production, rapid page switching caused stale data to appear. The issue was a missing cache invalidation key in the Redis layer. No unit test caught it because staging traffic was too low.

The working approach: We added a composite cache key using page_number and last_updated_at in src/services/customer_service.py. We wrote a test that simulated 50 concurrent requests. The fix was a 40-line diff in cache_keys.py.

Pitfalls to warn an intern: Never trust staging traffic patterns. Always test cache invalidation under load. A clean diff can still hide concurrency bugs.

What we'd do differently: We'd require a load test for any endpoint that touches Redis, even if it's a small change.

Diff 2: The SQL Injection That Passed Linting

What we tried: A backend intern wrote a search endpoint using string concatenation for a LIKE query. The linter passed, the reviewer missed it, and it shipped.

What actually failed: A security audit flagged it as a critical SQL injection risk. The query was in src/api/v1/search.py and used f"SELECT * FROM products WHERE name LIKE '%{query}%'".

The working approach: We replaced it with a parameterized query using SQLAlchemy's ilike() method: Product.name.ilike(f"%{query}%"). We also added a pre-commit hook that runs bandit on every PR.

Pitfalls to warn an intern: Linters don't catch logic-level security issues. Always use parameterized queries, even for simple searches. Never concatenate user input into SQL strings.

What we'd do differently: We'd add a mandatory security checklist item for any PR that touches database queries, signed off by a senior engineer.

Diff 3: The Feature Toggle That Wasn't Toggled

What we tried: An intern added a new pricing calculation behind a feature flag. The code looked correct, tests passed, and it deployed.

What actually failed: The flag was never enabled in production. For three weeks, the new pricing logic sat dormant while the old logic continued running. When we finally flipped it, we discovered a rounding error that affected 2% of orders.

The working approach: We moved the flag to config/feature_flags.py and added a health check endpoint at /health/features that reports the status of all flags. We also wrote a test that asserts the flag is enabled in the test environment.

Pitfalls to warn an intern: A feature flag that's never toggled is dead code. Always verify the flag is active in the target environment before considering the PR complete.

What we'd do differently: We'd require a deployment verification step that confirms the flag is enabled, not just that the code is deployed.

The Checklist We Now Require Every Intern to Use

Before any PR, walk through these items:

• Main execution paths: walk through mentally
• Boundary conditions: empty input, null, zero, negative, max values
• Error paths: do they work or silently swallow exceptions?
• SQL injection and IDOR: scan for raw query construction with user input
• PII in logs: confirm no sensitive data is logged
• Tests cover unhappy paths, not just success cases
• Backward compatibility: API, database, and queue changes are safe
• Feature toggles: confirm the flag is active in the target environment
• Integration timeouts: verify all external calls have timeouts set

What We'd Do Differently Next Time

We'd integrate automated risk checks into CI. A script that flags:

• Any PR touching database queries without parameterized queries
• Any PR with cache logic without invalidation tests
• Any PR with feature flags without a verification step

We'd also rotate reviewers so no single person becomes a bottleneck, and we'd track time-to-first-review as a team metric.

The Real Lesson

Code review isn't about style. It's about risk. Every diff we shipped to production taught us something. The pagination bug taught us that staging traffic lies. The SQL injection taught us that linters miss logic-level issues. The feature toggle taught us that deployment isn't completion.

We now require every intern to sign off on this checklist before submitting a PR. It's not perfect, but it's better than learning the hard way.

---

Sources:

• Code Review Best Practices for India Dev Teams 2026
• Code Review Checklist, 2G
• Self-code review checklist I wish I had when I was a Jr. Engineer at Amazon
• AI increased our throughput. So code review became our safety system.
• Code reviews that actually help
• What I Check Before Every Deployment