The tools cannot be very interactive with developers. While they provide remediation advice for what they find, the advice is usually generic in nature and not tailored for the specific code in question. Tools also don't know who created the code and see it all as the same. Therefore, they do not help identify developers or teams who may need help with specific issues.
Why manual code review is key
The reviewer who follows-up after the tools to evaluate their results can do better. They take their logical knowledge of the environment and context of the code to provide better remediation advice to the developers. The reviewer helps the developers understand the issues and answer questions in ways the tools cannot. Even better, they can join the developers at the white board and help them come up with detailed fixes for complex issues and evaluate the fixes before the code is committed and ready for another scan.
The reviewer can also get to know the code and who owns particular parts of the code. Over time, they may begin to know that particular developers or particular teams create the same security bugs time and time again. They may begin to see that Steve has a problem with time and state issues, Bob has problems validating input, and Sue often forgets to encode output for the proper context. This insight can guide training efforts either for one-on-one training or broader group efforts. This, in turn, can help keep the problems from recurring over and over again, reducing the time spent fixing the same old bugs and make tight schedules easier to meet.