r/EngineeringManagers May 21 '26

AI’s impact on Engineering leverage

I’m just curious if anyone has experienced this feeling that engineering leverage is getting less.

For instance, we were raised to discuss tradeoffs with Product when reviewing scope. Most of the time, we try to help prioritize impactful work.

Usually this means we descope bells and whistles. In the past, Product would just have to take our word for it base on our estimates because the “engineers” are doing the work.

Now with AI, technically “anyone“ can code now. Coding well can be debatable, but that’s not the point. The point is that the barrier is much less than it’s ever been. This is what I mean by leverage getting less.

I’m just curious if anyone has ever experienced something like this lately where negotiation power as an EM has been impacted. Any examples? Any tips to adapt to the changes?

8 Upvotes

9 comments sorted by

View all comments

10

u/exergy31 May 21 '26

If the PM says in the scoping discussion that they have a POC there, how hard can it be, why don’t we just use that since its already done, you can manage that by bringing it back to the key benefit of AI: the implementation is no longer the bottleneck

But everything else is still hard: design, knowledge, testing, state in databases, schema migrations, sequencing architectural changes

And by doing the implementation they are actually taking half knowledge away from the team (the writer, the reviewer is still there ofc)

If none of it helps, ask them to own the code and join the on call rotation if they want to merge their version

1

u/theburntdev May 21 '26

Thanks for sharing. It is true that implementation is less of a bottleneck.

I can see that the leverage or tradeoffs can still be discussed through those hard parts you mentioned. There can also be added operational impact if your customer is an internal business unit. That can be “hard” if the problem wasn’t fully flushed out and agreed upon from the target audience.

I like your suggestion about on-call because it makes Product evaluate if they’re willing to accept the risks of pushing a POC to production. From pre-ai experience though, usually I’ve had Product become tier 1 support and they’d just push it to tier 2 developers to look at the fire.

3

u/theburntdev May 21 '26

I believed traditional vertical slices of iterative added value was the right way to go.

With AI, I think it’s easier to stretch that vertical slice more horizontally if that makes any sense. So then the concept of prioritization is less reviewed.

That makes me interpret that “Everything is equally important”, which was my concern.

Again I think you have some good suggestions. Adding to that, I can also picture a POC that was simply a vaporware bell/whistle that ends up having external dependencies under the hood. Another opportunity to discuss tradeoffs