Passing lint is a good sign, but it is not the same as being safe to ship. A file can be perfectly formatted and still contain a broken assumption, a risky control path, or a security problem that only shows up in real use.
What lint does not prove
- That the code is correct
- That the behavior is secure
- That the file matches the intended product logic
- That the change is safe in production
Why this mistake happens
Teams often treat lint output as a quality signal for the whole file. It is only one signal. If the rest of the review process is weak, a lint-clean file can move through too quickly even when the important parts were never checked.
What reviewers should still confirm
- The control flow matches the business requirement
- The file does not open a new trust boundary
- Secrets, tokens, and sensitive data stay protected
- The file’s failure mode is acceptable
The practical takeaway
Treat lint as the floor, not the finish line. If the file matters enough to merge, it matters enough to review for correctness and security after linting has done its job.