This is the fundamental issue to address in education, so thank you Amarda. @luisgranadosdc also very well expressed in your comment. I am a business school professor and programme designer and the debate I am having with my colleagues- especially those who are still active professionals and especially those who are younger and in tech native businesses: how do we teach in a way that students learn the necessary substrate knowledge and skills without making people use obsolete methods and tools.
My experience so far is that there are no easy answers. LLMs - used in almost any way in education - are more likely to damage fundamental learning than to enhance it, or even to allow real learning to occur unless we are teaching how to use LLMs to do things for you. But without the fundamental learning / substrate, learners have no criteria to correctly plan or judge the outputs.
I am beginning to meet people at Master's programme level who became extremely over-dependent on LLMs during their undergraduate studies. It is not that they have no substrate in particular areas of skills or knowledge, they have no substrate in their thinking. Unable to formulate appropriate questions to ask an LLM, for example. Unable to interpret insightful questions they are asked to answer. Unable to see glaring incoherence in their reasoning from one minute to the next.
GenAI is 99.9% (gotta have some hope) going to remain a part of our present and future even if it the majority of its use is low value, as now.
So thanks again for stating the issue clearly and offering potential approaches to resolving it. If we don't, we will very soon have generations arriving at adulthood who are largely dependent on these tools - not because they are lazy, but because they are incapable of thinking properly for themselves.
Thank you for sharing your experience, Antony. The redesign is difficult and will require folks that are both clear-eyed and courageous. It will be bumpy.
Bumpy indeed. I'll keep that, a nicer way of saying it that I have been. Best of luck with your work at George Mason. From the outside it looks like a very interesting role they have created and you have taken on. So much better to face GenAI/AI and its consequences head-on and transparently.
I just finished a two-semester Python course. I did pretty well, and I liked my teachers. But the whole time, it bothered me that SO much energy was being expended on preventing me from using the tools I would undoubtedly be using from Day One if I were to get a job in the field (or to use my newly attained knowledge as I intend to.) It’s like teaching someone to be a carpenter while banning use of a nail gun and electric screwdriver. I would prefer the capenter working on my house to have great proficiency with both.
I have been spending too much time memorizing exception types to think much about the question of how this could be done better. But I think the author's suggestions here are excellent. Suppose I had seen a longish question on my exam that said "Here are four code blocks approaching the problem of _________. Evaluate the efficacy of each, under various circumstances." My eyes would have glazed over, while I'm thinking "I'm going to have to strain my brain over this." Isn't that what employers want their new hires to be able to do?
Phasing all this in will be tricky. But I do agree that institutions that fail to get ahead of this curve are doing no one any good, least of all themselves.
Your surmise is completely correct: training in fundamentals is something that you’ll come back to at critical times. For example, there are a number of representations for numbers. Sometimes you may need to care which representation is in use, because you could be sending that format to a system with a different representation.
Exactly, Luis. Thank you for instantiating what I wrote with a very recent experience of yours. It will be tricky indeed, but I have confidence in smart folks coming together and making some hard decisions.
“ Computational thinking has assessment instruments that do not depend on the student writing every line of syntax herself.”
This is what I learned in high school in 1976. At that time, banks were taking bright tellers and giving them six months of COBOL instruction and making good programmers out of them. It was the same at the phone company – – anybody who worked at the phone company who showed the ability to put steps in order was given an aptitude test that did not have anything to do with programming. If they did well, they got a spot in programming school. In my high school we did flow charts for about two months. Could we make a program to add up 10 numbers? Could we make that program add up any number of numbers? Take a list of numbers, and spit out the average and the standard deviation?
The delightful woman who taught this class was the one who taught me geometry the year before. Toward the end of that year she started giving me much harder proofs to do, and said I was going to take her computer problem-solving class whether I wanted to or not!
Once we graduated from flowcharts, we hand wrote machine code on special coding forms, and simulated the execution at our desks on paper, filling in the boxes on the coding form for successive iterations through the loop. She called it a “register record“. She would mark it up and give it back to us if it had mistakes. Then we would do another register record, starting over.
When the program was provably correct, she would give us cards to punch by hand with a stylus, punching in the binary patterns for the op code and operand.
After doing three or four of those programs, that’s when she would give us access to the BASIC language time sharing system. By the time we were writing basic, we had enough “computational thinking“ to write with confidence I don’t remember anybody in my class doing much debugging by the time they went through that early process, they had the discipline to write code that was almost certain to work, unless they skipped a line while they were typing it in , or put a typo in the line number of “go to”.
Karpathy is right that the act of writing syntax is becoming negotiable, and pretending otherwise is silly. The individual skill shift is real.
The quieter problem the 'new skill' framing keeps dodging is headcount. If one engineer with AI can do the work of five, the company does not need five times the output. It needs fewer engineers. The productivity gain accrues to capital, not to the worker who diligently learned the new skill. You can master the tool that replaces you.
The other thing the 'learn this' genre underplays is timing. Telling a mid-career developer to retrain into AI-native engineering assumes a stable runway and a clear destination. Both are getting shorter. A six-month course cannot teach the years of judgment that actually survive automation, taste, architecture, knowing when not to ship.
Coding is not so much dying as compressing. The headcount implications of that compression are the bit nobody wants to put in a headline.
Not likely. Ask an LLM about Jevon's Paradox. Accountants used to spend hours every day managing spreadsheets by hand. But Visicalc/123/Excel did not reduce the number of accountants.
Jevons is the right mechanism to reach for, and induced demand is real. But it's a tendency with conditions, not a law. Employment grows only if demand expands faster than output-per-worker rises. That happened with spreadsheets because there was a huge backlog of financial modelling too expensive to do by hand. Whether there's a comparable reservoir of unbuilt software waiting to be unlocked is an empirical question. Naming the paradox doesn't answer it.
And the accountant example does less work than it looks. The spreadsheet displaced a task inside the role. Accountants still did the audit, the sign-off, the client judgement, the regulatory work, so the tool ate the manual recalculation, not the job. The profession grew. But the manual-ledger bookkeeper didn't ride that growth by standing still. They climbed into advisory work or they didn't make it. The aggregate number went up and the specific job went away, both at once. That's the part the Jevons reply skates over: even in the case picked to disprove displacement, the displaced cohort still had to move. 'More accountants' is cold comfort to the bookkeeper who couldn't make the jump in time. Which is the timing point, not a separate one.
I've spent the past year on the research for a book on exactly this question, a few hundred sources in, and one thing does look genuinely different this time. Spreadsheet-induced demand for analysis still needed a human pointing the spreadsheet and reading the output. The open question is whether software demand unlocked by cheap code gets served by more developers or by more agents. If it's the latter, the induced demand doesn't loop back into human headcount the way it did for accounting. That's the argument worth having. Jevons doesn't end it.
Ok, although I think your paragraph on headcount fails to capture the nuance. The firm need fewer engineers to do the same old thing--but it will want to do much more engineering. And whether that is done in the firm or outsourced is entirely unclear.
But, I absolutely would bet that (to borrow your phrasing) there is a huge backlog of software engineering that has been too expensive to do up to now. I'd grant that the tasks and skills of a "software engineering job" (if it even exists as such) will change as radically as those in accounting did, and strongly away from "coding." Looks to me like a huge opportunity for new entrants in the field.
Yes, I had this exact conversation a few weeks ago. There is a way to revitalize/resurrect software engineering but it will be further away from coding and closer to engineering.
That's the through-line of your piece, really. The substrate stops being the gatekeeper, so the field can finally teach the judgement it always said it wanted to.
The bit I'd sit next to it: the academy gets to teach judgement at the same moment the workplace stops growing it. Junior work was where the rest of that judgement used to get built, the part no course reaches. So the on-ramp reopens at the university and narrows at the firm. Whether those two move in step is, I think, the thing that decides how this lands for the people in the middle.
Agreed on most of this. Demand for engineering goes up, the role shifts hard away from coding, and in-house versus outsourced is genuinely unclear. Though the outsourcing question doesn't move the headcount maths much: work going to a smaller AI-leveraged shop is still fewer chairs in total, just in a different building.
The backlog I'd probably bet on with you. But 'the backlog is real' and 'the backlog gets served by humans' are two different claims, and the second doesn't follow from the first. That's still the developers-or-agents question, and it's the one that decides whether the opportunity exists at all.
Where I'd actually push back is 'opportunity for new entrants.' They're the worst-positioned group here, for the exact reason you gave. If the role moves towards judgement, taste, architecture, knowing when not to ship, none of that comes from a course. It comes from years of doing the junior work. And the junior work is what's compressing. So you take away the rung people used to climb to acquire the judgement the senior role now demands. The established engineer who already has it is fine. The new entrant has lost the ladder. The backlog can be real and still flow almost entirely to people who are already up it.
Fabulous and timely. Very interesting references. I used the book The Art of Computer Programming by Davidson and colleagues to try to understand computational thinking .
There’s a classic you may enjoy: Gerald Weinberg’s “ the psychology of computer programming“. Although the tech is Stone Age, many of the thinking skills are the same: questioning assumptions, formulating hypotheses for systems that don’t work, devising experiments to test the hypotheses, estimating when you will truly be done, etc. if you have the mind of a historian, you will enjoy what one of the brightest people in the 1960s was thinking!
This is the fundamental issue to address in education, so thank you Amarda. @luisgranadosdc also very well expressed in your comment. I am a business school professor and programme designer and the debate I am having with my colleagues- especially those who are still active professionals and especially those who are younger and in tech native businesses: how do we teach in a way that students learn the necessary substrate knowledge and skills without making people use obsolete methods and tools.
My experience so far is that there are no easy answers. LLMs - used in almost any way in education - are more likely to damage fundamental learning than to enhance it, or even to allow real learning to occur unless we are teaching how to use LLMs to do things for you. But without the fundamental learning / substrate, learners have no criteria to correctly plan or judge the outputs.
I am beginning to meet people at Master's programme level who became extremely over-dependent on LLMs during their undergraduate studies. It is not that they have no substrate in particular areas of skills or knowledge, they have no substrate in their thinking. Unable to formulate appropriate questions to ask an LLM, for example. Unable to interpret insightful questions they are asked to answer. Unable to see glaring incoherence in their reasoning from one minute to the next.
GenAI is 99.9% (gotta have some hope) going to remain a part of our present and future even if it the majority of its use is low value, as now.
So thanks again for stating the issue clearly and offering potential approaches to resolving it. If we don't, we will very soon have generations arriving at adulthood who are largely dependent on these tools - not because they are lazy, but because they are incapable of thinking properly for themselves.
Thank you for sharing your experience, Antony. The redesign is difficult and will require folks that are both clear-eyed and courageous. It will be bumpy.
Bumpy indeed. I'll keep that, a nicer way of saying it that I have been. Best of luck with your work at George Mason. From the outside it looks like a very interesting role they have created and you have taken on. So much better to face GenAI/AI and its consequences head-on and transparently.
I just finished a two-semester Python course. I did pretty well, and I liked my teachers. But the whole time, it bothered me that SO much energy was being expended on preventing me from using the tools I would undoubtedly be using from Day One if I were to get a job in the field (or to use my newly attained knowledge as I intend to.) It’s like teaching someone to be a carpenter while banning use of a nail gun and electric screwdriver. I would prefer the capenter working on my house to have great proficiency with both.
I have been spending too much time memorizing exception types to think much about the question of how this could be done better. But I think the author's suggestions here are excellent. Suppose I had seen a longish question on my exam that said "Here are four code blocks approaching the problem of _________. Evaluate the efficacy of each, under various circumstances." My eyes would have glazed over, while I'm thinking "I'm going to have to strain my brain over this." Isn't that what employers want their new hires to be able to do?
Phasing all this in will be tricky. But I do agree that institutions that fail to get ahead of this curve are doing no one any good, least of all themselves.
Your surmise is completely correct: training in fundamentals is something that you’ll come back to at critical times. For example, there are a number of representations for numbers. Sometimes you may need to care which representation is in use, because you could be sending that format to a system with a different representation.
Exactly, Luis. Thank you for instantiating what I wrote with a very recent experience of yours. It will be tricky indeed, but I have confidence in smart folks coming together and making some hard decisions.
“ Computational thinking has assessment instruments that do not depend on the student writing every line of syntax herself.”
This is what I learned in high school in 1976. At that time, banks were taking bright tellers and giving them six months of COBOL instruction and making good programmers out of them. It was the same at the phone company – – anybody who worked at the phone company who showed the ability to put steps in order was given an aptitude test that did not have anything to do with programming. If they did well, they got a spot in programming school. In my high school we did flow charts for about two months. Could we make a program to add up 10 numbers? Could we make that program add up any number of numbers? Take a list of numbers, and spit out the average and the standard deviation?
The delightful woman who taught this class was the one who taught me geometry the year before. Toward the end of that year she started giving me much harder proofs to do, and said I was going to take her computer problem-solving class whether I wanted to or not!
Once we graduated from flowcharts, we hand wrote machine code on special coding forms, and simulated the execution at our desks on paper, filling in the boxes on the coding form for successive iterations through the loop. She called it a “register record“. She would mark it up and give it back to us if it had mistakes. Then we would do another register record, starting over.
When the program was provably correct, she would give us cards to punch by hand with a stylus, punching in the binary patterns for the op code and operand.
After doing three or four of those programs, that’s when she would give us access to the BASIC language time sharing system. By the time we were writing basic, we had enough “computational thinking“ to write with confidence I don’t remember anybody in my class doing much debugging by the time they went through that early process, they had the discipline to write code that was almost certain to work, unless they skipped a line while they were typing it in , or put a typo in the line number of “go to”.
Karpathy is right that the act of writing syntax is becoming negotiable, and pretending otherwise is silly. The individual skill shift is real.
The quieter problem the 'new skill' framing keeps dodging is headcount. If one engineer with AI can do the work of five, the company does not need five times the output. It needs fewer engineers. The productivity gain accrues to capital, not to the worker who diligently learned the new skill. You can master the tool that replaces you.
The other thing the 'learn this' genre underplays is timing. Telling a mid-career developer to retrain into AI-native engineering assumes a stable runway and a clear destination. Both are getting shorter. A six-month course cannot teach the years of judgment that actually survive automation, taste, architecture, knowing when not to ship.
Coding is not so much dying as compressing. The headcount implications of that compression are the bit nobody wants to put in a headline.
Fewer chairs is fewer chairs.
Not likely. Ask an LLM about Jevon's Paradox. Accountants used to spend hours every day managing spreadsheets by hand. But Visicalc/123/Excel did not reduce the number of accountants.
Jevons is the right mechanism to reach for, and induced demand is real. But it's a tendency with conditions, not a law. Employment grows only if demand expands faster than output-per-worker rises. That happened with spreadsheets because there was a huge backlog of financial modelling too expensive to do by hand. Whether there's a comparable reservoir of unbuilt software waiting to be unlocked is an empirical question. Naming the paradox doesn't answer it.
And the accountant example does less work than it looks. The spreadsheet displaced a task inside the role. Accountants still did the audit, the sign-off, the client judgement, the regulatory work, so the tool ate the manual recalculation, not the job. The profession grew. But the manual-ledger bookkeeper didn't ride that growth by standing still. They climbed into advisory work or they didn't make it. The aggregate number went up and the specific job went away, both at once. That's the part the Jevons reply skates over: even in the case picked to disprove displacement, the displaced cohort still had to move. 'More accountants' is cold comfort to the bookkeeper who couldn't make the jump in time. Which is the timing point, not a separate one.
I've spent the past year on the research for a book on exactly this question, a few hundred sources in, and one thing does look genuinely different this time. Spreadsheet-induced demand for analysis still needed a human pointing the spreadsheet and reading the output. The open question is whether software demand unlocked by cheap code gets served by more developers or by more agents. If it's the latter, the induced demand doesn't loop back into human headcount the way it did for accounting. That's the argument worth having. Jevons doesn't end it.
Ok, although I think your paragraph on headcount fails to capture the nuance. The firm need fewer engineers to do the same old thing--but it will want to do much more engineering. And whether that is done in the firm or outsourced is entirely unclear.
But, I absolutely would bet that (to borrow your phrasing) there is a huge backlog of software engineering that has been too expensive to do up to now. I'd grant that the tasks and skills of a "software engineering job" (if it even exists as such) will change as radically as those in accounting did, and strongly away from "coding." Looks to me like a huge opportunity for new entrants in the field.
Yes, I had this exact conversation a few weeks ago. There is a way to revitalize/resurrect software engineering but it will be further away from coding and closer to engineering.
That's the through-line of your piece, really. The substrate stops being the gatekeeper, so the field can finally teach the judgement it always said it wanted to.
The bit I'd sit next to it: the academy gets to teach judgement at the same moment the workplace stops growing it. Junior work was where the rest of that judgement used to get built, the part no course reaches. So the on-ramp reopens at the university and narrows at the firm. Whether those two move in step is, I think, the thing that decides how this lands for the people in the middle.
Agreed on most of this. Demand for engineering goes up, the role shifts hard away from coding, and in-house versus outsourced is genuinely unclear. Though the outsourcing question doesn't move the headcount maths much: work going to a smaller AI-leveraged shop is still fewer chairs in total, just in a different building.
The backlog I'd probably bet on with you. But 'the backlog is real' and 'the backlog gets served by humans' are two different claims, and the second doesn't follow from the first. That's still the developers-or-agents question, and it's the one that decides whether the opportunity exists at all.
Where I'd actually push back is 'opportunity for new entrants.' They're the worst-positioned group here, for the exact reason you gave. If the role moves towards judgement, taste, architecture, knowing when not to ship, none of that comes from a course. It comes from years of doing the junior work. And the junior work is what's compressing. So you take away the rung people used to climb to acquire the judgement the senior role now demands. The established engineer who already has it is fine. The new entrant has lost the ladder. The backlog can be real and still flow almost entirely to people who are already up it.
Fabulous and timely. Very interesting references. I used the book The Art of Computer Programming by Davidson and colleagues to try to understand computational thinking .
There’s a classic you may enjoy: Gerald Weinberg’s “ the psychology of computer programming“. Although the tech is Stone Age, many of the thinking skills are the same: questioning assumptions, formulating hypotheses for systems that don’t work, devising experiments to test the hypotheses, estimating when you will truly be done, etc. if you have the mind of a historian, you will enjoy what one of the brightest people in the 1960s was thinking!