If you’ve worked in the tech industry for a while, you’ve seen numerous stand-alone roles disappear.  The role of database administrator is one example.  Quality assurance staff, whether you called them engineers or testers are another example.  A previous employer of mine, having adopted agile delivery lead as a hybrid of scrum master and project manager years earlier, eliminated every employee with agile in their job title during the depths of the pandemic—1700 jobs in total.  The disappearance of those roles did not mean their work disappeared.  It meant the work shifted to those who remained.  Developers and engineers inherited DBA and QA work.  Product owners and senior engineering managers inherited the work of agile delivery leads.  

In each case, the quality of the work and the level of productivity declined, while we who inherited the new work absorbed and adjusted to the broader scope.  What tech companies previously did by blurring the line between development leads and development managers is now being applied to more senior engineering managers,  brought by AI (at least according to James Stanier).  At least in my experience, the blurring of roles and responsibilities at the next level already happened during the pandemic—prior to the launch of ChatGPT.

In the section of his piece with the heading “The evolving engineering manager role” Stanier  lists the following things AI automates that “defined many engineering manager roles”: status updates, progress tracking, meeting summaries, and scheduling.  This looks a lot like work I inherited after every agilist in my organization was laid off—in addition to my existing responsibilities.  However, that list falls well short of defining all the work I did as a senior engineering manager for 12-18 engineers spanning 2-3 teams over the past few years.  My responsibilities included quarterbacking production incident response, defining and driving application modernization, and providing technical feedback on significant architectural changes across multiple systems within our group.  After the flattening that same organization executed in 2025, my scope of people management above and beyond my technical responsibilities grew from 7 engineers to 12 engineers.  Combining people leadership with genuine technical depth was already the job description for engineering leaders at my level, along with fulfilling the responsibilities of people in roles which were previously eliminated.  Stanier's framing treats coordination as organic engineering overhead.  But in larger organizations, it was a stand-alone role—held by non-engineers—which senior engineering managers absorbed when those roles were eliminated.

Stanier again: “The coordination was never valuable in itself; it was a cost imposed by the limits of what one person could do alone.  AI is removing that limit, and the data is starting to show it.”  I’ve written previously about the impacts of organizational flattening that I’ve observed personally and read, but it’s worth drilling down on what Stanier oversimplifies by calling it “coordination”.  That’s not the only thing happening when engineers collaborate to solve problems.  They are sharing institutional knowledge.  They are building tacit knowledge—the kind that exists primarily in relationships built through repeated collaborations over time.  Engineers have much longer and more durable “context windows” than AI, and the software resulting from repeated collaborations over time is more likely to be better-designed and more robust than its AI-generated equivalent.  

Stanier references The AI Productivity Paradox Report approvingly, but it contains findings which undermine his argument.  He acknowledges its finding that high AI adoption results in 9% more bugs per engineer and PRs which are 154% larger on average. Amazon pivoting to requiring senior engineer sign-off on AI-assisted changes has likely caused review bottlenecks as AI generates large PRs faster than humans can review them.  A Barcelona-based engineering leader for a large online wedding planning company I’ve spoken with regarding Stanier’s article has observed this phenomenon with a recent project his team led.    

Even those boosting AI adoption acknowledge that it drives both significant code bloat, and the same report "observed no significant correlation between AI adoption and improvements at the company level”. By suggesting that senior engineering managers cede coordination and reporting responsibilities to AI and leverage it to generate code, Stanier is advocating compounding AI-associated risk and putting responsibility on the senior engineering manager to effectively mitigate both.  As strategic decision-makers, senior engineering managers should be mitigating risk—not compounding it.