I believe there will be 5 main changes that will force us to adapt:
The constraints (AKA bottlenecks) in the organizations will move
A much bigger scope of responsibility for teams
More outages, bugs, and crises
The engineers will have to make product decisions
Less focus time for engineers
Before I go deeper into each one, here are my assumptions:
AI will not replace (most) developers in the next 5 years. Non-technical people will be able to create basic (and great!) products - but will continue to hit the ceiling with more complex products. A developer + prompt > non-developer + prompt.
The LLMs will become better and better at complex coding tasks. Cursor and others have a growing goldmine of data. They know what doesn’t work based on our frustrated prompts, and there will be great LLMs specifically for coding.
Software engineers will become much faster, across most domains. The newer the company, and the simpler the domain, the bigger the improvement. An improvement of 2-3x software delivery speed will be common at ‘classic’ SaaS startups.
The 5 changes I’m covering will start with the younger, simpler, companies. Still, I believe that even big and complex companies will have similar changes (just slower, and to a lower degree).
1. Moving the bottleneck
Every process has a constraint (bottleneck) and focusing improvement efforts on that constraint is the fastest and most effective path to improved profitability.
I first truly understood the Theory of Constraints and bottlenecks while reading ‘The Goal’ and its tech version, ‘The Phoenix Project’ - both highly recommended.
It’s the one place where if you improve your speed, you will deliver more. For example, if your bottleneck is the QA process, writing more code won’t help - the features will be stuck waiting for QA. If you hire 2x many QA people, the bottleneck moves to developers - QA people will sit idle, waiting for features to test (just an example, not a big fan of manual QA roles).
Today, in most companies, our software teams are the bottlenecks!
We never fix all the bugs (no time)
We negotiate with the PM on the scope (no time for everything)
There is an endless backlog of ‘wishes’ (no time)
That’s why engineers were always in demand, and our salaries kept rising. Companies needed innovation and new features - and the only way to do that was to hire more software engineers.
Now imagine the scenario where you come to your PM, saying: “Ok, so we finished the roadmap 2 months early, and all the tickets in the backlog are completed. What now?”. I would like to see their reaction🙃
This scenario sounds crazy, but the shift is already happening.
So what does it look like when engineering is no longer the bottleneck?
Turns out there is nothing new here. I recently re-read 'Extreme Programming' by , where he wrote (20+ years ago!):
”…Development team begins applying XP [Extreme Programming], dramatically improves quality and productivity, but then is disbanded, its leaders fired and the rest of the team scattered.
Why does this happen?
From the Theory of Constraint perspective, the team’s improved performance shifted the constraint elsewhere in the organization. The new constraint (e.g. marketing, who can’t decide what they want fast enough) doesn’t like the spotlight.”
This is starting to happen.
We have been seeing a lot of layoffs in the last 2 years, but only recently “higher developer productivity” started to appear as the reason. For example, Salesforce will not hire engineers in 2025:
These advancements have significantly accelerated the company's engineering capabilities, making it unnecessary to expand the software engineering team for the upcoming year.
In my opinion, this will continue to happen in companies that are doing “more of the same”. Eventually, it will stabilize, and then things become interesting.
What does it mean for Engineering Managers
I wrote 14 months ago about how Product Management is broken. The situation where the PM decides on WHAT to build was always problematic, and led to poor results.
It was always true that the best EMs have a bit of a Product Manager side to them - the new reality just strengthens it.
There will be less and less place for the purely technical Engineering Manager. We will have to take part in the ‘business’ conversations, and not rely on the PM to make the decisions.
Why are we building this feature?
How do we measure its success?
How does our business make money?
Drive Business Impact as an EM - 30 minute lightening session
I’ve been thinking and writing about this topic for a while. I truly believe that engineering managers can and should affect business outcomes - and that it’s easier than it sounds!
In a couple of weeks I’ll hold a free 30-minute lightening session about how to drive business impact as an Engineering Manager. I would love to see you there :)
2. A bigger scope of responsibility for each team
Every manager of a long-standing team has experienced this scenario:
You continue developing new features, but you rarely get the chance to deprecate old ones. The graph of “lines of code my team is responsible for” (and projects/systems/features) keeps going up.
This can become very challenging. People come and go (or are let go), and the newer people are not familiar with the ‘legacy’ code. It becomes very hard to understand all the systems you are responsible for.
But the organization doesn’t really care. They take into account only the new work you are doing, not the cost of maintaining everything that was done until now.
So if you can create 2X more features → you can support 2X more features…
What does it mean for Engineering Managers
LLMs are also great at explaining existing code, which makes those expectations somewhat realistic (but still very challenging). Everyone will have to get used to jumping between apps and codebases. More context switches, more chaos.
And while our developers will need to deal with the technical challenges of the increased scope, we will need to deal with the business implications, and with the next point ↓
3. More outages, bugs and crises
2X more code => 2X more problems. As simple as that. Even if you read every line the LLM write, and have terrific code reviews, you will still have more problems.
In addition, you will have to deal with realities like this:
Now, a customer reports a bug via Slack → support tags it → AI iterates on the fix → pipeline goes green → deploy straight to production.
This might be nice for a very simple app, but we are not there yet. I’ve experienced the mess Cursor can cause. In a big and complex codebase, this will create pure chaos.
We will face A LOT of pressure to deliver faster, write more code, and verify it less. I’m SURE there will be very funny (and sad) stories of crazy outages caused by LLM-written code. There will be weird bugs, and ‘commando’ engineers who will have to dive into a mess of a codebase to fix those issues.
What does it mean for Engineering Managers
You will become the gatekeeper. And honestly? While I’m sure the overeager people will get burned - I recommend not fighting the revolution but finding a safe way to integrate it.
In 1957, engineers were writing in Assembly, than FORTRAN came along.
You know what happened? Senior engineers insisted on reviewing the compiled Assembly code. "You can't trust the compiler!"
How did that work out? (Ok I admit, this is purely anecdotal and I don’t think it really happened like that. But you get the point.)
Today, we're at the same crossroads with AI. Yes, AI-generated code mostly sucks right now. But, there will be a day soon when reviewing every line of code will be as outdated as checking compiled Assembly.But here's what I think we will still do:
Thorough tests - integration tests matter more than ever.
Sample the output - when you find issues, improve the prompts. Fix patterns, not instances.
Focus on Architecture - engineers should definitely still own the big picture.
Build guardrails:
Automated quality checks
Performance thresholds
Security scanning
4. Engineers will have to make product decisions
I’m pretty sure about the first 3 points - I honestly believe that most engineering managers will feel them in the upcoming years, in various degrees.
The next 2 points are more speculative, I would love to hear your thoughts!
So far, we have:
Less people
More responsible
More problems
Now, some good news! :)
Today, most engineers usually get a pretty detailed requirements document. We do a technical design, kick it off, and then go to implement it.
Then, during the implementation, we might need the PM’s input once every couple of days, when we encounter some dillema or case we didn’t think about. Usually a daily standup is enough to cover those.
With vibe coding, the ‘long and boring’ tasks will disappear. The technical challenges will become easier, too. Engineers will spend even less time coding, and more time thinking about the users, the product, and the problem we are trying to solve.
To do that effectively, our engineers must understand the bigger context, and have the authority to make smaller product decisions themselves. They can’t go running to the PM about every button placement.
What does it mean for Engineering Managers
This depends a lot on your company. I believe that in some places, the roles of EM and PM will combine to ‘Product Engineering Manager’. In other places, PMs will be more outbound, and EMs will need to help the engineers gather the context and understand why we are building things.
I love ’s approach to it, that they covered in this article:
Our engineers run the show. They manage product teams. They have complete autonomy and drive our products forward. They even *gasp* talk to users.
Engineers often don’t have the bandwidth to gather and distill all the information they need. This is where PMs can help. At PostHog, it’s their job to:
We think of PMs as the team’s compass. They don’t decide the destination, but they provide information to let the team know if they’re headed in the right direction.
Not PMs deciding. Not EMs deciding. Engineers deciding.
Most engineers are not ‘born’ product engineers, and they need help to learn and sharpen their product skills. That’s where we come in.
5. Less focus time, more “people” time
Building software will become a much more interactive effort. There will be fewer and fewer super complex problems you need to spend 3 days alone to code. If it was already solved by someone (as 99.9% of problems), AI will probably write most of it for you (with the right prompt).
When you add that to the previous point (engineers being more involved in ‘product’ decisions), it’s clear that there will be a lot of benefits for engineers to work together and to bounce ideas off each other.
One of the practices outlined in “Extreme Programming” is pair programming (writing all production programs with two people sitting at one machine).
Seems like only 15% of developers pair program at least once a week, and I’m not surprised - I’ve felt the discomfort from it too. Still, I believe it is a great practice, and that adoption will slowly increase.
With more and more code being written by prompts - maybe we will have ‘Pair Vibing’ getting more common :)
Final words
That’s quite a lot to take in.
Of course, those changes will take time, and will not happen in a day (or even a year). Still, I really believe the EM profession will look very different.
I spent a lot of time thinking and reading about this topic, but I would REALLY love to hear your take on it!
And of course, would love to see you at my lightening session :)
Further (great!) reading on the topic
These topics should concern EVERY engineering manager. We are in the middle of a new era, so it’s worth taking time to become smarter about it:
The End of Programming as We Know It by Tim O’Reilly.
A Vision For Product Teams by Marty Cagan.
The 70% problem: Hard truths about AI-assisted coding by . Great article on the limits of LLMs.
Beyond the 70%: Maximizing the human 30% of AI-assisted coding by . Part 2, covering the engineering skill that remain critical.
What I enjoyed reading this week
As I overloaded you a bit with deeper articles, today this section will be great non-tech articles :)
Our Souls Need Proof of Work by (the author of “The Making of a Manager”)
You Don't Need To Document Everything - Stop selling your life off so cheaply to strangers
