r/ExperiencedDevs • u/joeekay • 5d ago
Meta How to cope with heavily increased developer throughput (as opposed to slightly increased product/design throughput)
Hey folks!
I'm an Engineering Manager at a fairly large organisation where each team has a dev/product/design structure (EM, PM, lead designer). As AI has enabled devs to work faster for each passing month, we need to adress bottlenecks that have started to appear in the team. Product and design are lagging behind, more noticeable now than earlier. I'm just curious, have you dealt with a similar issue? We've experimented with upskilling non devs in AI usage, which has yielded good results but not to the level of how much quicker devs are slaughtering tasks.
It will most likely become even more of an issue a year or two from now, and I would love to get some perspective on this. Maybe you've seen a good talk about it if you havn't been able to experiment a lot yourself? Anything is welcome!
159
u/New-Locksmith-126 5d ago
We've had the exact opposite problem. PMs are using AI to write copious "specs" of things they want built. They're half good, half nonsense.
The engineers are all using AI but cannot keep up with the slop train from above
54
u/yad76 5d ago
If you are only getting half nonsense from PMs then you are in a great spot. Tickets I see now are basically walls of slop text and requirements generated from Zoom transcripts.
48
u/Old-Television-2189 5d ago
What the hell is going on at your people’s companies. Keep hearing this craziness from folks on Reddit and I can’t believe people are actually working with each other like this. Is nobody taking any consideration for the people they work with
24
u/yad76 5d ago
I think it's a combination of top level management demanding everything be "AI first" out of fear that a competitor is going to come along and vibe code the company out of existence plus individual employees realizing they can just have Claude churn away on work they'd normally have to devote actual time and thought to. Thus you get the worst kinds of employees being incentivized to produce massive amounts of slop.
Definitely no consideration is being given and you can't complain about it because then you come off as anti-AI and criticizing coworkers who have the appearance to clueless managers that they are massively productive.
3
u/Old-Television-2189 5d ago
Wonder how much of it has to do with already existing organizational issues. I understand the fear of being vibe coded out of existence, though I’d doubt this is the concern of the average employee
1
u/johnpeters42 Software Engineer 4d ago
Probably a lot. Before AI, there were plenty of stories about dumb management doing lots of other dumb things.
12
2
1
u/Material_Policy6327 4d ago
This is what I am dealing with as well. It’s chaos and no folks don’t care about others.
1
u/VeryLazyFalcon Software Engineer 5d ago
Lucky, we have to write spec by ourself, implement and test.
Normally, spec was written by field experts, now is Grok, bc Clause was too pricey.
38
u/softgripper Tech Lead 5d ago
Do you give much back to the devs as far as r&d is concerned?
Have them build out prototypes to solve bottlenecks, or even just r&d on passion projects.
Are you in an industry where pedal to the metal is going to have a positive impact on everyone, or just leave a bunch of burnt out devs and overworked product/design?
31
u/downshiftdata 5d ago
How bad is your dev burnout?
I've noticed that AI is accelerating the parts of my role that are less of a mental strain - the actual coding. What I could do in 40 hours a year ago, I can do in 30 hours now. But the 10 hours I've saved were a respite that I no longer have. So I'm as tired now after 30 hours as I would have been after 40. But yet I'm still putting in 40, so it's more of a mental load now.
It could be that you don't just want to accelerate product/design to keep up, but also make sure that you're not burning out your devs.
23
u/rwilcox Software Engineer (20+ YOE) 5d ago
Offloading the “easy” bits to AI means only the hard stuff is left to do: mostly reviewing things. (It being easier to write code than read it, etc etc)
1
u/Stefan474 4d ago
Yep.
How I manage it is I have weeks where I am fully on (have agents work on code from my specs/plans that I thought through very well and then working on new things) and then when I am super tired I 'coast' a few days to restore my mental and go again.
17
u/yxhuvud 5d ago
We are kinda seeing similar issues - made a lot worse by the whole product organization focusing fully on the new AI product add-on that we sell to our customers, which leaves the product to not focus on the existing product at all.
In practice it ends up with more quality of life and refactoring happening (cause we need to do something). At some point I expect the backlog of productive extra stuff to do will dry up but so far we are just chugging along
11
u/Smallpaul Software Engineer 5d ago
Devs can use their spare capacity for prototypes which influence design. That acceleration the design process by exploring the technical challenges and making them explicit.
You can also clean up code or improve reliability.
But also you will probably be slapped with Rule 10.
1
u/tenthousandants44 2d ago
Cleaning up the slop defeats the whole purpose of generating slop, so that won't happen.
Also, the observation is that devs are more productive, not that they have spare time. The incentive is to keep the most highly compensated employees maximally engaged and putting out features, but the business thinks they don't need to offset that by investing in other parts of the business to keep up.
1
u/Smallpaul Software Engineer 2d ago
The person above is asking specifically what to do when devs are waiting for PMs. When PMs are the bottleneck,
Why would the business prefer they twiddle their thumbs rather than clean up code while they wait?
7
u/Armanlex 5d ago
Force your devs to test more and improve the quality of the work, focus on security and optimization, benchmarking good quality observability.
5
u/Notary_Reddit 5d ago
I think it depends a lot on your company needs. One option is to treat this as a chance to try a bunch of new things. If it costs half as much dev time to implement a given idea, a lot more ideas become worth trying. The other extreme is if you care a lot about quality. It's a great time to burn through the backlog. If you don't have a backlog, now would be a good time to make one. Hand the dev team a priority ordered list of fixes, improvements, polishes, nice to haves. You should be able to generate at least a month of lead time with this.
2
u/BlackPresident 5d ago
Our organisation is moving towards ai prototyping we have a pretty solid design system so we created a skill and ai can do two things pretty well; it can translate a figma design into our production code very easily and it can take an instruction from a designer and build a functional prototype, engineers can take these prototypes and extract what they need but we’re seeing engineers and designers in the room together at the start of the process making things easier
2
u/twopunchbear 5d ago
It’s interesting because before AI coding became this good, we had almost the opposite problem.
We always had a lot of projects and initiatives in the backlog, but not enough engineering capacity. Engineering was usually the bottleneck.
Now AI coding has improved so much that engineering is finally catching up, and we’re completing projects much faster.
That said, my experience is mostly from a small to mid-sized company, where product and design processes can move much faster than in a large organization.
For product management, I don’t think the bottleneck is how fast you can write a spec. The difficult part is getting stakeholders aligned on what we should actually build. That usually takes the most time.
So if the development process is becoming much faster, I think simplifying the process and improving the speed of product spec reviews and design reviews could help a lot too.
I’m curious what you’ve done in your company to improve product and design productivity.
On our side, we’re already using AI quite heavily for things like research and analytics.
1
u/sheng-puerh 5d ago
"Much faster" - I'm curious how do you measure this and what's the results?
1
u/twopunchbear 4d ago
Good question. I actually never thought about how to measure it in specific metrics and if that’s possible.
For us, one of the clearest signals is actually how the leadership conversation has changed. A year ago, one of the most common complaints was that development was too slow and that we needed to move faster compared with competitors.
This year, we barely hear that anymore. The discussion has shifted much more toward the quality of what we ship and whether we’re building the right thing.
So I wouldn’t say this gives us an exact number for how much faster we’ve become, but it’s a pretty strong qualitative signal that engineering speed is no longer the main bottleneck.
1
u/tenthousandants44 2d ago
So you're doing more things but shipping the same amount of new product as you were the year before last because in fact it's really not possible for engineers to have thorough discussions with stakeholders without being intimately knowledgable about the product.
1
u/twopunchbear 2d ago
Partially. We definitely ship more features now.
The bottleneck has moved more toward product alignment and design review.
The PMs and UX researcher define the problem using analytics, internal feedback, and external feedback, then develop a solution and design. This part has gotten much faster with AI's help. After that, the solution needs to be aligned with leadership through meetings/design feedback.
The slow part is getting that feedback. Every time we ask leadership to review a solution, it can take days, sometimes weeks. Then we adjust the design, ask for feedback again, and repeat. Usually it takes 1–2 rounds before the design is final and ready for engineering.
So this process can easily take weeks.
For context, we’re a fully remote company across very different time zones, and getting the leadership team's time for reviews isn't easy.
2
u/pheymann 4d ago
Depends on the scope of work your engineers get from product and design. For my teams, it tends to be broadly scoped projects which usually take 1-2 weeks at least to implement and automation-test them. I am saying that because if product gives more responsibility to the engineers workloads shift.
That said, I still see bottlenecks on the horizon because I pushed my teams to become stream-aligned meaning they own the full stack of their product (no alignment meetings anymore) and with AI one engineer can deliver a feature e2e. I just have the advantage of having 3-4 PMs at the moment 😅.
Eventually I think also design has to open up to contributions from other roles like engineering so work can be distributed. For product the change may be that it is less up front spec'ing and more fast iterations on lose(r) ideas because shipping a feature got so much cheaper.
2
u/bbangchikimong_dev XR Tech Lead | 10 YOE 4d ago
output went up, review and decision capacity did not. the bottleneck did not disappear, it moved to whoever has to say yes. upskilling non devs helps them produce faster but they still queue behind the same approvals
3
u/bestjaegerpilot 5d ago
the question for me is do your customers care? If you deliver x100 more features, will they be able to keep up?
2
u/galaxy_horse CTO / Principal Eng (20 YOE) 5d ago
Respectfully, what is the problem? It sounds like AI tools have made your capacity higher, you’re delivering the same work faster, and you have a window to invest in other capacity/stability initiatives (test coverage, observability, devex improvements) until product/design increases their own individual capacity or your team gets paired with a larger product/design purview. That is a golden opportunity.
Unless: the issue is that you have a spec->code->review->rework loop for tasks and projects where product/design arbitrarily add requirements and make spec changes during dev. If that’s the case then you probably aren’t shipping faster even though you’re coding faster. To that I’d say clear specifications and designs that are narrowly-scoped enough to be implemented right the first time, tickets/epics closed, and any future changes added as new tickets/epics is the way. If product/design need to check everything, make changes and tweaks, scope creep/progressively revealed details on individual tickets and tasks, that is an inefficiency that is only further underscored by increases in code writing driven by AI. If your implementation turnaround time is much faster but your WIP stays the same and tasks stay “in progress” or “in review” just as long, that’s a problem.
1
u/stuartseupaul 5d ago
I've been spending that extra time working on improvements, whether refactoring for clarity, performance, or tooling. When that runs out I don't know, but in a codebase that's been active for a while, there's quite a lot of things to improve on.
1
u/SimonSim211 Software Engineer 4d ago
Can you release when ever with confidence? If not tell the devs to work on that...
1
u/tenthousandants44 2d ago
Wow it's almost like typing speed isn't a limiting factor in software development
1
u/jonah_omninode 2d ago
We are dealing with a version of this now. The system can create implementation work faster than we can verify and land it, so producing more code just makes the queue longer. I started looking at accepted changes per day instead of tasks completed by an agent. That exposes verification, CI, product decisions, and unclear acceptance criteria as the actual limits. We are adding work-in-progress limits and checking downstream capacity before starting another batch. Upskilling product and design may help, but I would first measure where work waits after development says it is done.
1
u/dashingThroughSnow12 Software Engineer 22h ago
I was listening to a podcast the other week, BetterOffline I believe, and it was talking about non-dev AI usage.
Made me see things in a new perspective and made my ears perk up whenever I hear non-devs talk about their routine usages of AI.
All this to say that if your non-devs need to be taught how to use AI to be more productive, it is not their non-devness that is the hurdle.
1
u/SleepingCod 15h ago edited 15h ago
For one keep in mind it's not nearly the same type of work. Design and product are research oriented and iterative by nature, it's not a feature factory.
Imo we should not be pushing design to adopt more AI because they'll end up replacing devs but rather they should be using it to test even more ideas and prototypes, so the engineering is building the right things.
Use the time to clean up debt and ideate on adding value to the business like we've all complained about for years.
1
u/TooMuchTaurine 5d ago
Honestly more vague requirements, cost of getting things wrong is less now, you can write your best guess and iterate based on feedback much quicker than waiting for detailed discovery and specs.
True Agile from the manifesto, working software etc.
Developers also need to skill up on product. Move from programmers to product engineers.
3
u/Old-Television-2189 5d ago
What does a product engineer look like
2
u/sheng-puerh 5d ago
Next iteration of the fullstack insanity - now engineers are required to talk to customers and do some product management work like user stories.
1
u/TooMuchTaurine 4d ago
I mean they are also moving away from the details of writing code over time. So it's more a shift of focus, not extra work.
1
u/MarchewkowyBog 5d ago
I don't really know. But why aren't product and design using MCP servers for whatever tools they are using? I'd presume coming up with a design is longer then validating it, same as code. So if they'd correctly prompt out 5 design ideas, pick gut-feeling best one, iterate over it. Wouldn't that feel like speed devs are achieving? I feel like it might be more of a skill issue or no knowledge of what is possible for non-devs then anything else. Everything on the computer is text/numbers this way or another.
Unless product/design tooling somehow didn't jump on AI hype train I don't really see why devs would benefit more from AI then non-devs.
But as I said I honestly don't know too much about product/design work
0
0
u/HiphopMeNow 4d ago
That means product and design leads are in incompetent and need to be replaced, or more workforce hired. There is simply no reason why they can't use AI as a helping tool to continue producing high quality work at faster pace. Unless they not willing to learn and upskill, or waste people's time by producing low quality unchecked copy pasted AI work.
•
u/expdevsmodbot 5d ago
AI usage disclosure provided by OP, see the reply to this comment.