Your article captures my biggest concern about AI so far. Emphasis on "so far".
I worry the rush to implement AI for efficiency gains will prove to be incredibly short-sighted. AI is replacing many of the tasks that help junior experts become better experts, and how the organisation learns in general. Efficiency is obtained over the short term, but there is a risk to the long-term capability of an organisation that doesn't stop to think about how they are going to compensate for the impact on their talent pipeline.
And I completely agree with "The visible output of code review is better code. The invisible output is a better engineering organization."
The invisible output can be much more important over time. A junior expert watches how the senior expert thinks, what they notice, which evidence they ignore, where they challenge an assumption, and why a similar problem is actually an exception.
I've written previously about the importance of deliberate practice in developing expertise. Expertise isn't simply accumulated knowledge. It develops through repeated experience, feedback, and opportunities to make increasingly difficult judgments.
If we automate something because its visible output can be produced faster, do we actually know what invisible developmental work we've just removed?
Your concern crosses two areas I'm scared about. One, that we're losing the knowledge sharing from code review. And two, that the rush to do a one-time automation of human expertise, we've stopped hiring junior devs and starved our pipeline for future expertise (even if we could figure out a way to build it, once they're hired).
Thanks for pointing that out, Pito. That was a mathematically impossible statement that I had carried over from the underlying paper. I have corrected it after confirming what the authors have said about it.
Your article captures my biggest concern about AI so far. Emphasis on "so far".
I worry the rush to implement AI for efficiency gains will prove to be incredibly short-sighted. AI is replacing many of the tasks that help junior experts become better experts, and how the organisation learns in general. Efficiency is obtained over the short term, but there is a risk to the long-term capability of an organisation that doesn't stop to think about how they are going to compensate for the impact on their talent pipeline.
And I completely agree with "The visible output of code review is better code. The invisible output is a better engineering organization."
The invisible output can be much more important over time. A junior expert watches how the senior expert thinks, what they notice, which evidence they ignore, where they challenge an assumption, and why a similar problem is actually an exception.
I've written previously about the importance of deliberate practice in developing expertise. Expertise isn't simply accumulated knowledge. It develops through repeated experience, feedback, and opportunities to make increasingly difficult judgments.
If we automate something because its visible output can be produced faster, do we actually know what invisible developmental work we've just removed?
Your concern crosses two areas I'm scared about. One, that we're losing the knowledge sharing from code review. And two, that the rush to do a one-time automation of human expertise, we've stopped hiring junior devs and starved our pipeline for future expertise (even if we could figure out a way to build it, once they're hired).
“…reduced by more than 330%” ?
Thanks for pointing that out, Pito. That was a mathematically impossible statement that I had carried over from the underlying paper. I have corrected it after confirming what the authors have said about it.