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.
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.
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.
> 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'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.
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.
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
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.
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.
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.
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.
> 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 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 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.
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.
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.
Well LLMs also spout a lot of bullshit sometimes. I had a conversation with one just recently where it couldn’t do arithmetic too well with a challenge involving coins of a foreign currency. I think maybe it got tripped up because the convo got a bit too long or maybe it didn’t like that I was using the dollar sign.
You can also make LLMs agree with your own biases for some reason. For example, the people who use them to plan shady stuff.
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.
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.
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.
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.
I've been using Fable (effort=xhigh) to plan new personal-use side projects and it virutally always has been making good decisions (from architecture to granular impl detail) that would've made me feel super foresightful had I planned them all myself.
My value was mainly relegated to making product decisions, and my technical interjections are increasingly optional and limited to preferences.
The idea that a human engineer will always add value as a steering role over an AI's shoulder is weaker every year, and we need to start planning for that not being the case.
I think we're at a point where bad developers are only producing bad code if they were too prescriptive.
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. 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.
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 tolerate things 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.
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.
The mega-rich clowns firing everyone and then hiring back just those few that they realize they actually needed to keep after-the-fact are actually driving themselves right off that same cliff along with everyone else, and they don't even realize it. I bet money all this "AI" nonsense don't end up leadin' to the "Rich Guy Utopia" they think they're workin' toward. It's much more likely gonna just lead to a shittier world for everyone on Earth, rich and mega-ultra-totally-too-rich folk included. Wait'll the "AI bubble" bursts and see how much fun they have losin' zillions while pretty much everyone else lands in the "poor house" and comes lookin' to them for retribution. I suspect the guillotine is makin' a comeback sometime in the future.
I'm a junior and I probably spend a similar amount of time thinking vs reviewing. I rarely write code unless it's about <5 lines.
I find the instantaneous thinking easier now. I can have several ideas in mind, and have a concrete implementation made for each, making it easier to compare alternatives. Although, since each problem is alone easier to think about, I do end up handling a greater number of problems. But I expect that my total volume of thinking is likely the same as before.
Where I do certainly feel more tired is when I try to solve too many problems in parallel. If I try to do that, I end up constently dropping context. So I generally try to finish a big chunk of something before switching (usually that means getting it ready for another code-review cycle).
I do miss writing code myself. It's certainly satisfying. It's just significantly slower in most cases. I try to do it in my free time.
> I can have several ideas in mind, and have a concrete implementation made for each, making it easier to compare alternatives.
I would ask what exactly are you comparing. I don't think I've ever wrote 2 versions of code to compare between each.
I've written exploratory code. A few lines to quickly inspect the behavior of module/function because it's undocumented. If something needs tuning, I surface the parameter in the interface, hook it to an harness to plot and manually tune.
I've also written alternative implementation of some feature, that later was abandoned.
But I've never written multiple versions of the same feature at the same time. I either model it (algorithm) or sketch it (interfaces or some other flow). It's way easier to interate with those than some demo/prototype code. The latter is when we settled on a solution and wants to fine tune it.
Somebody talking about researchers, I think it was Hamming, once said that there are people who just can't think without a bench full of equipment in front of them. So if you want to get good work out of them, your job as a lab director, then, is to give them that bench full of equipment and let 'em cook. I think the same thing is true of some programmers, and I think I might be one of them. We could sit around and conceptualize till we're blue in the face, but without an editor open with code in it we can't think through our conceptualizations effectively, and a chatbot is no substitute. A chatbot just adds another layer of abstraction to a process that's already thick with them, like a wall that got repainted so many times it's covered in a few millimeters of stratified goo that partially melts in the summer, and what's worse its behavior cannot be meaningfully predicted or reasoned about. Everything you think you know about how to correctly get results out of an LLM is either guesswork or folklore, and may be obsolete by Labor Day.
This also partially explains why I'm fond of Lisp. Paul Graham once said that while Lisp is a great language to work in, its real value comes as a language for thinking in.
> 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
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.
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.
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.
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.
> As a professional programmer entering the final third of an enjoyable career, I would now place "learning to code" in the same category as "making a living as a poet." As in, it's truly enjoyable art and some people appreciate it, but you'd better plan for a day job.
Not wrong. Probably.
I'm reminded of an old friend from long ago. She was an early music major at Harvard, and graduated with a MFA. She was very good. She read and wrote Latin and Greek, could compose and play music using medieval notations, and published a book on early needlepoint.
She never obtained an academic appointment. She never found a job that needed those skills.
She died alone a few years ago.
> I'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.
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.
Right, but if things progress as they promised, it will require far fewer people to do the same work, which means the industry already has all the people it so need for at least a couple decades. That’s what happened with tool and die guys when offshoring kicked off, and now they’re scrambling to get apprentices because the last of the OG ones are retiring. There were decades that pretty much nobody (relative to prior eras) got trained for that work.
You're making an assumption on what AI lab have promised? The same AI labs that have made a strategy out of lying for hype? Thats crazy man, regardless of whether anything else you're saying is valid.
You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been?
> You are assuming that the amount of work is finite, so more productive people implies fewer people are required. Is that the case though? Has it ever been?
How many horse farriers have you met? How many coopers, blacksmiths, or shoemakers?
Not a fair comparison. Unlike shoemaker or coopers who do ONE thing, a SWE doesnt do just one thing.. atleast in general. I churned through basic, logo, c, c++, java, c#, python, go and now agents. The executable building on single machine died when distributed systems came in. It again evolved when cloud took over. We have been reinventing our work every few years. Every job change requires us to learn new skills.
How much did a horse farrier have to learn if they switched their employers?
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…
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 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.
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.
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 otherwise.
For now, I can imagine a not too distant future where this is largely untrue.
LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs?
At some point you stopped needing to understand the layer down because the layer you were on became so good. Yes there are always corner cases, but for the vast majority of developers/engineers out there, staying at your layer was enough to make a career out of it once your layer hit a certain maturity.
> LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs
The what is the semantic mapping between <some lang> and LLMs?
I know the semantic mapping between maching code and assembly (some light weight syntax manipulation and macros). I know the one between assembly and C (the C abstract machine, which is mostly about the stack and whatever call/ret instructions pair). I know the one between C and something like python (not so much different than the one between C and assembly in mechanism).
Please talk about how you go from A LLM prompt to a piece of code in Python and guarantee the intent remains unchanged.
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.
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.
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
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.
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.
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?)
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.
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.
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.
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.
> 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.
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.
274 comments
[ 2.8 ms ] story [ 79.9 ms ] threadThe 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"
Something I'm trying to do right now is to build something and avoid using LLMs to write any code. I still use it to consult. I'm writing a Dota2 tournament match aggregator in Elixir that takes tournament streams and chronologically orders them in a format that makes it easier to watch them sequentially since I find YouTube hard to use for ingesting series of videos.
I'm building it because... I like programming. I like making things. I find that LLMs are making me intellectually lazy and making things with them feels unfulfilling. I want to build. It's human to want to build.
Anything a human feels is human, regardless if it's to build or to not build :) Some people prefer some ways of building, others in other ways, it's all fine. I think lots of people forget that programming is a heavily creative endeavor in the end.
If I wanted to be slightly controversial, I'd argue building a program is more like painting a painting than building a bridge, for better and worse.
I'm a house painter, and while the work is... It's just relentless work and staring all day.
It's the end results of making something just, better, with the simple acts of reputation and giving a shit about it.
Just wondering where house painter falls in your scale, I'd hunch.
The difference this comparison is capturing in my opinion is that of thinking up something new, compared to arranging things in a well known/already defined configuration. We know how to build bridges, we just have to do it (maybe including some calculations and site surveys, yes, but novel solutions are rightfully shunned). Similarly painting a house.
Developing software is practically definitionally creating a novel thing. If we wanted the same software over again we could literally copy and paste the existing executable (and we do that all the time, it's just not called developing software or enough work to be a job, since we have machines that are excellent at arranging the electrical charge in the pre-defined manner).
The actually-a-job* software equivalent of painting a house or building a bridge would be weaving a program into core rope memory: https://en.wikipedia.org/wiki/Core_rope_memory
* Not a job you can get anymore.
People who are new to the scene may find "browsing catalog"/"configuring models" tedious, but that's how you develop the intuition of what works and what not. After a while, you can shortcut most of the tediousness with those heuristics. You know enough blocks that it's just choosing the right one to fit the solution and you do not have to research them and understand them at the same time (where most of the beginners' time is dedicated to).
Once you get away from the very trivial side of programming, yes you are standing on the shoulders of giants, but the design decisions are in fact truly novel un-forced choices. Ask two people to make a "note taking app for university students" and you'll get two very differently shaped apps.
And basically this is the problem I see in LLMs: they robbed me of these moments of enjoying the art of programming itself.
You are still free to enjoy it in your free time, just like I enjoy drawing or guitar playing in my free time. The loss we have experienced is the luxury of doing at work something we enjoy for its own sake.
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.
If the best we've got for convincing people to learn to code is that it's like math notation (the most hated part of math for the uninitiated), or pretty like a violin (useless for a new grad), then coding is in serious trouble.
IMO a better argument is it helps you "think like a computer". But if you wanted to learn that there are many video games I'd recommend mastering instead of learning to code. For most people "learn to code" is like telling programmers to "learn asm".
(I've been coding ~30 years)
I just sort of assume people don't want to be stupid and ignorant, but maybe I'm wrong
the most useful thing i learned about computers is to create logic gates by hand. nothing gave me a deeper insight into how a computer works than that. programming is the next step up. you can skip all the layers in between because you can extrapolate them. no need to learn assembler, but it may be worth reading about it, just to get an idea.
understanding the layers from logic gates, to assembly, to programming, to games and now AI is kind of like reading about the OSI model to understand networking. it's one layer of abstraction on top of another.
learning programming is worthwhile because it is the highest layer of abstraction that is shared by everything above it. despite there being hundreds of programming languages, the concepts are all the same. once you understand programming through learning one language you can apply that understanding to almost all other languages. on the other hand there are tens of thousands of games in hundreds of types. not to mention all the other applications. the tree of variation explodes at that level.
That's funny. I've told a mathy friend that I've sometimes wondered if I could have grown up without the whole, "... except I suck at math", and I think that's why.
I don't struggle with the problem solving. I've watched people reinvent chunks of "difficult" math in code without realizing or caring that they've done it.
I've started to think that math might actually be awful on purpose.
This is such a good way to put it.
I could learn asm maybe in a college course. But no other incentive.
No one wanted to read asm. Now no one wants to read thru code.
Everyone in this thread is failing to sell the pen lol
that's the barrier to entry
But a competitor to Anthropic at the product level? With open source models, very little barrier.
That's the optimistic case, anyway.
"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.
All these are amazingly valuable skills/mindsets that can be highly portable to other "problem solving" domains.
https://youtu.be/BRTOlPdyPYU
It’s a bit like learning to program, but without a compiler as the referee or the domain constraints. Maybe that’s where we should put more energy if learning to think is the goal, though I don’t know what could replace the purely logical and verifiable qualities of programming. That isn’t so readily available with philosophy, for better or worse.
We do need people to practice thinking and self-interrogation far more than we do today.
I think a lot of people are turning to AI for this, which can be dangerous if they haven’t already developed these critical thinking skills.
The issue is probably that many managers can't really tell the difference between a good programmer and a vibe-coder. The vibe coder ships a lot of PRs. Maybe they themselves ship some vibe-coded PRs. They hate the idea that programmers might know better than them.
The layperson may be able to get ahold of a spellbook, but without Understanding it comes with high risk of turning your niece into a frog.
Whereas Wizards can cast increasingly powerful spells that build on each other, and make Art.
Both LLMs and divination methods also have the danger that someone could kind of drive themselves into madness with it. I don’t know too much about what how or why people can drive themselves crazy by chatting with an LLM, but with divination, I heard it can cause distress to ask the same questions about yourself many too frequently and also they ask about outcomes instead of methods.
You can also make LLMs agree with your own biases for some reason. For example, the people who use them to plan shady stuff.
Lev Grossman wrote an entire book that hinged on this idea of melding magic with technology.
https://en.wikipedia.org/wiki/Daemon_(novel)
Real Estate, it always boils down to real estate.
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.
My value was mainly relegated to making product decisions, and my technical interjections are increasingly optional and limited to preferences.
The idea that a human engineer will always add value as a steering role over an AI's shoulder is weaker every year, and we need to start planning for that not being the case.
I think we're at a point where bad developers are only producing bad code if they were too prescriptive.
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. 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.
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.
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...
Talk about driving people off a cliff
The mega-rich clowns firing everyone and then hiring back just those few that they realize they actually needed to keep after-the-fact are actually driving themselves right off that same cliff along with everyone else, and they don't even realize it. I bet money all this "AI" nonsense don't end up leadin' to the "Rich Guy Utopia" they think they're workin' toward. It's much more likely gonna just lead to a shittier world for everyone on Earth, rich and mega-ultra-totally-too-rich folk included. Wait'll the "AI bubble" bursts and see how much fun they have losin' zillions while pretty much everyone else lands in the "poor house" and comes lookin' to them for retribution. I suspect the guillotine is makin' a comeback sometime in the future.
I find the instantaneous thinking easier now. I can have several ideas in mind, and have a concrete implementation made for each, making it easier to compare alternatives. Although, since each problem is alone easier to think about, I do end up handling a greater number of problems. But I expect that my total volume of thinking is likely the same as before.
Where I do certainly feel more tired is when I try to solve too many problems in parallel. If I try to do that, I end up constently dropping context. So I generally try to finish a big chunk of something before switching (usually that means getting it ready for another code-review cycle).
I do miss writing code myself. It's certainly satisfying. It's just significantly slower in most cases. I try to do it in my free time.
I would ask what exactly are you comparing. I don't think I've ever wrote 2 versions of code to compare between each.
I've written exploratory code. A few lines to quickly inspect the behavior of module/function because it's undocumented. If something needs tuning, I surface the parameter in the interface, hook it to an harness to plot and manually tune.
I've also written alternative implementation of some feature, that later was abandoned.
But I've never written multiple versions of the same feature at the same time. I either model it (algorithm) or sketch it (interfaces or some other flow). It's way easier to interate with those than some demo/prototype code. The latter is when we settled on a solution and wants to fine tune it.
This also partially explains why I'm fond of Lisp. Paul Graham once said that while Lisp is a great language to work in, its real value comes as a language for thinking in.
Sorry what people would tolerate? Go look around and ask people, friends and family. They all hate slow bloated software, it costs us dunno how much in time and productivity. With the advent of LLMs it only got worse not better
If we end up with those being the kind of jobs you have to get to make a living as a programmer we could end up with programming a lot like sports.
You can enjoy playing basketball, say, as an amateur, and you can play more seriously in high school and college, but if you want to make a living playing basketball you need to be good enough to make the NBA.
Um no, you've gone too far.
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.
must be a Raku coder -Ofun
Senior people who already know how to code are doing OKish for now, from the data I've seen, but the job is increasingly babysitting models like they were junior contributors.
Not wrong. Probably.
I'm reminded of an old friend from long ago. She was an early music major at Harvard, and graduated with a MFA. She was very good. She read and wrote Latin and Greek, could compose and play music using medieval notations, and published a book on early needlepoint.
She never obtained an academic appointment. She never found a job that needed those skills. She died alone a few years ago.
That may be the fate of many programmers.
This sounds to me like a life well lived!
It will be fewer and fewer people with, probably, deeper and deeper knowledge (and job security and compensation to boot).
Poet is a bad comparison. But something like low-level semiconductor physics or assembly is closer to the mark.
How many horse farriers have you met? How many coopers, blacksmiths, or shoemakers?
How much did a horse farrier have to learn if they switched their employers?
Cobblers design, make and repair shoes of various kinds, boots for various purposes, slippers and moccasins with leather, cloth, rubber, and many kinds of threads using punches, knives, various machines, glues…
That is precisely the point. They still exist, but it is a far less common occupation than it once was.
So there will always be a point where people aren't willing to hire more software developers because there are enough already.
> Has it ever been?
Well… yes? So very many industries shrank, even disappeared in practical terms, because efficiency, automation and technological improvements. Industrial revolution? Calculators? Computerized accounting? I mean the list is giant.
I’m not saying I like that future, but I can imagine it.
LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs?
At some point you stopped needing to understand the layer down because the layer you were on became so good. Yes there are always corner cases, but for the vast majority of developers/engineers out there, staying at your layer was enough to make a career out of it once your layer hit a certain maturity.
The what is the semantic mapping between <some lang> and LLMs?
I know the semantic mapping between maching code and assembly (some light weight syntax manipulation and macros). I know the one between assembly and C (the C abstract machine, which is mostly about the stack and whatever call/ret instructions pair). I know the one between C and something like python (not so much different than the one between C and assembly in mechanism).
Please talk about how you go from A LLM prompt to a piece of code in Python and guarantee the intent remains unchanged.
In other words, superintelligence often referred to as AGI might either be months away or just VC-Money induced cult-speak many fall victim to.
It doesn’t matter because the only certainty is that it’s not here now, and neither tomorrow etc.
For coding you still need to be in control if you want a good result.
nothing prevents people from committing their prompts. I've started seeing prompts being committed into repos, or at least as part of the commit message.
In any case, if in the future there's a prompt specific language, it would be committed. I dont think we've reached there yet, but i dont doubt this is on the path to the future.
You mean, like a ... programming language? Honestly I can't tell these days what is satire and what isn't.
People keep trying to make that analogy, but it doesn't really work because LLMs aren't deterministic like compilers and assemblers.
They’re not reproducible, nor are they even reliable right now.
Regardless, you can make them deterministic by turning the temperature down to zero. Just nobody likes doing that for whatever reason. I guess it ruins some sort of illusion people seem to like.
But it is a requirement for them to be an "abstraction just like" assemblers or compilers.
I work at a certain level, like Ruby code. That's what I write, debug and maintain. I don't really care about the internals of the interpreter or about the source code of Linux, because these layers are taken care of, they're reliable and they're being developed by competent people. I [think I] know what Ruby code should look like in order to remain [reasonably] fast, maintainable and reliable, and it's my job to build a product out of that kind of code. If I keep writing code like that, I know for sure that I'll be able to keep building the product, because the layers underneath are deterministic. It's like the certificate chain of trust, but with "surely these people are not idiots". And that's simply not the case with LLMs.
Not only can the LLM be a massive idiot, but also an unpredictable one. I can try to warn it, steer it, police it or review as much as you ask me to, but ultimately you're asking me to delegate my job and my responsibilities to an intermediate whose reasoning I don't understand, who has no loyalty, no sense of pride, no sense of ethics, can't be taught and can't be fired.
(Which is pretty much what determinism would get us, but in these conversations way too many people seem not to understand what determinism is, so describing it in terms of actions the developer takes might work better?)
I just don't see that, not least of all because natural language is inherently ambiguous, whereas all the other rungs in your latter ("machine code -> assembly -> C/JVM -> some lang") are completely unambiguous by design. Consider "I saw the man with the binoculars". Does that mean "I used binoculars to look at the man", or "The man I looked at was holding binoculars"? This is the kind of inherent ambiguity that Lojban was invented to mitigate. Maybe some day we'll write "natural" language prompts in Lojban that can be unambiguously translated by an LLM, but that sounds a lot like just using a "some lang".
Knowing how to code (and more generally software engineering and other roles in software teams) is definitely still extremely useful, but is rapidly becoming less vital as a human-provided skill as models and harnesses greedily hoover up the knowledge margin.
I mean it might. But I wouldn't rule out Jevon's paradox where the increased efficiency increases demand.
Build more roads, congestion gets worse. Make developers more efficient, demand for developers increases. I wouldn't be surprised if demand for bespoke software goes up.
Learning to code is not merely learning a syntax and some tooling. It’s best described in the SICP and HTDP books, as a mindset of formalizing a process enough that a dumb machine could do it. Then by building abstractions towers, we have better symbols and semantics to notate the formal aspect.
It seems that a lot of management no longer wants to provide workflows tooling to their users. Instead they want to create a wish box where those workflows would materialize somehow.
Where is the data? There is no data but a lot of vibes, from the data I have seen
Contra: I'm reading digital circuits and introductory FPGA programming books this summer - fullstack development for the robotics dominated future here I come ;) Granted some EE classes in your old major will help. But modern digital circuits and embedded hardware space also have a lot of similarity to your muscle memory as a software developer.