Also, calculators did millions of operations, but the were 99.999999% right all the time. That's what set the apart from human people: eternal reliability 24/7. AI is about right 1% of the time, a human is needed to recognise when the machine is wrong, and it keeps repeating the same mistakes when identified and corrected. People WISH it was like a calculator, but you know, magic thinking doesn't make things happen.
In case it wasn't clear, I'm using "OCR" in my comment above for "reading and interpreting textual documents provided as images", not as a reference to a specific tech such as Tesseract.
In the app, I am, in fact, using AI/ML tech and I'm saying it's very accurate for my use case, as a counterpoint to the parent comment which says AI works in 1% cases, maybe.
But since you brought it up, this workflow works better than the supposedly "99.999999% right all the time" traditional code (traditional OCR tools).
One of the best skills for developers is to lookup information using search engines. All the information is out there already you just need an understanding what you are looking for. This is similar to painting the colors are there already but not everyone is a good painter. LLMs empower skilled developers and do the boilerplate work usually done by mediocre developers.
Later on it will depend on who can write the best prompt but that requires understanding.
> In 2025, the engineer probably beats Gemini. Sure, great. But in 2030, who wins this hypothetical?
I don't think we need to wait for 2030. Today, using aider/cursor and Gemini-pro-2.5, I'm pretty sure a team of two or three senior developers with great domain knowledge would be competitive with a team of 10 average devs. Being a small, close-knit team has a lot of advantages. And LLMs can help close the productivity gap.
Spend any amount of time, reading the implementation of powerfull algorithms (A* search, Bubble sort), and you will realize that the power is in the idea, not the feeble attempt at coding it in PHP, Go, JS or what ever.
The 10 average devs can produce hundreds of thousands of lines of buggy, poor performance code that implement thousands of features poorly in the same amount of time the senior developers could implement tens of thousands of lines of great code that implement hundreds of features perfectly.
But what if the three senior devs could produce thousands of lines of great code that implement thousands of features perfectly. I don't think this is the case but I believe this is what the OP means.
the interest is of course because what "the business" wants is thousands of features, perfectly or imperfectly is a secondary consideration.
on edit: changed senior devs hundreds of thousands to thousands because one benefit is that much of the code the average make is not really needed.
>I'm pretty sure a team of two or three senior developers with great domain knowledge would be competitive with a team of 10 average devs.
You are comparing senior vs average devs here.
What will happen if a team of 'two or three senior devs' with AI/ML tools compete with equally skilled 10 senior devs with AI/ML tools?
I wish people would stop making predictions about LLMs so confidently. Some people confidently predict that LLMs will never be able to replace capable engineers, and other people equally confidently predict that we'll all be out of a job in five years.
The reality is that we don't know.
We don't know what the ceiling is for LLM programming ability. We don't know how much better they can get without scaling up the hardware. We don't know how well we'll be able to scale up the hardware. We don't know how many more billions we'll allow companies to spend building better and better models until the market loses confidence in them.
We can make educated guesses, but that's all they are. We just don't know.
We _do know_ that companies are typically driven by greed and profit, so if it is possible for them to replace their human workers with something that does a similar level of work but also does not require a paycheck, we would be absolute fools to assume that they won't do everything in their power to make that a reality, regardless of the understood reliability of LLMs.
Unless its too expensive or just doesn't work well. Although in entrenched fields like healthcare that act with impunity I guess an LLM would make a slightly cheaper firewall between the industry and the customers you "serve".
We also know that incompetent management is widespread, so many companies would replace their humans workers with LLMs even if it is not possible, and we know many investors are also incompetent, so these companies might even be allowed to continue to exist and might even grow really big.
We don't know but we can see that progress has staggered a bit. This also correlates with how we think LLMs work (even their operators don't seem to understand 100%). So my bet would be that we'd rather reach the ceiling.
I echo the parent comment. It's not the fact that predictions are made, it's the fact that no certainty interval is ever given, and everything is pronounced with complete confidence.
Clear and concise thinking, its the first time I have read someone cut through the hype and argue logically for what the next incremental steps are in making progress down this path of LLMs creating technology.
The first steam engines were too expensive and underpowered, the first cars were deatch traps when they actually ran. Dont lul yourself into the dream of a static world.
We see the wave coming, I will look for a way to surf it. Don't be the stunned sceptic waiting to feel the crush.
For one, I have started using the tools that are available right now, to increase my productivity and intuition with what the new capabilities are.
I think the original author is on to something, about how the structure of our codebases will change, and therefore our preferred frameworks will change as well.
The frameworks we use today, assume that the codebase is DRY[1], and that a human will verify the workings of the codebase. A human will write a single test, for a single component and verify that the test functions correctly - then leave it in there, for successive runs to prove there has been no regression to the code quality.
But as the author points out - that doesn't lend itself to truly parallel programming. Because as one programmer/agent changes a central component that another programmer/agent also changed in the same release cycle, merge conflicts arise and grown into architectural conflicts and grow into team conflicts.
I see how accepting more duplication, can lead to more parallelization. I mostly cared about keeping code DRY because its hell to refactor a codebase with 5 implementations of the same thing. But if I am just instructing an LLM to make the change, I dont care how many files it has to visit - its still the same single instruction from me.
So I will think long and hard about how tooling needs to improve, and how frameworks need to change, to be part of this new paradigm. Similar to how Object Oriented Programming optimised for human logic rather than cpu cycles, the time of LLMs will optimise for testability and parallelisation rather than gpu cycles, or DRY paradigmes.
DRY is also about coherence not just refactorability. If you have multiple different behaviors for the "same" thing then your customers are going to think you suck.
Tangential, but an entry level developer at 190k USD per year seems nuts, is that really a reasonable number? From a quick search, I find numbers below 100k USD for the bay area, which seems more reasonable.
In a well off European country, you'd pay around 45k USD for a strong entry level developer. I can imagine 2x salaries, considering costs of living, fire at will and all that, but >4x? Not sure how to back that up.
Also, a few years ago I had teams in multiple countries (South East Asia, India, Easter Europe, Western Europe, East and West Coast), all well paid (but not at FAANG levels). While their capacity was roughly similar, the West Coast ones were by far the more expensive ones, but also quite stressed out to make ends meet (buying a house, having a kid, putting them through school) compared to the other teams.
Eastern Europe was a place to find hidden gems (very cheap - but not so now), and some brilliant people (but not all of them). Western Europe was consistent, solid moderate quality at moderate costs vs US. So in line with your views
>but also quite stressed out to make ends meet (buying a house, having a kid, putting them through school) compared to the other teams.
Because a well paid SW dev wages goes soooo much further in developing countries, you're basically a king as every other profession earns very poor in comparison, so home ownership is no issue.
Well, the author did cite Levels, which is pretty reliable. A quick search shows that >150k seems accurate for a lot of the top tech companies (eg. Google).
I absolutely know people individually who made 150k+ out of college. Sorry europeans, but Bay Area salaries are definitely a large multiple of European salaries, even entry level.
A lot of this is possible because these companies make a lot of money, and a lot of money per employee, and that trickles down to new-hire salaries. It doesn't seem like there are many wildly profitable European companies in tech, at least not ones that can really drive up salaries like this. It's too bad, because Europe broadly has really strong talent, but I imagine there is a constant pressure pulling people away for more money.
Definitely not what they were, especially for more junior developers as I understand it. And I assume total comp is somewhat depressed too if only because of the stock market.
>In a well off European country, you'd pay around 45k USD for a strong entry level developer. I can imagine 2x salaries, considering costs of living, fire at will and all that, but >4x? Not sure how to back that up.
You back that up with the fact that Google makes 500k USD profit per employee, AFTER they pay each of them 200k+ in salaries plus added taxes and other expenses. Valve makes 19 Million USD profit per employee. There are no European tech companies that make even remotely as much profit per employee, so obviously they'll never be able to pay such salaries no matter how much EU workers as for.
It's not like the US tech workers work 4x harder, or 4x faster, or are 4x smarter than the European ones, it's that their companies are 4x more profitable and that reflects in workers' compensation.
Agree US market seems bloated, not only salaries but also positions, you can find "seniors" with 2 years of experience, maybe a side effect from the pandemic boom
I find the outlined scenario well argued and plausible.
What's more interesting to me though is the complete lack of mention of labor unions as a potential defense mechanism for engineers (either in the OP or in the conversation here, at least so far).
For a while now I've felt it's quite arrogant and completely naive of us to not accept that we're just keyboard workers, and not rare special flowers that will forever be economically privileged.
You get something right, something awfully wrong. It's true that machines dont sleep, but less true that every software engineer costs 230000$ an year. Maybe (!) that's true in Silicon Valley. In Italy, it costs 35000E.
And we don't see many software companies in Italy. Why? Because I'm sad to have that explained, code is 10% of development. Whatsapp was sold for 17 billion dollars and it was 55 employees, and it's an IRC chat made mobile. At the time, it didn't have video.
I can keep going on, but this discussion sounds so out-in-space that only USA people could not see. Sorry if you're from somewhere else.
Certainly the sorts of salary numbers thrown around with the likes of Google are not generally true of smaller companies, east coast companies except perhaps for some finance roles, and certainly not for IT/developer roles at non-tech companies. Nor is it true for pretty much any other STEM jobs. Doesn’t seem sustainable. I’m tempted to think that a lot of people learning CS today because it’s so lucrative are going to be disappointed.
USA is the worldwide exception when it comes to SW industry, not the rule.
The US tech industry is reaping the benefits of being the WW2 and cold war victor, the first to the punch in SW development and online capitalization, a homogenous single language market with the top economy in the world and owning the world reserve currency, meaning they can print and throw ungodly sums of money at any app that helps with mass data collection, data which is more valuable to advertisers because the US consumer has the highest purchasing power in the world by a long margin, and subject to less linguistical, financial and legal fragmentation and gov oversight than the EU.
It's a positive reinforcing feedback loop where more money helps creates even more money, like a snowball rolling downhill. It's not something Italy or any EU as a whole can replicate. We can replicate the same SW tech/concepts here, but not the scale and monetary effects that the same tech has in the hands of the US. US is basically playing the game with the infinite money glitch, and the crazy US salaries are a second order effect of that.
The difficult question to answer is not if we will lose our jobs to AI, but when. Are we talking 100 years from now? Are we talking 5 years, 1 year? But yeah, given enough time it is clear to see computers will one day program themselves.
I tried vibe-coding some non-trivial code. It failed successfully.
The resulting code had a memory leak (from good old Promise.race) that would have caused the app to continuously grow the RAM usage.
I decided to let the AI code, and then asked it to fix the problems, describing the issue (steadily growing RAM usage). It was not able to find the issue.
That's what I'm afraid of. We'll get megabytes of code that just fails sometimes, for unfathomable reasons.
I guess that your takes on parallel, compartimentalized, self healing, game-theory based micro AI agents could be spawned and organized code their own way. But... wake me up when it happens, ok? ;)
Also, calculators did millions of operations, but the were 99.999999% right all the time. That's what set the apart from human people: eternal reliability 24/7. AI is about right 1% of the time, a human is needed to recognise when the machine is wrong, and it keeps repeating the same mistakes when identified and corrected. People WISH it was like a calculator, but you know, magic thinking doesn't make things happen.
> AI is about right 1% of the time
I have an app where people scan their retail/restaurant/cafe receipts and store them. I use Gemini 2.0 for OCR.
It is right more than 99% of the time. I would be making many more errors transcribing the receipts manually.
AIs are a different kind of tools, for a different kind of problems, with a different kind of failure cases.
OCRs are quite different from AI/ML, which the parent comment is referring to. In fact, OCR existed way before the current AI wave.
In case it wasn't clear, I'm using "OCR" in my comment above for "reading and interpreting textual documents provided as images", not as a reference to a specific tech such as Tesseract.
In the app, I am, in fact, using AI/ML tech and I'm saying it's very accurate for my use case, as a counterpoint to the parent comment which says AI works in 1% cases, maybe.
But since you brought it up, this workflow works better than the supposedly "99.999999% right all the time" traditional code (traditional OCR tools).
Hope this clears it up.
OCRs are AI/ML in the sense it meant to everyone before 2020.
> AI is about right 1% of the time
just write another prompt
edit to say:
One of the best skills for developers is to lookup information using search engines. All the information is out there already you just need an understanding what you are looking for. This is similar to painting the colors are there already but not everyone is a good painter. LLMs empower skilled developers and do the boilerplate work usually done by mediocre developers. Later on it will depend on who can write the best prompt but that requires understanding.
> In 2025, the engineer probably beats Gemini. Sure, great. But in 2030, who wins this hypothetical?
I don't think we need to wait for 2030. Today, using aider/cursor and Gemini-pro-2.5, I'm pretty sure a team of two or three senior developers with great domain knowledge would be competitive with a team of 10 average devs. Being a small, close-knit team has a lot of advantages. And LLMs can help close the productivity gap.
> I'm pretty sure a team of two or three senior developers with great domain knowledge would be competitive with a team of 10 average devs.
This has always been true. LLMs didn't change that.
Yes!
Spend any amount of time, reading the implementation of powerfull algorithms (A* search, Bubble sort), and you will realize that the power is in the idea, not the feeble attempt at coding it in PHP, Go, JS or what ever.
The 10 average devs can produce hundreds of thousands of lines of buggy, poor performance code that implement thousands of features poorly in the same amount of time the senior developers could implement tens of thousands of lines of great code that implement hundreds of features perfectly.
But what if the three senior devs could produce thousands of lines of great code that implement thousands of features perfectly. I don't think this is the case but I believe this is what the OP means.
the interest is of course because what "the business" wants is thousands of features, perfectly or imperfectly is a secondary consideration.
on edit: changed senior devs hundreds of thousands to thousands because one benefit is that much of the code the average make is not really needed.
Typing shouldn't be what's taking up most of your time if you are a great dev writing great code.
which kind of typing are we talking about here? if it's the kind that my hands do on a keyboard that is obviously not what is meant by writing code.
I think you're building a 100x tech debt with that.
I agree that's a very real risk if you don't architect and test well.
>I'm pretty sure a team of two or three senior developers with great domain knowledge would be competitive with a team of 10 average devs.
You are comparing senior vs average devs here. What will happen if a team of 'two or three senior devs' with AI/ML tools compete with equally skilled 10 senior devs with AI/ML tools?
I wish people would stop making predictions about LLMs so confidently. Some people confidently predict that LLMs will never be able to replace capable engineers, and other people equally confidently predict that we'll all be out of a job in five years.
The reality is that we don't know.
We don't know what the ceiling is for LLM programming ability. We don't know how much better they can get without scaling up the hardware. We don't know how well we'll be able to scale up the hardware. We don't know how many more billions we'll allow companies to spend building better and better models until the market loses confidence in them.
We can make educated guesses, but that's all they are. We just don't know.
Correct.
But...
We _do know_ that companies are typically driven by greed and profit, so if it is possible for them to replace their human workers with something that does a similar level of work but also does not require a paycheck, we would be absolute fools to assume that they won't do everything in their power to make that a reality, regardless of the understood reliability of LLMs.
Unless its too expensive or just doesn't work well. Although in entrenched fields like healthcare that act with impunity I guess an LLM would make a slightly cheaper firewall between the industry and the customers you "serve".
We also know that incompetent management is widespread, so many companies would replace their humans workers with LLMs even if it is not possible, and we know many investors are also incompetent, so these companies might even be allowed to continue to exist and might even grow really big.
s/making predictions/talking their book/
https://news.ycombinator.com/item?id=18146703
We don't know but we can see that progress has staggered a bit. This also correlates with how we think LLMs work (even their operators don't seem to understand 100%). So my bet would be that we'd rather reach the ceiling.
To be fair, if we know something will happen with high certainty then its not much of a prediction.
The fact that no one really knows how LLMS will pan-out means every projection in future is a prediction.
I echo the parent comment. It's not the fact that predictions are made, it's the fact that no certainty interval is ever given, and everything is pronounced with complete confidence.
Clear and concise thinking, its the first time I have read someone cut through the hype and argue logically for what the next incremental steps are in making progress down this path of LLMs creating technology.
The first steam engines were too expensive and underpowered, the first cars were deatch traps when they actually ran. Dont lul yourself into the dream of a static world.
We see the wave coming, I will look for a way to surf it. Don't be the stunned sceptic waiting to feel the crush.
> We see the wave coming, I will look for a way to surf it. Don't be the stunned sceptic waiting to feel the crush
What would you do to surf it? What would you suggest to who's an engineer right now?
For one, I have started using the tools that are available right now, to increase my productivity and intuition with what the new capabilities are.
I think the original author is on to something, about how the structure of our codebases will change, and therefore our preferred frameworks will change as well.
The frameworks we use today, assume that the codebase is DRY[1], and that a human will verify the workings of the codebase. A human will write a single test, for a single component and verify that the test functions correctly - then leave it in there, for successive runs to prove there has been no regression to the code quality.
But as the author points out - that doesn't lend itself to truly parallel programming. Because as one programmer/agent changes a central component that another programmer/agent also changed in the same release cycle, merge conflicts arise and grown into architectural conflicts and grow into team conflicts.
I see how accepting more duplication, can lead to more parallelization. I mostly cared about keeping code DRY because its hell to refactor a codebase with 5 implementations of the same thing. But if I am just instructing an LLM to make the change, I dont care how many files it has to visit - its still the same single instruction from me.
So I will think long and hard about how tooling needs to improve, and how frameworks need to change, to be part of this new paradigm. Similar to how Object Oriented Programming optimised for human logic rather than cpu cycles, the time of LLMs will optimise for testability and parallelisation rather than gpu cycles, or DRY paradigmes.
1. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
DRY is also about coherence not just refactorability. If you have multiple different behaviors for the "same" thing then your customers are going to think you suck.
Tangential, but an entry level developer at 190k USD per year seems nuts, is that really a reasonable number? From a quick search, I find numbers below 100k USD for the bay area, which seems more reasonable.
In a well off European country, you'd pay around 45k USD for a strong entry level developer. I can imagine 2x salaries, considering costs of living, fire at will and all that, but >4x? Not sure how to back that up.
You’re right, but you’ve only got half the truth. Bay Area devs are overpaid and European devs are underpaid.
Also, a few years ago I had teams in multiple countries (South East Asia, India, Easter Europe, Western Europe, East and West Coast), all well paid (but not at FAANG levels). While their capacity was roughly similar, the West Coast ones were by far the more expensive ones, but also quite stressed out to make ends meet (buying a house, having a kid, putting them through school) compared to the other teams.
Eastern Europe was a place to find hidden gems (very cheap - but not so now), and some brilliant people (but not all of them). Western Europe was consistent, solid moderate quality at moderate costs vs US. So in line with your views
>but also quite stressed out to make ends meet (buying a house, having a kid, putting them through school) compared to the other teams.
Because a well paid SW dev wages goes soooo much further in developing countries, you're basically a king as every other profession earns very poor in comparison, so home ownership is no issue.
Well, the author did cite Levels, which is pretty reliable. A quick search shows that >150k seems accurate for a lot of the top tech companies (eg. Google).
I absolutely know people individually who made 150k+ out of college. Sorry europeans, but Bay Area salaries are definitely a large multiple of European salaries, even entry level.
A lot of this is possible because these companies make a lot of money, and a lot of money per employee, and that trickles down to new-hire salaries. It doesn't seem like there are many wildly profitable European companies in tech, at least not ones that can really drive up salaries like this. It's too bad, because Europe broadly has really strong talent, but I imagine there is a constant pressure pulling people away for more money.
I'm not sure many are hiring European devs at all at the moment, not sure what the US market is like.
Definitely not what they were, especially for more junior developers as I understand it. And I assume total comp is somewhat depressed too if only because of the stock market.
Totally agree, and USA hasnt delocalized that, so if cost was the problem, or code production... why?
>In a well off European country, you'd pay around 45k USD for a strong entry level developer. I can imagine 2x salaries, considering costs of living, fire at will and all that, but >4x? Not sure how to back that up.
You back that up with the fact that Google makes 500k USD profit per employee, AFTER they pay each of them 200k+ in salaries plus added taxes and other expenses. Valve makes 19 Million USD profit per employee. There are no European tech companies that make even remotely as much profit per employee, so obviously they'll never be able to pay such salaries no matter how much EU workers as for.
It's not like the US tech workers work 4x harder, or 4x faster, or are 4x smarter than the European ones, it's that their companies are 4x more profitable and that reflects in workers' compensation.
Agree US market seems bloated, not only salaries but also positions, you can find "seniors" with 2 years of experience, maybe a side effect from the pandemic boom
I find the outlined scenario well argued and plausible.
What's more interesting to me though is the complete lack of mention of labor unions as a potential defense mechanism for engineers (either in the OP or in the conversation here, at least so far).
For a while now I've felt it's quite arrogant and completely naive of us to not accept that we're just keyboard workers, and not rare special flowers that will forever be economically privileged.
There was a job once consisting of painting with color black and white photography.
Color photographic film ended that job, but not photography nor painting.
What ended was just the small intersection between the two that was, for a moment, very popular and valuable but suddenly became not a job.
So diversification within the same or adjacent skillset is probably a good idea. Better than panic or putting all chips on one thing.
We don't know the future after all. So much can change so fast.
You get something right, something awfully wrong. It's true that machines dont sleep, but less true that every software engineer costs 230000$ an year. Maybe (!) that's true in Silicon Valley. In Italy, it costs 35000E. And we don't see many software companies in Italy. Why? Because I'm sad to have that explained, code is 10% of development. Whatsapp was sold for 17 billion dollars and it was 55 employees, and it's an IRC chat made mobile. At the time, it didn't have video. I can keep going on, but this discussion sounds so out-in-space that only USA people could not see. Sorry if you're from somewhere else.
Certainly the sorts of salary numbers thrown around with the likes of Google are not generally true of smaller companies, east coast companies except perhaps for some finance roles, and certainly not for IT/developer roles at non-tech companies. Nor is it true for pretty much any other STEM jobs. Doesn’t seem sustainable. I’m tempted to think that a lot of people learning CS today because it’s so lucrative are going to be disappointed.
USA is the worldwide exception when it comes to SW industry, not the rule.
The US tech industry is reaping the benefits of being the WW2 and cold war victor, the first to the punch in SW development and online capitalization, a homogenous single language market with the top economy in the world and owning the world reserve currency, meaning they can print and throw ungodly sums of money at any app that helps with mass data collection, data which is more valuable to advertisers because the US consumer has the highest purchasing power in the world by a long margin, and subject to less linguistical, financial and legal fragmentation and gov oversight than the EU.
It's a positive reinforcing feedback loop where more money helps creates even more money, like a snowball rolling downhill. It's not something Italy or any EU as a whole can replicate. We can replicate the same SW tech/concepts here, but not the scale and monetary effects that the same tech has in the hands of the US. US is basically playing the game with the infinite money glitch, and the crazy US salaries are a second order effect of that.
The difficult question to answer is not if we will lose our jobs to AI, but when. Are we talking 100 years from now? Are we talking 5 years, 1 year? But yeah, given enough time it is clear to see computers will one day program themselves.
How much are people paying per month per user for coding AI services?
20-40 USD per seat is typical (Cursor and GitHub Copilot are both around there)
I tried vibe-coding some non-trivial code. It failed successfully.
The resulting code had a memory leak (from good old Promise.race) that would have caused the app to continuously grow the RAM usage.
I decided to let the AI code, and then asked it to fix the problems, describing the issue (steadily growing RAM usage). It was not able to find the issue.
That's what I'm afraid of. We'll get megabytes of code that just fails sometimes, for unfathomable reasons.
> We'll get megabytes of code that just fails sometimes, for unfathomable reasons.
But…that’s the current situation.
>> We'll get megabytes of code that just fails sometimes, for unfathomable reasons.
> But…that’s the current situation.
Where? Bugs are fixed by humans. I want to see a ticket closed due to "can't find bug".
Sorry, not even close.
A single human can't write megabytes of code within a few hours, unless it's something that was repeatedly cut&pasted.
AI can create megabytes of complicated code that will be impossible to debug. It can do what you want it to do, but not quite.
Kinda like a genie from a lamp.
I guess that your takes on parallel, compartimentalized, self healing, game-theory based micro AI agents could be spawned and organized code their own way. But... wake me up when it happens, ok? ;)