> Code is a beautiful form of creative expression, as rich as literature or music
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.
Most programming is that, but most music and literature are probably uninspired junks as well. But there are many beautiful algorithms (such as the ones in Knuths books) that are more beautiful than any music for me personally.
Finally my turn to shine! I learned how to play guitar for like a decade before I got into programming. I also write a lot and have some small novels I have finished.
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".
I kinda like the music comparison because it's so rich with sociological analogues. You have the gear snobs who can't stop buying more premium gear but never sit down and write anything. The kids who pick up a copy of Garageband and put together hits with their natural talent, sense of taste and and interesting story to tell. Soundtrack and videogame composers who have hybrid instincts of session musicians and architects. Avant garde musicians who you're never fully sure of whether they're playing a joke you're in on (or on you) and that's kinda the point. Music critics who have never played or written music a day in their life and yet end up becoming arbiters (or more accurately, delegates) of taste. Fandom stans and ringleaders who absorb it as an identity and run extraordinarily well organized cults with an iron fist.
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.
As a professional programmer entering the final third of an enjoyable career, I would now place "learning to code" in the same category as "making a living as a poet." As in, it's truly enjoyable art and some people appreciate it, but you'd better plan for a day job.
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.
For now, I can imagine a not too distant future where this is largely untrue.
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.
> LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs
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.
The non-determinism is one of the relevant features of this layer of abstraction! And one can learn to validate that the translation is being done properly. Some of the tools you have include writing extremely detailed specs, generating visualizations of the internals of the tool, or (perhaps) reading the code, though that becomes less feasible with volume.
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."
LLMs will still blithely ignore the specs and steering documents, apologize profusely for doing so after the fact, and tell you "I'll do better next time" which they might do once or twice. But after the context is cleared or a new session opened, the Dixie Flatline gets reset and it doesn't remember it screwed up, or that you told it not to.
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.
This is only true if it plateaus. What you are saying is “I don’t think LLMs will achieve superintelligence.” Which is a fine opinion to have, but it’s an opinion.
Consider the difference between capabilities when gpt3 was released and now - the "increasingly babysitting" is exactly right.
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.
Right, but if things progress as they promised, it will require far fewer people to do the same work, which means the industry already has all the people it so need for at least a couple decades. That’s what happened with tool and die guys when offshoring kicked off, and now they’re scrambling to get apprentices because the last of the OG ones are retiring. There were decades that pretty much nobody (relative to prior eras) got trained for that work.
You're making an assumption on what AI lab have promised? The same AI labs that have made a strategy out of lying for hype? Thats crazy man, regardless of whether anything else you're saying is valid.
You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been?
> You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been?
How many horse farriers have you met? How many coopers, blacksmiths, or shoemakers?
Not a fair comparison. Unlike shoemaker or coopers who do ONE thing, a SWE doesnt do just one thing.. atleast in general. I churned through basic, logo, c, c++, java, c#, python, go and now agents. The executable building on single machine died when distributed systems came in. It again evolved when cloud took over. We have been reinventing our work every few years. Every job change requires us to learn new skills.
How much did a horse farrier have to learn if they switched their employers?
I think there’s potentially a future where software engineers learn how to “babysit” models instead of the details of programming. Kind of how software engineering students for the last decade at least haven’t learnt a great deal of assembly or cpu architecture. Maybe you had a unit on CPUs but it’s not central to the course.
I’m not saying I like that future, but I can imagine it.
Yeah. I’ve been saying that for a while (and switched fields entirely.) People were getting hung up on the idea that an LLM could not truly replace a developer, and that’s true, but it doesn’t matter. For the job market to be severely impacted, you just need to reduce the number of people required to do the parts of the job that LLMs suck at, and that only requires increased efficiency for existing developers. Even if your average developer is a measly 30% more efficient, that might create 20% less demand for developers, which would have a giant impact on demand, which would have a giant impact on wages for those still employed.
> Even if your average developer is a measly 30% more efficient, that might create 20% less demand for developers
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.
> As a professional programmer entering the final third of an enjoyable career, I would now place "learning to code" in the same category as "making a living as a poet." As in, it's truly enjoyable art and some people appreciate it, but you'd better plan for a day job.
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.
> I would now place "learning to code" in the same category as "making a living as a poet." As in, it's truly enjoyable art and some people appreciate it, but you'd better plan for a day job.
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.
> Code is a beautiful form of creative expression, as rich as literature or music
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.
Not the person you're replying to, but I'd agree with them, and think house painting would be basically identical to building a bridge.
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).
Creating a program is more like the interior designer choosing paints or the engineer designing a bridge in some CAD software. The actual painting/building has been automated for ages and they are the compiler/computer combo.
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).
There is programming that is like that - it is not all programming, and I strongly suspect not the the majority by dollars invested into developers - even it is less of an interior designer choosing paints and more of an entire designer designing an entire interior.
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.
I've done a lot of match aggregation in dota2 using stratz / opendota. It's a lot of fun and it will definitely make you a better programmer given how much data there is.
Anecdotally, the people who I know who were not particularly good developers pre-llms still manage to produce bad code even using flagship models now.
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.
100% this. I observe this all the time. LLMs can be a force multiplier but those who don’t ask the right questions or understand the nuance still produce bad code, it’s just amplified. I don’t think any of the current models can avoid that, especially when it’s based on data it’s been fed, which is historically human generated.
I was quite worried about having to code when I interviewed recently. A two- or three- year layoff is a lot. Turns out that it didn't really make much difference! After a few weeks of warm-up exercises, coding was as natural as ever and turned out to be the easier part of technical assessments. I guess a couple decades of muscle memory is hard to lose.
Now then, back to using Fable. It is doing work that previously took me months in an evening.
I have always found similarities between programming and filmmaking.
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.
If you can’t code, you’ll be like a mathematician or statistician who can’t do basic math because they have tools that can do it for them. We don’t tell kids they don’t need to know how to do basic math operations because they have Excel and calculators.
Please correct me if I'm wrong, but aren't AI agents replacing the coding mostly being done on the outer layers of development? I mean, end user applications, apps, dashboards, business applications? On this "outer crust" people can maybe tolerate things with 99% accuracy, or bloated code. A vibe coded app can be argued to be "good enough." (Even then, look at the disaster that Microsoft apps have become post AI adoption.)
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?
There are ways to do it correctly. You just end up spending a lot of time conceptualizing and refining abstractions.
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.
I'm a junior and I probably spend a similar amount of time thinking vs reviewing. I rarely write code unless it's about <5 lines.
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 can have several ideas in mind, and have a concrete implementation made for each, making it easier to compare alternatives.
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.
Somebody talking about researchers, I think it was Hamming, once said that there are people who just can't think without a bench full of equipment in front of them. So if you want to get good work out of them, your job as a lab director, then, is to give them that bench full of equipment and let 'em cook. I think the same thing is true of some programmers, and I think I might be one of them. We could sit around and conceptualize till we're blue in the face, but without an editor open with code in it we can't think through our conceptualizations effectively, and a chatbot is no substitute. A chatbot just adds another layer of abstraction to a process that's already thick with them, like a wall that got repainted so many times it's covered in a few millimeters of stratified goo that partially melts in the summer, and what's worse its behavior cannot be meaningfully predicted or reasoned about. Everything you think you know about how to correctly get results out of an LLM is either guesswork or folklore, and may be obsolete by Labor Day.
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.
This type of comment retroactively assigns human written code a quality which it has never had. "No one wants to build on code that is 99% accurate or bloated" - my friend have you ever used Windows??
Of course Windows is garbage. But this is the sort of defeatist argument that always shows up among both AI optimists and places where corruption is rampant. Corruption and incorrectness is established as an inescapable baseline, and then greater systematic corruption (like LLMs producing constantly sub-par code) is justified.
While there are certainly more examples than either of us can count of shitty half-baked codebases claiming quality code has never existed is pretty wild. With humans it's at least something to be aspired to and occasionally even accomplished.
Aren't the things in your second paragraph only a small fraction of coding jobs?
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.
Are they? Most B2C tooling are free or nearly free or serve a very small market. The heavyweights are all B2B and I don’t believe they can tolerate the inefficiency for long.
> On this "outer crust" people can tolerate things 99% accuracy, or bloated code
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
Learning to code = understanding a problem, breaking it down into small, manageable pieces, putting all the pieces back together. Debugging. Iterating towards better metrics, etc.
All these are amazingly valuable skills/mindsets that can be highly portable to other "problem solving" domains.
Yeah I mean, if you don't know how to code, you just know how to prompt, you have no idea how to tell what's a good solution vs what isn't. The best you can do is have the model figure it out for you. You also have no idea how to design a good API, or how to break up a system into modules, etc.
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.
Lately I wonder if people should learn philosophy because it teaches you how to reason, what to reason about, and why. Just like with programming, you’re constantly forced to interrogate your impressions and reconsider what you took for granted. It’s an extremely useful exercise. Nothing will show you how wrong you constantly are like testing the logic of a program you wrote.
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.
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".
The most compelling reason to learn to code is exactly the same reason to read lots of books (fiction or otherwise). It exercises your brain. A brain that can easily sort, parse, and understand basic logic and control flow is more resistant to propaganda and influence. Which is the same benefit a lot of reading does, but for different avenues of thinking (more worldviews exposed to -> more critical thought of each of those views -> more critical thinking in general).
But that in itself also isn't compelling to lots of people, why should they care about "exercising your brain"? I do it because it's fun, probably the most common reason I do anything, or because it feels nice. But probably exercising my brain for me is fun and makes me feel nice, this isn't true for everyone, sadly.
Besides the reward of a more capable brain, the reduced effects/risks of dementia, the contrarian need to argue, the altruistic desire to help neighbors with difficult problems, the selfish urge to daydream... yeah, there are people for whom none of those are motivating factors.
> 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 [...]
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.
i think video games are to abstract to connect them to learning to think like a computer.
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.
The problem is that coding was sold as the pancea. If you were fired, "learn to code", if you're in prison, "learn to code", if you're in kindergarden, "learn to code".
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.
And that worked for maybe, what... half a decade? But eventually the Illuminators all transitioned to being Arcane Scribes, the cost of spells plummeted due to increased supply, and in the end only Wizards who had invested in Arcane Sanctums had anything to show for it 50 years later.
I think they're being silly, but it's a pretty common trope: comparing the weird, sometimes highly idiosyncratic syntactical constructs of programming languages to a series of magical incantations.
Lev Grossman wrote an entire book that hinged on this idea of melding magic with technology.
I have actually thought something similar but more in terms of divination. There’s some people who might compare LLMs to something like Tarot or automatic writing (think Ouija) because there’s a sense of randomness with LLMs too.
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.
Knowing someone's true name in the wizarding world meant to hold power over them. Though if you know someone's account name on Reddit or only fans or Snapchat, it's kind of the same thing.
It's worth learning to harvest with a scythe because it's cheap, good exercise, and has no mechanical parts to fail.
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".
Here's an alternative farming analogy: knowing how to program(and adjacent skills) is like understanding plant biology, climate, food demand, supply chains etc.
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.
Learning anything is worthwhile. Just because you code in Python it doesn't mean that knowing how instructions are processed in a CPU or the memory is managed is useless.
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
> 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"
I’m a web dev but always curious. Which is why I figured out what was breaking the time calls (we’d switched from CENTOS to Red Hat which returned totally different v8 time strings from the underlying calls). You don’t need to know what’s going on underneath the mountain of code you rely on until suddenly you do.
Exactly. I'm not saying that you should go back to code in assembly. But, come on, you can surely dedicate 30 minutes of your time to read how a CPU works... Just have curiosity would be my advice
At the expense of what, though? That's 30 minutes not spent learning about the business, or talking to customers, or to your kids. Or watching the World
Cup. Or reading Hacker News.
If you want to fully understand / contribute to / fully leverage the most powerful technology humanity has ever devised (AI), you must learn to read and write code. That’s the only reason anyone should need.
To create things via AI without being able to comprehend the output is to trust completely in the agent(s). Operating that way is more optimistic than experience has taught me to be.
The very fact we need to discuss that it's a sign that we lost and slop has won. Learning to code it's a journey that never ends, after almost 15+ years I feel like I still learn and that my code sucks, if I delegate everything to the slot machine I feel like I'm being retro actively turned into a junior, thanks but no thanks. I'll still use LLMs and Agents the best I can but coding is mine
I have this mindset too. I use LLMs too, but strictly as a helper. nothing goes in my code that I don't understand, or that doesn't follow the style of the rest of the project. It's a great research tool, although I can already feel my documentation reading skills diminishing slightly.
Thin post with more ads for their company than arguments.
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.
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.
With everyday bringing new developments in the world, a lot of skills that used to be in demand are being replaced with new age tools. This has been the case in many industries and its evolving. The last 6 years have reshaped the world as we know it very aggressively and the best we can do is flow and adapt to the new times
I mean, iteration and interaction builds your understanding which verifies and validates what you built. Relying on agents without formal validation is like saying a tree fell in the forest
Perhaps coding will be optional rather than a requirement for the most in-demand tech jobs. But for roles including AI Engineer, someone who knows how to code will have a premium over an AI Engineer that only vibes.
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.
Even if you want to use an LLM (which you probably shouldn't, but it's your life), you best know how to program if you want to make anything good. They suck at programming, and need a human to guide them.
Learning itself still has value.
Just because my arms and legs are shorter than others doesn't mean I should cut them off.
Just because an LLM can do most things better than I can doesn't mean I should stop learning.
Also, whether the LLM's knowledge is suited for humans is a separate issue.
This isn't limited to coding—all fields of study are ultimately humanity's process of understanding the world, and it's participating in that historical process that has been passed down from our ancestors.
I think the idea that something has or doesn't have value just because an LLM exists is purely a capitalistic perspective. I sincerely question whether something that doesn't generate money in a capitalist sense is truly without value
Note that every single person telling you to not learn to code currently knows how to code, often at an expert level, and is therefore capable of reasoning about 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.
I don't entirely disagree, but I absolutely hate these blog posts. They always miss the point entirely. It's been enough years of this that it seems like a deliberate muddying of waters.
"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.
Only because the US government is putting a bar on how intelligent of a model they are willing to allow and it seems like we are already at it. China won’t stop though so it’s going to be months to a year before we get models where learning to code makes no sense.
For a little while. But we’re already at the point where a layperson can feed back errors into the LLM well enough for most apps for it to fix the problems and those are the errors it misses, it gets most of them on its own.
Learning to code will never not make sense. It will never make sense to me why software engineers are so eager to make the skills they've developed over years obsolete.
I think pieces like this miss the forest for the trees. Software is the bottleneck for a vast array of economic activities. Attention from intelligent people is most of the rest. Both are mostly-commoditized already and are just waiting around for technological diffusion and the closing of the RSI loop. Unless you're doing so as a hobby with no expectation of returns, I'm not sure what, if anything, is worth learning anymore.
You build without knowing by delegating to a system that extrapolates what it knows about you and what you want, and is able to execute on that to deliver faster, better, and more completely than you ever could. You'll live as a ball of intent and values, observing in wonder as everything you desire springs up around you before you know you want it. You could choose not to live like this of course, but it would be like driving a DIY go-kart on the highway - you'll fall behind and get in others' way, and the rest of society will treat you accordingly.
I assume you don't ascribe to the thought that friction leads to growth. In this future of complete frictionless existence wont humanity stagnate? In this world of no effort, nothing has meaning.
More or less, yeah. I'm not a proponent of it, I just think there's enough inertia in that direction of short-term vastly-superintelligent AI. Maybe we can figure out how to become subordinate components of a machine like that, but I think that's the best we can reasonably hope for.
A few years from now after the AI hype has cooled down (it has already started), where will be two types of people:
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.
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 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? :)
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.
I am sure I could make a decent industrial PLC tech, same shit, different tools.
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.
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.
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.
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?
I’m not saying I like that future, but I can imagine it.
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.
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.
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.
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.
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.
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.
Now then, back to using Fable. It is doing work that previously took me months in an evening.
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.
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?
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 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.
I think conceptualizing and refining the abstraction is the essence of the beauty of the craft and progress.
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.
Talk about driving people off a cliff
2026: "the median developer is a craftsman whose work is being replaced by AI slop"
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.
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
All these are amazingly valuable skills/mindsets that can be highly portable to other "problem solving" domains.
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.
https://youtu.be/BRTOlPdyPYU
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.
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
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.
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.
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.
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.
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.
Real Estate, it always boils down to real estate.
Lev Grossman wrote an entire book that hinged on this idea of melding magic with technology.
https://en.wikipedia.org/wiki/Daemon_(novel)
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.
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.
must be a Raku coder -Ofun
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"
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.
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.
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.
Only two jobs? You'll need a better reason than that.
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.
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.
Um no, you've gone too far.
"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.
That's the optimistic case, anyway.
that's the barrier to entry
But a competitor to Anthropic at the product level? With open source models, very little barrier.
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.