Code Review
Code Review
What Is Code Review?
- Peers review code to find errors and improvements
- Catches mistakes you miss alone
- AI code needs review too
Once code review takes hold, ownership of the code changes. Phrases like 'that’s Kim’s module' fade away, and from the moment code is merged it becomes an asset the whole team shares accountability for. Code doesn’t become an orphan when its owner goes on vacation or leaves the company. Problems also surface earlier. A mistake that once had to be found by digging through logs at dawn after an outage gets caught by a single question just before merge. Review isn’t a procedure that eats into the schedule; it’s spending time up front on what would otherwise blow up later.
There are two main ways to run it. Synchronous review, where you go over the screen together and trade feedback on the spot, suits changes that shake up the structure. Asynchronous review, where comments are left on the PR, suits everyday changes. The key is size. A PR that has ballooned to thousands of lines can't be read to the end, so it ends up with a rubber stamp. Each team is better off setting a cap per PR and splitting work into smaller pieces. Roles also need clear boundaries. Leave indentation, naming, and unused variables to linters and static analysis tools, and have people look at design intent and edge cases. Confirming that the code works is the job of test code and QA, not something a reviewer should try to execute by eye.
The most common breakdown in practice is approving without reading. When reviews pile up on one or two senior engineers, PRs stall for three or four days, and the moment a rushed author says 'let's merge now and look later,' review becomes a formality. Conversely, when review becomes a place to push personal taste, juniors grow afraid of opening PRs at all and end up dumping changes in one big batch. AI-generated code is no different: if merging without reading becomes a habit because it seems to run fine, a few months later code that no one can explain sits at the heart of the service.
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ lectures, who gets non-specialists using AI right away
John KimJohn Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”It evolved from quality-control practices in software engineering and became part of everyday development culture as Git and pull requests spread.
Let's look at a hypothetical case. Company A, an e-commerce platform with 140 employees and 22 developers, had 14 post-release rollbacks in the last quarter alone. Under pressure to hit feature deadlines, merging without review had become routine, and only one person really knew the payment module.
- At the quarterly retrospective, the CTO pointed out that '8 of the 14 rollbacks could have been caught before release,' and the team decided to stop merging without review.
- The backend lead had PRs split to 300 lines or fewer and set up branch protection so that merging is blocked until 1 of 2 reviewers approves.
- In the first two weeks, comments were flooded with convention nitpicks, so the team added a linter and static analysis to CI. Machines now catch what they can, and people focus only on design and error handling.
- When review waits grew to an average of 31 hours, the team fixed 10:20 a.m. every day as 'review time' and added a promise: the first comment within 24 hours.
- After the team banned one-line 'LGTM' approvals and required reviewers to note what they actually checked, such as 'I only checked the payment-failure retry path,' rubber-stamp approvals dropped noticeably.
- Three months later, monthly rollbacks fell from 3.5 to 0.8, review wait time dropped from 31 hours to 7, and onboarding for new developers shortened from 6 weeks to 3.