I swear there's not a econ/tech writer on the planet that has any idea what engineers actually do.
A software engineer is most importantly a *type of engineer*. And by and large engineers are people who define and solve problems. "Coding" is incidental to the job. It's like thinking mechanical engineers were all going to lose their jobs because CAD came along, after all, didn't they spend their days at a drafting table?
You keep mixing up the technological toolset of the job with, like, the actual substance of the job in this frustratingly reductive way.
I'm sympathetic, a bit, because there was this period of time where software engineers got a little high on their own supply and convinced themselves and everyone else that "coding" was this God-like skill set that was just *different* than everything else, and so I don't mind seeing them taken down a peg. But fundamentally coding was never engineering.
To say nothing of the fact that in most organizations most engineers stop actually using these tools (drafting in CAD, coding etc.) once they become senior enough. Generally at that point the job has less to do with production and more to do with design, coordination, tradeoffs etc.
Not that LLMs aren't also getting better and better at that too but it will likely take a bit longer and always be a bit messier.
edit: On the "learn to code" front. Once thing that became clear to me as a hiring manager in the industry was there was an enormous difference between people who "learned to code" and engineers. One does not make the other.
Has nothing to do with their academics either. In my experience there were plenty of people with non-STEM degrees who "learned to code" in a bootcamp or via YouTube or something and ended up brilliant engineers because they had, at their core, an engineering mind. Likewise, plenty of folks with engineering degrees who at their core do not.
As an engineer, I agree with you somewhat. Although I think Noah generally has a good handle on things. Until I actually started working on a Masters in Computer Science (which I did not finish) I had real issues with the term “software engineer”.
I think this is mostly right. In an AI-heavy environment, programmers may spend more of their time doing planning and architectural design than coding.
But I have to say that I'm more skeptical of the overall benefit of AI coding tools. I've only tried to use Gemini and for toy applications, and it didn't do very well writing code from scratch. It could toss out some excerpts that did some of the functionality, but FWIW, the architecture for the application was all wrong.
What it could do was relatively simple debugging. When I was playing around with an Internet Radio player, I could upload code, give a loose description of what I saw ("I see a crash at line XXX of this file when I press the "+20" button" or "I hear noise every few seconds when I'm playing a station."), and it found the problems near instantly.
https://siddhantkhare.com/writing/ai-fatigue-is-real describes at a level of detail I hadn't seen before what it's like to program by prompts. It sounds horrible, frankly: AI generating different approaches when the same prompt is used at a different time; having to check the generated code after each iteration; keeping up with tools that change from week to week; having to puzzle out how the generated code works, since if something goes wrong you, not the AI, are going to get that 3 AM phone call.
From my experience, it will quickly reproduce common apps that have been made a million times. It will do fun ittle projects.
But if you're (1) creating a *software product* that will need to be extended and maintained or (2) doing anything fairly bespoke, you can't have it produce a bunch of black box code and hope for the best. You need to keep your hands on the architectural reigns, laying out exactly what you want and letting it save you some time by filling in snippets. It's that process of definition that's connected to the entire motivation for the project in the first place. To have AI do it, you still need to explain it to AI; it's circular.
This is an incredibly useful tool. It's not a magic genie that ends engineering.
I really can't emphasize how much the experience of working with the most advanced Claude model inside the Claude Code harness (or GPT 5.4 inside Codex) is different from using Gemini in the way you describe. It's true the industry is moving fast and it can be easy to feel overwhelmed by whatever the new hotness is, but there are real skills and approaches to be learned there, and once you get them it's all different ballgame.
Yeah, it *is* true that I like badmouthing AI in general because Sam Altman's such a twit. And if I have to read one more article about how AGI will cure cancer or build a fusion reactor, I'll barf.
But intellectual honesty has forced me to fork over $20 to Anthropic to see if using Claude really is a different experience than Google's Gemini. And it physically pains me to admit this, but Claude Code is remarkably good.
I've just given Claude a task to refactor a class that both downloads some data and then provides access to the stored data, so that the downloader can be deleted or reset while preserving the already downloaded data in a separate object.
It took about 5 wall clock minutes and did what I asked for. Now, it didn't read my mind, so I have more work to do to be able to make use of that data, but there's no way I could have done that work as quickly. I *am* going to have to proofread the results, and that will take more time than Claude took to do the work but I can see how something like this could add 20% overall to your productivity.
Just wait until you really get a setup that you like in place - for example I have skills and hooks that force TDD with red green refactor (something I hated when writing code manually, but the machine doesn’t complain so), as well as tell it to create makefiles with standard commands for lining/testing/etc regardless of language I’m writing in. Small things like this and you really start to fly.
So, I've continued to play around with my radio app, and I've learned a few things:
1 -- **It can be a bit sloppy**. The code will work, but it isn't very good at designing modules to keep implementation details hidden. It added one module as part of one of my requests and then had the module's caller reach into it to grab a *mutex* to save it the trouble of allocating its own.
2 -- **You really have to proofread *everything* it does**. I had a flag that told me when a cached array index was still valid, to avoid redoing a search of the array, but it cleared that flag all the time, essentially killing off the optimization. And when you have to do multiple prompts to get what you want, you basically have to do repeated proofreading passes over the modified code.
3 -- **Proofread everything, after every change**: not only does it sometimes break optimizations, it sometimes just gets code wrong. I have a call that blocks the player from starting until there's a decent amount of audio queued up, and in one of the changes, it was supposed to store some older data on disk instead of keeping it all in memory. But when Claude added the amount queued in memory with the amount queued on disk, it essentially added a bunch of random metadata also stored on disk to the final value, getting the sum wrong.
4 -- **The prompts have to be very detailed to get even half-decent results.** You're not going to get good quality apps from a non-programmer writing these prompts. And non-programmers aren't going to be able to review the AI-written code.
5 -- **Right now, at least, this is not going to be a job killer for software developers.** See items 1-4 above :-)
I can definitely see how someone can be impressed by how much code it cranks out (95% of which makes sense) and still end up less productive after having done 5-10 proofreading and debugging passes to get something actually working.
Note also my test is a trivial application: an internet radio player implemented in 8500 LOC of Objective C. Proofreading changes to a much bigger application would no doubt take more time, although doing the work manually would also likely take more time in a larger code base.
I'm 99% sure that I'm going to cancel my Claude subscription at the first month anniversary. With all the required proofreading and repeated prompts, I'm pretty sure I'm less productive with Claude than without. And it is certainly less *fun* to just sit here and read its code rather writing the stuff myself.
Yes... there seems be a big gap in understanding. BTW.. there is a reason one can see a 10X difference in productivity in software engineering...and it is not about how fast they code.
“Software engineers, for whom ‘writing code’ was a big part of the job description just a few months ago, are now mainly checkers and maintainers of code written by AIs.”
This gets a lot of press and as a software engineer it drives me a little crazy every time I see it. Even if we accept that the coding part has been or will be handled exclusively by AI, the engineer’s actual role hasn’t changed. The ability to competently produce working code is still in the job description and I would argue that it was never the most important part in the first place. Using AI doesn’t turn a software engineer into a “checker and maintainer of code written by AI” any more than pneumatic nail guns turned carpenters into checkers and maintainers of nailed together pieces of wood.
The hard part of being a software engineer isn't writing code. The hard part is "requirements" - figuring out what you or your customers want so precisely that you can tell even a machine how to do it.
I'm a software engineer. I can only speak for myself and what I see in my own company and team. But at least where I am we're a fair bit off from software engineers no longer writing code themselves. Code gen tools are definitely impressive, but they're still not super great at making large changes to established code bases themselves. At least not with extensive prompting that's as time consuming as doing it yourself. They may very well get there (and sooner than some think), but the transition hasn't happened yet. They're better at stand alone prototypes and for certain boilerplate implementations (tests, etc).
But beyond that, the actual writing of code (as in the actual typing lines of code into an editor) has never really been the lion share of the work of a software engineer. A lot more of my time has always been spent determining what needs to be built, how it will interact with things other people are building, and how to build it to be debugable and editable by others in the future. Much of the rest is spent evaluating how things are performing, debugging etc. AI is making inroads into SOME of those spaces, but I think it's quite a bit slower there.
I suspect some massive changes are on the horizon, though it's difficult to predict the scale and the timeline (6months? 2 years? longer?), but at least where I'm sitting the change isn't dramactic YET.
Well, Anthropic claims that all their code is now written by Claude. I wonder if Claude was the one who leaked the Claude Code .MAP file into that public npm package.
I'm going to help all the "but now you don't need to learn to code" people (who probably studied liberal arts). In the age of AI we will still need people who "know how to code", or stated more precisely: who study computer science. I think we'll need more of them.
What non-tech people don't seem to get is that Computer Science is at its core studying the way that problems are solved using computers and problem solving in general. Modern coding itself is done on layers of abstractions. Java programmers are writing code that is compiled to "byte-code" which is then translated again into machine instructions. AI is just another tool of abstraction. Computer science education will of course evolve, but it is far from redundant.
Want to be useful in the age of AI? Study Computer Science.
It's not necessary today. What you mean to say is useful. If you think problem solving will not be useful in 10 years, then I'd build that bunker now.
Edit: I'll state it another way: AI will just mean a larger share of problems are solved with computers. It will be more important than ever to know how to harness this power.
I think that basic level REAL courses in the sciences are part of a liberal education. The scientists of 17th and 18th centuries certainly thought so. Even though I got my PHD in history, I would feel naked without my basic understanding of biology, chemistry. and physics.
The humanities and sciences are the same here, both focusing on general knowledge and skills, rather than more career-oriented majors that try to teach you skills for a specific job.
This does sound horrible. It’s also unlikely. More likely is the code reviewer or maintainer (to stick to coding) is a specialist who is needed when the AI messes up. I’m fairly dubious that coding has been replaced fully really - only the companies selling the AI are saying that, with the results we see from Claude recently.
Programmers aren’t, except for trivial apps, writing prompts like “build me an app to show a dog barking”, but instead getting AI to write what they could write themselves, with strong architectural inputs and frameworks and system knowledge.
People that are good at spotting errors are almost always those that are VERY familiar with the subject (IE specialists).
A generalist doesn't have enough knowledge to spot the error because they aren't familiar enough with the material.
I've been at my company a while I have an sense of how the number should look. If I went to a totally new company it would take me years to regain that sense. And if I did an entirely new job say working in QA in the plant, it would take me even longer.
Yep. Gotta be able to know when the computer is giving you the wrong answer! (My father worked in circuit design, and he's run into several cases in which the commercial simulation software had been using incorrect models...)
I dont see any mention of the service industry here, what do you expect to happen to stockers and fast food workers? Or the trades? Is half the American economy just not worth a mention?
When people are talking about job replacement with regards to the present AI systems, it’s Office work. If you are using your legs, and body to work you are safe, at least from the first order effects.
I have to pile on with the other commenters here -- your framing of the shift of the work software developers do continues to be dramatically overstated. I work at a huge software development company, we are pushing HARD to use AI in a maximally-effective way, and we are NOT EVEN CLOSE to becoming "mainly checkers and maintainers of code written by AIs." We are trying to become this! It isn't working yet! We all acknowledge that it MAY become the case in the future, but framing it as a shift that occurred IN THE PAST -- which you've been doing for weeks! -- is just factually wrong, and it makes the rest of your analysis uncharacteristically unhelpful.
Others have pointed out that "writing code" is NOT the main thing software engineers do, which I agree with. A big part of our job description is finding ways to tame or understand the complexity of intrinsically complex systems. In the past, as software has gotten more complex, it has tended to raise the demand for software developers. So far, code written by AI is often helpful, but not costless -- it generates complexity that we then have to maintain. In theory, AI lets us generate complexity faster than ever before! So, while it's possible that AI will simply take over software developer jobs once it gets smart enough, it's also possible that, even if AI manages to take over the task of writing code itself, the demand for software developers may skyrocket.
I've long been an AI doomer, expecting software development jobs to be first on the chopping block, but lately I'm starting to view the "AI causes demand for software developers to accelerate" scenario to be much more likely than I previously thought.
If AI eventually does make software development a lot more productive, there are going to be a lot of people using custom software that wouldn't have been able to afford it before. So as long as hiring a team that includes humans and AI is better than doing all the AI wrangling yourself, there are still going to be lots of jobs for software developers.
The salaryman analogy is interesting but the institutional gap is the elephant in the room. Japan's system rested on lifetime employment guarantees (30-35% of workforce), seniority wages, enterprise unions, and government retention subsidies. American median tenure is 3.9 years vs Japan's 12.5. The "no-hire no-fire" economy isn't salaryman culture taking root; 76% of employers cite difficulty finding replacements as the reason they're hoarding (Indeed, 2024). That's pandemic trauma, not a new labor model.
Also, the Humlum and Vestergaard study is excellent but Denmark spends 20x more per capita on active labor market policies than the US. Citing Danish outcomes as a forecast for American workers is a stretch.
Interesting take... I am not sure this is the right take on AI, and its impact. I would encourage you to look at three concepts for inspiration around these topics.
1) Computer Aided Engineering: EDA(electronics), Mcad, etc... These are highly sophisticated systems which have introduced a huge amount of automation. Inside many of these systems are various algorithms which in the modern language would be called AI. Without exception, the introduction of these capabilities actually grew the employment market...why? it allowed a much broader class of engineers to be useful.
2) Liability vs Best Efforts: Most interesting economic transactions have attached liability. For AI to truly take over interesting jobs, we need a view of liability around AI. This is pretty much an unsolved problem today ...partly because the legal system is built around the concept of "reasonable behavior given a totality of the facts." ... how is "reasonable" defined... what normal humans do....
3) The edge of knowledge: AI is particularly good at capturing existing knowledge (in an admittedly inconsistent fashion). However, all the interesting work is actually on the edge and it is very hard to see AI replacing work at this edge. The huge jumps in productivity come from AI aided understanding for humans of the current status.
“2) Liability vs Best Efforts: Most interesting economic transactions have attached liability. For AI to truly take over interesting jobs, we need a view of liability around AI. This is pretty much an unsolved problem today ...partly because the legal system is built around the concept of "reasonable behavior given a totality of the facts." ... how is "reasonable" defined... what normal humans do....”
If AI has a lower error or damage rate than humans, what’s the problem with liability?
1) Liability attaches to a person... someone you can sue ... it might be the AI companies or the AV companies...doubt they would sign up for this...
2) demonstrating a damage rate is lower is not very easy... .especially for complex problem sets ... why ? the "judge" here are other humans (jury/judge)... humans understand other humans, but don't understand artificial humans.
3) AI does not have any formal model of behaviour .. it is inherently probabilistic in nature.
“2) demonstrating a damage rate is lower is not very easy... .especially for complex problem sets ... why ? the "judge" here are other humans (jury/judge)... humans understand other humans, but don't understand artificial humans.”
Uber will know exactly how much safer AI drivers are than humans. So will hospital systems.
Well... not really... you need to know this information at the "facts and circumstances level." High level statistics are not that helpful. Also, a number of the interesting situations are based on intent. How does the AV communicate its intent and how does it accept intent of third parties (even animals). As an aside, this is starting to get tested as Tesla has lost a couple of suits. Waymo is closest with geographic approach... but this will also get tested in the courts at the first inevitable accident. At least the liability point is clear in that situation.
Oh but AI *has* affected software engineer jobs: Hiring for entry level sw jobs is way down: My son's cohort (graduated 2025) who stayed in CSci are really struggling to find jobs. This means that there's no "bench" to grow through the ranks and become a senior/experience sw engineer. This, obviously, spells trouble for my profession (I'm a very senior sw eng/architect and I use AI tools).
The greatest advantages of the Japanese-style employment system—organized around non-specialist generalists who rotate through different roles on a regular basis—are that it becomes relatively easy for young people to find employment and that job security is enhanced. Most young people can find jobs immediately upon graduating from university or vocational school, and even when economic conditions deteriorate, unemployment rates do not rise sharply. On the other hand, as workers' specialization goes largely unrewarded and labor mobility declines significantly, the balance between labor and management shifts heavily in favor of employers. The notoriously workplace culture, which evokes the era of feudalism, is inseparable from the guarantee of lifetime employment.
I managed projects for years and you always had budgets (people) and timelines as nearly fixed constraints. Scope was typically your variable. If AI can allow us to deliver more in the same time and same budget, then it is a win for everyone.
Also, hard working smart people who show up on time and aren’t distractions to others will always be able to find work. They always have. Maybe we encourage people to develop those traits. Seems like we encourage the opposite.
I swear there's not a econ/tech writer on the planet that has any idea what engineers actually do.
A software engineer is most importantly a *type of engineer*. And by and large engineers are people who define and solve problems. "Coding" is incidental to the job. It's like thinking mechanical engineers were all going to lose their jobs because CAD came along, after all, didn't they spend their days at a drafting table?
You keep mixing up the technological toolset of the job with, like, the actual substance of the job in this frustratingly reductive way.
I'm sympathetic, a bit, because there was this period of time where software engineers got a little high on their own supply and convinced themselves and everyone else that "coding" was this God-like skill set that was just *different* than everything else, and so I don't mind seeing them taken down a peg. But fundamentally coding was never engineering.
To say nothing of the fact that in most organizations most engineers stop actually using these tools (drafting in CAD, coding etc.) once they become senior enough. Generally at that point the job has less to do with production and more to do with design, coordination, tradeoffs etc.
Not that LLMs aren't also getting better and better at that too but it will likely take a bit longer and always be a bit messier.
edit: On the "learn to code" front. Once thing that became clear to me as a hiring manager in the industry was there was an enormous difference between people who "learned to code" and engineers. One does not make the other.
Has nothing to do with their academics either. In my experience there were plenty of people with non-STEM degrees who "learned to code" in a bootcamp or via YouTube or something and ended up brilliant engineers because they had, at their core, an engineering mind. Likewise, plenty of folks with engineering degrees who at their core do not.
As an engineer, I agree with you somewhat. Although I think Noah generally has a good handle on things. Until I actually started working on a Masters in Computer Science (which I did not finish) I had real issues with the term “software engineer”.
I think this is mostly right. In an AI-heavy environment, programmers may spend more of their time doing planning and architectural design than coding.
But I have to say that I'm more skeptical of the overall benefit of AI coding tools. I've only tried to use Gemini and for toy applications, and it didn't do very well writing code from scratch. It could toss out some excerpts that did some of the functionality, but FWIW, the architecture for the application was all wrong.
What it could do was relatively simple debugging. When I was playing around with an Internet Radio player, I could upload code, give a loose description of what I saw ("I see a crash at line XXX of this file when I press the "+20" button" or "I hear noise every few seconds when I'm playing a station."), and it found the problems near instantly.
https://siddhantkhare.com/writing/ai-fatigue-is-real describes at a level of detail I hadn't seen before what it's like to program by prompts. It sounds horrible, frankly: AI generating different approaches when the same prompt is used at a different time; having to check the generated code after each iteration; keeping up with tools that change from week to week; having to puzzle out how the generated code works, since if something goes wrong you, not the AI, are going to get that 3 AM phone call.
From my experience, it will quickly reproduce common apps that have been made a million times. It will do fun ittle projects.
But if you're (1) creating a *software product* that will need to be extended and maintained or (2) doing anything fairly bespoke, you can't have it produce a bunch of black box code and hope for the best. You need to keep your hands on the architectural reigns, laying out exactly what you want and letting it save you some time by filling in snippets. It's that process of definition that's connected to the entire motivation for the project in the first place. To have AI do it, you still need to explain it to AI; it's circular.
This is an incredibly useful tool. It's not a magic genie that ends engineering.
I really can't emphasize how much the experience of working with the most advanced Claude model inside the Claude Code harness (or GPT 5.4 inside Codex) is different from using Gemini in the way you describe. It's true the industry is moving fast and it can be easy to feel overwhelmed by whatever the new hotness is, but there are real skills and approaches to be learned there, and once you get them it's all different ballgame.
Yeah, it *is* true that I like badmouthing AI in general because Sam Altman's such a twit. And if I have to read one more article about how AGI will cure cancer or build a fusion reactor, I'll barf.
But intellectual honesty has forced me to fork over $20 to Anthropic to see if using Claude really is a different experience than Google's Gemini. And it physically pains me to admit this, but Claude Code is remarkably good.
I've just given Claude a task to refactor a class that both downloads some data and then provides access to the stored data, so that the downloader can be deleted or reset while preserving the already downloaded data in a separate object.
It took about 5 wall clock minutes and did what I asked for. Now, it didn't read my mind, so I have more work to do to be able to make use of that data, but there's no way I could have done that work as quickly. I *am* going to have to proofread the results, and that will take more time than Claude took to do the work but I can see how something like this could add 20% overall to your productivity.
Just wait until you really get a setup that you like in place - for example I have skills and hooks that force TDD with red green refactor (something I hated when writing code manually, but the machine doesn’t complain so), as well as tell it to create makefiles with standard commands for lining/testing/etc regardless of language I’m writing in. Small things like this and you really start to fly.
So, I've continued to play around with my radio app, and I've learned a few things:
1 -- **It can be a bit sloppy**. The code will work, but it isn't very good at designing modules to keep implementation details hidden. It added one module as part of one of my requests and then had the module's caller reach into it to grab a *mutex* to save it the trouble of allocating its own.
2 -- **You really have to proofread *everything* it does**. I had a flag that told me when a cached array index was still valid, to avoid redoing a search of the array, but it cleared that flag all the time, essentially killing off the optimization. And when you have to do multiple prompts to get what you want, you basically have to do repeated proofreading passes over the modified code.
3 -- **Proofread everything, after every change**: not only does it sometimes break optimizations, it sometimes just gets code wrong. I have a call that blocks the player from starting until there's a decent amount of audio queued up, and in one of the changes, it was supposed to store some older data on disk instead of keeping it all in memory. But when Claude added the amount queued in memory with the amount queued on disk, it essentially added a bunch of random metadata also stored on disk to the final value, getting the sum wrong.
4 -- **The prompts have to be very detailed to get even half-decent results.** You're not going to get good quality apps from a non-programmer writing these prompts. And non-programmers aren't going to be able to review the AI-written code.
5 -- **Right now, at least, this is not going to be a job killer for software developers.** See items 1-4 above :-)
I can definitely see how someone can be impressed by how much code it cranks out (95% of which makes sense) and still end up less productive after having done 5-10 proofreading and debugging passes to get something actually working.
Note also my test is a trivial application: an internet radio player implemented in 8500 LOC of Objective C. Proofreading changes to a much bigger application would no doubt take more time, although doing the work manually would also likely take more time in a larger code base.
I'm 99% sure that I'm going to cancel my Claude subscription at the first month anniversary. With all the required proofreading and repeated prompts, I'm pretty sure I'm less productive with Claude than without. And it is certainly less *fun* to just sit here and read its code rather writing the stuff myself.
Yes... there seems be a big gap in understanding. BTW.. there is a reason one can see a 10X difference in productivity in software engineering...and it is not about how fast they code.
“Software engineers, for whom ‘writing code’ was a big part of the job description just a few months ago, are now mainly checkers and maintainers of code written by AIs.”
This gets a lot of press and as a software engineer it drives me a little crazy every time I see it. Even if we accept that the coding part has been or will be handled exclusively by AI, the engineer’s actual role hasn’t changed. The ability to competently produce working code is still in the job description and I would argue that it was never the most important part in the first place. Using AI doesn’t turn a software engineer into a “checker and maintainer of code written by AI” any more than pneumatic nail guns turned carpenters into checkers and maintainers of nailed together pieces of wood.
Many people are saying!
It’s like something that has never been seen before.
The hard part of being a software engineer isn't writing code. The hard part is "requirements" - figuring out what you or your customers want so precisely that you can tell even a machine how to do it.
I'm a software engineer. I can only speak for myself and what I see in my own company and team. But at least where I am we're a fair bit off from software engineers no longer writing code themselves. Code gen tools are definitely impressive, but they're still not super great at making large changes to established code bases themselves. At least not with extensive prompting that's as time consuming as doing it yourself. They may very well get there (and sooner than some think), but the transition hasn't happened yet. They're better at stand alone prototypes and for certain boilerplate implementations (tests, etc).
But beyond that, the actual writing of code (as in the actual typing lines of code into an editor) has never really been the lion share of the work of a software engineer. A lot more of my time has always been spent determining what needs to be built, how it will interact with things other people are building, and how to build it to be debugable and editable by others in the future. Much of the rest is spent evaluating how things are performing, debugging etc. AI is making inroads into SOME of those spaces, but I think it's quite a bit slower there.
I suspect some massive changes are on the horizon, though it's difficult to predict the scale and the timeline (6months? 2 years? longer?), but at least where I'm sitting the change isn't dramactic YET.
Well, Anthropic claims that all their code is now written by Claude. I wonder if Claude was the one who leaked the Claude Code .MAP file into that public npm package.
I'm going to help all the "but now you don't need to learn to code" people (who probably studied liberal arts). In the age of AI we will still need people who "know how to code", or stated more precisely: who study computer science. I think we'll need more of them.
What non-tech people don't seem to get is that Computer Science is at its core studying the way that problems are solved using computers and problem solving in general. Modern coding itself is done on layers of abstractions. Java programmers are writing code that is compiled to "byte-code" which is then translated again into machine instructions. AI is just another tool of abstraction. Computer science education will of course evolve, but it is far from redundant.
Want to be useful in the age of AI? Study Computer Science.
I think that's true now. But I could certainly foresee a future in 10+ years where that won't be necessary at all. AI will just be better.
It's not necessary today. What you mean to say is useful. If you think problem solving will not be useful in 10 years, then I'd build that bunker now.
Edit: I'll state it another way: AI will just mean a larger share of problems are solved with computers. It will be more important than ever to know how to harness this power.
I will put it another way, I think AI will be better at solving those problems than the vast majority of people will.
It won't be tomorrow but over a medium time frame I expect the vast majority of jobs will be automated away by AI then robotics.
The combination will just be better and cheaper than people for 90% + of jobs.
What problems will it solve?
For education, this suggests a stronger emphasis on interdisciplinary study. Liberal education.
I think that basic level REAL courses in the sciences are part of a liberal education. The scientists of 17th and 18th centuries certainly thought so. Even though I got my PHD in history, I would feel naked without my basic understanding of biology, chemistry. and physics.
That's the sense of liberal education I have in mind: across the disciplines, and not just the humanities.
The humanities and sciences are the same here, both focusing on general knowledge and skills, rather than more career-oriented majors that try to teach you skills for a specific job.
Where do you live?
I argue here that university research and undergraduate research should become more important in higher education. https://bobm858524.substack.com/p/the-work-of-humans
This does sound horrible. It’s also unlikely. More likely is the code reviewer or maintainer (to stick to coding) is a specialist who is needed when the AI messes up. I’m fairly dubious that coding has been replaced fully really - only the companies selling the AI are saying that, with the results we see from Claude recently.
Programmers aren’t, except for trivial apps, writing prompts like “build me an app to show a dog barking”, but instead getting AI to write what they could write themselves, with strong architectural inputs and frameworks and system knowledge.
More like pilots and auto pilots.
People that are good at spotting errors are almost always those that are VERY familiar with the subject (IE specialists).
A generalist doesn't have enough knowledge to spot the error because they aren't familiar enough with the material.
I've been at my company a while I have an sense of how the number should look. If I went to a totally new company it would take me years to regain that sense. And if I did an entirely new job say working in QA in the plant, it would take me even longer.
Yep. Gotta be able to know when the computer is giving you the wrong answer! (My father worked in circuit design, and he's run into several cases in which the commercial simulation software had been using incorrect models...)
I dont see any mention of the service industry here, what do you expect to happen to stockers and fast food workers? Or the trades? Is half the American economy just not worth a mention?
When people are talking about job replacement with regards to the present AI systems, it’s Office work. If you are using your legs, and body to work you are safe, at least from the first order effects.
I have to pile on with the other commenters here -- your framing of the shift of the work software developers do continues to be dramatically overstated. I work at a huge software development company, we are pushing HARD to use AI in a maximally-effective way, and we are NOT EVEN CLOSE to becoming "mainly checkers and maintainers of code written by AIs." We are trying to become this! It isn't working yet! We all acknowledge that it MAY become the case in the future, but framing it as a shift that occurred IN THE PAST -- which you've been doing for weeks! -- is just factually wrong, and it makes the rest of your analysis uncharacteristically unhelpful.
Others have pointed out that "writing code" is NOT the main thing software engineers do, which I agree with. A big part of our job description is finding ways to tame or understand the complexity of intrinsically complex systems. In the past, as software has gotten more complex, it has tended to raise the demand for software developers. So far, code written by AI is often helpful, but not costless -- it generates complexity that we then have to maintain. In theory, AI lets us generate complexity faster than ever before! So, while it's possible that AI will simply take over software developer jobs once it gets smart enough, it's also possible that, even if AI manages to take over the task of writing code itself, the demand for software developers may skyrocket.
I've long been an AI doomer, expecting software development jobs to be first on the chopping block, but lately I'm starting to view the "AI causes demand for software developers to accelerate" scenario to be much more likely than I previously thought.
If AI eventually does make software development a lot more productive, there are going to be a lot of people using custom software that wouldn't have been able to afford it before. So as long as hiring a team that includes humans and AI is better than doing all the AI wrangling yourself, there are still going to be lots of jobs for software developers.
The salaryman analogy is interesting but the institutional gap is the elephant in the room. Japan's system rested on lifetime employment guarantees (30-35% of workforce), seniority wages, enterprise unions, and government retention subsidies. American median tenure is 3.9 years vs Japan's 12.5. The "no-hire no-fire" economy isn't salaryman culture taking root; 76% of employers cite difficulty finding replacements as the reason they're hoarding (Indeed, 2024). That's pandemic trauma, not a new labor model.
Also, the Humlum and Vestergaard study is excellent but Denmark spends 20x more per capita on active labor market policies than the US. Citing Danish outcomes as a forecast for American workers is a stretch.
Wrote a longer response with FRED charts here: https://noahpinionot.substack.com/p/salarymen-without-the-safety-net
Interesting take... I am not sure this is the right take on AI, and its impact. I would encourage you to look at three concepts for inspiration around these topics.
1) Computer Aided Engineering: EDA(electronics), Mcad, etc... These are highly sophisticated systems which have introduced a huge amount of automation. Inside many of these systems are various algorithms which in the modern language would be called AI. Without exception, the introduction of these capabilities actually grew the employment market...why? it allowed a much broader class of engineers to be useful.
2) Liability vs Best Efforts: Most interesting economic transactions have attached liability. For AI to truly take over interesting jobs, we need a view of liability around AI. This is pretty much an unsolved problem today ...partly because the legal system is built around the concept of "reasonable behavior given a totality of the facts." ... how is "reasonable" defined... what normal humans do....
3) The edge of knowledge: AI is particularly good at capturing existing knowledge (in an admittedly inconsistent fashion). However, all the interesting work is actually on the edge and it is very hard to see AI replacing work at this edge. The huge jumps in productivity come from AI aided understanding for humans of the current status.
“2) Liability vs Best Efforts: Most interesting economic transactions have attached liability. For AI to truly take over interesting jobs, we need a view of liability around AI. This is pretty much an unsolved problem today ...partly because the legal system is built around the concept of "reasonable behavior given a totality of the facts." ... how is "reasonable" defined... what normal humans do....”
If AI has a lower error or damage rate than humans, what’s the problem with liability?
1) Liability attaches to a person... someone you can sue ... it might be the AI companies or the AV companies...doubt they would sign up for this...
2) demonstrating a damage rate is lower is not very easy... .especially for complex problem sets ... why ? the "judge" here are other humans (jury/judge)... humans understand other humans, but don't understand artificial humans.
3) AI does not have any formal model of behaviour .. it is inherently probabilistic in nature.
“2) demonstrating a damage rate is lower is not very easy... .especially for complex problem sets ... why ? the "judge" here are other humans (jury/judge)... humans understand other humans, but don't understand artificial humans.”
Uber will know exactly how much safer AI drivers are than humans. So will hospital systems.
Well... not really... you need to know this information at the "facts and circumstances level." High level statistics are not that helpful. Also, a number of the interesting situations are based on intent. How does the AV communicate its intent and how does it accept intent of third parties (even animals). As an aside, this is starting to get tested as Tesla has lost a couple of suits. Waymo is closest with geographic approach... but this will also get tested in the courts at the first inevitable accident. At least the liability point is clear in that situation.
There are also those of us who will protect our jobs because we can. Bars, in particular, will preserve jobs in fields like Law and Medicine.
I would have thought bars would have preferred to preserve jobs in fields like bar tending
A lawyer, a doctor and an AI walked into a bar, but the AI ducked so only the first two smashed their heads.
Oh but AI *has* affected software engineer jobs: Hiring for entry level sw jobs is way down: My son's cohort (graduated 2025) who stayed in CSci are really struggling to find jobs. This means that there's no "bench" to grow through the ranks and become a senior/experience sw engineer. This, obviously, spells trouble for my profession (I'm a very senior sw eng/architect and I use AI tools).
The greatest advantages of the Japanese-style employment system—organized around non-specialist generalists who rotate through different roles on a regular basis—are that it becomes relatively easy for young people to find employment and that job security is enhanced. Most young people can find jobs immediately upon graduating from university or vocational school, and even when economic conditions deteriorate, unemployment rates do not rise sharply. On the other hand, as workers' specialization goes largely unrewarded and labor mobility declines significantly, the balance between labor and management shifts heavily in favor of employers. The notoriously workplace culture, which evokes the era of feudalism, is inseparable from the guarantee of lifetime employment.
I am still getting lots of inquiries from head hunters for controls engineers. There has even been a bit of a flurry in the last couple of days.
I managed projects for years and you always had budgets (people) and timelines as nearly fixed constraints. Scope was typically your variable. If AI can allow us to deliver more in the same time and same budget, then it is a win for everyone.
Also, hard working smart people who show up on time and aren’t distractions to others will always be able to find work. They always have. Maybe we encourage people to develop those traits. Seems like we encourage the opposite.