5 ms·

Here's my current thinking on the impact of GPT-4 on the developer job market: - I expect developer productivity to go up 1.5x - 15x over the next several year

Here's my current thinking on the impact of GPT-4 on the developer job market: - I expect developer productivity to go up 1.5x - 15x over the next several years assuming GTP-4 based tooling is integrated into IDEs. - There will be two opposing forces acting on developer wages. First, developers will be more productive, therefore the price of one hour of work should go up. But - the supply of developer output will increase as well, which would push price per "line of code" or per "unit of developer output" down. So the big unknown is the demand curve. - There will be a temporary boost in demand for developer work connected with the transition to this new technology. Big corporations will want to upgrade their systems to automate consumer support, startups will make new tools for AI-generated graphics, etc. - We can also study the effects of technology-driven increases in worker productivity by looking into history. Developer productivity has always been going up - thanks to stackoverflow.com, better languages, better IDEs, more and better libraries, etc. There's also a greater supply of developers (e.g. India). Didn't change the job market too much. One should not draw strong conclusions from this though, it's a very superficial analysis. On the other hand, people working in agriculture have become much more effective, which lead to much fewer people working in agriculture, maybe because people need to eat as much calories per day as they did 100 years ago. - My base case, based on the assumption that GPT-4 will not improve dramatically, is that developer wages will stay roughly constant. But there's a lot of uncertainty in this conclusion and in the assumption.

austin-cheney 4y ago
I completely disagree because of how this batch of AI learns. It learns by studying what is currently available as opposed to supplying something new. Bad developers on the way of becoming obsolete by AI will see drastic improvements from the thing that’s about to replace them. Otherwise it’s slightly better intellisence integrated in your editor. The difference is that bad developers are primarily concerned with literacy and their primary intent is chasing easy. Better developers are comfortable reading code no differently than an attorney reading a large contact and their primary intent is chasing better automation. It’s the difference between designing a car engine versus hammering pieces together. I suspect this will open wage distinctions. Those who can write software will be identified from those who can’t. Those who can will be fewer in number and their wages will increase. Those who can’t will be a lower skilled commodity with depreciated wages, like the way data entry was once a skilled profession many decades ago but no longer.
- eggsmediumrare 4y ago
  I think a lot of "good" developers making this very argument will be in for a nasty surprise when they find out which bucket they're actually in
  - austin-cheney 4y ago
    I don’t doubt that at all. “Good” is relative to something but what that thing is often makes for a poor quality of measure with few samples compared. The are objective ways to measure competence in software but nobody wants to use them. Most people don’t want to discover just how good they aren’t.
habibur 4y ago
> - I expect developer productivity to go up 1.5x - 15x over the next several years assuming GTP-4 based tooling is integrated into IDEs. Hardly. 10% of the time spent is in writing code and the other 90% goes behind debugging and fixing things. Even if AI shrinks the time spent in that 10% in writing by another 90%, you still have have to take full time for maintaining that code. Changing, debugging, testing, deploying, profiling, log analysis. Worse, its now someone else's code you need to understand and debug, and not the one written by yourself.
- deleted 4y ago
  [deleted]
- RivieraKid 4y ago
  It's not just writing code, GPT and GPT-based tools can help with fixing bugs, solving configuration problems, understanding existing code, suggesting variable names, etc.
- kristofferR 4y ago
  ChatGPT is better at that 90% than the 10%.
mdorazio 4y ago
I think you have two common misconceptions here. 1) Wages have very little to do with value/productivity in a free market. They are almost entirely determined by supply and demand. Value simply places a ceiling on compensation. Thus, if far more people can perform a "programming" job because of GPT-X, unless the demand for those jobs rises significantly the net result will be wage reduction. 2) There's this weird thinking on HN that since a developer's job involves [insert your % estimate of time spent actually coding/bug fixing] and the rest is figuring out requirements, dealing with weird requests, planning, etc. that means developers can't be replaced. However, I don't see a whole lot of discussion around what the difference is between a developer and a competent business analyst in a GPT-X world. The latter can be had for significantly less money, requires less training, and if the actual programming part is largely automated away or concentrated in the hands of fewer "real" developers, those roles start to look awfully similar.
- amelius 4y ago
  It's not that more people can do programming with GPT-X around, because the AI will only solve the problems that have already been solved thousands of time in the past in slightly different ways. What GPT-X cannot do is left to real CS people. So instead of coding CRUD systems, we can do real algorithms research again, except fewer people are capable of it.
- CuriouslyC 4y ago
  The developer can prompt for a solution with specific storage/performance requirements by specifying an algorithm, and specific scalability requirements using by specifying an architecture. Imagine a business analyst prompting for an app, and getting a ruby on rails monolith with O(N^2) performance for the core behavior for a service that is expected to have millions of requests daily.
  - _fat_santa 4y ago
    > Imagine a business analyst prompting for an app, and getting a ruby on rails monolith with O(N^2) performance for the core behavior for a service that is expected to have millions of requests daily. I see this as the main argument against "we will just have tools that allow managers and ba's to do what devs do now". I think folks often forget that there are two sets of requirements for every app: business requirements and technical requirements. Non technical folks might understand the business requirements very well and may even be able to write code that satisfies those requirements, but the real value in a dev is squaring those business requirements with technical ones. A BA might look at a DynamoDB table and say "yeah lets just run a scan for the items we need", whereas a dev will look at the same problem and say "yeah we can do that but it will cause issue A, issue B and sometimes issue C". And the dev knowing those gotchas is why you have them there in the first place, a dedicated person that knows all these gotchas and makes sure you organization avoids a footgun in prod.
coffeebeqn 4y ago
> up 1.5x - 15x over I wish! I still often find out my team members don’t know basic text/Unix tools. Heck one guy took our list of enums in a JSON file and wrote on his keyboard by hand each of them into a class. It took me maybe a minute in Sublime Text when he wasted at least a day
cableshaft 4y ago
> On the other hand, people working in agriculture have become much more effective, which lead to much fewer people working in agriculture, maybe because people need to eat as much calories per day as they did 100 years ago. Except population exploded also, and the only reason we could support such a population has been thanks to advances in agriculture (it could be argued that's not a good thing, as the larger population is helping fuck our planet up in other ways, but that's for a different thread). So there has been an increased demand for food. However, there's only so much arable land on this planet. The planet is finite in size. So when basically the entire planet is already being farmed, you can't really add more farmers, so further efficiency is just leading to less farmers. Software is not so finite. It technically is, as we only have so many servers or whatever, but we're nowhere near the upper limits of what all we can handle or the appetite for software that companies have (which seems about infinite). Additionally, we have a habit of rebuilding and replacing software every few years, so even if we reach capacity limits, there's still demand for new software to replace the old, or working on new features for existing software. So it's a bit different of a situation and not really comparable.
- arwhatever 4y ago
  Also, much like that law of bureaucracy stating how work expands to fill the time available, every employer I’ve worked for has been able to envision and request vastly more software functionality than any dev team has been able to produce, which might not extrapolate forever, but has sustained the field so far. On the other hand, people are much more finite in the amount of food that they require
roflyear 4y ago
Supply generally doesn't decrease cost fyi
danaris 4y ago
> assuming GTP-4 based tooling is integrated into IDEs. And how, exactly, is this going to work? Is every IDE going to pay some license fee to OpenAI? Will that be up to the companies or—even worse—individuals who use the IDEs? What happens when OpenAI decides that GPT-4 is passé and it's time to move on to something else? Will the existing IDEs that are designed to interact with GPT-4 stop working? Will GPT-5 or whatever provide the same kinds of assistance, or will there be regressions? Will they require a completely different license for it? See, these are some of the important questions that come with assuming that a fairly new for-profit company will act as the backbone for your marvelous programming renaissance—particularly when the service in question is one that takes quite a lot of resources to continue to operate. Personally, I would be interested in some kind of LLM-assisted IDE, but no way in hell am I going to make any significant portion of my job dependent on an organization that decided, as soon as it was clear there was real interest in what they were doing, that they'd just toss the "Open" part of their name and principles out the window and just go for closed-source proprietary product and maximum hype for more profit.

austin-cheney 4y ago

I completely disagree because of how this batch of AI learns. It learns by studying what is currently available as opposed to supplying something new. Bad developers on the way of becoming obsolete by AI will see drastic improvements from the thing that’s about to replace them. Otherwise it’s slightly better intellisence integrated in your editor. The difference is that bad developers are primarily concerned with literacy and their primary intent is chasing easy. Better developers are comfortable reading code no differently than an attorney reading a large contact and their primary intent is chasing better automation. It’s the difference between designing a car engine versus hammering pieces together. I suspect this will open wage distinctions. Those who can write software will be identified from those who can’t. Those who can will be fewer in number and their wages will increase. Those who can’t will be a lower skilled commodity with depreciated wages, like the way data entry was once a skilled profession many decades ago but no longer.

eggsmediumrare 4y ago
I think a lot of "good" developers making this very argument will be in for a nasty surprise when they find out which bucket they're actually in
- austin-cheney 4y ago
  I don’t doubt that at all. “Good” is relative to something but what that thing is often makes for a poor quality of measure with few samples compared. The are objective ways to measure competence in software but nobody wants to use them. Most people don’t want to discover just how good they aren’t.

habibur 4y ago

> - I expect developer productivity to go up 1.5x - 15x over the next several years assuming GTP-4 based tooling is integrated into IDEs. Hardly. 10% of the time spent is in writing code and the other 90% goes behind debugging and fixing things. Even if AI shrinks the time spent in that 10% in writing by another 90%, you still have have to take full time for maintaining that code. Changing, debugging, testing, deploying, profiling, log analysis. Worse, its now someone else's code you need to understand and debug, and not the one written by yourself.

deleted 4y ago
[deleted]
RivieraKid 4y ago
It's not just writing code, GPT and GPT-based tools can help with fixing bugs, solving configuration problems, understanding existing code, suggesting variable names, etc.
kristofferR 4y ago
ChatGPT is better at that 90% than the 10%.

mdorazio 4y ago

I think you have two common misconceptions here. 1) Wages have very little to do with value/productivity in a free market. They are almost entirely determined by supply and demand. Value simply places a ceiling on compensation. Thus, if far more people can perform a "programming" job because of GPT-X, unless the demand for those jobs rises significantly the net result will be wage reduction. 2) There's this weird thinking on HN that since a developer's job involves [insert your % estimate of time spent actually coding/bug fixing] and the rest is figuring out requirements, dealing with weird requests, planning, etc. that means developers can't be replaced. However, I don't see a whole lot of discussion around what the difference is between a developer and a competent business analyst in a GPT-X world. The latter can be had for significantly less money, requires less training, and if the actual programming part is largely automated away or concentrated in the hands of fewer "real" developers, those roles start to look awfully similar.

amelius 4y ago
It's not that more people can do programming with GPT-X around, because the AI will only solve the problems that have already been solved thousands of time in the past in slightly different ways. What GPT-X cannot do is left to real CS people. So instead of coding CRUD systems, we can do real algorithms research again, except fewer people are capable of it.
CuriouslyC 4y ago
The developer can prompt for a solution with specific storage/performance requirements by specifying an algorithm, and specific scalability requirements using by specifying an architecture. Imagine a business analyst prompting for an app, and getting a ruby on rails monolith with O(N^2) performance for the core behavior for a service that is expected to have millions of requests daily.
- _fat_santa 4y ago
  > Imagine a business analyst prompting for an app, and getting a ruby on rails monolith with O(N^2) performance for the core behavior for a service that is expected to have millions of requests daily. I see this as the main argument against "we will just have tools that allow managers and ba's to do what devs do now". I think folks often forget that there are two sets of requirements for every app: business requirements and technical requirements. Non technical folks might understand the business requirements very well and may even be able to write code that satisfies those requirements, but the real value in a dev is squaring those business requirements with technical ones. A BA might look at a DynamoDB table and say "yeah lets just run a scan for the items we need", whereas a dev will look at the same problem and say "yeah we can do that but it will cause issue A, issue B and sometimes issue C". And the dev knowing those gotchas is why you have them there in the first place, a dedicated person that knows all these gotchas and makes sure you organization avoids a footgun in prod.

coffeebeqn 4y ago

> up 1.5x - 15x over I wish! I still often find out my team members don’t know basic text/Unix tools. Heck one guy took our list of enums in a JSON file and wrote on his keyboard by hand each of them into a class. It took me maybe a minute in Sublime Text when he wasted at least a day

cableshaft 4y ago

> On the other hand, people working in agriculture have become much more effective, which lead to much fewer people working in agriculture, maybe because people need to eat as much calories per day as they did 100 years ago. Except population exploded also, and the only reason we could support such a population has been thanks to advances in agriculture (it could be argued that's not a good thing, as the larger population is helping fuck our planet up in other ways, but that's for a different thread). So there has been an increased demand for food. However, there's only so much arable land on this planet. The planet is finite in size. So when basically the entire planet is already being farmed, you can't really add more farmers, so further efficiency is just leading to less farmers. Software is not so finite. It technically is, as we only have so many servers or whatever, but we're nowhere near the upper limits of what all we can handle or the appetite for software that companies have (which seems about infinite). Additionally, we have a habit of rebuilding and replacing software every few years, so even if we reach capacity limits, there's still demand for new software to replace the old, or working on new features for existing software. So it's a bit different of a situation and not really comparable.

arwhatever 4y ago
Also, much like that law of bureaucracy stating how work expands to fill the time available, every employer I’ve worked for has been able to envision and request vastly more software functionality than any dev team has been able to produce, which might not extrapolate forever, but has sustained the field so far. On the other hand, people are much more finite in the amount of food that they require

roflyear 4y ago

Supply generally doesn't decrease cost fyi

danaris 4y ago

> assuming GTP-4 based tooling is integrated into IDEs. And how, exactly, is this going to work? Is every IDE going to pay some license fee to OpenAI? Will that be up to the companies or—even worse—individuals who use the IDEs? What happens when OpenAI decides that GPT-4 is passé and it's time to move on to something else? Will the existing IDEs that are designed to interact with GPT-4 stop working? Will GPT-5 or whatever provide the same kinds of assistance, or will there be regressions? Will they require a completely different license for it? See, these are some of the important questions that come with assuming that a fairly new for-profit company will act as the backbone for your marvelous programming renaissance—particularly when the service in question is one that takes quite a lot of resources to continue to operate. Personally, I would be interested in some kind of LLM-assisted IDE, but no way in hell am I going to make any significant portion of my job dependent on an organization that decided, as soon as it was clear there was real interest in what they were doing, that they'd just toss the "Open" part of their name and principles out the window and just go for closed-source proprietary product and maximum hype for more profit.