Serguey Asael Shinder: The task you automate may be the one that trained your reviewers
On 24 September Mihaela Nistor, chief risk officer of the Federal Reserve Bank of New York, gave a speech about a risk from AI that, in her words, will not show up in a loss event and will not trip a control. Institutions have long trained experts through repetitive, lower-level work: junior analysts built the reports, control testers walked the process maps line by line. Nobody mourned the manual work, she said, but it had a second purpose. It was how people learned which numbers looked wrong and when to escalate. Automate it, and the efficiency is visible now while the loss appears five to seven years later as thinner benches of experienced judgment.
She was talking about banks. The same pipeline runs through every engineering team.
Where engineers learn to review
Nobody learns to review code by reading about reviewing. You learn by writing the migration and getting it wrong, by tracing the flaky test to a race, by being the person who had to read the stack trace at two in the morning. The tedious tasks are where you build the pattern library that later lets you glance at a pull request and say that this lock is taken in the wrong order.
When those tasks are handed to a tool, the output may be fine. What stops is the practice. A team can keep shipping correct changes for years on the judgment of people who learned the hard way, while the next group never gets the repetitions. Nothing fails. The review queue just slowly fills with approvals from people who cannot say what they would have caught.
What to do about it
This is not an argument against automation. It is an argument for noticing which work was also training, and for replacing the training on purpose:
- Keep some of the work by hand, deliberately. Rotate newer people through the tasks the tools now do, as exercises with a reviewer, not as production load.
- Make the tool show its working. A generated change that arrives with the reasoning, the rejected alternatives and the tests it ran can be reviewed and learned from. A bare diff can only be approved.
- Ask who could check it without the tool. For each automated task, name the people who could do it unaided. If the list is short and senior, the pipeline is already thinning.
Nistor's point for risk managers carries over directly: without intention, you transfer risk forward in time. The time to notice is before the people who learned by hand have all moved on.