I think that, even among those who have had the ability to code since before LLMs, the skill of coding has been in atrophy, and will continue to be so over the next 10 or 20 years. Learning to code, over the same period of time, will not be worthwhile. At the end of that process, cracks in the system will start to show: Namely, we will have nothing but LLM-generated code to train future LLMs on, and codebases for production code will be so low in quality that they will be unintelligible to humans, and LLMs, too, will have trouble maintaining them. At that point, coding will become a valuable skill again. The practical question for someone planning out their career from todays' point of view, is that it's uncertain when that time will come, and these markets can and will stay irrational for longer than any single individual trying to resist them will be able to stay solvent.
It is a bit like in "Profession" by Isaac Asimov. We will still have the need for some people who will write code manually, fix the craft. We will need the "Feeble Minded" asylum that is actually a secret sanctuary for society's true creators. Because everyone else relies on generated code, they can only repeat what is already known. Only the people who learn the hard way through actual studying possess the creativity and intelligence required to invent new knowledge and create new educational tapes.
The reason LLMs seem powerful is that they can churn out the Nth variation of a CRUD app in minutes. But it’s hard to imagine they’ll ever independently develop a compiler for a truly novel programming language, for instance. They don’t have creativity. They are pattern generators.
> it’s hard to imagine they’ll ever independently develop a compiler for a truly novel programming language
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.
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.
At the time the LLM generated the compiler, just syntax. The semantics it generated were the subset of C that the C version of the compiler already used.
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.
I'd say that even if the task is "a compiler for an existing language" the empirical results are far from stellar, and indeed, border the terrain of comedy.
Claude has made my Ruby compiler pass 8k more rubyspecs tests over the last two weeks, and that includes solving crashing bugs in hours that I'd failed to fix for weeks in the past.
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.
Isn't "creativity" the result of a combination of patterns (usually from different contexts) that casually works? I bet LLMs/agents can do that (we can't know how far that can goes).
For me that creativity is very well expressed by the principle of abduction. With induction, generalise towards rules, or deduction, use rules on data, we have this combination of patterns via different contexts. I think abduction might not be possible via LLMs.
> ...and [1] codebases for production code will be so low in quality that they will be unintelligible to humans, and [2] LLMs, too, will have trouble maintaining them. [3] At that point, coding will become a valuable skill again.
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.
> 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.
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.
Having worked at a company with thousands of microservices, I feel like most of it is just a bunch of boilerplate riddled with tons of ridiculous business logic, security and otherwise bugs. It seems like people were historically more concerned about Java inheritance and spreading everything around different files and directory hierarchies, while ignoring common sense business requirements completely. With each service being on separate older version, many being very difficult to start up locally, I don't see how LLMs could do worse than that, and that is a profitable, working business.
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.
I swear I see far worse from humans for working businesses, and in much worse ways than just duplication of code. At least AI tends to be smarter about React intricacies even if it does create huge files. For my personal projects however I have straight token limits per file, whether it is backend or frontend so AI can't do that many lines of code. And I have specifically token limits so it would avoid hacking with formatting. And for React specifically I force it to put hooks in separate files and component files to be presentational only with max 1 hook usage.
> At least AI tends to be smarter about React intricacies even if it does create huge files.
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.
I feel like I've seen people frequently doing the mistake of keeping way too many things in state that could and should be computed, but instead they would useEffect to read to dependencies change to update the state. And frequent useEffect infinite loops. I guess it depends heavily on how you would set up the initial prompts I suppose, but yeah if someone is new to React, maybe AI will do that you are right.
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.
> 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.
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.
We've been on this merry go round before with the "outsourcing to the cheapest programmers in india" boom.
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.
Outsourcing never ended but it did happen in waves. Right after ZIRR ended but before the AI panic multiple companies started to layoff in developers in western countries and double down on outsourcing to India. During ZIRP they employed more people in the US/EU and less work was outsourced.
I have the last native Fujitsu laptop that is worthy of mention. I am a big fan. Fun story: about 5 years ago they decided to resume their laptop production, and the only practical way was to enroll old retired Japanese workers. I guess, the youth do not have the skill or/and do not want to bother. They made some batches, then I believe it ended.
Panasonic still makes laptops, enterprise use only, very expensive.
I think in order to be a productive programmer with Claude you still need to understand what you are doing.
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
To be clear: I don't envision a scenario where people who are completely unable to code will come out of nowhere, and make a career out of prompting claude to write software without ever learning to code. What I am saying is that the threshold of what constitutes "good enough" coding skill has shifted down, and those people who already knew how to code now have a certain multiplier on the outcomes they deliver. (this multiplier is high if you measure on low time horizons and gets lower, the longer the time horizons, but the latter doesn't matter in managers' minds). So there will, for a time, be a massive overhang of good-enough coding skill from "old stock", so to speak. For those who do not already know how to code, this make the proposition of learning to code right now uneconomical. If there is already a massive oversupply of grapes in the market, and you're trying to decide which crop to plant, then planting more grapes is economically probably a pretty poor decision. It would be better to plant things that are undersupplied.
> make the proposition of learning to code right now uneconomical
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.
One might argue that these people will not understand the code they write if they use LLMs. I would counter that with my observation that plenty didn’t understand the code they wrote before LLMs too.
LLMs are trained with a large corpus of commercially available source code. However, intentional training on individual skills such as medicine, finance, mathematics, and software engineering is conducted to the tune of a few billion dollars per year.
Your scenario would only unfold if frontier labs decided not to compete on capabilities. It sounds unlikely.
How will they hire experts from those professions on whose output to train on, if they destroy the skills currently extant in those professions? Maybe lawyers will still read contracts every once in a while. Certainly, programmers around me no longer bother with reading code. ...and you can make an argument that a similar effect will happen that is widely observed in language-learners: Namely, if you only ever use a language passively (to read/listen), you're not necessarily able to use it actively (to write/speak).
> 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?
Your argument assumes premises that are hardly certain. We use automobiles to travel, yet tens of thousands can still ride horses today. Hell, there are thousands of blacksmiths and glass blowers. If there's a several hundred million dollar market for programming language experts, this will provide sufficient incentive for some people to remain sharp.
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.
Actually, riding horses is a great example, and you happened to pick a domain within which I dabble: People are not capable of riding horses today at the level of skill of a nobleman from Renaissance Europe. People at the forefront of the riding arts today read manuscripts from Guérinière, second-guessing at the meaning of every last syllable, because many of those sources describe things that are unintelligible and unfathomable today that seem to have been quite commonplace. And this is despite even the centuries of continuity of government funding for institutions that have been dedicated to trying to prevent precisely this. (Namely the Spanish Riding School of Vienna and similar institutions in Lisbon and Jerez, the Cadre Noir, etc.)
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?
Similarly, I spent a few hours one day going down a rabbit hole of modern marble carvings, wondering if there were any hidden great masters of the art. I found that despite there being essentially limitless wealth and people compared to when the Pietà was made, there’s nobody making marble carvings like the masters did. Now there are some somewhat stylized marble carvings but in my opinion they pale in comparison to a masterwork marble statue. After all, why do that when you can just snap a photograph?
More like, "old developers will continue to denounce the diminishing code quality, and long for the old days of programming".
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.
>codebases for production code will be so low in quality that they will be unintelligible to humans, and LLMs, too, will have trouble maintaining them
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.
Part of the industry always seek humans able to code with deep understanding. AI is fast but always lacks depth, works better if you are able to pilot it with your knowledge. If that changes, learning code becomes useless. If you learn code with limited depth (nextjs bros), this is already useless.
> Part of the industry always seek humans able to code with deep understanding.
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.
Most AI-refugees where quality doesn't matter will embrace the slop, they will become slop experts, slop consultants. Learning to code become less relevant, except if you are looking for a work that really needs it and it will still be valuable, that won't be for everyone.
> 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 throwaway garbage, and if plumbing was treated remotely like that we'd be in deep shit, literally.
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.
I get your point, but I think that's a poor example. I've been around plenty of Plumbers, Mechanics, Contractors, and Electricians. You're almost guaranteed a comment or remark about the previous guy's work.
I didn't say it doesn't happen, but I for one never experienced it, I saw zero churn and posturing or kool-aid. I guess plumbing got more professional the more widespread and crucial it became, while software is just getting sloppier and more bloated.
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 actually think plumbing does require a bunch of creativity. Trying to add some fixture to an old house with out of spec walls and prior creative solutions can be a real challenge. And you can really appreciate the people who come up with an elegant solution that isn't "tear it out and redo it from scratch".
Yeah that also makes sense. I guess a better comment would have been to highlight the art/work aspects of any process. Like yeah, most jobs (even those that include creativite processes) will just become boring because jobs are standardized usually where you're going from point a to point b doing the same thing again and again. But that doesn't mean there is no art/creativity to the process itself but rather we restrict it intentionally in fixed jobs to standardize and this causes the split between thinking of code as a creative or non-creative pursuit.
You can find my blog here: https://decodingvibes.com/. It does have an RSS feed and no ads or any kind of tracking or lead forms, etc. Do note it's mostly an entertainment or pop-programming style writing, not something that does deep dives into super technical stuff (mostly because I don't think I am qualified to write something I don't fully understand) but I try to keep it fun!
Looks like you two are on opposite sides of the same fence. The demo scene exists it's programming for fun and creative expression. Also the ioccc. That's the equivalent of a creatively written novel. Then there's writing for just a job like writing knowledge bases. That would be programming for plumbing aka crud and cloud.
what about stock music/corporate event production and writing knowledge bases/advertising? those would be the plumbing equivalents of music and writing imo
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.
Programming as in forming structures of computation is exceedingly beautiful and as intricate as any art, but that's indeed far, far removed from the everyday reality of a programmer.
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 don't think it's overstating it at all. If anything, I would argue that code is more expressive than literature or music because it's more general. Consider the space of all possible video games, demos/intros, generative paintings, generative music, etc. which wouldn't be possible without code.
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.
In the 1980s, you often had programmers create the art and music for games, but for the last three decades at least there have been dedicated artists and composers who often have no coding skill at all.
It's like the purpose of portraits before photographs were invented. Maybe ai is like the camera for the photograph, and the canvas for portraits is writing code.
The point of art (like music and litterature) is the art itself. Code is a craft, it is means to an end. It can still be beautiful and impressive and creative, but it is a different thing.
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.
But it can, demonstrably because sometimes code is music. The C64 demoscene is art and code and music and graphics, all in one. And it doesn't really do anything, unlike that handmade watch.
Now, is the demoscene "high art"? For the most part, perhaps not. But some of it definitely is.
Thank you for understanding my comment. Code is a craft and could maybe be more compared to pottery, which usually has a use, and is primarily judged by well it fulfills its purpose. I'm not saying that there isn't "beautiful" code, and certainly not denying clever code. But the goalpost that code is just as expressive as literature or music is just too much. Show me the code that is inspired by the reflection of a sunset on a pond on a windy day.
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.
You also have people who just like bangers and love throwing some tracks together, like to create sets or playlists, think they might be a DJ one day, to move the crowd, no time/inclination in making music per se but care about the created experience and will learn the 'plumbing' if they have to....
Coding is so rich that you can use it for artistic pursuits, but I argue that the output is the real art, and the code itself is not art and itself is not expressing anything.
>I think this is overstating it and makes me wonder how familiar the author is with literature and music...
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.
> The coding we want for industry sure. Difference between IKEA and my uncle, an incredible, sought after carpenter.
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.
You could write (literature) SEO-driven articles all day, or pain copies of famous paintings all day and then painting and writing is closer to plumbing, too.
On plumbing, there are building codes that must still be followed. I think software engineering hasn't evolved to that stage yet where it's possible to assure quality.
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.
I don't think there's a meaningful difference between "deterministic" and "reproducible" the way you just used them. How can something be reproducible if you can't accurately predict what it will do?
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.
Also to be a compiler-type next-level-up abstraction we'd have to be at the point where we commit the prompts and throw away the code.
(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 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.
> 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.
Writing Specs that are thousands of lines wrong without formalism, type and correctness checking is a major PITA. Wish we had a..compiler that can check our code..err I mean spec.
Oh, are you still handwriting your specs? How Q2 2026. Handcrafted artisan specs are obsolete and you will be left behind in the dust if you still insist on them.
If this is true, then at some point we will stop committing source code to repositories, and instead commit prompts. The LLM would be a "compiler" that can reliably turn a vast collection of natural-language prompts into a complete system.
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".
IMO English as a programming language is a fools errand. Part of the reason why we _have_ programming languages is because it turns out human language is too ambiguous.
There's an increasing amount of jobs where the job role is analyst but you're just feeding the ai with whatever the task assigned to you was. These are not software jobs but are business jobs. Like User acceptance testing quality assurance aka bureaucracy
They aren't because we're not committing prompts. The analogous would be compiling to and then committing unmaintainable assembly when the higher level language, which is a deterministic compiler, already exists
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.
> 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.
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.
To me it looks like they've been pretty plateaued for a good while already? Sure they do marginally better on benchmarks or whatever, but to me as a user there's really not much difference between chatgpt today and chatgpt a couple years ago. Main difference is just added capabilities like web search, image recognition etc.
For coding you still need to be in control if you want a good result.
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 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?
No profession uses only one skill. I’ve had a few, the longest-running as a developer, and there is nothing uniquely varied about working in software. One thing that is pretty unique to software is how superior they feel to most other professionals, when in reality, it’s a pretty mediocre discipline compared to electrical or mechanical engineering, medicine, chemistry…
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.
They absolutely still exist just not in the US. Bad comparison IHMO. What they make is just imported into the US and they often work in factories in low wage countries like Bangladesh, Pakistan, Cambodia. They were just offshored
The amount of work in any given market at any given time is finite. Beyond that, developers likely won’t even be the bottleneck if everyone is a 10x ultradev 3000.
> 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.
The amount of work is not a fixed number, it's more of a supply/demand curve. Do we need 100 programs? Yes definitely! 10k? Yes. 1m? Probably. 100m? Uhm... 1bn? Probably not.
So there will always be a point where people aren't willing to hire more software developers because there are enough already.
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.
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.
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.
Imagine managing a team of people with no knowledge of their craft, like a team of doctors when you know nothing about being a doctor. You might be pretty confident that you can do it really well. The doctors would probably think that your "management" is unnecessary and potentially counter-productive.
Agreed, you can feel this change strongly with Opus vs Fable. Fable doesn't feel like a junior developer anymore. And it requires a lot less ceremony to boot.
> 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.
If I have learned something is that people in this field of work highly underestimate their skills. I still remember when people said gpt 3.5 was the end of programming and that I shouldn't pursue it. I am so glad I took the risk anyway. Although things are much brighter outside the us and Europe https://hai.stanford.edu/ai-index/2026-ai-index-report exactly the same countries where ai is mostly seen as unacceptable.
> 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.
> 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.
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.
I see it go in either two directions, assuming it plateaus at a marginal increase in productivity. Either this newly found productivity helps teams tackle backlog tasks that they never had the time to complete, or it's used to churn out more low quality work.
Yeah that’s exactly the same if you completely ignore context and market dynamics. It’s like trying to use the patterns of the colonial American horse market as a vehicle to analyze the modern American auto industry.
Pro: In the last ten years backend development has turned into AWS SDK-orientied programming mostly. Databricks-oriented in case of data engineering recently too. Between this and python/js popularity it is more of unskilled labor now.
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.
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.
And interestingly, a few good people at work are learning faster with the LLMs at hand.
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.
> 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.
painting can either be a plumbing job or a canvas with an image. using clay and concrete can be either a bridge (similarly to the function of plumbing) or a sculpture. programming can be the same either crud and cloud or something just created for artistic expression like the ioccc.
I'm reading Seneca right now and in one of his letters he said: "That focused concentration on one's work is deeply enjoyable in itself; the pleasure one has in the finished product after the work is done does not equal it. Now, the artist is enjoying the result of his art; while he was painting, he was enjoying the art itself".
And basically this is the problem I see in LLMs: they robbed me of these moments of enjoying the art of programming itself.
I sympathize completely with you, but.. they robbed you of these moments of enjoying the art of programming itself at your day job.
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.
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.
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.
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.
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.
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.
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
Does anyone here know any mathematicians who can’t do long division or basic algebra?
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.
I take the opposite view but to the same conclusion. I've heard the joke "the more advanced you get the worse you get at math" from a lot of mathematicians. I'd bet most mathematicians can't do a long division problem without having to think pretty hard about it, because they've long since moved past that skill.
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.
I think a major difference between math and software development is that software development tends to get easier after one gets through the educational barrier to entry, whereas math (and many other topics) become more complex/puzzly. Something that could highly accurately revert to the mean would be insanely useful when the overwhelming majority of what you're doing is mundane and has been done a million times before - the analog of something like basic arithmetic or calculus.
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.
I agree with the second part, 90% of apps are just a vague rehashing of 100 other apps, very little novel software ever gets written, especially at the component level. The point being that if you want to create truly novel systems you best know how to program, even if an LLM is writing the less novel parts of that system.
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.
I'm in the same boat! It's a reasonable stance but the specific examples aren't air tight. I'm a Mathematician and I can't do long division, I could probably work it out? Like you say, long division was part of a journey that made me very mathematically capable, even if it's no longer an active contributor. My capacity for pencil and paper calculus is undoubtably many many fold worse than my peak around undergraduate studies!
I'm not anymore, but I used to be a research mathematician. I absolutely cannot remember how to do long division, though I was certainly competent at it at one point. I'm also terrible at mental arithmetic these days.
These things were still indispensable on my path to being a mathematician though, they just ceased to be relevant as abstraction increased.
I feel like "I can do X" always comes with an implied timescale and a degree of confidence. For example, I "can" speak Chinese, in the sense that I have no reason to believe I cannot: Chinese people do not have fundamentally different mouths or brains to me. But still, even after many years of study and practice, you might be disappointed in my ability. If I were you I would not have any confidence in my ability in Chinese.
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.
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.
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.
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.
This. Even before LLMs it was well understood that you don't really understand a program unless you wrote it yourself. There's just no shortcut for it.
The arguments put forward are very weak, in my opinion. It made me depressed, not hopeful, as in: if this is all we have left, things are becoming desperate indeed.
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.
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.
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.
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.
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.
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.
Coding does not inherently have the “precision” of mathematics. If you’ve ever tried to formally verify even a basic algorithm you’ll know how “loose” programs are with their specifications.
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.
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.
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.
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.
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.
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.
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.
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.
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.
i always hear this argument. and then those that proclaim it get stuck for a sprint trying to fit a square peg in a round hole
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.
I'm not sure what archetype my comment makes me fall under, but my point is people spend time and effort learning about the things that are important to them. The things that are important to them aren't important to you and I'm saying that being interested in how a CPU actually works doesn't make you better or smarter than them being interested in how other parts of the business work.
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.
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.
> Learning Classical Latin and Ancient Greek is also worthwhile.
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.
Latin and Greek were taught at grammar schools: part of upper class status signalling. But also deeply foundational to many languages, literature and history, if you think those topics are useful.
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."
Yet the publications in English (mainly state sources?) don't mention that. I enjoy cross-language jokes but my language skills are undeveloped. I enjoy asking AI to find crazy connections, but I'm not sure if programming myself that way is healthy. I also worry what other good questions I haven't thought to ask professor AI to teach me.
Yes, I'm not sure it was clear, but that was largely my point – to say it's "worthwhile" as a flat statement probably doesn't capture the nuance.
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.
This “don’t need to learn code” vibe will bring a big quality and good pay wave programming. It was getting more obnoxious because of more and more mba guys getting into programming because there is money in it.
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
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.
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
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
Sometimes I think that I must be a complete low IQ imbecile, because for me, even using Fable, code is still a pretty much hands-on affair. Not in the sense of actually writing lines of code (I still like to create things like structs, interfaces, traits, as a form of prompting, natural language for that kind of stuff is actually more verbose and way less precise).
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.
There’s a huge difference between does it work vs is it elegant.
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.
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.
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.
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.
Here's a much simpler reason: the output of an LLM, mathematically, is average. The code it writes is, effectively, the geometric mean of github. The ideas it comes up with are the geometric mean of wikipedia and reddit. Go ask it how to do something truly "out there" and watch it give you the most milquetoast reply you've ever seen. I asked Fable 5 to create a profitable business and the best it could come up with was:
>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.
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.
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
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.
I think that, even among those who have had the ability to code since before LLMs, the skill of coding has been in atrophy, and will continue to be so over the next 10 or 20 years. Learning to code, over the same period of time, will not be worthwhile. At the end of that process, cracks in the system will start to show: Namely, we will have nothing but LLM-generated code to train future LLMs on, and codebases for production code will be so low in quality that they will be unintelligible to humans, and LLMs, too, will have trouble maintaining them. At that point, coding will become a valuable skill again. The practical question for someone planning out their career from todays' point of view, is that it's uncertain when that time will come, and these markets can and will stay irrational for longer than any single individual trying to resist them will be able to stay solvent.
It is a bit like in "Profession" by Isaac Asimov. We will still have the need for some people who will write code manually, fix the craft. We will need the "Feeble Minded" asylum that is actually a secret sanctuary for society's true creators. Because everyone else relies on generated code, they can only repeat what is already known. Only the people who learn the hard way through actual studying possess the creativity and intelligence required to invent new knowledge and create new educational tapes.
The reason LLMs seem powerful is that they can churn out the Nth variation of a CRUD app in minutes. But it’s hard to imagine they’ll ever independently develop a compiler for a truly novel programming language, for instance. They don’t have creativity. They are pattern generators.
> it’s hard to imagine they’ll ever independently develop a compiler for a truly novel programming language
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.
My main argument about this kind of work is that it is (essentially if not exactly) in the training set.
I want a different argument before I believe that LLMs are doing “out of training dataspace creativity” (extrapolation not interpolation).
It's true. Creative work is in the training set.
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.
But what was novel about the language?
At the time the LLM generated the compiler, just syntax. The semantics it generated were the subset of C that the C version of the compiler already used.
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.
I'd say that even if the task is "a compiler for an existing language" the empirical results are far from stellar, and indeed, border the terrain of comedy.
Claude has made my Ruby compiler pass 8k more rubyspecs tests over the last two weeks, and that includes solving crashing bugs in hours that I'd failed to fix for weeks in the past.
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.
Isn't "creativity" the result of a combination of patterns (usually from different contexts) that casually works? I bet LLMs/agents can do that (we can't know how far that can goes).
For me that creativity is very well expressed by the principle of abduction. With induction, generalise towards rules, or deduction, use rules on data, we have this combination of patterns via different contexts. I think abduction might not be possible via LLMs.
Reminds me of 'I don't think a computer will ever beat a human at chess'.
> ...and [1] codebases for production code will be so low in quality that they will be unintelligible to humans, and [2] LLMs, too, will have trouble maintaining them. [3] At that point, coding will become a valuable skill again.
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.
> 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.
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.
Having worked at a company with thousands of microservices, I feel like most of it is just a bunch of boilerplate riddled with tons of ridiculous business logic, security and otherwise bugs. It seems like people were historically more concerned about Java inheritance and spreading everything around different files and directory hierarchies, while ignoring common sense business requirements completely. With each service being on separate older version, many being very difficult to start up locally, I don't see how LLMs could do worse than that, and that is a profitable, working business.
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.
The 1500 line react component that my unsupervised agentic coding side project produced says that it can get worse than we have now.
I swear I see far worse from humans for working businesses, and in much worse ways than just duplication of code. At least AI tends to be smarter about React intricacies even if it does create huge files. For my personal projects however I have straight token limits per file, whether it is backend or frontend so AI can't do that many lines of code. And I have specifically token limits so it would avoid hacking with formatting. And for React specifically I force it to put hooks in separate files and component files to be presentational only with max 1 hook usage.
> At least AI tends to be smarter about React intricacies even if it does create huge files.
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.
I feel like I've seen people frequently doing the mistake of keeping way too many things in state that could and should be computed, but instead they would useEffect to read to dependencies change to update the state. And frequent useEffect infinite loops. I guess it depends heavily on how you would set up the initial prompts I suppose, but yeah if someone is new to React, maybe AI will do that you are right.
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.
The difference is, if you tell the LLM that the component is too big and ask it to use some strategies to break it up, it will.
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.
> 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.
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.
We've been on this merry go round before with the "outsourcing to the cheapest programmers in india" boom.
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.
Funny you say that.
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.
Outsourcing never ended but it did happen in waves. Right after ZIRR ended but before the AI panic multiple companies started to layoff in developers in western countries and double down on outsourcing to India. During ZIRP they employed more people in the US/EU and less work was outsourced.
I have the last native Fujitsu laptop that is worthy of mention. I am a big fan. Fun story: about 5 years ago they decided to resume their laptop production, and the only practical way was to enroll old retired Japanese workers. I guess, the youth do not have the skill or/and do not want to bother. They made some batches, then I believe it ended.
Panasonic still makes laptops, enterprise use only, very expensive.
How is that relevant? Well, directly.
I think in order to be a productive programmer with Claude you still need to understand what you are doing.
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
To be clear: I don't envision a scenario where people who are completely unable to code will come out of nowhere, and make a career out of prompting claude to write software without ever learning to code. What I am saying is that the threshold of what constitutes "good enough" coding skill has shifted down, and those people who already knew how to code now have a certain multiplier on the outcomes they deliver. (this multiplier is high if you measure on low time horizons and gets lower, the longer the time horizons, but the latter doesn't matter in managers' minds). So there will, for a time, be a massive overhang of good-enough coding skill from "old stock", so to speak. For those who do not already know how to code, this make the proposition of learning to code right now uneconomical. If there is already a massive oversupply of grapes in the market, and you're trying to decide which crop to plant, then planting more grapes is economically probably a pretty poor decision. It would be better to plant things that are undersupplied.
> make the proposition of learning to code right now uneconomical
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.
One might argue that these people will not understand the code they write if they use LLMs. I would counter that with my observation that plenty didn’t understand the code they wrote before LLMs too.
This is the correct take.
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.
LLMs are trained with a large corpus of commercially available source code. However, intentional training on individual skills such as medicine, finance, mathematics, and software engineering is conducted to the tune of a few billion dollars per year.
Your scenario would only unfold if frontier labs decided not to compete on capabilities. It sounds unlikely.
How will they hire experts from those professions on whose output to train on, if they destroy the skills currently extant in those professions? Maybe lawyers will still read contracts every once in a while. Certainly, programmers around me no longer bother with reading code. ...and you can make an argument that a similar effect will happen that is widely observed in language-learners: Namely, if you only ever use a language passively (to read/listen), you're not necessarily able to use it actively (to write/speak).
> 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?
Your argument assumes premises that are hardly certain. We use automobiles to travel, yet tens of thousands can still ride horses today. Hell, there are thousands of blacksmiths and glass blowers. If there's a several hundred million dollar market for programming language experts, this will provide sufficient incentive for some people to remain sharp.
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.
Actually, riding horses is a great example, and you happened to pick a domain within which I dabble: People are not capable of riding horses today at the level of skill of a nobleman from Renaissance Europe. People at the forefront of the riding arts today read manuscripts from Guérinière, second-guessing at the meaning of every last syllable, because many of those sources describe things that are unintelligible and unfathomable today that seem to have been quite commonplace. And this is despite even the centuries of continuity of government funding for institutions that have been dedicated to trying to prevent precisely this. (Namely the Spanish Riding School of Vienna and similar institutions in Lisbon and Jerez, the Cadre Noir, etc.)
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?
Similarly, I spent a few hours one day going down a rabbit hole of modern marble carvings, wondering if there were any hidden great masters of the art. I found that despite there being essentially limitless wealth and people compared to when the Pietà was made, there’s nobody making marble carvings like the masters did. Now there are some somewhat stylized marble carvings but in my opinion they pale in comparison to a masterwork marble statue. After all, why do that when you can just snap a photograph?
More like, "old developers will continue to denounce the diminishing code quality, and long for the old days of programming".
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.
If you haven't read it, I think you'd enjoy The Machine Stops by E.M. Forster. It's amazingly prescient, given it was written in 1909.
>codebases for production code will be so low in quality that they will be unintelligible to humans, and LLMs, too, will have trouble maintaining them
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.
Funny but also not true unless you have low standards, potentially as a result of just not being very good yourself.
Part of the industry always seek humans able to code with deep understanding. AI is fast but always lacks depth, works better if you are able to pilot it with your knowledge. If that changes, learning code becomes useless. If you learn code with limited depth (nextjs bros), this is already useless.
> Part of the industry always seek humans able to code with deep understanding.
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.
Most AI-refugees where quality doesn't matter will embrace the slop, they will become slop experts, slop consultants. Learning to code become less relevant, except if you are looking for a work that really needs it and it will still be valuable, that won't be for everyone.
[flagged]
[dead]
> 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 throwaway garbage, and if plumbing was treated remotely like that we'd be in deep shit, literally.
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.
I get your point, but I think that's a poor example. I've been around plenty of Plumbers, Mechanics, Contractors, and Electricians. You're almost guaranteed a comment or remark about the previous guy's work.
I didn't say it doesn't happen, but I for one never experienced it, I saw zero churn and posturing or kool-aid. I guess plumbing got more professional the more widespread and crucial it became, while software is just getting sloppier and more bloated.
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 actually think plumbing does require a bunch of creativity. Trying to add some fixture to an old house with out of spec walls and prior creative solutions can be a real challenge. And you can really appreciate the people who come up with an elegant solution that isn't "tear it out and redo it from scratch".
I'd like to read that blog post.
Yeah that also makes sense. I guess a better comment would have been to highlight the art/work aspects of any process. Like yeah, most jobs (even those that include creativite processes) will just become boring because jobs are standardized usually where you're going from point a to point b doing the same thing again and again. But that doesn't mean there is no art/creativity to the process itself but rather we restrict it intentionally in fixed jobs to standardize and this causes the split between thinking of code as a creative or non-creative pursuit.
> 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 find my blog here: https://decodingvibes.com/. It does have an RSS feed and no ads or any kind of tracking or lead forms, etc. Do note it's mostly an entertainment or pop-programming style writing, not something that does deep dives into super technical stuff (mostly because I don't think I am qualified to write something I don't fully understand) but I try to keep it fun!
Looks like you two are on opposite sides of the same fence. The demo scene exists it's programming for fun and creative expression. Also the ioccc. That's the equivalent of a creatively written novel. Then there's writing for just a job like writing knowledge bases. That would be programming for plumbing aka crud and cloud.
The demo scene — as cool as it is — is an obscure hobby for a particular kind of nerd.
The business side of programming puts food on the table for tens of millions of people.
Can't the same thing be said about literature and music?
The earnings distribution in those arts are highly concentrated. Not the case for SWE.
what about stock music/corporate event production and writing knowledge bases/advertising? those would be the plumbing equivalents of music and writing imo
No. And if it could, I sure as hell never would have become a programmer.
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.
Programming as in forming structures of computation is exceedingly beautiful and as intricate as any art, but that's indeed far, far removed from the everyday reality of a programmer.
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 don't think it's overstating it at all. If anything, I would argue that code is more expressive than literature or music because it's more general. Consider the space of all possible video games, demos/intros, generative paintings, generative music, etc. which wouldn't be possible without code.
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.
In the 1980s, you often had programmers create the art and music for games, but for the last three decades at least there have been dedicated artists and composers who often have no coding skill at all.
Yes, if you're just going down a list of jira tickets and implementing product features, but for many folks it's also an art medium.
It's like the purpose of portraits before photographs were invented. Maybe ai is like the camera for the photograph, and the canvas for portraits is writing code.
The point of art (like music and litterature) is the art itself. Code is a craft, it is means to an end. It can still be beautiful and impressive and creative, but it is a different thing.
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.
But it can, demonstrably because sometimes code is music. The C64 demoscene is art and code and music and graphics, all in one. And it doesn't really do anything, unlike that handmade watch.
Now, is the demoscene "high art"? For the most part, perhaps not. But some of it definitely is.
Thank you for understanding my comment. Code is a craft and could maybe be more compared to pottery, which usually has a use, and is primarily judged by well it fulfills its purpose. I'm not saying that there isn't "beautiful" code, and certainly not denying clever code. But the goalpost that code is just as expressive as literature or music is just too much. Show me the code that is inspired by the reflection of a sunset on a pond on a windy day.
https://www.dwitter.net/d/35814
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.
You also have people who just like bangers and love throwing some tracks together, like to create sets or playlists, think they might be a DJ one day, to move the crowd, no time/inclination in making music per se but care about the created experience and will learn the 'plumbing' if they have to....
Coding is so rich that you can use it for artistic pursuits, but I argue that the output is the real art, and the code itself is not art and itself is not expressing anything.
>I think this is overstating it and makes me wonder how familiar the author is with literature and music...
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.
The coding we want for industry sure. Difference between IKEA and my uncle, an incredible, sought after carpenter.
> The coding we want for industry sure. Difference between IKEA and my uncle, an incredible, sought after carpenter.
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.
And when it's time to solve some bugs in these code base in a year, which one's going to be more expensive in terms of time, and tokens?
You could write (literature) SEO-driven articles all day, or pain copies of famous paintings all day and then painting and writing is closer to plumbing, too.
Have you not seen the Mechanical Watch work of art by Bartosz Ciechanowski? My goodness it's beautiful.
https://ciechanow.ski/mechanical-watch/
On plumbing, there are building codes that must still be followed. I think software engineering hasn't evolved to that stage yet where it's possible to assure quality.
Totally agree. Programming is not art. Does my company pay thousands of engineers to make art? I think not!
We're paid to solve a problem that the customer has.
I think literature, music and programming are all crafts, but I can't quite go so far as to call programming 'art'.
I make this comparison a lot and a lot of devs don't like it.
I am sure I could make a decent industrial PLC tech, same shit, different tools.
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.
The babysitting work would still be impossible if you didn't actually know how to code.
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?
People keep trying to make that analogy, but it doesn't really work because LLMs aren't deterministic like compilers and assemblers.
They don’t need to be dererministic, only reproducible.
They’re not reproducible, nor are they even reliable right now.
I don't think there's a meaningful difference between "deterministic" and "reproducible" the way you just used them. How can something be reproducible if you can't accurately predict what it will do?
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.
Also to be a compiler-type next-level-up abstraction we'd have to be at the point where we commit the prompts and throw away the code.
(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?)
It is not obvious to me that determinism is a requirement for an abstraction
IMO delegation isn't abstraction.
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.
> It is not obvious to me that determinism is a requirement for an abstraction
But it is a requirement for them to be an "abstraction just like" assemblers or compilers, which is what was being claimed.
> 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.
Writing Specs that are thousands of lines wrong without formalism, type and correctness checking is a major PITA. Wish we had a..compiler that can check our code..err I mean spec.
Oh, are you still handwriting your specs? How Q2 2026. Handcrafted artisan specs are obsolete and you will be left behind in the dust if you still insist on them.
Poe’s law displayed beautifully here
In which direction? It wasn't long ago having the agent generate a plan before acting on it was a "best practice".
Writing specs validates the translation is being done properly? Was this written by an LLM?
Writing detailed specs is an important tool to help the LLM translate the idea in your head to code. The spec is an intermediate artifact.
If this is true, then at some point we will stop committing source code to repositories, and instead commit prompts. The LLM would be a "compiler" that can reliably turn a vast collection of natural-language prompts into a complete system.
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".
IMO English as a programming language is a fools errand. Part of the reason why we _have_ programming languages is because it turns out human language is too ambiguous.
There's an increasing amount of jobs where the job role is analyst but you're just feeding the ai with whatever the task assigned to you was. These are not software jobs but are business jobs. Like User acceptance testing quality assurance aka bureaucracy
LLMs are as much an "abstraction" as outsourcing your app to a bunch of contractors: a silly dilution of the word to the point of meaninglessness.
They aren't because we're not committing prompts. The analogous would be compiling to and then committing unmaintainable assembly when the higher level language, which is a deterministic compiler, already exists
> not committing prompts.
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.
> 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.
I posted a while ago about connecting an LLM directly to an assembler and people thought it was a bad idea. Now we're going in exactly that direction
But at every point, your product was better if you still understood the lower level. Your Python is better if you understand Assembly.
There is a always going to be the gap of what you can do with LLMs if you know how to code vs if you don’t
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.
once, if ever, the plateauing happens. Until then there is going to be this gap.
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.
To me it looks like they've been pretty plateaued for a good while already? Sure they do marginally better on benchmarks or whatever, but to me as a user there's really not much difference between chatgpt today and chatgpt a couple years ago. Main difference is just added capabilities like web search, image recognition etc.
For coding you still need to be in control if you want a good result.
AGI is human level intelligence. superintelligence is ASI
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 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?
You asked for counterexamples, so I gave you a few. Did I misinterpret your question?
No profession uses only one skill. I’ve had a few, the longest-running as a developer, and there is nothing uniquely varied about working in software. One thing that is pretty unique to software is how superior they feel to most other professionals, when in reality, it’s a pretty mediocre discipline compared to electrical or mechanical engineering, medicine, chemistry…
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.
They absolutely still exist just not in the US. Bad comparison IHMO. What they make is just imported into the US and they often work in factories in low wage countries like Bangladesh, Pakistan, Cambodia. They were just offshored
> They absolutely still exist
That is precisely the point. They still exist, but it is a far less common occupation than it once was.
The amount of work in any given market at any given time is finite. Beyond that, developers likely won’t even be the bottleneck if everyone is a 10x ultradev 3000.
> 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.
The amount of work is not a fixed number, it's more of a supply/demand curve. Do we need 100 programs? Yes definitely! 10k? Yes. 1m? Probably. 100m? Uhm... 1bn? Probably not.
So there will always be a point where people aren't willing to hire more software developers because there are enough already.
Considering the dev job market right now, lack of developers doesn’t seem to be a bottleneck for the industry.
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.
That’s why I said “if” and not “when.”
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.
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.
Imagine managing a team of people with no knowledge of their craft, like a team of doctors when you know nothing about being a doctor. You might be pretty confident that you can do it really well. The doctors would probably think that your "management" is unnecessary and potentially counter-productive.
> babysitting work would still be impossible if you didn't actually know how to code
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 fear the capability of the models will quickly outpace the need for a human to validate their output. They won't be juniors for much longer.
Agreed, you can feel this change strongly with Opus vs Fable. Fable doesn't feel like a junior developer anymore. And it requires a lot less ceremony to boot.
And thats why noone should learn to code.
> 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.
That may be the fate of many programmers.
If I have learned something is that people in this field of work highly underestimate their skills. I still remember when people said gpt 3.5 was the end of programming and that I shouldn't pursue it. I am so glad I took the risk anyway. Although things are much brighter outside the us and Europe https://hai.stanford.edu/ai-index/2026-ai-index-report exactly the same countries where ai is mostly seen as unacceptable.
> 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.
This sounds to me like a life well lived!
It's such a shame that our society doesn't value more, in economic terms, this type of skills.
Can you expand on why you think society should value it?
What is a society without culture? Decline.
> 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.
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.
I see it go in either two directions, assuming it plateaus at a marginal increase in productivity. Either this newly found productivity helps teams tackle backlog tasks that they never had the time to complete, or it's used to churn out more low quality work.
We can get a preview of it all in the media creation world. Slop slop slop.
Did Object Oriented programming create less demand for developers?
Were the software and dev markets even remotely comparable in the 60s?
How much more efficient did compilers make developers?
Yeah that’s exactly the same if you completely ignore context and market dynamics. It’s like trying to use the patterns of the colonial American horse market as a vehicle to analyze the modern American auto industry.
a ton. that's why fortran was invented
Pro: In the last ten years backend development has turned into AWS SDK-orientied programming mostly. Databricks-oriented in case of data engineering recently too. Between this and python/js popularity it is more of unskilled labor now.
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.
Can I ask what data you are seeing?
Well I guess this is highly location dependent. Outside western countries where ai is not acceptable, https://hai.stanford.edu/ai-index/2026-ai-index-report ai has driven up demand for software.
> from the data I've seen,
Where is the data? There is no data but a lot of vibes, from the data I have seen
Which models and tools do you use to write and validate code?
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.
And interestingly, a few good people at work are learning faster with the LLMs at hand.
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.
> 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.
> 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.
Interesting you bring up (artistic) painting and bridge building.
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.
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).
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.
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.
And then endless tweaks for CSS when the home owner decides they don't like the color of their molding...
painting can either be a plumbing job or a canvas with an image. using clay and concrete can be either a bridge (similarly to the function of plumbing) or a sculpture. programming can be the same either crud and cloud or something just created for artistic expression like the ioccc.
I'm reading Seneca right now and in one of his letters he said: "That focused concentration on one's work is deeply enjoyable in itself; the pleasure one has in the finished product after the work is done does not equal it. Now, the artist is enjoying the result of his art; while he was painting, he was enjoying the art itself".
And basically this is the problem I see in LLMs: they robbed me of these moments of enjoying the art of programming itself.
I sympathize completely with you, but.. they robbed you of these moments of enjoying the art of programming itself at your day job.
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.
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.
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.
Just exhausting...
That's why I say, just don't use LLMs.
I think conceptualizing and refining the abstraction is the essence of the beauty of the craft and progress.
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.
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.
I wonder what the rates of burnout are going to look like in a couple of years, if this is the future
Talk about driving people off a cliff
> 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.
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.
2016: "the median developer is too stupid to do FizzBuzz correctly"
2026: "the median developer is a craftsman whose work is being replaced by AI slop"
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
I agree 100%. I was just trying to say people can sort of get away with more, or justify it easier.
doesn't the recent bun controversy tell a different story?
exactly, it seems like people run away when a tool becomes heavily AI developed.
Does anyone here know any mathematicians who can’t do long division or basic algebra?
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.
I take the opposite view but to the same conclusion. I've heard the joke "the more advanced you get the worse you get at math" from a lot of mathematicians. I'd bet most mathematicians can't do a long division problem without having to think pretty hard about it, because they've long since moved past that skill.
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.
I think a major difference between math and software development is that software development tends to get easier after one gets through the educational barrier to entry, whereas math (and many other topics) become more complex/puzzly. Something that could highly accurately revert to the mean would be insanely useful when the overwhelming majority of what you're doing is mundane and has been done a million times before - the analog of something like basic arithmetic or calculus.
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.
I agree with the second part, 90% of apps are just a vague rehashing of 100 other apps, very little novel software ever gets written, especially at the component level. The point being that if you want to create truly novel systems you best know how to program, even if an LLM is writing the less novel parts of that system.
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.
I'm in the same boat! It's a reasonable stance but the specific examples aren't air tight. I'm a Mathematician and I can't do long division, I could probably work it out? Like you say, long division was part of a journey that made me very mathematically capable, even if it's no longer an active contributor. My capacity for pencil and paper calculus is undoubtably many many fold worse than my peak around undergraduate studies!
I'm not anymore, but I used to be a research mathematician. I absolutely cannot remember how to do long division, though I was certainly competent at it at one point. I'm also terrible at mental arithmetic these days.
These things were still indispensable on my path to being a mathematician though, they just ceased to be relevant as abstraction increased.
I feel like "I can do X" always comes with an implied timescale and a degree of confidence. For example, I "can" speak Chinese, in the sense that I have no reason to believe I cannot: Chinese people do not have fundamentally different mouths or brains to me. But still, even after many years of study and practice, you might be disappointed in my ability. If I were you I would not have any confidence in my ability in Chinese.
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.
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.
Steve Jobs used to say that everyone should learn to program, because it teaches you how to think.
https://youtu.be/BRTOlPdyPYU
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.
> 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.
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.
This. Even before LLMs it was well understood that you don't really understand a program unless you wrote it yourself. There's just no shortcut for it.
The arguments put forward are very weak, in my opinion. It made me depressed, not hopeful, as in: if this is all we have left, things are becoming desperate indeed.
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.
Those are not compelling arguments.
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)
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.
> But that in itself also isn't compelling to lots of people, why should they care about "exercising your brain"
I just sort of assume people don't want to be stupid and ignorant, but maybe I'm wrong
learning lots of different games would achieve the same objective.
> For most people "learn to code" is like telling programmers to "learn asm".
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.
> 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.
“Sell me this pen”
Everyone in this thread is failing to sell the pen lol
Programmers should learn ASM, or at least have a surface level knowledge of it, the same way electrical engineers should know how a vacuum tube works.
What games do you have in mind?
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.
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.
Everybody should learn to program a computer, because it teaches you how to think
- Steve Jobs
Everybody should learn to program a computer, so we could hire the best to build our products.
That's what he wanted to say. If he really meant what he said, he'd took some effort to learn himself
It teaches you a very specific way of thinking, albeit a useful one.
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.
Ah damn, sorry about that. I removed my footer "ads" in response to this feedback. Appreciate it.
Driving schools will shut down within the year because self driving cars will be prevalent
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.
Where do these new top notch programmers come from and what proof of top notchness will be required for job proof? (Honest questions)
MIT. A degree from MIT. Kind of joking but not really.
Coding does not inherently have the “precision” of mathematics. If you’ve ever tried to formally verify even a basic algorithm you’ll know how “loose” programs are with their specifications.
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.
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.
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.
Well this is ridiculous. Literature or music?!
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.
There’s always value in the fundamentals you just might not get paid for them.
<<And finally, programming is simply fun. It's a joy. My calling in life is to spread the joy of programming,>>
must be a Raku coder -Ofun
The era of LLMs is similar to when Magic was discovered in the 1400s.
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.
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.
Real Estate, it always boils down to real estate.
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.
I can’t tell if you’re serious or not.
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.
https://en.wikipedia.org/wiki/Daemon_(novel)
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.
The obvious difference is LLMs are real and divination is bullshit.
I think he’s wasting time.
Well good for him
tf are you saying, magic isn’t real
What is "learn to code"?
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.
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.
Abstractions are one thing, not putting any effort into learning is another. People worry about the latter.
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.
i always hear this argument. and then those that proclaim it get stuck for a sprint trying to fit a square peg in a round hole
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.
I'm not sure what archetype my comment makes me fall under, but my point is people spend time and effort learning about the things that are important to them. The things that are important to them aren't important to you and I'm saying that being interested in how a CPU actually works doesn't make you better or smarter than them being interested in how other parts of the business work.
>spend time and effort learning about the things that are important to them
But Earlier ...
>Or reading Hacker News.
Reading Hacker News is important to you?
it's not for you?
The extra 30 minutes will be spent chatting with the AI as if it's your best friend.
You may have to spend 4 hours in the future when something stops working and the AI can't fix it
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.
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.
Learning Classical Latin and Ancient Greek is also worthwhile.
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.
> Learning Classical Latin and Ancient Greek is also worthwhile.
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.
Latin and Greek were taught at grammar schools: part of upper class status signalling. But also deeply foundational to many languages, literature and history, if you think those topics are useful.
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.
Yet the publications in English (mainly state sources?) don't mention that. I enjoy cross-language jokes but my language skills are undeveloped. I enjoy asking AI to find crazy connections, but I'm not sure if programming myself that way is healthy. I also worry what other good questions I haven't thought to ask professor AI to teach me.[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...
Surely you're capable of understanding that the term "worthwhile" has multiple meanings.
Yes, I'm not sure it was clear, but that was largely my point – to say it's "worthwhile" as a flat statement probably doesn't capture the nuance.
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.
This “don’t need to learn code” vibe will bring a big quality and good pay wave programming. It was getting more obnoxious because of more and more mba guys getting into programming because there is money in it.
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
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.
Coding is easy. It's the programming that's hard.
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.
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.
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
Who in the world has time to learn how to code? Who has that much copious free time when they're working two jobs?
> Who has that much copious free time when they're working two jobs?
Only two jobs? You'll need a better reason than that.
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
Just because I have a car doesn't mean I should stop walking.
Sometimes I think that I must be a complete low IQ imbecile, because for me, even using Fable, code is still a pretty much hands-on affair. Not in the sense of actually writing lines of code (I still like to create things like structs, interfaces, traits, as a form of prompting, natural language for that kind of stuff is actually more verbose and way less precise).
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.
There’s a huge difference between does it work vs is it elegant.
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.
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.
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.
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.
Here's a much simpler reason: the output of an LLM, mathematically, is average. The code it writes is, effectively, the geometric mean of github. The ideas it comes up with are the geometric mean of wikipedia and reddit. Go ask it how to do something truly "out there" and watch it give you the most milquetoast reply you've ever seen. I asked Fable 5 to create a profitable business and the best it could come up with was:
>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.
Nothing is worthwhile if we all die in the end...
it sounds like backing up any learning... not just coding
Learning the fundemntals but not syntax
It has always been.
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.
>Nobody hires code monkeys.
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.
Correction: Learning to software engineer is still worthwhile
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
"Code is a beautiful form of creative expression, as rich as literature or music"
Um no, you've gone too far.
I'm no Mozart, but I find it really fucking weird when we act like woodworking is artful and creating software isn't.
Programmers do woodworking in their free time and programming at the assembly line in the crud factory.
Sounds like you have no artistic sensibility
Roller Coaster Tycoon was programmed in fucking assembly. That's a work of artistry right there.
Calling it as rich as the best works of literature is peak programmer angst.
Trying to compare apples to oranges is peak idiocy.
i recommend you look at the demo scene for a counter argument.
[flagged]
[dead]
[flagged]
[dead]
[flagged]
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.
I feel like no matter the model, it's going to be more powerful when used by a skilled software engineer vs a layperson.
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.
We most certainly are not at that point.
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.
Man, that makes coding tools, says you should learn to code lolz. I don't disagree. Just worth noting.
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.
I don't know how one would build anything without knowing. If it was true, I would be building a competitor to Anthropic right now.
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.
That's the optimistic case, anyway.
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.
I mean only people with billions of dollars can make competitors to anthropic because of necessary compute costs
that's the barrier to entry
Only people with billions of dollars can train foundation models, yes.
But a competitor to Anthropic at the product level? With open source models, very little barrier.
Lots of unsubstantiated claims here