Learning to code is still worthwhile
stevekrouse.com
stevekrouse.com
I think this is overstating it and makes me wonder how familiar the author is with literature and music. Most programming is closer to plumbing. We come in, gripe about the guy who did the prior job, and solve a puzzle with some unique constraints. The reason LLMs are good at coding is because with coding we want boring, banal code.
I am sure I could make a decent industrial PLC tech, same shit, different tools.
You can probably find correlates here with coding and AI any which way you look. Coding is so rich that you can use it to do artistic, creative pursuits because it really is an interactive and world building medium if you want it to be. And it can also be a practical, reliable machine that helps you get useful business objectives done. And anywhere in between!
Perhaps the author is indexing on the former because there's an intrinsic value to that, and intrinsic values seem to be quite drowned out by the noise of extrinsic values in this media supercycle.
But I don't think it'll be that way forever. Whenever things get too noisy, people have a way of seeking peace and quiet.
The thing is that programming was one of those rare crafts/arts, where you could have your cake and eat it too: Since you were writing all the code by hand, and since that process takes a fair bit of time anyway, you might as well write good code at no extra cost (which is where the artisanship comes in). Now the difference between good code and cheap code that does the same thing is the difference between 2 months of hand-crafting code and micromanaging LLMs versus an afternoon of vibing, and that is much less defensible from a business point-of-view.
I feel your analogy is right but it can extend to anything. Plumbing is a job, programing is a job and yes its basically the same process if you see at as a job.
But what OP means is the skill/ability of programming rather than the job of it. Think of a professional musician that plays cruise ships, their job is also like plumbing in the way you describe, which would mean its also just like programming in terms of a job.
Yet the skill/art to me has a lot to do with the art of music or the art of writing. All of them can be channels for creativity while forcing you to do very hard work on the mechanics. I cannot say the same about the art of plumbing where you do have the mechanics and need to work on it but it doesn't require cerativity or allow you to channel it.
I am currently working on a blog trying to explain concurrency and parallelism using the song "Free Bird".
Ok, now I'm hooked :)
What's your blog? I don't suppose it has an RSS feed, hopefully? :)
I'd like to read that blog post.
The business side of programming puts food on the table for tens of millions of people.
I can vouch for that statement. I have written poetry. And often searching for a right word or expression is often akin to searching for an elegant abstraction or architecture when programming.
I was enjoying writing a poem in just the same way I was enjoying writing a program.
It is not a value judgement. Art can be bad or bland and code can be a work of genius. But the moon lander or a handmade watch are beautiful because they actually work. It can’t really be compared to music.
Now, is the demoscene "high art"? For the most part, perhaps not. But some of it definitely is.
I think you're confusing the common use of a medium with expressiveness. Many uses of ordinary language also aren't that interesting, but we need to consider the full space of possibilities.
I'd say the two are as connected as Rembrandt and painting prefab homes' walls are.
Most programmers are in denial about this and think their job is a delicate flower full of undiscovered mathematical gems. Meanwhile all they do is transforming data from and to databases, but refuse to see the general pattern so they'll create the same system over and over and over again in just about any variation possible.
I never had plumbers come in and complain about the previous guy. They either changed something, or fixed something I caused. And whatever they did, it worked for years and decades, perfectly, even when I didn't treat it as well as I should have.
And to make things boring and banal is still an "art", for lack of a better word. You don't want your functions named like in minified code, you don't want ThisIsTheEntryPointOfTheProgram() either, and what do to instead can be subject of endless deliberation and discussion. We take all these "small" things for granted because we take churn and bloat for granted, and don't care, in a way plumbers would never. They don't have a new pipe material every week they install everywhere now, until the next fad that finally fixes everything for sure. They generally build stuff that lasts longer than people, so that profession is on a whole other planet IMO.
True, it's the electricians who do this =)
We're paid to solve a problem that the customer has.
You are a very optimistic person. IMHO, claims #1 & #2 will happen, but #3 won't. People, especially business leaders, will just adjust their expectations downwards (or be forced to do so).
Just think of how often some "new and improved version" drops some important feature you used without providing a good replacement? We'll get more of that. If the codebase is unmaintainable, they'll just regenerate a new pile of garbage that will change stuff randomly and call it an improvement.
That slopfest ended with a new executive dogma of "hire only the best programmers" as so many of those projects were humiliating disasters which had to be junked. I do not think that was coincidental.
Executive fashions can remain remarkably consistent and irrational for years as they try to make reality conform to their expectations before doing a complete 180.
Outsourcing to India never ended. The Indian Service companies kept growing over last two decades.
Now many Western companies are setting up Global Capability Centers driving strategic innovation, IT, and R&D.
So the work going to India has moved up from "outsourcing to the cheapest programmers in india" to "we will hire the best talent in India directly and set up our company's base there".
To give some credit to your point, moving some low efficiency work to India since early 2000s freed up resources for many Tech companies to invest their best programmers into more profitable ventures.
But with the GCCs being set up in India, even a lot of the innovation and R&D work is now moving to India.
If that's any indication to your parallels with companies investing in AI. Something similar can happen with AI - where low end work moves to AI first, and the over time as the Technology develops more challenging and innovative tasks move to AI.
Most production systems dont have such a high tolerance for embarrassing bugs. Startups can completely fail if they have too low quality. Established businesses can lose to competition if orders don't arrive, compliance has bugs etc etc. So quality has to be good enough, that's a constraint that wont go away.
Funnily enough AI is the one discovering all those glaring issues now, and everyone is overwhelmed with getting it fixed. You could allow AI to attempt fixing it, but even though all of it was human written it is still hard to review, and even locally spin up or test because no one any more knows the true business requirements as people have rotated etc, so it's a nightmare.
The code on the first sight looks good, but what could be a simple config map, is spread out abstraction that is impossible to understand. Think just massive amounts of boilerplate to make a proxy call to another microservice etc.
Oh no it's not. You just haven't seen where it goes when barely supervised by someone new to React. I've seen a level of spaghetti code with excessive useEffect and useMemo, reinventing two-way binding, I didn't even know was possible in React.
Spent months detangling weeks of AI-generated work earlier this year. Eventually got to the point we were actually fixing bugs by accident that previously neither they nor the tool could figure out.
But also I see people constantly baking in more and more stuff into a single component and more and more useEffects and convoluted stuff, without no one ever daring or deciding to split up the file, because it doesn't seem like part of the ticket. And it never will.
At least to AI I can set guardrails and rules/logic to follow, to keep files small, but many people working on many random things one small ticket a time, where no one is there doing the refactor, things will also get crazy.
At least I feel I can use AI with guardrails to keep the codebase in a better shape than 100s of people working on the same monorepo.
Humans? Also maybe, but I always suspect the humans actually don’t know a better way. The LLM does, just that pathway wasn’t activated.
Made by an actual human, before OpenAI was a household name.
I'm 99% sure any SOTA LLM could've refactored that in a day to something actually manageable. It could've done it on a weekend.
No. It's just screwed up priorities. Those "glaring issues" were always a problem for the people maintaining those apps. It's just that no one gave a shit about those people or cared to make their job easier or them more successful (see the challenge or prioritizing tech debt remediation), but those same people are some reason willing to whatever it takes to make the machines successful.
There's a lot of contempt for humanity in the business world. It probably stems for a contempt for labor and a fetishization of capital.
Name them. In my 16 years in the business I've never come across any; I've always worked under leaders who did not care about code quality in the slightest and just looked at outcomes, and when outcomes stopped happening as a result of poor code quality were always unable to connect those dots (or wilfully looked the other way).
I think embedded software for highly-regulated medical devices or whatever is just not enough to take in all the "AI-refugees" who are now seeking meaningful work that has been taken away from them. The pessimistic side of me expects that it's probably not true in the first place that these industries work any different than what I'm used to. And even the optimistic side of me has to admit that the laws of supply and demand imply that, in those few niches where it still matters, there are enough people out there desperate to do that kind of work right now, that it will be done for free and won't present a real earning opportunity.
Learning to code is a must. You need to know what is possible or easy to know how much you can ask.
What will be less important is to keep your sword sharp.
I notice that if code less for some time I do more one-off errors, copy/paste mistakes etc. With llm keeping the coding skill warm is less important but I cannot imagine doing my work - even with Fable if I didn't know how to do it without him
I disagree with this part. The bar of skill you need to write complex now is much lower now, so a new person might very quickly learn just enough to be able to build cool products.
Maybe not operating systems, but useful web apps, browser plugins, productivity tools, programs that solve business needs outside of IT, ETC.
Edit; but if you mean learning to code with the purpose of finding a job as a programmer then I'm more willing to agree.
Of course you need to know how to code to code. We just no longer need to write code the same, or even reason about the same problems. It's awesome.
Panasonic still makes laptops, enterprise use only, very expensive.
How is that relevant? Well, directly.
Compilers for existing languages is if anything one of the lower bars for LLMs, given existing implementations or test suites provides an oracle to test against.
It's not lack of ability that is stopping this, but that it's a space where very few people are experimenting and willing to burn enough tokens.
I did exactly that using an LLM. It may not count as independent depending on how strict you are about that, but then LLMs don't do anything independently.
I wrote a small sample program and expected output, then told the LLM to write a compiler for it in C using LLVM. I subsequently told it to extend the language until it could be used for its own compiler, and rewrite the compiler in the new language. It did.
I don't think that contradicts your point about creativity. A compiler is probably a more mechanical task than a CRUD app is. There's a non-negotiable definition of done and correct.
Designing a language is a creative task of course, and I wouldn't expect an LLM to come up with a novel or ergonomic design on its own. In fact subsequent experiments have shown me that LLMs will consistently ignore terrible ergonomics in a language, never seeking opportunities to add abstraction or beauty.
I want a different argument before I believe that LLMs are doing “out of training dataspace creativity” (extrapolation not interpolation).
Being serious. "Think about what this might mean..." Finding unexpected links between various ideas and background knowledge. What we call a "novel idea" is virtually always the repurposing of an idea/concept in a new context. A system that maps arbitrary inputs into abstraction spaces in which similarities are discoverable, such as say a deep learning system, is perfect for this.
You could set the goalposts such that it wasn't novel enough to count, but for a short time I had code running in a language that nobody had ever known. Getting it from that point to a language that's ergonomic to use, teaches something about computing, or both is a longer journey, and certainly not one an LLM could take on its own.
An LLM won't come up with an interesting CRUD app on its own either. Parts of that process are pretty mechanical, but we had skeletons and templates before we had LLMs.
Your scenario would only unfold if frontier labs decided not to compete on capabilities. It sounds unlikely.
> large corpus of commercially available source code
Like garbling up GitHub? Currently, people put hand-crafted code there to earn "street cred". Will people continue to do that, if AIs regurgitate their code without giving credit? Will people continue to bother with learning to code, when AI has reconfigured the economy to make this skill a worthless commodity?
We still have COBOL programmers for a reason. The economic incentive to keep the skill never left.
====
>linkregister: LLMs are trained with a large corpus of commercially available source code. However...
This concedes your point. Hence the following "however". It's bizarre to argue against it.
Also: Saying that "learn to code" has been reduced from a meme about a surefire ticket to economic security to the equivalent of glassblower, is not really refuting what, in broad strokes, the original point actually was; is it?
The concern for code quality has become increasingly unfounded. I have noticed over the last year or so that you can still tell when a codebase is 100% AI generated, but not because it is poorly written or disorganized, but that it is now dramatically better than any human would have written.
Meanwhile more people will build and use software than ever before, and all of these "everything is going to hell" diatribes will be laughably overblown.
Senior people who already know how to code are doing OKish for now, from the data I've seen, but the job is increasingly babysitting models like they were junior contributors.
Not wrong. Probably.
I'm reminded of an old friend from long ago. She was an early music major at Harvard, and graduated with a MFA. She was very good. She read and wrote Latin and Greek, could compose and play music using medieval notations, and published a book on early needlepoint.
She never obtained an academic appointment. She never found a job that needed those skills. She died alone a few years ago.
That may be the fate of many programmers.
This sounds to me like a life well lived!
It will be fewer and fewer people with, probably, deeper and deeper knowledge (and job security and compensation to boot).
Poet is a bad comparison. But something like low-level semiconductor physics or assembly is closer to the mark.
How many horse farriers have you met? How many coopers, blacksmiths, or shoemakers?
How much did a horse farrier have to learn if they switched their employers?
Cobblers design, make and repair shoes of various kinds, boots for various purposes, slippers and moccasins with leather, cloth, rubber, and many kinds of threads using punches, knives, various machines, glues…
How much does a developer need to learn about their core competency when switching employers? Not even close to as much as a machinist. It’s not a useful comparison.
That is precisely the point. They still exist, but it is a far less common occupation than it once was.
So there will always be a point where people aren't willing to hire more software developers because there are enough already.
> Has it ever been?
Well… yes? So very many industries shrank, even disappeared in practical terms, because efficiency, automation and technological improvements. Industrial revolution? Calculators? Computerized accounting? I mean the list is giant.
I’m not saying I like that future, but I can imagine it.
LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs?
At some point you stopped needing to understand the layer down because the layer you were on became so good. Yes there are always corner cases, but for the vast majority of developers/engineers out there, staying at your layer was enough to make a career out of it once your layer hit a certain maturity.
The what is the semantic mapping between <some lang> and LLMs?
I know the semantic mapping between maching code and assembly (some light weight syntax manipulation and macros). I know the one between assembly and C (the C abstract machine, which is mostly about the stack and whatever call/ret instructions pair). I know the one between C and something like python (not so much different than the one between C and assembly in mechanism).
Please talk about how you go from A LLM prompt to a piece of code in Python and guarantee the intent remains unchanged.
Basically it turns out that code is full of incidental details and what you really want is to verify the important parts, while receiving a guarantee that the vast tail of incidentals is handled "reasonably."
This happened to a coworker of mine. Generally the response from one-shotted devs is a shrug of the shoulders and "wellp, them's the breaks! As long as it looks sensible from 10,000 feet up it's still a huge productivity win." But the devil, as they say, is in the details.
In other words, superintelligence often referred to as AGI might either be months away or just VC-Money induced cult-speak many fall victim to.
It doesn’t matter because the only certainty is that it’s not here now, and neither tomorrow etc.
For coding you still need to be in control if you want a good result.
nothing prevents people from committing their prompts. I've started seeing prompts being committed into repos, or at least as part of the commit message.
In any case, if in the future there's a prompt specific language, it would be committed. I dont think we've reached there yet, but i dont doubt this is on the path to the future.
You mean, like a ... programming language? Honestly I can't tell these days what is satire and what isn't.
People keep trying to make that analogy, but it doesn't really work because LLMs aren't deterministic like compilers and assemblers.
They’re not reproducible, nor are they even reliable right now.
Regardless, you can make them deterministic by turning the temperature down to zero. Just nobody likes doing that for whatever reason. I guess it ruins some sort of illusion people seem to like.
But it is a requirement for them to be an "abstraction just like" assemblers or compilers, which is what was being claimed.
I work at a certain level, like Ruby code. That's what I write, debug and maintain. I don't really care about the internals of the interpreter or about the source code of Linux, because these layers are taken care of, they're reliable and they're being developed by competent people. I [think I] know what Ruby code should look like in order to remain [reasonably] fast, maintainable and reliable, and it's my job to build a product out of that kind of code. If I keep writing code like that, I know for sure that I'll be able to keep building the product, because the layers underneath are deterministic. It's like the certificate chain of trust, but with "surely these people are not idiots". And that's simply not the case with LLMs.
Not only can the LLM be a massive idiot, but also an unpredictable one. I can try to warn it, steer it, police it or review as much as you ask me to, but ultimately you're asking me to delegate my job and my responsibilities to an intermediate whose reasoning I don't understand, who has no loyalty, no sense of pride, no sense of ethics, can't be taught and can't be fired.
(Which is pretty much what determinism would get us, but in these conversations way too many people seem not to understand what determinism is, so describing it in terms of actions the developer takes might work better?)
I just don't see that, not least of all because natural language is inherently ambiguous, whereas all the other rungs in your latter ("machine code -> assembly -> C/JVM -> some lang") are completely unambiguous by design. Consider "I saw the man with the binoculars". Does that mean "I used binoculars to look at the man", or "The man I looked at was holding binoculars"? This is the kind of inherent ambiguity that Lojban was invented to mitigate. Maybe some day we'll write "natural" language prompts in Lojban that can be unambiguously translated by an LLM, but that sounds a lot like just using a "some lang".
Knowing how to code (and more generally software engineering and other roles in software teams) is definitely still extremely useful, but is rapidly becoming less vital as a human-provided skill as models and harnesses greedily hoover up the knowledge margin.
I mean it might. But I wouldn't rule out Jevon's paradox where the increased efficiency increases demand.
Build more roads, congestion gets worse. Make developers more efficient, demand for developers increases. I wouldn't be surprised if demand for bespoke software goes up.
Learning to code is not merely learning a syntax and some tooling. It’s best described in the SICP and HTDP books, as a mindset of formalizing a process enough that a dumb machine could do it. Then by building abstractions towers, we have better symbols and semantics to notate the formal aspect.
It seems that a lot of management no longer wants to provide workflows tooling to their users. Instead they want to create a wish box where those workflows would materialize somehow.
Where is the data? There is no data but a lot of vibes, from the data I have seen
Contra: I'm reading digital circuits and introductory FPGA programming books this summer - fullstack development for the robotics dominated future here I come ;) Granted some EE classes in your old major will help. But modern digital circuits and embedded hardware space also have a lot of similarity to your muscle memory as a software developer.
I think having solid knowledge/understanding of good architecture and general practices is still crucial, and it's easy to forget that the foundational knowledge and instinct you take for granted now actually took a lot of time and effort to learn when you were less experienced.
To a degree, it looks like LLMs help them overcome the blank page anxiety and help them with the grunt work of, well, actually writing code, which actually contains a lot of technical nuances to keep track of. But once that's down, I'm having very good discussions with them on what makes good, maintainable and sustainable code bases.
It's almost like the old writing advice my Mark Twain: “Writing is easy. All you have to do is cross out the wrong words.” It's easier to dislike a part of something existing and fix that, than trying to create the perfect thing at once.
Something I'm trying to do right now is to build something and avoid using LLMs to write any code. I still use it to consult. I'm writing a Dota2 tournament match aggregator in Elixir that takes tournament streams and chronologically orders them in a format that makes it easier to watch them sequentially since I find YouTube hard to use for ingesting series of videos.
I'm building it because... I like programming. I like making things. I find that LLMs are making me intellectually lazy and making things with them feels unfulfilling. I want to build. It's human to want to build.
Anything a human feels is human, regardless if it's to build or to not build :) Some people prefer some ways of building, others in other ways, it's all fine. I think lots of people forget that programming is a heavily creative endeavor in the end.
If I wanted to be slightly controversial, I'd argue building a program is more like painting a painting than building a bridge, for better and worse.
I'm a house painter, and while the work is... It's just relentless work and staring all day.
It's the end results of making something just, better, with the simple acts of reputation and giving a shit about it.
Just wondering where house painter falls in your scale, I'd hunch.
The difference this comparison is capturing in my opinion is that of thinking up something new, compared to arranging things in a well known/already defined configuration. We know how to build bridges, we just have to do it (maybe including some calculations and site surveys, yes, but novel solutions are rightfully shunned). Similarly painting a house.
Developing software is practically definitionally creating a novel thing. If we wanted the same software over again we could literally copy and paste the existing executable (and we do that all the time, it's just not called developing software or enough work to be a job, since we have machines that are excellent at arranging the electrical charge in the pre-defined manner).
The actually-a-job* software equivalent of painting a house or building a bridge would be weaving a program into core rope memory: https://en.wikipedia.org/wiki/Core_rope_memory
* Not a job you can get anymore.
People who are new to the scene may find "browsing catalog"/"configuring models" tedious, but that's how you develop the intuition of what works and what not. After a while, you can shortcut most of the tediousness with those heuristics. You know enough blocks that it's just choosing the right one to fit the solution and you do not have to research them and understand them at the same time (where most of the beginners' time is dedicated to).
Once you get away from the very trivial side of programming, yes you are standing on the shoulders of giants, but the design decisions are in fact truly novel un-forced choices. Ask two people to make a "note taking app for university students" and you'll get two very differently shaped apps.
And basically this is the problem I see in LLMs: they robbed me of these moments of enjoying the art of programming itself.
You are still free to enjoy it in your free time, just like I enjoy drawing or guitar playing in my free time. The loss we have experienced is the luxury of doing at work something we enjoy for its own sake.
But people are still staying away from LLMs on the critical compilers, frameworks, tools and libraries that people need to really rely on. No one wants to build on code that is 99% accurate or bloated. No one wants to use an AI coded web browser. To really build good building materials, you need to code it and know what you're doing. Where is anybody even getting close to phasing out coding in those critical areas?
2026: "the median developer is a craftsman whose work is being replaced by AI slop"
To me the issue is more that conceptualizing requires a certain state of mind. Before llms it was 10% hard thinking 90% implementing. Implementation was actually sort of a reward, it felt so good just being in the zone and fleshing out ideas.
Post llms I find myself walking up and down quite a lot, only doing the thinking. Now it's more like 40% thinking 60% reviewing plans/code. I haven't experienced flow state since. The thinking is fun but exhausting, the reviewing is just kind of annoying, especially as llms get into these weird failure modes. Before I could look at a bad piece of code and instantly tell what the author was thinking and why the thing doesn't work. Now I need to be a lot more careful because there is little code smell, but a lot of badly chosen abstractions.
Just exhausting...
I think conceptualizing and refining the abstraction is the essence of the beauty of the craft and progress.
Talk about driving people off a cliff
The mega-rich clowns firing everyone and then hiring back just those few that they realize they actually needed to keep after-the-fact are actually driving themselves right off that same cliff along with everyone else, and they don't even realize it. I bet money all this "AI" nonsense don't end up leadin' to the "Rich Guy Utopia" they think they're workin' toward. It's much more likely gonna just lead to a shittier world for everyone on Earth, rich and mega-ultra-totally-too-rich folk included. Wait'll the "AI bubble" bursts and see how much fun they have losin' zillions while pretty much everyone else lands in the "poor house" and comes lookin' to them for retribution. I suspect the guillotine is makin' a comeback sometime in the future.
I find the instantaneous thinking easier now. I can have several ideas in mind, and have a concrete implementation made for each, making it easier to compare alternatives. Although, since each problem is alone easier to think about, I do end up handling a greater number of problems. But I expect that my total volume of thinking is likely the same as before.
Where I do certainly feel more tired is when I try to solve too many problems in parallel. If I try to do that, I end up constently dropping context. So I generally try to finish a big chunk of something before switching (usually that means getting it ready for another code-review cycle).
I do miss writing code myself. It's certainly satisfying. It's just significantly slower in most cases. I try to do it in my free time.
I would ask what exactly are you comparing. I don't think I've ever wrote 2 versions of code to compare between each.
I've written exploratory code. A few lines to quickly inspect the behavior of module/function because it's undocumented. If something needs tuning, I surface the parameter in the interface, hook it to an harness to plot and manually tune.
I've also written alternative implementation of some feature, that later was abandoned.
But I've never written multiple versions of the same feature at the same time. I either model it (algorithm) or sketch it (interfaces or some other flow). It's way easier to interate with those than some demo/prototype code. The latter is when we settled on a solution and wants to fine tune it.
This also partially explains why I'm fond of Lisp. Paul Graham once said that while Lisp is a great language to work in, its real value comes as a language for thinking in.
Sorry what people would tolerate? Go look around and ask people, friends and family. They all hate slow bloated software, it costs us dunno how much in time and productivity. With the advent of LLMs it only got worse not better
If we end up with those being the kind of jobs you have to get to make a living as a programmer we could end up with programming a lot like sports.
You can enjoy playing basketball, say, as an amateur, and you can play more seriously in high school and college, but if you want to make a living playing basketball you need to be good enough to make the NBA.
Probably not, because they *don’t exist because learning basic math is necessary to learn higher level math*. Whether or not we have calculators to do basic math is irrelevant if you want to become a mathematician.
I’d argue that “whether or not the average dev will be writing any code by hand in 5 years” is irrelevant to whether or not one should learn to code *if they want to master designing and building complex software* using whatever method they will be using.
All that said, people still learn and do manual math at all levels in order to advance the field even though calculators and python notebooks exist.
I think people get too wrapped up in LLMs being the entirety of the future when the LLMs themselves are entirely a product of the past. An LLM is less a thinking machine than a lossy JPEG for language and to an extent, knowledge represented in language. As such, if you want to expand the field and move into the future you aren't going to rely solely on an algorithm that reverts to the mean.
Take for instance most CRUD apps. They're all doing basically the same stuff just with variations on interface/schema. And that's a huge chunk of all professional software development. We're already at the point where you can describe said schema/interface and get a pretty good implementation of it, and things will likely continue to only get better. I think the job-apocalypse is unlikely, but I also think it's unlikely that 'manual coding' will be anywhere near as significant a part of the economy in the future as it is today.
If we're smart about this, maybe it means we get to do novel work a little more frequently. That said, I fear that a lot of people don't look at every single LLM output and think "Eh it's workable but it doesn't spark joy" and anyone who doesn't think that is likely going to be seeing their QOL decreasing. At that point your time might be better spent learning how to make Molotovs.
These things were still indispensable on my path to being a mathematician though, they just ceased to be relevant as abstraction increased.
On the other hand, if I were to hire you to perform long division I would have complete confidence in you turning in your first calculation within an hour given your research background. So I would definitely say you can do long division.
If software were a purely mechanistic task like long division then I'd have confidence in anyone being able to turn out working code within an hour too. But we can't just keep turning out new programs every time we want to change them. Even with LLMs this is prohibitively expensive. So software is really about being able to build things and maintain them over time which requires a much deeper understanding. Long division is like snakes and ladders. Software is like chess.
All these are amazingly valuable skills/mindsets that can be highly portable to other "problem solving" domains.
It’s a bit like learning to program, but without a compiler as the referee or the domain constraints. Maybe that’s where we should put more energy if learning to think is the goal, though I don’t know what could replace the purely logical and verifiable qualities of programming. That isn’t so readily available with philosophy, for better or worse.
We do need people to practice thinking and self-interrogation far more than we do today.
I think a lot of people are turning to AI for this, which can be dangerous if they haven’t already developed these critical thinking skills.
The issue is probably that many managers can't really tell the difference between a good programmer and a vibe-coder. The vibe coder ships a lot of PRs. Maybe they themselves ship some vibe-coded PRs. They hate the idea that programmers might know better than them.
If the best we've got for convincing people to learn to code is that it's like math notation (the most hated part of math for the uninitiated), or pretty like a violin (useless for a new grad), then coding is in serious trouble.
IMO a better argument is it helps you "think like a computer". But if you wanted to learn that there are many video games I'd recommend mastering instead of learning to code. For most people "learn to code" is like telling programmers to "learn asm".
(I've been coding ~30 years)
I just sort of assume people don't want to be stupid and ignorant, but maybe I'm wrong
the most useful thing i learned about computers is to create logic gates by hand. nothing gave me a deeper insight into how a computer works than that. programming is the next step up. you can skip all the layers in between because you can extrapolate them. no need to learn assembler, but it may be worth reading about it, just to get an idea.
understanding the layers from logic gates, to assembly, to programming, to games and now AI is kind of like reading about the OSI model to understand networking. it's one layer of abstraction on top of another.
learning programming is worthwhile because it is the highest layer of abstraction that is shared by everything above it. despite there being hundreds of programming languages, the concepts are all the same. once you understand programming through learning one language you can apply that understanding to almost all other languages. on the other hand there are tens of thousands of games in hundreds of types. not to mention all the other applications. the tree of variation explodes at that level.
That's funny. I've told a mathy friend that I've sometimes wondered if I could have grown up without the whole, "... except I suck at math", and I think that's why.
I don't struggle with the problem solving. I've watched people reinvent chunks of "difficult" math in code without realizing or caring that they've done it.
I've started to think that math might actually be awful on purpose.
This is such a good way to put it.
I could learn asm maybe in a college course. But no other incentive.
No one wanted to read asm. Now no one wants to read thru code.
Everyone in this thread is failing to sell the pen lol
To elaborate, if coding is like art, it's the worst art there is. It's far closer to something like legos and the satisfaction you get from completing a noteworthy build. Maybe that's the writer's point - yes it's still worthwhile, in a purely hobbyist sort of way.
I find the "coding helps math" argument to be similarly weak. Yes, it certainly helps with algebra, but overall I would argue the coding flavor of math largely helps more coding type of math. It's a strange type of math with loops and rules and conditionals that wouldn't be mainstream if software wasn't so mainstream to begin with. When you pull back the covers, the argument sounds more circular than something with true meat on the bones.
Now then, back to using Fable. It is doing work that previously took me months in an evening.
Even in this article, it's talking about how it's a good way to learn math and formal thinking. Yea, as an application. If you want to learn math, learn some basic fundamentals tied specifically to math, and then come apply it to code.
Coding is like welding in that it's a useful skill, a craft unto itself, but also integral for modern day manufacturing that opens up a world of possibilities. You don't see welding being suggested as a form of excercise, or the ticket to being a multi-millionaire.
- Steve Jobs
That's what he wanted to say. If he really meant what he said, he'd took some effort to learn himself
Many pursuits are worthwhile, yet almost no one does most pursuits. Coding is going to become a niche activity like portrait painting or making toys. It’s fun but there’s far cheaper easier ways to get a superior product.
The issue isn't whether it's worth learning something in a personal development sense, it's whether it's worth going into massive student loan debt to pursue a career path that was once seen as a ticket to a comfy office job. LLMs probably won't replace top performing software engineers. Will they replace the mediocre cog-in-the-machine coders that most people become? In 5 years? 10 years? 20 years? That's what has college students worrying about whether it's "worth it".
Code generators are like synthetic fertilizers and pesticides. Powerful stuff. Lots of production. Solved some big problems. But we're seeing new problems like soil depletion, runoff, decreased nutrition and knock-on effects like obesity.
To solve those problems will take lots of people with the right skills, not people ignorantly using the fertilizers and pesticides according to the profit driven manufacturers instructions.
If you end up down this route you’ll gain an appreciation for a branch of mathematics that has spent most of its history maligned by the wider community.
I too finally started grokking trigonometry and calculus in high school thanks much due to programming.
I don’t think it’s the best entry point for mathematics though. Us programmers tend to bias its effect on our learning and appreciation. For most people programming is tedious, cryptic, and frustrating. It doesn’t aid understanding mathematics if you can’t even use it.
Maths is beautiful on its own. And so is programming.
I think it’s still worthwhile because for all that these systems can do it still takes an experienced human to drive them. Any positive results are due to a human understanding the training data, the system, and importantly the output. You can’t one-shot a production grade C compiler or OS with these tools and never will be able to without over fitting the model. You need to know what a production grade C compiler requires in order to generate one using tools like this.
So keep learning. Mainly because it suits you, benefits you, and you like doing it.
Programmer being the director and the LLM being the entire apparatus upon which the film/software is built. This became evident to me while doing spec-driven development for a few of my projects where I specify the constraints upon which the software should be build, but have limited control over the performance similar to how a director has limited control over an actor's performance.
must be a Raku coder -Ofun
The layperson may be able to get ahold of a spellbook, but without Understanding it comes with high risk of turning your niece into a frog.
Whereas Wizards can cast increasingly powerful spells that build on each other, and make Art.
Both LLMs and divination methods also have the danger that someone could kind of drive themselves into madness with it. I don’t know too much about what how or why people can drive themselves crazy by chatting with an LLM, but with divination, I heard it can cause distress to ask the same questions about yourself many too frequently and also they ask about outcomes instead of methods.
You can also make LLMs agree with your own biases for some reason. For example, the people who use them to plan shady stuff.
Lev Grossman wrote an entire book that hinged on this idea of melding magic with technology.
Real Estate, it always boils down to real estate.
No, learning to code is still worthwhile because the AI cannot do useful abstraction well at all. If you don't know how to code, then you'll fail to build useful tools and useful reusable components that can (a) further accelerate your development speed, and (b) reduce token spend.
The excuse that we don't need to know how things work because AI will take care of it is going to bite a lot of people on their asses
Abstractions always led to this sort of behavior. So many of my web development peers screamed at me for being curious about what happens behind/further down then the stack we were learning, and this was decades ago. Seems it differs a lot per person, and what I've found out only later, depending on the situation; nowadays I'm comfortable with both approaches of "this is below the abstraction I actually care about" and "No, I have to dive deeper to actually understand properly the abstraction level I'm at right now"
and then i get a ticket a month later because the customer reported the feature isn't working. all while they proclaim how much they care about the customer.
i'm not just talking about one person. i feel as if there's an archetype of programmer that thinks like this.
But Earlier ...
>Or reading Hacker News.
Reading Hacker News is important to you?
While the peak of "learning to code" is surely in the past, there is resentment (at least in my personal experience) that's fueling the "anti-learning to code". Personally, it was very frustrating when learning how to program and I gave up many times before finally getting it. In general, when people cannot obtain competence in a certain area, they tend to disregard the importance of it to shield their ego. What's going on now in corporate are nasty politics because people who decided not to learn to code seek that the skill is disregarded entirely and even mocked.
Like learning a programming language, these activities stretch your mind in different ways.
And expose you to a different kind of beauty and a very different world.
In what sense?
From this perspective everything is worthwhile.
If "worthwhile" is relative to learning other skills then Classical Latin and Ancient Greek is near the bottom of that pile, and you probably know what which is why you cited them.
So then the question is where coding sits on that hierarchy, and if someone should learn to code vs acquiring other skills.
Personally I'd not advise anyone to learn to code today. It's not just that I'm not convinced of the utility of the skill going forward, but I also think it's very hard to actually learn to code competently for someone starting out today. I had the luxury of spending decades coding without LLMs professionally. No one learning today is realistically going to have the opportunity to compete with old school coders with decades of experience writing code by hand, even if we assume the skill will be worth anything.
It's obviously going to be worthwhile in some sense as almost all skills are worthwhile to some degree. But normally when we're talking about whether something is worthwhile to learn we're weighing up other competing things we could be learning instead. In that sense I think it's far more debatable about whether coding is worthwhile to learn.
I'm a Dilbert, yet today I asked AI why т (\tau) was being used by Huawei for their latest chip design and I specifically asked about the meaning in Mandarin.
The choice of the character “韬” (tāo) [1] has a deliberate second meaning: In classical Chinese, it means to conceal, or to sheathe a weapon. It implies keeping one's sharpest edges hidden while quietly building up inner strength. The naming directly references the famous Chinese idiom “韬光养晦” (tāo guāng yǎng huì), which means "to hide one's light and bide one's time."
[1] AFAIK tāo has nothing to do with the philosophical "tao" commonly referenced in English like Tao of Pooh. Different characters and completely different meanings. See https://technode.com/2026/07/06/huawei-mate-90-series-report...
Is it learning the syntax of a programming language? Is it learning CS fundamentals? Is it learning OS fundamentals? Is it learning common tools and libraries? Is it learning programming paradigms? Is it learning how to read and debug code? Is it learning Java boilerplate? Is it learning an esoteric sequence of keystrokes to perform an edit in vim?
That last one I think has definitely been superceded by LLMs, and I say this as an ed user.
I'm glad I'm a programmer and not just a coder. Just like Hemingway was a writer and not just a stenographer or typist.
Hopefully this will act as an effective filter against money people so they can keep going into law or w/e else they believe there is money
Only two jobs? You'll need a better reason than that.
But I hate waste, I hate dead code, I hate byzantine constructions and reinventing the wheel, and thus, most of the time, I keep a close eye on reasoning traces, frequently interrupt and steer the agent, and prefer to review the diffs as they are done in very small increments.
And everytime I am lazy, and try to just vibe code stuff, inevitably the old "all abstractions are leaky" adage rear its ugly head and I see myself reviewing a fucking giant delta and asking the agent: "but, why? when you could just..."
It is not possible that all those famous people are wrong and I am right. If my results when giving full autonomy to an agent are usually sub-optimal under my point of view, well, what if the problem is with MY point of view?
I am starting to get depressed thinking that maybe I have some personality flaw that will prevent me from truly reaping the fruits of this new age. At one side I think it is absurdly fantastic that I have this pair programmer so productive and with fantastic recall, but on the other side, I can't really relinquish control, I feel like it can't build a coherent architecture, I am still attached to the idea that engineering principles like low coupling, information hiding, high cohesion, low cyclomatic complexity, modularity, sound typing are important, and maybe I am just a fucking old curmudgeon that can't get up with the times.
As a software engineer I have been strict on making sure my code is elegant.
Vibe coding has switched me to product (and project) manager. Why would I care about what the code looks like? Does it work!? Does it do what I want? Does the app have the right UI and UX? These are my concerns now. I rarely look at the output code.
I learned to build such useless things as operating systems, databases and neural nets from scratch. That knowledge is foundational to my ability today to lead technical teams effectively, even in the era of copilot.
I would absolutely not hire an engineer who could not code. Don't get me wrong, I don't need code monkeys any more than I need assembly experts.
I need engineers who have experience building, tuning and maintaining complex software.
Someone who can't code can't crack open what they're working on and reason about it in a meaningful way. That's a huge liability. Also like... they just haven't ever done that work before. I don't even know if they're going to be capable of it.
I did some consulting a few years ago to convert startup codebases from Ruby on Rails to something that "would scale". Some of the projects I opened up were beyond comical. Millions and millions of dollars of investor capital burned torturing cut-rate junior engineers to get them to make a product-shaped solutions that could not be maintained, could not be scaled, could not be modified without everything breaking... entire teams of cheerful idiots who were replaceable with a single capable senior engineer who knew what they were actually doing. It was just tragic. Literal futures burned up as friction with reality, because neither the founder nor their engineers could write actual code to build clean, scalable systems without tripping over their own feet.
You're signing future engineers up to be those utterly lackluster juniors for the rest of their lives. Stay in school kids. Learn to code.
1. The ones who use AI for everything and therefore, are unable to think on their own, unable to make decisions on their own, and everything in between.
Looking for a job will be fun because their skills now depend on AI dependency rather than skill.
2. The ones who use AI as tool and therefore, are still able to do things on their own, make decisions on their own.
Looking for a job will be just another Tuesday in the office, and were are already seeing companies hiring them back to replace AI.
>Sell an expensive, recurring B2B service into your network, fulfill it with technical leverage, then productize it into software once you've done the same work five times.
Yeah, good fucking work, nobody's ever thought of that. It's obvious why it picked that though, every 3rd post on this forum and half of the rest of the internet is singing the praises of be-your-own-boss SaaS passive income and it turns out that if you convolve all of that into a black box this is what you're gonna get.
"Knowing how to code" has always been poorly defined and full of silly arguments. Nobody employs code monkeys. What matters more is that you understand how things work. There's zero progress on that with AI. LLMs might even be negative progress on education.
Respectfully disagree here. People have always hired code monkeys and arguably they will hire more of them as engineers become increasingly able to defer their judgment to LLMs. It might be true that the top level companies expect strong mental models of the code but in my experience many companies (especially startups) really just want the 0->1 ability and don’t care how you get there.
Um no, you've gone too far.
that's the barrier to entry
But a competitor to Anthropic at the product level? With open source models, very little barrier.
That's the optimistic case, anyway.