> In most teams, coding - reading, writing, and debugging code - used to be the part that took engineers the most time, but that is no longer the bottleneck.
Do most engineers find this to be true? For me the balance switched within a few years of being a senior (nearly a decade ago). Writing code is easy, negotiating over what code to write takes time.
I have found it to really depend on the company. Large companies, there is a ton of time spent on architecture reviews, paperwork, design, hitting new library updates, etc. That work is on seniors, then mid levels do a lot of the actual coding (at least in my experience).
But I have worked in some areas that its not like that. What we are building is decided pretty quick, but the implementation takes a month of two.
The constant back and forth between architecture and product and project management roles is the new norm for more senior/staff engineers it feels like. rarly do i get an opportunity to work on code during regular hours.
my days are spent in meetings discussion how to implement things or why do it certain ways - when most of that time spend asking inevitably turns into "when can this be ready?"....well if you didnt have me stuck discussing it for the last 6 months it would've been ready yesterday like you wanted.
Really depends on the company. For me it isn't true, but it used to be when i worked at a bank with terrible management. Nowadays i'm in a tooling team (for Network and security teams), where my "clients" are other devs from the same company. Of course we still have negotiation, but i'd say 60-80% of my time is spend coding, and that's with me being basically a "senior".
And by the way, one thing is missing from the OP graph: i now spend maybe 50% less time writing my own code, and 100% more time fixing my juniors PRs and fixing production issues after my reviews miss issues...
I'm with you and I'm a solo dev right now. Reading, understanding, and trying to decide what is the right code and how that code fits is the most time consuming.
I find that I spend less time reading, writing, and debugging code. That much is true. But it has been replaced with context switch recovery time. Its like having a coworker who nags you every few minutes. I see no apparent increase in output. The bottleneck just moved the goalposts around.
Product and design were always the bottleneck. Engineering speed was never the issue, it was the politics and indecision in product that always slowed engineering teams down. I can't count how many prep meetings product had before they presented to their boss what the new font and color looks like. They basically had a team of PMs just running around creating busy work and making decision based on pure whim and personal feeling, without actually looking at any data. And God forbid they ever talk to customers. Ew, who cares about what they have to say.
Engineering is never the bottleneckā¦ until it is. I have at this very moment months of completed design features that engineering should have already implemented if they were not in a constant churn of refactoring, reorganizing and spiking to fix self-inflicted defects.
> constant churn of refactoring, reorganizing and spiking to fix self-inflicted defects
Sometimes thereās valid reasons for addressing technical debt and reworking things to be better in the futureā¦ and other times people are just rewriting working code because reasonsā¢.
Encountering the latter can be quite demotivating, especially when it turns to nitpicking over small stuff or keeping releases back for no good reason. Personally, I try to lean away from that and more into the āif it works, it worksā camp (as long as you donāt ignore referential integrity and donāt mess up foundational logic).
> I don't buy that engineering is not also a bottleneck.
Depends. It definitely can be. When you get those people who want to spend weeks going back and forth over whether the button should be red or slightly darker red, as if they can somehow figure out the right answer from gut feeling alone, not realizing that in that time they could have tried both and learned from it, all while delivering other things of value on top, engineering has no hope of becoming the bottleneck.
I think it depends on the org, I did Product Design at a FAANG and 90% of the design was held back by engineering "appetite" and even then they would implement at best 60% of the UI to spec. This was building semi-niche professional products, not consumer so that was used as an excuse for not wasting time on polish.
That being said, I've recently made a few light weight apps for myself with Claude and I've easily spent 4x the time hand tuning the UI compared to implementing business logic / core features. Super fun tbh
The prediction that there will be greater demand for specialist frontend and backend engineers is the one that surprises me. How do folks think about it? I've been assuming the opposite - that demand for specialists will decline because expectations around what a single person should be able to do will grow.
I'm a frontend specialist developer currently taking some time off to reskill - and trying to decide exactly which direction to go. My thinking was that I would need to lean into design and product - leverage my technical knowledge in building interfaces to be able to inform the product side. Knowing what is easy or hard to build hopefully would speed up the product side.
The funny thing is how these pizzas were going to 5 full-stack engineers. You would think with this many people there would be a specialist for each layer of the stack, but it's just 5 people who have to be able to do everything.
100% agree with the org shift, but I think of things differently. Specialists are important for architectural insight and domain expertise, but are also the byproduct of codebases growing past a certain size.
It starts with "I know/can handle issues from infra to design" to regroupings of focus, often DevOps / code / design. But companies also might split focus by user concerns, like the "Admin console team" vs. "End user team". That depends on the product and the complexity of the specialist concerns.
I think across the board there is going to be a blurring of management and engineering. We see the value of "product engineers" now but they are starting to eat some of PM's lunch. On the other side, "technical PMs" are more valuable, as they come at things from the other side. The driver for this change is that both are using a shared context to bridge the gap from "business concerns + product requirements" to code.
I see the argument for saying in the future we will be at this place, but this is stated as though it's something that has already happened. It is stated as a simple fact that the time to produce a feature has gone down by orders of magnitude. I have not found this to be true, even if I do give honest tries to the process of coding with AI tools. I'm not a skeptic of AI coding tools, I'm actually one of the persons at my workplace that has best adopted it into their workflows. But this is not realistic.
Yeah, this matches my experience, line by line I can probably write code quicker but producing lines of code has never really been the bottle neck, nor infact the point, in software development.
I read the whole thing somewhat critically, but at the end it became clear that the core issue I had with this post were explained in a caveat at the end: the author assumes that AI capabilities wonāt improve much beyond the current state of the art.
If you replace this assumption with āweāre going to see the same magnitude improvement in the next six months that we saw in the last six monthsā then the post is already outdated. You canāt hire new people fast enough to effectuate this strategy before youāll have to change course.
Instead, Iād propose allowing a bit more anarchy in your teams, letting people know that itās OK to take the initiative, even if it means stepping on each others toes. Management should be clear that critical risks need to be mitigated (eg no security vulns, no prod outages) and be strict about those (to the point where you can say āyolo pushing a prod outage will affect your bonus and be added to your HR recordā), but otherwise let peopleāanyoneācode.
From my team's PoV, I reject the premise. The non-eng people can scale their ambitions and asks even faster than AI has accelerated the engineers' work. In fact, they always have a bunch of stuff that ends up below the line, they always would have wanted to go bigger and faster.
> Okay, so what are product engineers? They are software engineers empowered to handle some responsibilities of PMs and Designers, balancing the roles.
> Product engineers assume traditional PM roles, including owning the roadmap, engaging with users, analyzing data, framing opportunities, and determining what to build. However, they do not replace a PM. The PM still provides context but is no longer the main driver of implementation.
> Nothing worse than being famished and getting one measly slice of pizza.
I am not exactly a big guy but even I can easily eat two slices of pizza and I am talking about real slices of the Costco pizza which I love for its value for money. I can't imagine how you could feed a team of eight with a single pizza.
>The Theory of Constraints states that every system has a bottleneck, since without one, it would operate infinitely fast, which is impossible.
If we believe the AI-influenced system will be faster, more prolific and more experimental (cheaper experiments), then it seems human attention and the rate at which humans can change (individually, processes, tools, teams, etc) becomes the bottleneck.
In that system, the designer and PM functions become more important in addressing that bottleneck - in producing solutions to best overcome those bottlenecks?
Are we assuming the systems the AI is building are systems for humans?
Continuous learning systems aren't there yet, though we have the proto-learning systems with things like agents and skills. What does it look like when we have AI systems building systems for other AI systems?
Is that quote really true? I've always understood "bottleneck" as the slowest part of a system, so a system without a bottleneck simply has all parts being equally fast, it isn't necessarily infinitely fast.
There is still some room for improvement where trying to introduce LLMs into chaotic codebases and whatnot. LLMs continue to struggle there. Although so do humans, to be fair. Chaos is plain hard. However, in a lot of cases AI is already as good as it can get. "Won't improve much" is a fair take.
Technology has plenty of room to keep marching forward, but the next substantive improvement here will see it no longer be AI. It will become AGI.
>We will probably see fewer full-stack engineer openings and more roles for back-end and front-end engineers. This doesn't mean they will do only one or the other, but they will be expected to be an expert in one area.
Good. Fullstack roles are like giving away free options contracts away to businesses when they were only buying some stock. Sure, you don't work twice as much as fullstack and shouldn't get twice the pay, but the flexibility should have a price.
When fullstack engineers are making just as much as front-end/backend only engineers, they are giving the options away for free. Engineers simply didn't stand up for themselves to assert their worth in these positions, which led companies to prioritize hiring them over specialists. Any decrease in fullstack positions will help our compensation.
> In most teams, coding - reading, writing, and debugging code - used to be the part that took engineers the most time, but that is no longer the bottleneck.
This is just a blatant lie lmao, this is the core tenant that all these AI takes rely on and it is just flat out not true.
Another term for "100% AI run companies" is autonomous capital, which activates related concepts like capital self-ownership (this is where it really gets interesting).
When he starts vibe coding his rocket control software, I might find what he says credible. It's easy to say words, but quite another thing to bet your expensive rockets on it.
> In most teams, coding - reading, writing, and debugging code - used to be the part that took engineers the most time, but that is no longer the bottleneck.
Do most engineers find this to be true? For me the balance switched within a few years of being a senior (nearly a decade ago). Writing code is easy, negotiating over what code to write takes time.
I have found it to really depend on the company. Large companies, there is a ton of time spent on architecture reviews, paperwork, design, hitting new library updates, etc. That work is on seniors, then mid levels do a lot of the actual coding (at least in my experience).
But I have worked in some areas that its not like that. What we are building is decided pretty quick, but the implementation takes a month of two.
The constant back and forth between architecture and product and project management roles is the new norm for more senior/staff engineers it feels like. rarly do i get an opportunity to work on code during regular hours.
my days are spent in meetings discussion how to implement things or why do it certain ways - when most of that time spend asking inevitably turns into "when can this be ready?"....well if you didnt have me stuck discussing it for the last 6 months it would've been ready yesterday like you wanted.
Even when I was a junior (<2y experience) on a one pizza team of mostly juniors..no, coding was not the bottleneck. And definitely not the hard part.
Really depends on the company. For me it isn't true, but it used to be when i worked at a bank with terrible management. Nowadays i'm in a tooling team (for Network and security teams), where my "clients" are other devs from the same company. Of course we still have negotiation, but i'd say 60-80% of my time is spend coding, and that's with me being basically a "senior".
And by the way, one thing is missing from the OP graph: i now spend maybe 50% less time writing my own code, and 100% more time fixing my juniors PRs and fixing production issues after my reviews miss issues...
I'm with you and I'm a solo dev right now. Reading, understanding, and trying to decide what is the right code and how that code fits is the most time consuming.
No, most studies find that engineers spend only about 20-30% of their time coding.
Seems to me like this depends more on the existing codebase, framework suitability etc. than position in the hierarchy.
I find that I spend less time reading, writing, and debugging code. That much is true. But it has been replaced with context switch recovery time. Its like having a coworker who nags you every few minutes. I see no apparent increase in output. The bottleneck just moved the goalposts around.
> Product and design are the new bottleneck
Product and design were always the bottleneck. Engineering speed was never the issue, it was the politics and indecision in product that always slowed engineering teams down. I can't count how many prep meetings product had before they presented to their boss what the new font and color looks like. They basically had a team of PMs just running around creating busy work and making decision based on pure whim and personal feeling, without actually looking at any data. And God forbid they ever talk to customers. Ew, who cares about what they have to say.
I buy that product and design are bottlenecks. I don't buy that engineering is not also a bottleneck.
Engineers like to claim everyone else is their problem, when in fact, it's often the case that engineers are their own problem.
Engineering is never the bottleneckā¦ until it is. I have at this very moment months of completed design features that engineering should have already implemented if they were not in a constant churn of refactoring, reorganizing and spiking to fix self-inflicted defects.
Bottlenecks happen everywhere.
> constant churn of refactoring, reorganizing and spiking to fix self-inflicted defects
Sometimes thereās valid reasons for addressing technical debt and reworking things to be better in the futureā¦ and other times people are just rewriting working code because reasonsā¢.
Encountering the latter can be quite demotivating, especially when it turns to nitpicking over small stuff or keeping releases back for no good reason. Personally, I try to lean away from that and more into the āif it works, it worksā camp (as long as you donāt ignore referential integrity and donāt mess up foundational logic).
If only they were as good at their job as you are.
> I don't buy that engineering is not also a bottleneck.
Depends. It definitely can be. When you get those people who want to spend weeks going back and forth over whether the button should be red or slightly darker red, as if they can somehow figure out the right answer from gut feeling alone, not realizing that in that time they could have tried both and learned from it, all while delivering other things of value on top, engineering has no hope of becoming the bottleneck.
I think it depends on the org, I did Product Design at a FAANG and 90% of the design was held back by engineering "appetite" and even then they would implement at best 60% of the UI to spec. This was building semi-niche professional products, not consumer so that was used as an excuse for not wasting time on polish.
That being said, I've recently made a few light weight apps for myself with Claude and I've easily spent 4x the time hand tuning the UI compared to implementing business logic / core features. Super fun tbh
> The ideal team size now appears to be 2-3 engineers per project
That's pretty much always been true for greenfield that doesn't require large swaths of boilerplate (e.g. integrations)
boilerplate and integrations are now mostly done through AI
Citation needed.
merge.dev, nango, composio.dev, all commodity alternatives to managing integrations, with varying degrees of handholding
The prediction that there will be greater demand for specialist frontend and backend engineers is the one that surprises me. How do folks think about it? I've been assuming the opposite - that demand for specialists will decline because expectations around what a single person should be able to do will grow.
I'm a frontend specialist developer currently taking some time off to reskill - and trying to decide exactly which direction to go. My thinking was that I would need to lean into design and product - leverage my technical knowledge in building interfaces to be able to inform the product side. Knowing what is easy or hard to build hopefully would speed up the product side.
Who divides a pizza into 4 slices? A regular pizza is 8 slices, 6 if its actually a smaller pizza. 4 slices is mental.
Each person eats two slices though
how big are these pizzas, i almost always eat 4 [if i'm warming up a frozen one i'd have all of it tbh]
Stop eating two slices please
Fine, I'll have three
I donāt wanna live in a world where I only get to eat one slice of pizza
I usually solo a medium so yeah.
Who pre-slices a pizza - just order it and slice it yourself at the table!
I'd never share my pizza. A one pizza team, that's just me.
The funny thing is how these pizzas were going to 5 full-stack engineers. You would think with this many people there would be a specialist for each layer of the stack, but it's just 5 people who have to be able to do everything.
100% agree with the org shift, but I think of things differently. Specialists are important for architectural insight and domain expertise, but are also the byproduct of codebases growing past a certain size.
It starts with "I know/can handle issues from infra to design" to regroupings of focus, often DevOps / code / design. But companies also might split focus by user concerns, like the "Admin console team" vs. "End user team". That depends on the product and the complexity of the specialist concerns.
I think across the board there is going to be a blurring of management and engineering. We see the value of "product engineers" now but they are starting to eat some of PM's lunch. On the other side, "technical PMs" are more valuable, as they come at things from the other side. The driver for this change is that both are using a shared context to bridge the gap from "business concerns + product requirements" to code.
I think a corollary to this is that any pizza is a personal pizza if you believe hard enough.
Serve one pizza every hour, or something.
One 16" pizza can be a lunch for 2, maybe 3 people. Which, by the way, is a very good size for a team.
If I'm working late and the "compensation" is free pizza, then I better be getting a whole pizza to myself.
Whole pizza or not, what does receiving compensation for working late feel like?
Much better than receiving none.
I see the argument for saying in the future we will be at this place, but this is stated as though it's something that has already happened. It is stated as a simple fact that the time to produce a feature has gone down by orders of magnitude. I have not found this to be true, even if I do give honest tries to the process of coding with AI tools. I'm not a skeptic of AI coding tools, I'm actually one of the persons at my workplace that has best adopted it into their workflows. But this is not realistic.
Yeah, this matches my experience, line by line I can probably write code quicker but producing lines of code has never really been the bottle neck, nor infact the point, in software development.
Old idea: 1-2 pizza teams (Bezos, 2002)
New idea: 1-2 pizza companies
I read the whole thing somewhat critically, but at the end it became clear that the core issue I had with this post were explained in a caveat at the end: the author assumes that AI capabilities wonāt improve much beyond the current state of the art.
If you replace this assumption with āweāre going to see the same magnitude improvement in the next six months that we saw in the last six monthsā then the post is already outdated. You canāt hire new people fast enough to effectuate this strategy before youāll have to change course.
Instead, Iād propose allowing a bit more anarchy in your teams, letting people know that itās OK to take the initiative, even if it means stepping on each others toes. Management should be clear that critical risks need to be mitigated (eg no security vulns, no prod outages) and be strict about those (to the point where you can say āyolo pushing a prod outage will affect your bonus and be added to your HR recordā), but otherwise let peopleāanyoneācode.
From my team's PoV, I reject the premise. The non-eng people can scale their ambitions and asks even faster than AI has accelerated the engineers' work. In fact, they always have a bunch of stuff that ends up below the line, they always would have wanted to go bigger and faster.
> Okay, so what are product engineers? They are software engineers empowered to handle some responsibilities of PMs and Designers, balancing the roles.
> Product engineers assume traditional PM roles, including owning the roadmap, engaging with users, analyzing data, framing opportunities, and determining what to build. However, they do not replace a PM. The PM still provides context but is no longer the main driver of implementation.
How is this different from a "lead"?
Nothing worse than being famished and getting one measly slice of pizza.
> Nothing worse than being famished and getting one measly slice of pizza.
I am not exactly a big guy but even I can easily eat two slices of pizza and I am talking about real slices of the Costco pizza which I love for its value for money. I can't imagine how you could feed a team of eight with a single pizza.
Times are hard. Put up with less pizza or you're off the team.
One slice of vegetarian pizza.
>The Theory of Constraints states that every system has a bottleneck, since without one, it would operate infinitely fast, which is impossible.
If we believe the AI-influenced system will be faster, more prolific and more experimental (cheaper experiments), then it seems human attention and the rate at which humans can change (individually, processes, tools, teams, etc) becomes the bottleneck.
In that system, the designer and PM functions become more important in addressing that bottleneck - in producing solutions to best overcome those bottlenecks?
Are we assuming the systems the AI is building are systems for humans?
Continuous learning systems aren't there yet, though we have the proto-learning systems with things like agents and skills. What does it look like when we have AI systems building systems for other AI systems?
good point although built for humans > built for AIs is likely true for a while
Is that quote really true? I've always understood "bottleneck" as the slowest part of a system, so a system without a bottleneck simply has all parts being equally fast, it isn't necessarily infinitely fast.
the quoted text above is from the OP's article - your point is interesting though
I know one team, consists of me only :)
I'd be a lot more hesitant now if brin, gates or bezos invited me to a pizza party.
āMy post assumes that AI won't improve much beyond its current state, which seems like a safe prediction.ā
Say what?
There is still some room for improvement where trying to introduce LLMs into chaotic codebases and whatnot. LLMs continue to struggle there. Although so do humans, to be fair. Chaos is plain hard. However, in a lot of cases AI is already as good as it can get. "Won't improve much" is a fair take.
Technology has plenty of room to keep marching forward, but the next substantive improvement here will see it no longer be AI. It will become AGI.
>We will probably see fewer full-stack engineer openings and more roles for back-end and front-end engineers. This doesn't mean they will do only one or the other, but they will be expected to be an expert in one area.
Good. Fullstack roles are like giving away free options contracts away to businesses when they were only buying some stock. Sure, you don't work twice as much as fullstack and shouldn't get twice the pay, but the flexibility should have a price.
When fullstack engineers are making just as much as front-end/backend only engineers, they are giving the options away for free. Engineers simply didn't stand up for themselves to assert their worth in these positions, which led companies to prioritize hiring them over specialists. Any decrease in fullstack positions will help our compensation.
"Product and design are the new bottlenecks"
Yup, so far the LLMs just haven't been as great at product and design as us. But they'll get there.
i'm betting on the "personal pan pizza team" -> won't be long until we have a 1-person $1B company
I can eat half a pizza pretty easily.
So one person? Or am I just fat?
> In most teams, coding - reading, writing, and debugging code - used to be the part that took engineers the most time, but that is no longer the bottleneck.
This is just a blatant lie lmao, this is the core tenant that all these AI takes rely on and it is just flat out not true.
even this is an intermediary stage
as elon musk said, the next phase is 100% AI run companies, any sort of a human in a loop, even if in a minimal role, will collapse the productivity
Another term for "100% AI run companies" is autonomous capital, which activates related concepts like capital self-ownership (this is where it really gets interesting).
When he starts vibe coding his rocket control software, I might find what he says credible. It's easy to say words, but quite another thing to bet your expensive rockets on it.