The thing to understand is that it is not about improving developer efficiency. It is about improving corporate profits.

Because that engineer using “AI”? If they are doing work that can be reliably generated by an AI then they aren’t a particularly “valuable” coder and, most likely, have some severe title inflation. The person optimizing the DB queries? They are awesome. The person writing out utility functions or prototyping a feature? And, regardless, you are going to need code review that invariably boils down to a select few who actually can be trusted to think through the implications of an implementation and check that the test coverage was useful.

End result? A team of ten becomes a team of four. The workload for the team leader goes up as they have to do more code review themselves but that ain’t Management’s problem. And that team now has saved the company closer to a million a year than not.

And if people key in on “Well how do you find the people who can be trusted to review the code or make the tickets?”: Congrats. You have thought about this more than most Managers.

My company hasn’t mandated the use of AI tools yet but it is “strongly encouraged” and we have a few evangelists who can’t stop talking about how “AI” makes them two or three times as fast and blah blah blah. And… I’ve outright side channeled some of the more early career staff that I like and explained why they need to be very careful about saying that “AI” is better at their jobs than they are.

And I personally make it very clear that these tools are pretty nice for the boiler plate code I dislike writing (mostly unit tests) but that it just isn’t at the point where it can handle the optimizations and design work that I bring to the table. Because stuff is gonna get REALLY bad REALLY fast as the recession/depression speeds up and I want to make it clear that I am more useful than a “vibe coder” who studied prompt engineering.