> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
Because programmers have generally been forced to wear additional, invisible hats that are essential to making the code happen in the first place.
Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers. Either directly or worse. The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
> Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers.
That's like saying "building a car is not hard, building a real car that you can use and that passes regulation is".
IOW, writing code is hard in every reasonable context.
How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t.
(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)
> The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
That doesn’t describe any devs I know, especially not in the old days. Interrogating customers and bringing back requirements was the job of management (who got big salaries, too.)
Nobody is arguing that typing lines of code on a computer is hard.
However, when it's the AI that does the thinking in place of the programmer, it's not "the engineer writing correct code" anymore since the engineer...isn't engineering, it's the AI that becomes the engineer. period.
> Knowing what is correct in a setting with paying customers generally involves interacting with those customers.
Plenty of programmers never interact with the customer, this is the job of the analyst, not the programmer. Both jobs used to be distinct by the way.
I think you're confusing product and engineering. I get that programmers are smart so we just assume we can do every job, but it's a waste of your time and salary to talk extensively to customers and create product requirements. Let the PM's run the user research sessions, you can find more productive things to do.
However, where we agree, is that there is more to engineering than writing code. It's problem solving. Even if the product team, the c-suite, the board, the investors, et al, are all in on a product that they believe customers want, doesn't mean the real problem of bringing that idea to life at scale has been solved.
Writing code has a minimum IQ requirement; a significant fraction of the population will essentially never be able to code by themselves. That labor supply limitation is what's kept programmer salaries relatively high.
Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE or MechE work. Programmer salaries have been driven up by the ability to write-once-sell-globally and the dramatic profit margin difference between that and, say, producing chips where there's a much higher fixed cost due to the need for more real material, tooling, etc. Many of those roles require a much higher-than-baseline-skill, but it pulls up the compensation competition for almost everyone else too. (Though even then there are a lot of unglamorous, line-of-business, internal-tools-programming work that's not paid particularly well even in a lot of parts of the US far from the big tech companies.)
Programming salaries have been driven up by Venture Capital investing in tech startups during the "disrupt" era. Now that programming itself has been "disrupted", Now that money is going to the new disruptors.
Programming salaries were never that high outside USA, compared to civil engineering jobs in most of Europe for instance.
It's very likely IT salaries will start going down in USA, save from a very limited number of specialized jobs...
I agree, the whole 'developers don't code' AI defense was pretty ridiculous. I also concur that development is going to get a lot harder. Anyone that has successfully used AI coding tools knows that you can get massive productivity increases but now I have to figure out how to get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements. If you can do it, yeah you can get 10x results. But now I am engineering harnesses, architecture specifications, agent structures, statistically sampling, and formal verification systems to guide the code instead of writing the code.
>get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements
I see this comparison a lot, but I’m not sure I agree. At least not semantically. The list of what an engineer using agents is responsible for, largely hasn’t changed. Engineering managers haven’t changed responsibilities either.
Even with wrangling agents, you’re really just making them right the “correct code”. Something EMs don’t do, or at least the good ones don’t do with their ICs.
The answer to all these "if coding is easy" questions is that coding isn't programming (to put it in Lamport's terms).
Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard.
You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook?
When was the last time you built a system and stared reality right in face, that is:
- can't trust your clocks
- pick 2/3 of CAP
- exactly-once delivery impossible
- the code will need to be altered and released without downtime
- hackers will try to exploit you for fun and profit
- your manager doesn't want you wasting time getting the above right
I guess my impression using these tools daily is that it hasn't diminished the need for my own technical expertise. The conversations I have with it are highly highly technical, and to me the insights come from both sides, I see things the LLM doesn't, and the LLM sees things I don't. It writes a lot of bugs that I have to spot, and writes designs that aren't correct. (This isn't a criticism, I do the same). I think the ideal world version of this stuff is complementary, but the current insane bubble economics mixed with the insane religious fervor make that unpalatable to the leading AI companies. (Like, I think Sam Altman said that anything below a trillion dollar IPO valuation is a "non-starter".) So, "nice coding tool", even if that's the BEST and most realistic outcome, is just not going to do it for them.
Yes, writing code that (appears to) work was not the hard part. Even before LLMs you could find very cheap contractors on Upwork or through offshoring companies to write "code".
Well-engineered code is hard. It still is. Code that is reliable, extensible, maintainable, scalable, legible, understandable is hard. Code where the specs and the "why" behind it were pressure-tested via thought and good intuition.
The arguments are couched in questions… which all either have ready answers or imply strawman arguments that few are making.
I suspect it’s emotional and indirect because the author understands how poor its arguments are. That leaves open the question of why do the blog post at all, but I guess bloggers have to blog, whether or not they’ve got anything to say. An angry, emotional, vague post probably gets a nice amount of views.
Coding is easy if you enjoy doing it, met plenty of professional programmers that hated it and never felt the desire to improve. To them it was a way to get a paycheck that paid reasonably well.
Better to have a job you don't like that pays well than to have a job you don't like that pays poorly. But at the same time - if you're smart enough to program well enough to get paid while hating it it's such a shame to not find something you enjoy that will still pay you enough.
Is what he said wrong? Why don’t you attack his argument rather than his background. Not snark. I want to see the holes in what he says and I literally don’t care about who he is.
"Code was never the hard part" misses the point but so does this blog post. This blog post from 2011 is worth reading and really cuts into the middle of the dreads-of-programmer.
Don’t call yourself a programmer: “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired. You know Salesforce, widely perceived among engineers to be a Software as a Services company? Their motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)
This is dishonest. Nobody said "coding is easy" in a void. They said "code isn't the hard part" - in the context of LLMs. The obvious implication being that the actual speed of writing code wasn't the bottleneck. The implication is not that it's easy to think of what to write, or that any of the other parts of coding are easy.
To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries.
It's not that code wasn't difficult—it really was.
In CRUD apps, about 70 to 80 percent of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small.
Nope, only those without a degree that cannot do anything else, e.g. the bricklayers on a building.
Real engineering has always been about talking with the multiple parties, organising architecture meetings, taking down requirements, if no infra team available setup the whole CI/CD pipeline, and so on.
Programming could be done in whatever language, or low code/no code tool, solved the business problem.
what is -coding-? only typing down some code? the hard part is always the design part, reading doc, reading other code, understanding the sum of the parts, making choices, until the code to write is (quite) -obvious-.
Probably is a question of terms: there is two things: -design- and -coding- (but could be anything as: building, drilling, turning, traveling..) so to make things without a good design is the regal way to problems, many times is a problem left by others, and in a world more and more complex and fast-changing can only be more and more worst. Hard to say what part is really the hardest, but starting with a bad design is no good.
And now probably LLM will solve some problems, but for sure these tech will create more and more new ones.
> I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.
This is a specific attitude I try to beat out of juniors. You will not be dismissive of the point of this exercise.
The author's primary misunderstanding in my opinion is that time consuming is being conflated with hard.
>If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
There is more to those roles than just coding. In fact the more expensive "programmers" often do not code themselves.
>Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs?
Something being time consuming is different from something being hard. There are simple factory jobs that also demand overworking.
>Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?
Building software takes time and since velocity is important companies wanted people who could increase velocity.
>If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?
So authors can make money? Programming is learned by a ton of kids on their own there is no need for boot camps or college degrees just for the benefit of being able to program.
If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?
The earlier you are to a field the easier it is to have your impact recorded. In markets with first movie advantage being earlier also helps a lot. A lot of people were able to program so what made them earlier than others was not just being able to program.
>If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?
Again something being time consuming doesn't mean it was hard.
>If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?
When you spend a big percentage of your life doing something it becomes part of your identity regardless of difficulty.
>If coding is easy, why is software so damn buggy?
Because making bug free software takes a lot of time and resources. Those resources have a higher return on investment elsewhere.
>If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers?
People are clueless because it is hard. Pay is not based off of difficulty.
>If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?
Because the company finds it cheaper to outsource? A ton of companies have their employees setting up and using telemetry to understand their customers so it's not a one dimensional thing.
>If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for!
Programming takes time and resources. These may have a higher return on investment elsewhere than this niche feature. It may make maintaining the entire product take more resources to support a niche feature.
>If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?
Again building entire products takes a lot of resources. And 10x the cost of building every product is not going to be competitive in the market.
I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products and see code as an annoying intermediate step and "engineers" for people who build technically sound software.
It is usually forgetting that everything can fail and will fail. And I mean everything. If it shouldn't fail it will at some point. And you should take that into account. And we usually don't until third or so time...
That quotation is coming from programmers themselves.
Managers and execs aren’t saying this it’s the programmers and coders themselves making the claim that coding was never the hard part.
It is still an insult though. It’s an insult to themselves. It’s the lie all programmers including me tell themselves as reality itself insults us. Coding WAS the hard part.
That’s exactly what we were good at. Now our skills are getting owned by automation. How do we face reality shitting in our faces? We lie. We fabricate a reality that’s more acceptable. We frame our environment in a way that still validates our existence. If AI has invalidated all of my programming skill then I need to find something else to support my identity.
Code generation was never the hard part. Knowing wtf you’re supposed to actually write was always much harder and this hasn’t changed. It’s not hard to write a loop or an if-statement. It’s hard to actually solve a problem with them at production scale.
Claude writes 90% of my code but the bottlenecks always were and still are:
* getting clear requirements from product
* getting the damn code reviewed so I can merge it
Neither of these are fixed. Frankly, overuse of AI has made both of these worse. Claude brained product owners going hig wild with Claude Design are a nightmare to deal with, and the volume of absolute trash quality code being submitted for review is soul crushing.
No, using AI to automate code reviews is not acceptable. Code Review isn’t about a checklist it’s about making sure people understand the actual changes being made to the system because it’s people who are accountable for what happens in production. LLMs can be part of the process of reviewing code but they suffer from the same issues as any other chatbot based tools (hallucinations, context confusion or not enough context, grtting bogged down in impossible code paths or other minutia, etc…) so you have to review that review carefully too. Human judgment is still king.
These days my job is primarily reviewing offshore slop and making sure it’s in a good enough state to merge. I’m doing merge and release management way more than actually coding (and it sucks btw because I actually enjoy coding with or without agents). If the quality of the code turned in for me to review and merge is any indication, engineers/system architects are going to have their hands full.
Code is the hard part if you are John Carmack or in a similar position where you have to squeeze every drop of performance from a hardware. That is the minority of programmers.
It's a strange choice of something to take personally. It doesn't mean code is supposed to be easy for everyone at all times, just that past a certain point of your own personal path towards mastery the utility of not having to write code diminishes and the complications of delegating rise in proportion to the shrinking gains.
LLMs are the invention of the loom. Code is being industrialized.
Yes, there always will be artisinal weavers and a smaller number of them get paid a lot more money to do this by people who can afford it. Everyone else either started operating a loom or did something else.
Automated looms are now making mass amounts of textiles but the artisans are no longer doing the physical act of weaving. The artisans come up with cool designs, get feedback from customers, solve people's problems and outsource the rest (physical labor).
We are in the loom moment. Are you designing things people want? Are you doing the weaving? These two paths can coexist but they are diverging disciplines with diverging difficulties and diverging value.
Typing code into a computer is rapidly becoming physical labor now. The layer of creativity and problem solving is quickly raising to a level above the code since the code is a fluid now that comes and goes easily.
Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef.
There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days.
It's interesting realizing how mind numbingly thoughtless my job has become.
Interesting take. Can you link us to your (correct, maybe even formally correct) AI-generated software? Given how general this post is, I assume you wouldn't mind if I extend this to, Idk, aviation or spaceflight, so mind linking to any GH repos you have where you've written code to work in environments like that? I ask because all you said was "making software" and didn't say what kind of "software" we're talking about.
Since you apparently work on this kind of software, here's a challenge for you: take the last several bugs that were reported and paste them into Fable, pointing it at your code.
How long does it take? Does it find the issue? In more or less time than the engineers took?
Ask it to review your code for design and cohesiveness issues. How does it do?
Can you link us to your git repo(s) and/or other artifacts that demonstrate this take? I and many other here I think won't agree, and we mostly love being taught.
Because programmers have generally been forced to wear additional, invisible hats that are essential to making the code happen in the first place.
Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers. Either directly or worse. The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
That's like saying "building a car is not hard, building a real car that you can use and that passes regulation is".
IOW, writing code is hard in every reasonable context.
Now add the time dimension - keeping code correct as the business and the people in it change.
That's how I explain to people that LLMs will not replace us developers.
(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)
That doesn’t describe any devs I know, especially not in the old days. Interrogating customers and bringing back requirements was the job of management (who got big salaries, too.)
Nobody is arguing that typing lines of code on a computer is hard.
However, when it's the AI that does the thinking in place of the programmer, it's not "the engineer writing correct code" anymore since the engineer...isn't engineering, it's the AI that becomes the engineer. period.
> Knowing what is correct in a setting with paying customers generally involves interacting with those customers.
Plenty of programmers never interact with the customer, this is the job of the analyst, not the programmer. Both jobs used to be distinct by the way.
However, where we agree, is that there is more to engineering than writing code. It's problem solving. Even if the product team, the c-suite, the board, the investors, et al, are all in on a product that they believe customers want, doesn't mean the real problem of bringing that idea to life at scale has been solved.
Writing code has a minimum IQ requirement; a significant fraction of the population will essentially never be able to code by themselves. That labor supply limitation is what's kept programmer salaries relatively high.
Programming salaries were never that high outside USA, compared to civil engineering jobs in most of Europe for instance.
It's very likely IT salaries will start going down in USA, save from a very limited number of specialized jobs...
... as long as the buyers could never discern
Development is essentially becoming management.
Even with wrangling agents, you’re really just making them right the “correct code”. Something EMs don’t do, or at least the good ones don’t do with their ICs.
Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard.
You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook?
When was the last time you built a system and stared reality right in face, that is: - can't trust your clocks - pick 2/3 of CAP - exactly-once delivery impossible - the code will need to be altered and released without downtime - hackers will try to exploit you for fun and profit - your manager doesn't want you wasting time getting the above right
Coding is the easy bit.
Well-engineered code is hard. It still is. Code that is reliable, extensible, maintainable, scalable, legible, understandable is hard. Code where the specs and the "why" behind it were pressure-tested via thought and good intuition.
The arguments are couched in questions… which all either have ready answers or imply strawman arguments that few are making.
I suspect it’s emotional and indirect because the author understands how poor its arguments are. That leaves open the question of why do the blog post at all, but I guess bloggers have to blog, whether or not they’ve got anything to say. An angry, emotional, vague post probably gets a nice amount of views.
Of course he is an AI consultant among other things.
Edit to add: instead of "adapt" (which would imply "embrace AI", which I didn't say), my intent was more along the lines of "be adaptable."
You must be anti ai among other things.
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries.
It's not that code wasn't difficult—it really was.
In CRUD apps, about 70 to 80 percent of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small.
Real engineering has always been about talking with the multiple parties, organising architecture meetings, taking down requirements, if no infra team available setup the whole CI/CD pipeline, and so on.
Programming could be done in whatever language, or low code/no code tool, solved the business problem.
Now what will remain to humans is a big question.
https://www.nair.sh/guides-and-opinions/communicating-your-e...
Probably is a question of terms: there is two things: -design- and -coding- (but could be anything as: building, drilling, turning, traveling..) so to make things without a good design is the regal way to problems, many times is a problem left by others, and in a world more and more complex and fast-changing can only be more and more worst. Hard to say what part is really the hardest, but starting with a bad design is no good.
And now probably LLM will solve some problems, but for sure these tech will create more and more new ones.
https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf
This is a specific attitude I try to beat out of juniors. You will not be dismissive of the point of this exercise.
>If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
There is more to those roles than just coding. In fact the more expensive "programmers" often do not code themselves.
>Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs?
Something being time consuming is different from something being hard. There are simple factory jobs that also demand overworking.
>Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?
Building software takes time and since velocity is important companies wanted people who could increase velocity.
>If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?
So authors can make money? Programming is learned by a ton of kids on their own there is no need for boot camps or college degrees just for the benefit of being able to program.
If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?
The earlier you are to a field the easier it is to have your impact recorded. In markets with first movie advantage being earlier also helps a lot. A lot of people were able to program so what made them earlier than others was not just being able to program.
>If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?
Again something being time consuming doesn't mean it was hard.
>If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?
When you spend a big percentage of your life doing something it becomes part of your identity regardless of difficulty.
>If coding is easy, why is software so damn buggy?
Because making bug free software takes a lot of time and resources. Those resources have a higher return on investment elsewhere.
>If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers?
People are clueless because it is hard. Pay is not based off of difficulty.
>If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?
Because the company finds it cheaper to outsource? A ton of companies have their employees setting up and using telemetry to understand their customers so it's not a one dimensional thing.
>If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for!
Programming takes time and resources. These may have a higher return on investment elsewhere than this niche feature. It may make maintaining the entire product take more resources to support a niche feature.
>If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?
Again building entire products takes a lot of resources. And 10x the cost of building every product is not going to be competitive in the market.
Debugging is hard.
Managers and execs aren’t saying this it’s the programmers and coders themselves making the claim that coding was never the hard part.
It is still an insult though. It’s an insult to themselves. It’s the lie all programmers including me tell themselves as reality itself insults us. Coding WAS the hard part.
That’s exactly what we were good at. Now our skills are getting owned by automation. How do we face reality shitting in our faces? We lie. We fabricate a reality that’s more acceptable. We frame our environment in a way that still validates our existence. If AI has invalidated all of my programming skill then I need to find something else to support my identity.
Claude writes 90% of my code but the bottlenecks always were and still are:
* getting clear requirements from product
* getting the damn code reviewed so I can merge it
Neither of these are fixed. Frankly, overuse of AI has made both of these worse. Claude brained product owners going hig wild with Claude Design are a nightmare to deal with, and the volume of absolute trash quality code being submitted for review is soul crushing.
No, using AI to automate code reviews is not acceptable. Code Review isn’t about a checklist it’s about making sure people understand the actual changes being made to the system because it’s people who are accountable for what happens in production. LLMs can be part of the process of reviewing code but they suffer from the same issues as any other chatbot based tools (hallucinations, context confusion or not enough context, grtting bogged down in impossible code paths or other minutia, etc…) so you have to review that review carefully too. Human judgment is still king.
These days my job is primarily reviewing offshore slop and making sure it’s in a good enough state to merge. I’m doing merge and release management way more than actually coding (and it sucks btw because I actually enjoy coding with or without agents). If the quality of the code turned in for me to review and merge is any indication, engineers/system architects are going to have their hands full.
Now there is hard-er coding. Novel algorithms, performance sensitive stuff, and so on.
Yes, there always will be artisinal weavers and a smaller number of them get paid a lot more money to do this by people who can afford it. Everyone else either started operating a loom or did something else.
Automated looms are now making mass amounts of textiles but the artisans are no longer doing the physical act of weaving. The artisans come up with cool designs, get feedback from customers, solve people's problems and outsource the rest (physical labor).
We are in the loom moment. Are you designing things people want? Are you doing the weaving? These two paths can coexist but they are diverging disciplines with diverging difficulties and diverging value.
Typing code into a computer is rapidly becoming physical labor now. The layer of creativity and problem solving is quickly raising to a level above the code since the code is a fluid now that comes and goes easily.
There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days.
It's interesting realizing how mind numbingly thoughtless my job has become.
How long does it take? Does it find the issue? In more or less time than the engineers took?
Ask it to review your code for design and cohesiveness issues. How does it do?