How AI Is Changing the Engineering Manager Role: More Context, More Capacity, and the New Job of Protecting Focus

AI is changing the engineering manager role by widening access to technical context rather than turning managers back into full-time coders, and the real management problem it creates is overload: teams that once ran one or two workstreams now juggle several in parallel per person.

The job that emerges from this shift has less to do with reviewing code and more to do with deciding what a team should start next.

To understand how this plays out day to day, it helps to hear from two engineering managers with genuinely different vantage points on the same underlying shift.

Alejandro Rizzo is an Engineering Manager and Product Engineer on the Odin Squad at Codacy, working on new features and market-driven work, with a background spanning full-stack development, frontend, agile, UX and product management, independent consulting, and entrepreneurship before he joined Codacy as a frontend engineer.

Jorge Braz has spent ten years as an engineering manager, preceded by roughly ten years as a software developer, and now manages the Reliability and Tarot squads, which focus on platform stability and resilience.

What connects their experiences is a shared thesis: AI's biggest effect on the engineering manager role is not that it writes code faster, but that it expands access to technical context and the capacity to start new work, and that expansion creates a focus problem nobody was managing for before.

How AI Changed the EM Role

The most common assumption about AI and engineering management is that better tools pull managers back toward hands-on coding, but that assumption doesn't hold up once you look at how it actually plays out. What changes is the distance between a management decision and the technical system underneath it, not whether a manager ends up writing production code again.

Jorge’s experience illustrates this precisely because his day-to-day coding habits haven’t moved at all. AI, he said, “gave me the capability to contribute more from an IC perspective than I had before.” That meant data exploration, tooling, and other work that previously required specialized knowledge he didn’t have and didn’t want to acquire. It didn’t mean returning to production code: “I still don’t know how to read a single line of Scala.”

Alejandro’s experience runs in the opposite direction because he started from a more hands-on baseline, and AI simply extended that instinct further. He describes using it to build MCPs, extensions, and CLIs “from zero,” as greenfield projects, while also using it to navigate Scala code he wouldn’t otherwise be comfortable working in.

Two engineering managers, two very different starting points, but the same underlying mechanism: AI let each of them investigate, navigate, and understand systems faster than before, without requiring either of them to become the person who ships the fix.

How AI Changes Access To Context

The single most important shift both managers described is that building a working mental model of a codebase now takes minutes instead of hours, and that changes what a manager can reasonably ask an engineer to do before writing any code.

Context here means the accumulated understanding of how a system's pieces connect, where its assumptions live, and what breaks when you touch it, and that used to be earned slowly through direct experience.

Jorge framed this in terms of accessibility rather than automation. “Access to context or to an approximation of context is now way easier to get,” he said. What used to mean “hours of churning through code” can now produce a fast, if imperfect, picture of the problem. His expectation of engineers has shifted accordingly: he now expects them to leverage available tools rather than spend excessive time gathering context manually.

Alejandro takes the idea one step further. “The biggest difference on AI is not about writing the code itself,” he said. It’s about understanding “what needs to be built, what is going to change, what is going to be affected” and what constraints need to be accounted for. His estimate is striking: “85-90% of what actually helped is before writing code. Before writing anything.”

That reframes AI's contribution away from code generation and toward something closer to a fast pairing partner for investigation, one where the human still owns every decision about what to build and how.

For a manager, this is the part worth internalizing: you can now investigate a technical question yourself without needing to become the person who implements the answer, which is a genuinely new capability rather than a faster version of an old one.

What Happens When Everyone Can Do More

The problem, as Jorge puts it, is not simply that teams can do more, but that being able to do so much does not mean “that we have to do that much in parallel.” Before AI, a squad might have worked on one or two features at a time. Now, he says, “every single person can work on one feature and be planning the next one,” leaving three or four people juggling “four, five, six different topics” at once.

The result is a strange kind of productivity failure: the team is capable of moving more work forward, but its attention is fragmented across more unfinished work.

The cost of that isn't visible in a burndown chart. It shows up as context switching and cognitive load, which Jorge connected directly to stress, noting that this dynamic adds significant pressure on people even when the underlying capability feels like pure upside.

Alejandro recognizes the same problem in his own behavior. His new ability to contribute more also means he produces more for the team to absorb: new documents, proofs of concept, bugs, and ideas that someone else now has to read, check, or act on. “It’s really hard to keep balance on those two things,” he said.

He described how developers pile on topics themselves: a bug catches someone's attention, they start investigating, and within an hour they're juggling several open threads without having consciously decided to take any of them on.

That self-inflicted quality is precisely why this became a management responsibility rather than something teams naturally self-correct. Alejandro described actively working to limit the number of topics running per person and per squad, staying vigilant about it because the pressure to expand comes from stakeholders and from the engineers' own curiosity in roughly equal measure.

Managing Expectations About What AI Can Deliver

The stories driving those expectations are familiar: an app built in a week, bugs fixed from a commute, an agent reducing a security backlog from 1,000 vulnerabilities to 10. Alejandro described the effect plainly: “All of this creates expectations that many times add weight on developers maintaining a real codebase.”

Those stories are real in isolated cases, but they create expectations that land squarely on developers maintaining a production codebase with years of accumulated dependencies and edge cases.

But neither manager thinks AI invented unrealistic expectations. Jorge’s shorthand for the problem is an old one: “It’s just a button. Why isn’t it easy to just add a button?” The difference is that AI now gives everyone more ways to investigate, prototype, and produce something that makes the request look deceptively simple.

AI gave everyone, including the people making those assumptions, a new set of tools that reinforce the old assumption more convincingly than before. Estimation and impact analysis still belong to the engineers who understand the system's actual constraints, and faster inputs from AI don't replace the judgment required to commit to a scope and a timeline.

More Output Raises the Technical Bar

For Jorge, the basic tradeoff hasn’t changed. “AI is giving you more speed,” he said, “but the cost will always be quality or will always be a smaller scope.” For his reliability-focused teams, that makes the choice straightforward: quality is the corner that stays fixed.

For a team whose entire purpose is platform reliability, as Jorge's is, that means deliberately fixing the quality corner and accepting smaller gains in raw speed and scope than a team with more tolerance for failure might take.

Alejandro arrives at the same conclusion from the opposite direction. “The only code that has no bugs is no code,” he said. More code means more opportunities for bugs in absolute terms, even if the underlying defect rate hasn’t changed. If a team used to ship one feature a week with two bugs surfacing after release, and AI lets that same team ship a hundred features in a couple of days, the absolute bug count scales with volume even if nothing about code quality discipline has degraded.

That math is exactly why certain safeguards matter more now, not less, even though the safeguards themselves aren't new:

• Tests across paths and edge cases: guaranteeing that both the expected flow and the unusual cases are covered by tests, so regressions get caught automatically as the volume of shipped code grows.
• Low duplication and low complexity: keeping functions and modules small and legible rather than large and brittle, which matters more when a larger share of new code isn't hand-reviewed line by line.
• Higher standards for AI-generated code specifically: both managers described holding AI-produced code to stricter testing and complexity standards than they might have applied to human-written code a few years ago, and using Codacy itself to enforce that distinction consistently.

The risk that deserves the most attention here isn't an obvious breaking bug, because those get caught. It's automation bias, the tendency to trust well-formatted, confident-looking code simply because it looks correct, even when it's quietly compounding a problem that won't surface for months.

Jorge offered a useful nuance: some of this discipline is simply the same practice at higher speed, comparable to the leap from typewriters to computers, while other parts of this shift represent a genuinely different paradigm that the industry hasn't fully worked out how to measure yet.

What This Means for VPs of Engineering

The org-level version of this problem is straightforward to state and easy to miss in practice: giving every engineer and every manager more capacity to investigate and produce doesn't mean the organization should pursue everything that new capacity makes possible. The risk compounds easily.

Teams fill their available capacity with parallel work because they can, technical debt accumulates faster because volume is higher, and delivery expectations drift upward because a handful of visible wins get generalized into a baseline assumption.

What a manager actually needs in this environment isn't the ability to review every line their team or their AI tools produce. It's enough technical visibility to challenge assumptions about speed and scope, to protect focus deliberately rather than reactively, and to confirm that faster delivery isn't eroding quality underneath the surface.

This visibility has to come from somewhere other than manual inspection, because manual inspection doesn't scale with the volume AI-assisted development produces.

Codacy's AI Inventory gives engineering leaders visibility into which AI tools and technologies are actually running across their repositories, which matters more than it sounds because most organizations underestimate how fragmented their AI tool usage has become across teams.

Quality and security reporting provides the ongoing signal for whether increased speed is degrading code quality or introducing security risk, rather than waiting for that answer to arrive as an incident.

Quality gates enforce consistent standards at the point of change, including the stricter standards on AI-generated code that both Jorge and Alejandro described applying manually, which removes the manager from the position of being the last line of manual review for everything the team ships.

Closing Advice for Engineering Managers

Jorge’s answer to what engineering managers should focus on was deliberately non-technical: “Leading manager’s responsibility is not AI, it’s the people that are working in these teams.” His point is that the technology changes the environment, but the manager’s responsibility remains making sure the team has the “capabilities and the capacity” and the headspace to do the work.

Alejandro’s version is more practical. He has been deliberately trying to keep people from accumulating too many simultaneous threads, including threads they create themselves when a bug or interesting problem catches their attention. His advice is simple: “Just keep an eye on this, on how stressed and overloaded your people are.”

That may be the least futuristic answer to an AI-era management problem, but it may also be the most important one: when the cost of starting work approaches zero, deciding what not to start becomes part of the job.

Keep up with Alejandro Rizzo and Jorge Braz on LinkedIn.